Arrêtez de vouloir tout automatiser (certaines choses doivent rester manuelles)

Le culte de l'automatisation

Il y a quelque chose de religieux dans la façon dont on parle d'automatisation. Un process qui n'est pas automatisé est vu comme un process immature. Une équipe qui fait encore quelque chose à la main est vue comme une équipe qui n'a pas "mûri". Le vocabulaire lui-même est révélateur : on ne dit pas "nous avons automatisé ce process", on dit "nous avons enfin automatisé ce process". Comme si le manuel était une étape honteuse qu'il fallait dépasser.

Ce réflexe a une origine rationnelle. L'automatisation a permis des gains de productivité considérables, dans tous les secteurs. Elle a supprimé des tâches pénibles, répétitives, sans valeur ajoutée. Elle a rendu possibles des choses qui ne l'étaient pas. Personne de sérieux ne conteste ça, et cet article ne va pas le contester non plus.

Mais entre "l'automatisation est puissante" et "tout ce qui peut être automatisé doit l'être", il y a un pas. Un pas que beaucoup franchissent sans y penser, parce que la pression culturelle va dans ce sens, et parce que le coût de l'automatisation est souvent invisible là où son bénéfice est très visible.

Ce que l'automatisation fait vraiment bien

Soyons honnêtes sur ce point avant de critiquer. L'automatisation excelle dans un certain nombre de cas bien précis :

• Les tâches répétitives et déterministes. Un script qui déploie une application à chaque commit, c'est mille fois mieux qu'un humain qui tape les mêmes commandes en espérant ne pas se tromper.
• Le volume. Traiter 500 000 lignes de log, personne ne veut faire ça à la main. Une machine le fait en quelques secondes, sans se fatiguer.
• Ce qui doit tourner la nuit. Les sauvegardes, la surveillance, les alertes. La machine ne dort pas, ne prend pas de vacances, ne tombe pas malade.
• Ce qui doit être reproductible. Un pipeline de CI qui fait toujours la même chose dans le même ordre, c'est de la fiabilité. Pas de "ah mince, j'ai oublié une étape".

Dans ces cas-là, automatiser n'est pas une question de mode. C'est une évidence. Le débat n'est pas là.

Ce qu'elle fait mal (et qu'on ne veut pas voir)

Là où ça se complique, c'est quand on automatise des choses qui ne sont pas répétitives, déterministes, ou massives. Des choses qui reposent sur du jugement, du contexte, de la relation, ou de l'ambiguïté. Dans ces cas-là, l'automatisation ne supprime pas la tâche : elle la déplace, et souvent elle la dégrade.

Prenons un exemple simple. Une revue de code automatisée avec un linter, c'est utile. Ça attrape les virgules mal placées, les variables non utilisées, les conventions oubliées. Mais si on remplace la revue humaine par la revue automatisée, on perd exactement ce qui fait la valeur d'une revue de code : la question "est-ce que cette approche est la bonne pour ce problème ?". Un linter ne pose pas cette question. Il ne sait pas la poser. Il n'a pas le contexte.

Le piège de la dette d'automatisation

On parle beaucoup de la dette technique. On parle moins de la dette d'automatisation. C'est pourtant la même logique : un outil automatique qu'on met en place pour gagner du temps, qu'on ne maintient pas, qu'on ne documente pas, et dont personne ne se souvient du fonctionnement quand il tombe en panne.

Combien d'équipes ont un script critique qui tourne depuis 2019, écrit par quelqu'un qui est parti depuis, sans documentation, sans tests, et que personne n'ose toucher parce qu'"on ne sait pas ce que ça fait exactement" ? Ce script est devenu une boîte noire dont dépend une partie du système. Ce n'est plus de l'automatisation. C'est de la dépendance.

Le paradoxe, c'est qu'on a souvent automatisé précisément pour ne plus avoir à s'en occuper. Sauf que ce qu'on a gagné en temps d'exécution, on le paie en temps de compréhension le jour où ça casse. Et ce jour-là arrive toujours.

Automatiser ce qu'on ne comprend pas encore

C'est le piège le plus vicieux, et probablement le plus répandu. On a un process qu'on ne maîtrise pas complètement, on décide de l'automatiser "pour aller plus vite", et on encode dans l'outil nos incompréhensions actuelles. Résultat : on produit de manière consistante des résultats faux, sans point de friction pour s'en apercevoir.

Un process manuel a un avantage caché : il oblige à le traverser, étape par étape, avec un humain qui comprend (ou essaie de comprendre) ce qui se passe. Quand quelque chose cloche, on le voit. Un process automatisé, quand il est mal compris, fait ce qu'on lui a dit de faire, même si c'est absurde. Et il le fait à grande échelle.

C'est pour ça qu'une bonne règle est souvent : d'abord faire à la main, comprendre ce qu'on fait, puis automatiser. Dans cet ordre. Pas l'inverse. L'inverse produit des usines à gaz que personne ne sait plus démonter.

"Nous savons plus de choses que nous ne pouvons en dire."

Cette phrase de Polanyi dit quelque chose d'essentiel pour notre sujet. Une grande partie de ce qu'on sait faire, on ne sait pas l'expliquer. C'est du savoir tacite, de l'intuition professionnelle, du "je le sens quand c'est prêt". Ce savoir ne se laisse pas facilement formaliser, et donc difficilement automatiser. Quand on automatise quelque chose qui repose en partie sur ce type de savoir, on capture la partie explicite et on perd tout le reste, sans toujours s'en rendre compte.

