Un process Excel qui fonctionne peut quand même coûter cher.

Pas en argent, en énergie. Et ce coût-là est rarement signalé, parce qu'il s'est installé progressivement. Une étape ajoutée pour régler un incident. Une colonne créée en urgence. Une validation manuelle qui compensait un manque de structure dans le fichier. Chaque ajout avait sa logique d'origine — mais l'ensemble n'avait jamais été relu à froid. Résultat : un process que personne ne questionnait, parce que ça avait toujours été comme ça.

"Ça a toujours été comme ça" est la phrase la plus coûteuse de n'importe quelle organisation.

C'est ce que j'ai observé. Ce n'était pas mon périmètre. Mais j'ai appris à me méfier de cette frontière-là.

Ce qui a suivi — une phase d'écoute, beaucoup de suppression, et des macros Excel ciblées — a permis de réduire de 50% la durée du process. Sans migrer vers un nouvel outil, sans stack no-code, sans budget.

Voici comment.

L'observation

Un process qui tourne depuis longtemps finit par devenir invisible.

Les gens qui l'exécutent savent où il frotte. Ils connaissent les raccourcis informels, les étapes qu'ils font en automatique sans vraiment y penser, les allers-retours inutiles qu'ils ont appris à anticiper. Mais parce que ça "fonctionne" — les données entrent, les calculs sortent, les délais sont tenus — personne ne le questionne officiellement.

Ce type de friction est rarement signalé. Pas parce que les utilisateurs ne la ressentent pas. Parce qu'elle s'est installée progressivement, jusqu'à devenir le rythme normal du travail. Et remettre en cause ce qui "a toujours été comme ça" demande une énergie que la plupart des gens n'ont pas envie de dépenser sur quelque chose qui n'est pas en crise.

Intervenir n'était pas dans mon périmètre. J'ai quand même posé des questions.

Ce que j'ai trouvé

Avant de cartographier quoi que ce soit, j'ai passé du temps à comprendre le contexte dans lequel ce process avait été construit : les contraintes de l'équipe, l'absence de budget pour migrer, le niveau de confort variable avec Excel. Ces paramètres n'étaient pas des obstacles — ils définissaient ce qui était réellement faisable.

Ce que j'ai trouvé en cartographiant les étapes : un process construit par couches. Des informations ressaisies alors qu'elles existaient déjà dans le fichier Excel. Des validations manuelles qui compensaient un manque de structure plutôt qu'une vraie nécessité de jugement humain. Une architecture pensée pour stocker les données, pas pour les faire circuler.

Le diagnostic était clair : ce n'était pas un problème d'outil. C'était un problème de conception que l'outil avait progressivement absorbé. Aller directement aux macros aurait automatisé ce problème de fond — pas résolu.

C'est l'erreur la plus répandue en optimisation de process : mélanger la définition du problème et sa résolution. Bâcler le diagnostic pour aller vite vers la solution, c'est travailler dur pour aller dans la mauvaise direction. Beaucoup d'équipes finissent avec un process automatisé qui va deux fois plus vite dans le mauvais sens.

Retirer avant d'automatiser

La tentation naturelle, c'était d'aller directement aux macros.

J'avais identifié les frictions, je voyais où l'automatisation pouvait s'appliquer. Mais automatiser un process mal structuré, c'est juste aller plus vite dans le mauvais sens. Les mêmes problèmes reviennent, plus rapidement.

J'ai posé une règle simple : rien ne s'automatise avant d'avoir été simplifié.

Ce qui m'a frappée dans cette phase, c'est que retirer est systématiquement plus difficile qu'ajouter. Ajouter une étape répond à un problème visible. Retirer une étape oblige à reconnaître qu'un problème passé n'existe plus — ou que la solution crée plus de friction qu'elle n'en résout. Sans discipline explicite de suppression, n'importe quel process bureaucratise son terrain, couche après couche.

Concrètement : supprimer les étapes sans raison d'être, réorganiser la structure pour que l'information circule sans allers-retours, réduire les champs à remplir manuellement. Certaines choses que les utilisateurs faisaient par habitude — pas parce que c'était nécessaire.

Cette phase a pris plus de temps que l'automatisation elle-même. Et c'est elle qui a produit le plus de gains.

Ce que les macros ont fait (et pas fait)

Les macros n'ont pas tout résolu. C'était voulu.

Le périmètre était défini par une contrainte claire : les utilisateurs devaient pouvoir comprendre ce que l'outil faisait, et intervenir dessus sans aide technique. Une solution que personne ne maîtrise crée une nouvelle dépendance — on a juste déplacé le problème.

Les macros ont donc pris en charge les tâches à zéro valeur ajoutée : celles que les utilisateurs exécutaient en automatique, sans réflexion, qui consommaient du temps sans solliciter leur jugement. Mise en forme, consolidation, déclenchement de calculs déjà présents dans le fichier.

Ce qu'elles n'ont pas touché : les étapes qui demandent une lecture humaine, une validation, une décision. Ces moments sont restés manuels — non par manque de moyen, mais parce que c'est là que la valeur humaine se joue vraiment. Automatiser le jugement pour gagner cinq minutes, c'est une mauvaise optimisation.

Résultat : un outil que les utilisateurs comprennent encore. Ils savent ce que les macros font. Ils savent où intervenir. L'outil leur appartient toujours, il est juste moins épuisant à utiliser.

Le résultat et la vraie leçon

Au final : -50% sur la durée du process Excel.

Pas grâce à un nouvel outil. Pas grâce à une stack no-code sophistiquée. Grâce à une phase d'écoute sérieuse, une simplification structurelle, et des macros Excel ciblées sur ce qui avait le moins de valeur à faire manuellement.

Ce qui m'a le plus marquée dans cette expérience : les utilisateurs connaissaient les frictions depuis longtemps. Ils n'attendaient pas une solution miracle. Ils avaient juste besoin que quelqu'un décide que le problème méritait d'être résolu et que ce quelqu'un agisse sans attendre d'y être officiellement désigné.

L'idée n'est jamais la ressource rare dans une organisation. Ce qui est rare, c'est la personne qui décide de porter le problème envers et contre le confort de l'inaction.

Avant de chercher quel outil va régler ton process, assure-toi d'avoir compris pourquoi il ressemble à ça aujourd'hui. La plupart du temps, la majorité du gain se trouve dans ce qu'on retire, pas dans ce qu'on ajoute. Et aucun outil ne fera ce travail à ta place.

Un process qui "fonctionne" peut quand même coûter cher, est-ce que tu mesures vraiment ce qu'il te coûte en énergie humaine ?

Localisation

Le Mans, France

Contacts

ashlyne@qiveo.co

Qiveo
Je vois ce que les équipes ont normalisé. Je le questionne. J'écris ce que ça donne.

© 2026 Qiveo