Automatisation en PME : la question à poser avant l'outil

« On veut automatiser » n'est pas encore un projet

Un dirigeant de PME industrielle en forte croissance veut se recentrer sur la stratégie et se décharger de l'opérationnel. Il évoque des gains de temps ambitieux, des agents IA à différents endroits du process, une automatisation qui libérerait 60 à 70 % du temps aujourd'hui consacré à des tâches répétitives. Le projet paraît clair dans sa tête. Il ne l'est nulle part ailleurs : aucun des process critiques n'a encore été écrit noir sur blanc, y compris ceux qui portent le plus de risque, comme les contrôles de conformité effectués à la main.

Ce scénario se répète, presque à l'identique, dans une majorité de PME qui abordent l'automatisation par l'outil. « On veut automatiser » sonne comme un projet. C'est en réalité une intention, tant qu'elle n'a pas été traduite en une réponse précise à une question bien plus étroite : qu'est-ce que vous voulez, très concrètement, arrêter de faire.

Pourquoi l'automatisation par l'outil produit du chaos plus vite

Automatiser sans avoir répondu à cette question ne fait pas gagner de temps, ça accélère le désordre existant. Un process mal défini, exécuté par une personne qui connaît ses raccourcis et ses exceptions, reste un process qui fonctionne, même imparfaitement. Le même process, encodé dans un outil sans que ses raccourcis et ses exceptions n'aient été formalisés, devient un système qui échoue silencieusement sur les cas qu'il n'a jamais anticipés. La personne qui l'exécutait à la main savait s'adapter. L'outil ne le sait pas, sauf si on le lui a explicitement dit.

Le risque grandit avec l'ambition du projet. Un dirigeant pressé de se retirer de l'opérationnel a tendance à vouloir automatiser plusieurs étapes à la fois, avec des outils choisis pour leur rapidité de mise en place plutôt que pour leur cohérence d'ensemble. Le résultat est un empilement d'automatismes ponctuels qui ne parlent pas entre eux, chacun réglant un symptôme sans jamais toucher à la cause : l'absence d'un process écrit, validé, et partagé au-delà de la tête du dirigeant.

Ce scénario se rencontre particulièrement dans les structures où le dirigeant a lui-même porté toute la croissance, de deux à une dizaine de personnes en quelques années. Le savoir opérationnel n'a jamais eu besoin d'être écrit, parce qu'il vivait dans une seule tête, disponible à chaque question. C'est ce mode de fonctionnement, efficace à petite échelle, qui devient le vrai facteur limitant quand l'entreprise grandit : tant que ce savoir reste implicite, l'organisation reste une extension du dirigeant, et aucun projet d'automatisation ne peut réellement l'industrialiser.

« Nous, c'est plutôt ce qu'on essaie de les amener à faire, effectivement, de bien caler un cahier des charges. Déjà, rien que ça, souvent, c'est compliqué à réfléchir, à vraiment formaliser des besoins et cadrer un début de projet. »

Renoncer avant d'outiller : la question qui précède le choix d'outil

Chez Leando, ce principe s'appelle renoncer avant d'outiller : face à un dirigeant qui dit vouloir automatiser, la première réponse n'est jamais une liste d'outils, c'est une question : qu'est-ce que vous voulez arrêter de faire. Cette formulation n'est pas cosmétique. Elle oblige à nommer une tâche précise, avec ses étapes, ses exceptions, ses cas limites, plutôt qu'une intention générale de gagner du temps. Tant que la réponse reste floue, l'automatisation n'a rien à encoder : on ne peut pas arrêter de faire quelque chose qu'on n'a jamais décrit.

Ce que cette question force à clarifier

