Quand une tâche est lente, répétitive ou pénible, la première idée qui vient est toujours la même : automatisons-la. Avec l’IA, la tentation est plus forte encore. Lire un email, en extraire les informations, enrichir une fiche, générer une réponse, mettre à jour un CRM, déclencher une action sans intervention humaine — tout cela est devenu techniquement accessible en quelques heures de travail. La question n’est presque plus peut-on le faire ? mais combien de temps ça prend ?
C’est précisément là qu’on se trompe. Parce qu’une autre question devrait toujours passer avant :
Le workflow que je m’apprête à automatiser mérite-t-il seulement d’exister ?
Automatiser ne corrige pas, ça fige
Un processus mal conçu porte ses défauts en lui. Des étapes qui ne servent plus, des validations redondantes, des saisies multiples de la même donnée, des décisions prises trop tard. Quand on l’automatise sans l’avoir remis en cause, on ne supprime aucun de ces défauts — on les exécute simplement plus vite.
Une donnée inutile est désormais collectée automatiquement. Une validation sans valeur se déclenche instantanément. Une information erronée circule plus efficacement dans toute l’organisation. Et le pire, c’est l’impression de progrès : l’automatisation marche, elle tourne, elle produit des logs verts. On a le sentiment d’avoir avancé, alors qu’on vient de couler dans le béton une organisation imparfaite. Le mauvais processus est maintenant rapide, silencieux et beaucoup plus difficile à corriger.
C’est la même erreur que je décris depuis le début de cette série : confondre la vitesse d’exécution avec la qualité de la décision. L’IA accélère. Elle n’arbitre pas à notre place ce qui mérite d’être accéléré.
Commencer par dessiner ce qui se passe réellement
Avant d’écrire la moindre ligne d’automatisation, il faut faire un travail bien moins spectaculaire : décrire honnêtement le processus existant, sans l’embellir. Qui le déclenche ? Quelles données entrent ? Qui vérifie quoi ? Où ces données sont-elles recopiées, et combien de fois ? Quelles décisions sont réellement prises ? Quelles étapes attendent un humain — et pour quelle raison ? Quelles sorties sont vraiment utilisées en aval ?
Ce simple relevé révèle presque toujours la même chose : le problème n’est pas l’absence d’automatisation, mais l’accumulation historique de petites habitudes que plus personne ne questionne. Une case cochée « au cas où ». Une pièce jointe que personne n’ouvre. Une validation instaurée après un incident vieux de trois ans et jamais retirée.
Chez nous, cette discipline a un nom : audit-first. On ne code pas l’automatisation à la volée. On décrit et on audite le workflow existant avant. Ce n’est pas un principe abstrait — c’est outillé. Nos migrations passent par des procédures structurées dédiées, migrate-job et migrate-api-route, dont la première étape n’est jamais « écris le nouveau code » mais « cartographie précisément l’ancien ». On ne réécrit rien qu’on n’ait d’abord compris.
Supprimer, simplifier, standardiser — puis seulement automatiser
De cet audit découle un ordre d’opérations que je tiens pour non négociable. Il n’a rien d’intuitif, parce qu’il repousse l’automatisation à la toute fin :
- Supprimer ce qui ne sert plus. La première question n’est pas « comment automatiser cette étape ? » mais « peut-on la retirer purement et simplement ? »
- Simplifier ce qui reste. Fusionner deux validations en une, éliminer les saisies en double.
- Standardiser les entrées et les sorties. Une automatisation ne survit pas à des formats qui changent à chaque cas.
- Automatiser — mais seulement les étapes devenues stables et répétables.
- Garder l’humain là où il crée réellement de la valeur : le jugement, l’exception, la relation.
Ce que j’observe, c’est qu’en pratique on obtient souvent moins d’automatisation qu’au départ, et beaucoup plus d’efficacité. L’objectif n’a jamais été le workflow le plus impressionnant. C’est celui qui atteint un bon résultat avec le moins d’actions possible.
L’IA comme analyste de processus, avant d’être un exécutant
Voilà l’usage que je trouve le plus sous-estimé : se servir de l’IA avant toute ligne de code, comme analyste. On lui fournit la description du processus, quelques captures d’écran, des exemples de données réelles, la liste des problèmes rencontrés. Et on lui demande de contredire, pas de construire :
- Quelles étapes te semblent redondantes ?
- Quelles informations pourrait-on cesser de collecter sans rien perdre ?
- Où sont les risques d’erreur les plus probables ?
- Quelles décisions exigent réellement un humain ?
- Quelles étapes gagneraient à être fusionnées ?
- Quelles exceptions rendraient cette automatisation fragile ?
Un modèle capable de tenir tout le contexte d’un processus repère des incohérences que l’habitude nous cache. Ce n’est pas la même IA qui fait et qui questionne — et c’est très bien ainsi. Faire analyser un workflow avant de l’industrialiser coûte quelques minutes ; le détricoter une fois automatisé de travers coûte des semaines.
Une automatisation ne doit jamais devenir une boîte noire
Il y a un piège dans lequel je refuse de tomber : l’automatisation opaque. Un système qui déclenche des actions sans qu’on puisse dire pourquoi est une dette, pas un actif — même quand il fonctionne.
Pour chaque étape automatisée, on doit pouvoir répondre : pourquoi cette action a-t-elle été déclenchée ? Sur quelles données ? Quel modèle, ou quelle règle, a pris la décision ? Et surtout — comment un humain reprend-il la main s’il le faut ? Plus un processus est critique, plus cette traçabilité doit être forte. Une automatisation qu’on ne peut ni expliquer ni interrompre n’est pas un gain de contrôle : c’en est l’abandon.
Cette exigence a une conséquence pratique : on ne peut pas empiler les automatisations à l’aveugle. Notre planificateur de tâches récurrentes fait tourner de l’ordre d’une cinquantaine de jobs actifs — synchronisations, collectes, calculs en temps réel. Ce parc n’est pas une collection qui grossit toute seule : c’est un inventaire qu’il faut connaître, revoir et parfois élaguer. Un workflow automatisé qu’on oublie devient un coût silencieux, exactement comme la dépendance morte ou la clé d’API orpheline dont je parlais dans un précédent article.
Le meilleur workflow est parfois celui qui disparaît
J’insiste sur ce point parce qu’il est contre-intuitif : l’un des meilleurs résultats possibles d’un audit, c’est de découvrir qu’un processus n’a plus besoin d’exister. L’information qu’il produisait est déjà disponible ailleurs. La validation qu’il portait peut être remplacée par une règle simple. L’étape entière est absorbée par un outil qu’on possède déjà. Dans ces cas-là, ne rien automatiser du tout est une réussite — pas un échec.
C’est cette logique qui a présidé à nos plus gros chantiers. Notre migration de Heroku vers Scaleway n’a pas démarré sur une impulsion technique ni sur l’envie d’automatiser pour automatiser. Elle a été décidée sur audit : on a d’abord cartographié l’existant, service par service, pour savoir ce qui devait migrer, ce qui devait être simplifié, et ce qui pouvait simplement disparaître. La décision est venue après la compréhension, jamais avant.
Automatiser un mauvais processus, c’est le rendre définitif. Le comprendre d’abord, c’est se donner le droit de le supprimer. L’IA est un formidable exécutant — mais sa valeur la plus rare, c’est de nous aider à décider quels processus méritent encore d’exister.
Et chez vous — combien de vos automatisations existent parce qu’elles créent de la valeur, et combien parce que personne n’a jamais osé remettre le workflow en cause ?