L’IA ne va pas accélérer vos processus (et c’est tant mieux)

On vous a vendu l’IA comme un turbo sur votre organisation. Branchez ça sur vos workflows, et tout va 3x plus vite. Moins de tâches répétitives, plus de valeur ajoutée, les équipes enfin libérées du quotidien ingrat. C’est séduisant. Et c’est faux — ou du moins, c’est une lecture tellement incomplète qu’elle mène souvent droit dans le mur.

L’article de Frederick Van Brabant qui a buzzé sur Hacker News cette semaine remet les pendules à l’heure avec une franchise rafraîchissante : non, l’IA ne va pas accélérer vos processus. Pas parce que la technologie ne tient pas ses promesses, mais parce que vous posez la mauvaise question dès le départ. 580 points, 400 commentaires — autant dire que le sujet touche un nerf.

Si ton processus est bancal, lui greffer un LLM, c’est juste produire des erreurs plus vite. Et si ton processus est bon, l’IA va le changer — pas l’accélérer. La nuance est énorme, et elle explique une bonne partie des projets d’automatisation qui se terminent en POC orphelins rangés dans un dossier SharePoint que personne ne rouvrira.

Automatiser le chaos, c’est industrialiser le chaos

Prenons un exemple concret. Tu as un processus de traitement de demandes clients qui prend 3 jours en moyenne. Ton équipe saisit des données manuellement, relance par email, copie-colle entre deux outils qui ne se parlent pas. Tu branches une solution d’IA dessus. Résultat : le processus prend toujours 3 jours, mais tu produis des relances automatiques que personne ne lit et des données mal formatées plus vite qu’avant. Félicitations.

C’est ce que Van Brabant appelle le piège de l’accélération : on présuppose que le goulot d’étranglement, c’est la vitesse d’exécution. Mais dans la majorité des cas, le vrai problème c’est la conception même du processus. Pourquoi ces trois systèmes ne communiquent-ils pas entre eux ? Pourquoi cette validation manuelle existe-t-elle ? Qui a décidé qu’il fallait une relance J+1, J+3 et J+7 ?

Ces questions, personne ne les a posées depuis 2018. L’outil de l’époque les contournait suffisamment bien pour qu’on passe à autre chose. L’IA va les rendre douloureusement visibles — soit parce qu’elle échoue à les automatiser, soit parce qu’elle les automatise tellement bien que tu réalises que le résultat final ne sert à rien.

L’IA comme révélateur de dette de processus

Il y a un parallèle intéressant avec la dette technique en développement. Quand tu reprends un vieux codebase pour y ajouter une feature, tu ne te contentes pas d’ajouter des lignes. Tu découvres des couches de décisions passées, des workarounds devenus des fondations, des commentaires cryptiques du type // TODO: fix this properly — 2019. L’ajout de la feature, c’est 20% du boulot. Comprendre pourquoi le code fait ce qu’il fait, c’est les 80% restants.

Les processus métier ont exactement le même problème. Sauf que personne n’a jamais appelé ça « dette de processus » avec la même sévérité qu’on parle de dette technique. Du coup, les organisations accumulent des années de workarounds, d’exceptions devenues la règle, de formulaires qui existent « parce qu’on a toujours fait comme ça ».

Quand tu arrives avec un projet d’automatisation IA, tu fais inévitablement de l’archéologie organisationnelle. Et c’est là que les projets prennent du retard — pas à cause de la technologie, mais parce que personne ne s’attendait à devoir documenter et rationaliser des pratiques qui n’avaient pas été touchées depuis des années. C’est inconfortable. C’est aussi exactement là que se trouve la vraie valeur du projet.

Ce que l’IA fait vraiment : elle change la nature du travail

Là où Van Brabant est particulièrement juste, c’est quand il dit que l’IA ne fait pas les mêmes choses que les humains, juste plus vite. Elle fait des choses différentes. Ce déplacement de la nature du travail est beaucoup plus intéressant — et beaucoup plus complexe à gérer — que la simple promesse d’accélération.

Prenons un exemple : la rédaction de specs pour une application sur mesure. Avant, un développeur ou un product owner passait des heures à structurer un cahier des charges depuis des notes éparses. Aujourd’hui, l’IA peut prendre ces notes et produire une première structure en quelques minutes. Est-ce que le processus est plus rapide ? Pas forcément. Il est différent : le développeur passe maintenant 80% de son temps à valider, affiner, corriger les hallucinations — là où avant il passait 80% à écrire.