Répondre sérieusement à « qu'est-ce que vous voulez arrêter de faire » oblige à distinguer trois choses qu'une intention générale d'automatisation confond systématiquement : la tâche elle-même, ses variantes selon qui l'exécute, et les cas où elle ne se déroule jamais comme prévu. Une tâche qui change de forme selon la personne qui la fait n'est pas mûre pour être automatisée, elle a d'abord besoin d'être standardisée. Une tâche dont les exceptions ne sont pas listées produira un outil qui casse dès la première situation non anticipée, généralement dans les premières semaines d'usage.

Sur la manière de conduire cette structuration sans y consacrer des mois, notre approche lean de l'automatisation de processus métier détaille comment traiter un processus à la fois, avec un retour sur investissement mesuré dès les premières semaines plutôt qu'au bout d'un chantier de dix-huit mois.

Pourquoi cette étape se saute presque toujours

Formaliser une tâche avant de l'automatiser ne produit rien de visible à court terme, c'est précisément ce qui la rend facile à sauter. Un dirigeant pressé voit dans cette étape un délai supplémentaire avant le résultat qu'il attend, alors qu'elle est la condition pour que ce résultat existe réellement. L'écart se paie plus tard, sous une forme plus coûteuse : un outil livré, qui fonctionne sur le papier, mais que personne n'utilise parce qu'il ne correspond pas à la manière dont le travail se fait vraiment. À ce stade, le coût n'est plus seulement celui du temps perdu à formaliser après coup, c'est celui d'un outil à reprendre, voire à refaire.

Cette confusion se voit particulièrement sur les tâches qui touchent à la conformité ou à la sécurité produit : un contrôle encore réalisé par copier-coller entre deux fichiers, par exemple, porte un risque financier disproportionné par rapport à sa complexité apparente. Automatiser ce type de tâche sans avoir listé ses cas particuliers n'élimine pas le risque, il le déplace vers un système moins capable de s'adapter en cours de route qu'une personne expérimentée qui sait, sans se l'être jamais dit explicitement, dans quels cas ralentir et vérifier deux fois.

Sur la question complémentaire de la place laissée à l'humain pendant cette phase de transition, notre analyse de la distinction entre automatiser la création et automatiser l'exécution explique pourquoi aller trop vite dans l'automatisation produit souvent l'effet inverse de celui recherché.

Ce que ce principe ne dit pas

Renoncer avant d'outiller n'implique pas d'écrire l'intégralité des processus de l'entreprise avant de toucher à quoi que ce soit. C'est l'excès inverse, tout aussi coûteux : attendre une documentation exhaustive avant d'agir revient à ne jamais automatiser. Le principe demande seulement de formaliser la tâche précise qu'on a choisi d'arrêter, pas l'organisation entière. Sur un périmètre aussi ciblé, ce travail se fait en quelques jours, pas en quelques mois.

Il y a une manière simple de vérifier que la formalisation a atteint le bon niveau, ni trop vague, ni trop exhaustive : un collaborateur qui n'a jamais exécuté la tâche doit pouvoir la comprendre en lisant la description écrite, y compris les deux ou trois cas où elle dévie du chemin standard. Si ce collaborateur bute sur une question à laquelle la description ne répond pas, c'est le signal que la formalisation n'est pas encore terminée, pas que l'automatisation peut malgré tout démarrer en l'état.

Cette exigence peut sembler disproportionnée pour une tâche jugée mineure. Elle ne l'est pas : une tâche répétitive, même modeste dans son exécution unitaire, représente souvent, une fois cumulée sur un mois, un volume d'heures que personne n'a jamais additionné. C'est justement ce cumul invisible qui justifie l'investissement de quelques jours à l'écrire correctement, avant de la confier à un système qui ne rattrapera pas d'initiative ce qu'on aura oublié de lui préciser.

La prochaine fois que l'envie d'automatiser se présente, ne commencez pas par comparer des outils. Nommez la tâche que vous voulez arrêter de faire, avec ses variantes et ses exceptions. C'est cette réponse, pas la fiche technique d'un logiciel, qui détermine si le projet qui suit règle un vrai problème ou en crée un nouveau.