Trois exemples concrets

Le recrutement. Les filtres automatiques de CV sont devenus la norme dans beaucoup d'entreprises. Ils promettent de traiter plus de candidatures, plus vite. En pratique, ils filtrent souvent sur des critères qui reproduisent les biais existants, et ils éliminent précisément les profils atypiques qui apporteraient quelque chose. Personne ne recrute plus mal intentionnellement, c'est juste que la machine fait ce qu'on lui a dit de faire, et qu'on lui a dit de faire une chose qu'on n'aurait pas dû lui demander.

Le support client. Un chatbot qui traite 80 % des demandes, c'est un très bon chiffre sur une slide. Sauf que les 20 % restants sont souvent les cas les plus importants : les clients mécontents, les situations complexes, les demandes inhabituelles. Automatiser les 80 % faciles pour concentrer l'humain sur les 20 % difficiles, c'est une bonne idée. Automatiser la première ligne de support pour tout le monde, c'est envoyer tous les utilisateurs, y compris les plus fragiles, vers une machine qui ne saura pas les aider.

L'écriture. On peut générer un article, un email, une documentation avec un outil. Le texte produit sera grammaticalement correct, structuré, propre. Mais il n'aura pas ce qui fait la différence : un point de vue, une voix, une expérience vécue. C'est exactement le même constat que dans l'article sur le PO. L'outil remplit, il n'écrit pas.

Ce que l'humain apporte, et que la machine ne remplacera pas

Il y a trois choses que je vois revenir systématiquement quand on essaie de remplacer une tâche humaine par une tâche automatisée :

La présence. Quand quelqu'un vous écrit pour un problème, il ne cherche pas seulement une réponse. Il cherche à être entendu. Une machine peut fournir une réponse, elle ne peut pas fournir une présence. Et dans beaucoup de situations, la présence est la moitié du service.

Le jugement. La capacité à dire "en fait, ce n'est pas ça qu'il faut faire". À repérer qu'une demande, formulée d'une certaine façon, cache un autre besoin. À refuser une tâche. À proposer une alternative. Ce sont des choses qu'aucun outil ne fait bien, parce qu'elles demandent de sortir du cadre, et qu'un outil est précisément fait pour rester dans le cadre.

La responsabilité. Quand quelque chose se passe mal, il faut un humain à qui parler. Pas un formulaire, pas un ticket, pas un algorithme. Quelqu'un qui assume, qui explique, qui répare. C'est vrai dans le service client. C'est vrai dans le code. C'est vrai partout.

Et l'IA dans tout ça ?

On ne peut pas parler d'automatisation en 2026 sans parler d'IA. Et le parallèle est frappant. Les LLM sont des machines à produire du plausible. Ils génèrent du texte, du code, des idées, des plans, avec une fluidité qui donne l'impression d'une compréhension. Mais ils ne savent pas dire "je ne sais pas". Ils ne savent pas dire "ce n'est pas la bonne question". Ils produisent, toujours, avec la même assurance.

C'est pour ça que les usages les plus intéressants de l'IA aujourd'hui ne sont pas ceux où elle remplace l'humain. Ce sont ceux où elle amplifie un humain qui garde la main sur la décision. Un dev qui utilise un assistant pour écrire du code plus vite, mais qui relit, qui comprend, qui décide. Un designer qui génère des variantes mais qui choisit, qui arbitre, qui assume. L'IA propose, l'humain dispose.

Là où ça dérape, c'est quand on oublie ce partage. Quand on laisse l'outil décider, sous prétexte qu'il produit quelque chose de propre. Quand on confond vitesse de production et qualité du résultat. Quand on automatise, encore une fois, quelque chose qu'on ne comprend pas encore assez bien pour le déléguer.

Ce que cet article ne dit pas

Il ne dit pas qu'il faudrait revenir en arrière et tout faire à la main. Ce serait absurde. Il ne dit pas que l'automatisation est une mauvaise chose en soi. Elle est formidable, à sa place.

Il ne dit pas non plus que l'humain est toujours meilleur que la machine. Dans beaucoup de tâches, l'inverse est vrai, et depuis longtemps. Personne n'a envie de revenir aux fiches cartonnées pour gérer une base de clients.

Il ne dit pas, enfin, que le manuel est une vertu. Le manuel pour le manuel, c'est juste de l'inefficacité déguisée en authenticité. Ça n'a aucun intérêt.

Ce qu'il essaie de dire, c'est qu'il y a une question à se poser avant d'automatiser, et que cette question est rarement posée. Non pas "est-ce que je peux ?", mais "est-ce que je dois ?". Non pas "est-ce que ça va plus vite ?", mais "est-ce que je ne perds rien d'important en le faisant ?".

Automatiser, c'est un choix. Pas une évidence. Et comme tout choix, il mérite d'être posé consciemment, pas subi par réflexe culturel. Parfois, la bonne réponse est "oui, automatisons, on n'aurait pas dû attendre aussi longtemps". Parfois, la bonne réponse est "non, gardons ça à la main, ça a de la valeur". Les deux réponses sont défendables. Ce qui ne l'est pas, c'est de ne pas se poser la question.