La plupart des projets d’automatisation ne meurent pas d’un manque de technologie. Ils meurent d’un excès d’ambition. On veut tout automatiser, tout de suite, on touche à dix processus à la fois, et au premier grain de sable, plus rien ne tient. L’équipe revient aux vieux réflexes, le bel outil prend la poussière, et la conclusion qu’on en tire est fausse : on se dit que l’automatisation ne marche pas chez nous, alors que c’est la méthode qui était mauvaise.

Depuis 2019, je conçois des systèmes d’automatisation sur mesure avec NS Corp, pour des PME comme pour des structures plus grandes. La leçon la plus utile que j’en tire tient en une phrase : on n’automatise pas une intention, on automatise un processus qu’on a d’abord compris. Voici la méthode que j’applique, en quatre temps.

1. Choisir le bon processus, pas le plus voyant

Le réflexe naturel est de viser ce qui agace le plus, la tâche que tout le monde déteste. C’est rarement le bon point de départ, parce que les tâches les plus pénibles sont souvent les plus complexes et les plus pleines d’exceptions.

Le premier processus à automatiser doit cocher trois cases. Il est répétitif, donc le gain est récurrent. Il est stable dans le temps, donc on ne va pas redévelopper tous les trois mois. Et son résultat est facile à vérifier, donc une erreur se voit tout de suite.

Une saisie quotidienne, toujours identique, dont on contrôle le résultat d’un coup d’oeil : excellent candidat. Un processus qui change selon le client, le mois et l’humeur du marché, et dont l’erreur ne se révèle que trois semaines plus tard dans la comptabilité : très mauvais candidat pour un premier pas. On y viendra, mais plus tard, une fois la confiance installée.

2. Cartographier avant d’écrire la moindre ligne

C’est l’étape que tout le monde veut sauter, et c’est celle qui décide du succès. Avant de coder quoi que ce soit, on dessine le processus tel qu’il existe vraiment. Pas tel qu’il est censé exister dans une procédure oubliée. Qui fait quoi, dans quel ordre, avec quelles décisions, et surtout avec quelles exceptions.

Ce travail révèle presque toujours une surprise. La moitié des soi-disant problèmes techniques sont en réalité des processus que personne n’avait jamais posés clairement. Deux personnes font la même tâche différemment. Une étape officielle a été contournée depuis des mois. Une règle qu’on croyait absolue souffre en fait de cinq exceptions. Tant que ce flou existe, aucune automatisation ne tiendra, parce qu’on automatiserait une fiction.

Cartographier, c’est donc d’abord clarifier. Et cette clarté a de la valeur même si on n’automatise rien derrière.

3. Automatiser par tranches, en gardant l’humain dans la boucle

On n’éteint jamais l’ancien système le jour où le nouveau démarre. C’est le plus sûr moyen de tout perdre au premier imprévu.

On fait tourner les deux en parallèle pendant un temps. La machine propose, l’humain valide, on compare les résultats. Tant qu’ils divergent, on garde le filet et on corrige. Quand ils convergent de façon stable, sur plusieurs semaines, on retire progressivement le filet. Cette prudence n’est pas de la lenteur, c’est de l’assurance. Elle fait qu’un projet survit au premier cas tordu au lieu de s’effondrer.

Je vois souvent des dirigeants impatients à cette étape, qui voudraient basculer d’un coup pour toucher le gain plus vite. Je leur réponds toujours la même chose : le gain d’une automatisation, ce n’est pas la vitesse à laquelle on la lance, c’est la durée pendant laquelle elle tient. Une bascule brutale qui casse au bout d’un mois ne fait gagner rien du tout.

4. Prévoir l’exception, pas seulement le cas idéal

Un processus réel est plein de cas particuliers. Le client qui paie autrement, le fournisseur qui envoie un format bizarre, le mois où tout déborde. Une automatisation qui ne gère que le cas idéal crée plus de travail qu’elle n’en enlève, parce que chaque exception devient une urgence qu’il faut traiter à la main, dans la précipitation.

La règle est simple : une bonne automatisation sait reconnaître ce qu’elle ne sait pas traiter, et le remonter proprement à un humain, plutôt que de forcer une réponse. C’est moins spectaculaire qu’une démo parfaite où tout glisse, mais c’est précisément ce qui tient en production. On ne juge pas un système à sa démo, on le juge à sa façon de gérer le jour où ça ne se passe pas comme prévu.

L’erreur de cadrage qu’on me demande le plus de réparer

Pour finir sur du concret, voici le scénario qui revient le plus quand on m’appelle pour rattraper un projet. Une entreprise a voulu automatiser un grand bout de son activité d’un seul tenant, séduite par une promesse de transformation. Six mois plus tard, l’outil est à moitié utilisé, les équipes ont gardé leurs anciennes habitudes en parallèle, et plus personne ne sait quelle version de l’information fait foi.

La réparation passe rarement par plus de technologie. Elle passe par revenir en arrière, isoler un processus simple, le faire marcher vraiment, et reconstruire la confiance à partir de là. Automatiser, au fond, ce n’est pas remplacer les gens par du code. C’est leur retirer les gestes répétitifs pour leur rendre du temps de décision. On commence petit, sur un terrain compris, on garde l’humain à portée de main, et on étend une fois la confiance gagnée. Ceux qui font ça réussissent. Ceux qui veulent tout, tout de suite, n’ont rien.