La valeur créée n’est pas dans la vitesse. Elle est dans la réallocation du travail cognitif. Et ça, c’est beaucoup plus difficile à mesurer dans un PowerPoint de direction. Ce qui explique pourquoi tant de « bilans d’impact IA » sont creux : on essaie de mesurer du gain de temps sur une activité dont la nature a fondamentalement changé.

Automatiser un processus sans le comprendre, c’est construire une autoroute sur des fondations de sable. Tu vas vite jusqu’au premier affaissement.

Pourquoi les équipes résistent (et elles ont souvent raison)

Un des patterns les plus fréquents dans les projets d’intégration IA : les équipes qui « résistent au changement ». La direction pousse, les opérationnels freinent. La lecture managériale classique y voit de la frilosité, de l’attachement aux habitudes. C’est rarement aussi simple.

Souvent, c’est beaucoup plus rationnel que ça. Les équipes savent, intuitivement, deux choses que les slides ne disent pas. D’abord : le processus tel qu’il est décrit sur papier n’est pas le processus tel qu’il se pratique réellement. Il y a des cas limites quotidiens, des exceptions gérées à l’instinct, des connaissances tacites qui ne sont nulle part documentées. Automatiser le processus « officiel », c’est rater 40% des cas réels.

Ensuite : si l’automatisation se plante, qui ramasse les pots cassés ? Historiquement, ce sont les opérationnels. Ils absorbent les erreurs du système en silence, corrigent manuellement, compensent sans jamais être crédités pour ça. L’IA ne change pas cette dynamique — elle peut même l’aggraver en produisant des erreurs plus subtiles, plus difficiles à détecter qu’un bug franc et massif.

Par où commencer vraiment

Si l’IA ne doit pas être un turbo sur tes processus existants, quel est le bon angle d’attaque ? La réponse de Van Brabant — et c’est celle qui fait sens — c’est de commencer par les questions de design : pourquoi ce processus existe-t-il ? Quelle est la vraie contrainte qu’il résout ? Que se passerait-il si on l’abandonnait complètement ?

Ces questions semblent triviales. Elles ne le sont pas. Dans beaucoup de PME et ETI, certains processus existent depuis si longtemps que personne ne se souvient de leur raison d’être initiale. Ils se sont développés en réponse à un contexte qui a changé, avec des outils qui ont évolué, par des équipes qui ne sont plus là. Ce sont des fossiles organisationnels que personne n’a jamais eu le temps — ou le courage — de déterrer.

L’IA est une opportunité de faire ce ménage. Pas parce qu’elle l’impose, mais parce qu’elle force à formaliser ce qui était tacite. Pour qu’un LLM puisse traiter un cas, il faut être capable de le décrire précisément. Et souvent, cet exercice de formalisation est le vrai bénéfice du projet — indépendamment de ce qu’on finit par automatiser au bout du compte.

Ce que je pense vraiment de tout ça

L’argument « l’IA va tout accélérer » est confortable parce qu’il évite la vraie question : pourquoi tes processus sont-ils lents en premier lieu ? Répondre à ça demande de l’honnêteté organisationnelle, des conversations inconfortables, et du temps passé à cartographier des pratiques qui n’ont jamais été documentées. C’est moins sexy qu’une démo de GPT-4o sur un cas d’usage soigneusement choisi.

Ce qui m’a frappé dans les commentaires Hacker News, c’est que les témoignages les plus percutants ne venaient pas de gens qui avaient eu de mauvaises expériences avec l’IA — mais de ceux qui avaient eu de bonnes expériences et réalisé, après coup, que le vrai gain était ailleurs que prévu. L’IA les avait forcés à documenter, à standardiser, à choisir. Le LLM était presque anecdotique.

Mon pari : dans deux ou trois ans, on parlera beaucoup moins d’IA comme accélérateur, et beaucoup plus comme outil de transformation des interfaces de travail. Les organisations qui en tireront vraiment parti ne seront pas celles qui auront branché un LLM sur leurs anciens outils — ce seront celles qui auront eu le courage de se demander pourquoi leurs outils existaient, et si la réponse tenait encore la route. Ce n’est pas un problème de technologie. C’est un problème de management, de gouvernance, et d’humilité organisationnelle. L’IA ne va pas vous sauver de ça. Elle va juste rendre l’évitement plus coûteux.