Décider avant d'outiller

Le réflexe qu’il faut désapprendre

Face à une tâche répétitive, le réflexe le plus courant est de chercher l’outil qui va la prendre en charge. C’est une erreur de méthode, pas seulement de calendrier. Un outil bien choisi appliqué à un mauvais candidat produit le même résultat qu’un mauvais outil appliqué à un bon candidat : une dépense qui se répète et, un jour, quelqu’un qui doit comprendre pourquoi un workflow s’est arrêté sans que personne n’y ait touché depuis des mois. Décider ce qui mérite d’être automatisé précède toujours le choix de la plateforme. C’est le fil qui tient tout le reste du cours : la fascination pour l’outil est une erreur, la décision se prend avant l’outillage.

Décrire le processus tel qu’il est réellement exécuté

La première tâche n’est pas de choisir un outil, c’est de décrire. Et décrire un processus, ce n’est pas relire la procédure qui dort dans un wiki d’entreprise : c’est observer ce qui se passe réellement, avec ses détours et ses exceptions que personne n’a jamais documentés. Un processus « officiel » et un processus « réel » divergent presque toujours, et c’est dans cet écart que se cachent les tâches qui valent d’être automatisées, ou celles qui révèlent qu’un autre problème doit être réglé avant.

Décrire correctement, c’est répondre à cinq questions. Qui exécute chaque étape, et avec quelles compétences. Quelles sont les étapes, dans quel ordre, et lesquelles sont parfois sautées. Quelles données circulent, sous quel format, et où elles atterrissent. Quels outils interviennent, y compris le tableur oublié que personne ne cite en réunion mais que tout le monde utilise. Et surtout, quelles sont les exceptions, les cas particuliers, les situations où quelqu’un déroge à la règle parce qu’elle ne prévoyait pas ce cas. Un processus sans exception documentée n’est pas un processus simple, c’est un processus mal observé.

Mesurer avant de juger

Une fois le processus décrit, il faut le mesurer. L’intuition ment souvent sur ce qui coûte du temps : la tâche la plus visible n’est pas toujours la plus coûteuse, et la plus irritante n’est pas toujours la plus fréquente.

Quatre indicateurs suffisent à objectiver la décision. La fréquence : une fois par semaine et une fois par heure ne relèvent pas du même arbitrage, même si la tâche est identique. Le volume : le nombre d’occurrences par période détermine si l’effort de construction sera amorti. Le temps passé, mesuré sur un échantillon réel plutôt qu’estimé à la louche sur le souvenir qu’en garde la personne qui l’exécute. Le taux d’erreur : une tâche répétitive exécutée par un humain fatigué produit un taux d’erreur non nul, et ce taux a un coût, qu’il s’agisse d’une relance client en double ou d’une facture mal calculée.

Ces quatre chiffres, réunis, permettent de comparer des candidats sur une base commune plutôt que sur l’agacement qu’ils suscitent. Un processus rare et agaçant reste souvent moins prioritaire qu’un processus fréquent et silencieux.

La grille « automatiser ou pas »

Une fois le processus décrit et mesuré, cinq critères permettent de trancher.

La stabilité des règles : un processus dont les règles changent chaque trimestre coûtera plus cher à maintenir qu’à exécuter à la main. La volumétrie : en dessous d’un certain nombre d’occurrences, le temps de construction dépasse le temps économisé. La criticité : un échec silencieux sans conséquence n’exige pas la robustesse qu’exige un processus qui déclenche un paiement ou une décision opposable à un client. Le coût de maintenance : un workflow n’est jamais un projet fini, c’est un objet qui vieillit avec les API qu’il consomme, et quelqu’un doit rester responsable de sa santé dans la durée. La dépendance créée : automatiser revient souvent à rendre le processus dépendant d’un compte ou d’une personne qui seule sait comment le workflow fonctionne, un coût qui n’apparaît qu’au moment où cette dépendance se rompt.

Ces cinq critères ne donnent pas une réponse binaire. Ils offrent une base d’arbitrage partagée, qui permet de discuter d’un candidat sans se limiter à l’intuition de la personne la plus convaincante dans la pièce.

Ce qu’il ne faut jamais automatiser

La question la plus utile de ce chapitre n’est pas « comment automatiser », c’est « qu’est-ce qu’il ne faut pas automatiser ». Trois catégories méritent une prudence systématique.

Les processus instables, dont les règles changent au gré des décisions commerciales ou réglementaires : automatiser trop tôt revient à figer une organisation qui n’a pas fini de se stabiliser, et à payer deux fois, pour construire puis pour reconstruire.

Les cas rares, croisés une poignée de fois par an : leur coût de traitement manuel reste souvent inférieur au coût de conception d’une automatisation dédiée, sauf si leur criticité individuelle est très élevée.

Les décisions qui engagent la responsabilité de l’organisation, en particulier quand elles produisent un effet juridique ou affectent significativement une personne. Un refus de prestation, une décision de recrutement, une évaluation qui conditionne un droit : ces décisions supportent l’aide d’un outil, mais ne se délèguent pas entièrement à un système automatisé sans validation humaine effective. Ce n’est pas qu’une prudence de bon sens, c’est une exigence qu’on retrouvera au chapitre 4 sous sa forme réglementaire.

Ce qu’il faut retenir

Cartographier, mesurer, passer à la grille : ces trois étapes précèdent toute discussion d’outil, et produisent un résultat concret, une liste de candidats classés par valeur et par risque. Reste une question que ce chapitre n’a pas tranchée : sur quoi repose une automatisation solide, une fois le candidat choisi. C’est l’objet du chapitre suivant, consacré aux socles de données sur lesquels tout le reste s’appuie.