- ▸ Un billet de 1 500 mots qui réinterroge la promesse centrale de 2025
- ▸ La thèse : confondre tâche et processus est l'erreur d'analyse de 2026
- ▸ Contexte historique : trente ans de mesure des chaînes de valeur
- ▸ Analyse technique : où s'arrête vraiment l'accélération
Frederick Van Brabant, ingénieur logiciel et auteur indépendant, publie le 15 mai 2026 un billet qui prend le contre-pied du discours dominant : « I don’t think AI will make your processes go faster ». Sa thèse tient en une ligne — un assistant intelligent ne raccourcit pas un processus structurellement lent. Trois angles, trois mécaniques, trois angles morts que l’engouement actuel masque.
Points clés 1. Frederick Van Brabant, dans son billet publié le 15 mai 2026, défend une thèse simple : l’IA accélère des tâches, jamais un processus complet. 2. La distinction entre tâche unitaire et chaîne de valeur est l’angle mort numéro un des chantiers de transformation actuels. 3. L’exemple canonique de l’auteur — « send mail to user once sale is completed » — illustre que l’attente, et non la rédaction, gouverne le délai. 4. La théorie des contraintes d’Eliyahu Goldratt, publiée en 1984, fournit le cadre analytique le plus solide pour comprendre cette limite. 5. La promesse de productivité doit se mesurer sur le lead time global, pas sur la vitesse d’un poste de travail isolé.
Un billet de 1 500 mots qui réinterroge la promesse centrale de 2025
Le 15 mai 2026, Frederick Van Brabant publie sur son blog personnel un texte au titre frontal : « I don’t think AI will make your processes go faster ». L’auteur est ingénieur logiciel et tient un blog technique suivi par une audience de praticiens. Son billet ne s’inscrit ni dans le registre du contre-discours systématique ni dans celui de la défiance idéologique. Il pose une question méthodologique précise : où exactement, dans la chaîne de production d’une organisation, l’intelligence artificielle générative produit-elle un gain mesurable de cycle ?
La réponse de l’auteur tient dans une distinction. L’IA accélère l’exécution d’une tâche isolée. Elle n’agit pas sur la structure du processus qui enchaîne ces tâches. Or c’est cette structure qui détermine le délai total entre la demande d’un client et la livraison de la valeur.
La thèse : confondre tâche et processus est l’erreur d’analyse de 2026
Van Brabant identifie une confusion catégorielle au cœur des chantiers de transformation actuels. Le terme « processus » est employé indifféremment pour désigner une opération atomique — rédiger un courriel, écrire une fonction — et un enchaînement d’opérations coordonnées. Le premier objet est court, mesurable en minutes. Le second est long, mesurable en jours ou en semaines, et inclut des attentes, des validations, des transferts de responsabilité. L’IA agit sur le premier. Elle laisse intact le second.
Contexte historique : trente ans de mesure des chaînes de valeur
L’argument de Van Brabant n’est pas nouveau ; il s’inscrit dans une lignée intellectuelle ancienne et solide. La théorie des contraintes, formulée par le physicien et consultant israélien Eliyahu Goldratt dans son roman managérial The Goal publié en 1984, repose sur un postulat simple : le débit d’un système est gouverné par son maillon le plus faible. Accélérer un maillon non contraint n’augmente pas le débit global. Pire, cela peut accroître les stocks intermédiaires et masquer la véritable contrainte.
Dans le même registre, le mouvement Lean issu du Toyota Production System, théorisé par Taiichi Ohno dans les années 1970 et popularisé en Occident par l’ouvrage The Machine That Changed the World de James Womack, Daniel Jones et Daniel Roos publié en 1990, distingue rigoureusement le temps à valeur ajoutée et le temps total de traversée. Les ratios mesurés dans l’industrie automobile japonaise dans les années 1980 montraient que le temps à valeur ajoutée représentait fréquemment moins de 5 % du temps total. Le reste — 95 % — était de l’attente : files devant un poste, lots en transit, validations en suspens.
La transposition de cette grille au logiciel a été opérée par Mary et Tom Poppendieck dans Lean Software Development, publié en 2003. Les auteurs y rappellent que les développeurs passent l’essentiel de leur journée à attendre — un retour de revue, une réponse à une question, un environnement de test disponible. La frappe au clavier n’est qu’une fraction du cycle. Le mouvement DevOps, formalisé à partir de 2009 par les conférences DevOpsDays initiées par Patrick Debois en Belgique, a poussé cette logique plus loin en mesurant ce qui sera désormais l’indicateur de référence : le lead time, soit la durée entre l’inscription d’une demande dans le backlog et sa mise en production effective.
Les études Accelerate: State of DevOps publiées chaque année depuis 2014 par Nicole Forsgren, Jez Humble et Gene Kim, et reprises par Google sous la bannière DORA, ont établi quatre indicateurs canoniques de la performance logicielle : la fréquence de déploiement, le lead time pour modification, le taux d’échec de changement, et le délai moyen de restauration. Aucun de ces quatre indicateurs ne mesure la vitesse de rédaction d’une ligne de code. Tous mesurent des propriétés émergentes de la chaîne complète.
C’est dans ce cadre conceptuel que Van Brabant écrit. Sa critique n’est pas anti-IA ; elle est anti-mesure-locale. Elle pointe le risque que l’organisation moyenne, fascinée par le gain individuel mesuré au poste de travail, ignore la totalité de la littérature accumulée sur le débit des chaînes complexes depuis quarante ans.
Analyse technique : où s’arrête vraiment l’accélération
Pour rendre tangible la distinction entre tâche et processus, Van Brabant convoque un cas d’école que tout praticien du logiciel reconnaîtra : « send mail to user once sale is completed », autrement dit l’envoi d’un courriel de confirmation à l’issue d’une vente. La phrase tient en huit mots. Elle masque une chaîne de huit à douze étapes coordonnées.
Décomposons. Un développeur doit d’abord identifier l’événement métier qui déclenche l’envoi — la commande est-elle validée à la signature, au paiement, ou à l’expédition ? Il doit ensuite localiser le hook applicatif disponible, vérifier qu’il existe un service de mailing, en obtenir les identifiants, écrire la fonction d’envoi, gérer les cas d’erreur — utilisateur sans adresse, serveur SMTP indisponible, file de relance —, rédiger les tests, soumettre la modification à revue, attendre les retours de revue, corriger les retours, faire valider le contenu du courriel par le marketing, déployer en pré-production, faire valider par le métier, déployer en production.
Sur cette chaîne de douze étapes, un assistant IA accélère exclusivement la rédaction du code et la rédaction des tests, soit deux ou trois étapes sur douze. Le développeur tape moins de touches au clavier. Mais il attend toujours la revue, toujours la validation marketing, toujours la fenêtre de déploiement.
Le tableau ci-dessous synthétise la distribution observée typiquement.
| Étape | Nature | Durée typique | Accélérable par IA |
|---|---|---|---|
| Identification du déclencheur métier | Décision | 1-3 h | Partiellement |
| Localisation du hook | Lecture de code | 30 min | Oui |
| Rédaction de la fonction | Codage | 1-2 h | Oui |
| Rédaction des tests | Codage | 1 h | Oui |
| Revue de code | Attente | 4-24 h | Non |
| Corrections post-revue | Codage | 30 min-2 h | Oui |
| Validation contenu marketing | Attente | 24-72 h | Non |
| Déploiement pré-production | Attente | 1-4 h | Non |
| Validation métier | Attente | 24-48 h | Non |
| Déploiement production | Attente | 1-24 h | Non |
La somme des durées « accélérables » plafonne à quelques heures. La somme des durées en attente excède régulièrement la semaine. Le ratio entre temps actif et temps total — ce que la littérature Lean nomme l’efficacité du flux — reste, dans la plupart des organisations logicielles, sous les 15 %. Diviser par deux le temps actif fait passer ce ratio à un peu moins de 8 % au lieu de 15. Le lead time mesuré côté client, lui, baisse de quelques pourcents seulement.
L’auteur tire de cet exercice une conclusion qu’il formule sans ambages : un assistant qui écrit plus vite ne raccourcit pas un processus dominé par l’attente. La condition pour qu’un gain local devienne un gain global est connue depuis Goldratt : il faut que le gain s’applique au goulot. Si l’écriture de code n’est pas le goulot — et dans la plupart des organisations elle ne l’est pas — l’accélération de l’écriture ne déplace pas le lead time.
Impact terrain : ce que les directions techniques observent en 2026
La grille proposée par Van Brabant éclaire un paradoxe désormais largement documenté : les déploiements d’assistants de codage rapportent un gain de vélocité au niveau individuel, sans que les indicateurs de bout en bout des équipes ne progressent au même rythme. Les directions techniques qui ont mis en production des outils d’assistance au développement constatent depuis fin 2024 que l’amélioration de productivité au poste ne se traduit pas mécaniquement par une amélioration de la fréquence de mise en production ni du délai de mise en marché.
Le phénomène s’explique par la mécanique systémique décrite plus haut. Multiplier le débit d’une étape non contraignante augmente la pression sur l’étape contraignante située en aval. Si la revue de code est le goulot, accélérer la rédaction génère mécaniquement plus de revues en file d’attente, et donc plus d’attente pour chaque modification. La perception du développeur — « j’écris plus vite » — est vraie au niveau micro. La perception de la direction technique — « rien ne sort plus vite » — est vraie au niveau macro. Les deux observations sont compatibles, et Van Brabant en fournit l’explication.
Cette dissociation entre productivité individuelle perçue et débit organisationnel mesuré est l’un des effets les plus discutés dans la communauté ingénierie logicielle au premier trimestre 2026. Elle pose une question budgétaire concrète. Les budgets consacrés aux assistants génératifs ont crû fortement sur la période 2024-2026 dans la plupart des grandes organisations technologiques. La question de leur retour sur investissement, mesuré sur des indicateurs business, est devenue le sujet pivot des comités de pilotage. Si le lead time ne baisse pas, le coût des licences ne se rembourse pas par l’accélération de la mise en marché.
Une seconde conséquence terrain mérite l’attention. Les chaînes de production logicielle qui obtiennent les meilleurs gains à l’arrivée des assistants IA sont celles qui avaient déjà rationalisé leurs étapes d’attente : revue automatisée légère, déploiement continu, validations métier intégrées au flux. Pour ces organisations, l’étape de codage redevient un poste significatif dans le lead time, et son accélération produit un effet mesurable. Pour les autres, l’IA est une optimisation locale dont le bénéfice se dissipe dans le bruit du système.
Perspectives contradictoires : ce que la thèse de Van Brabant ne résout pas
L’argumentaire de Van Brabant est solide. Il appelle néanmoins trois objections sérieuses qu’un raisonnement rigoureux doit examiner.
La première objection est que la frontière entre tâche et processus n’est pas étanche. Un assistant suffisamment intégré dans la chaîne d’outils — du backlog jusqu’au déploiement — n’agit plus seulement sur la frappe au clavier ; il agit aussi sur la préparation des revues, la génération des descriptions de modification, l’identification des reviewers pertinents, la rédaction des notes de version. Ces interventions, modestes prises isolément, peuvent additionner leurs effets sur des étapes d’attente que Van Brabant classe comme non accélérables. La frontière qu’il trace entre l’accélérable et le non-accélérable est donc une frontière 2026, susceptible de se déplacer.
La deuxième objection touche à la nature de l’attente. Toutes les attentes ne sont pas équivalentes. Une attente de revue de code, dans une équipe surchargée, est une attente de capacité — elle se résout par plus de relecteurs, pas par plus de vitesse au clavier. Mais une attente de validation métier, dans une organisation où le métier manque de matière pour décider, peut se résoudre par une meilleure préparation amont — un brief plus clair, des cas de test pré-rédigés, une démonstration documentée. Or ces livrables sont précisément le terrain de prédilection des assistants génératifs. La thèse de Van Brabant sous-estime peut-être le rôle de l’IA dans la réduction du temps de décision.
La troisième objection est statistique. Les processus longs sont des distributions à queue longue. Le temps moyen est tiré par les cas extrêmes — les modifications qui restent bloquées en revue plusieurs jours, les validations qui s’éternisent. Une accélération même partielle des cas médians peut produire un gain perçu réel, même si la moyenne reste tirée vers le haut par les exceptions. La grille goulot-versus-non-goulot, qui raisonne en débit stationnaire, capture mal cette réalité statistique.
Ces trois objections ne renversent pas la thèse. Elles indiquent que l’écart entre la promesse marketing et la réalité mesurée se mesure en pourcentages — pas en ordres de grandeur — et qu’il existe une zone de gain réel, modeste, à condition de l’instrumenter correctement.
Prospective : la prochaine bataille se joue sur la mesure
Si l’on accepte la grille de Van Brabant, la question pertinente pour 2026-2027 n’est plus « combien de temps gagne un développeur grâce à l’IA » mais « quel poste, dans la chaîne complète, devient le nouveau goulot ». La réponse conditionne le prochain cycle d’investissement.
Si le goulot reste la revue, les outils qui automatisent la pré-revue — vérifications de cohérence, détection de régression, suggestion de reviewers — produiront plus de valeur que les assistants de codage. Si le goulot est la validation métier, les outils qui transforment la spécification en démonstrateur exécutable produiront plus de valeur que les générateurs de code. Si le goulot est la mise en production, l’investissement doit aller au déploiement continu et à l’observabilité, pas à l’accélération de l’édition.
Cette mécanique réoriente l’agenda 2026 des directions techniques. La métrique pertinente à suivre n’est plus la vélocité d’équipe mais le lead time complet, instrumenté à granularité fine. Le projet de Van Brabant — déplacer l’attention du clavier vers la chaîne — pourrait s’imposer comme le cadre dominant dans les douze à dix-huit mois qui viennent, à mesure que les premiers bilans de retour sur investissement des assistants IA arrivent en comité d’investissement.
FAQ
Pourquoi un assistant IA ne raccourcit-il pas un processus dominé par l’attente ?
Parce que l’accélération s’applique exclusivement aux étapes actives — l’écriture de code, la rédaction de courriels — qui ne représentent souvent qu’une fraction minoritaire du lead time. Tant que les attentes — revues, validations, fenêtres de déploiement — gouvernent le délai, accélérer le maillon non contraignant déplace les goulots sans réduire le temps total.
Comment identifier le vrai goulot d’un processus ?
En mesurant le lead time complet et en le décomposant étape par étape, depuis la prise en charge d’une demande jusqu’à sa livraison effective. La théorie des contraintes formulée par Eliyahu Goldratt en 1984 propose une méthode itérative : identifier le goulot, le saturer, le subordonner, l’élargir, puis recommencer. La règle clé est que toute amélioration appliquée hors du goulot ne change pas le débit global.
L’IA peut-elle s’attaquer aux étapes d’attente ?
Partiellement. Elle peut réduire la durée de certaines validations en améliorant la qualité des livrables soumis — brief plus clair, démonstration documentée, descriptif de modification mieux rédigé. Elle ne réduit pas, en revanche, la file d’attente structurelle d’une équipe sous-dimensionnée. La distinction entre attente résoluble par information et attente résoluble par capacité gouverne l’efficacité réelle.
Que devrait mesurer une direction technique en 2026 ?
Le lead time complet, la fréquence de déploiement, le taux d’échec de changement et le délai moyen de restauration — les quatre indicateurs DORA établis par Nicole Forsgren, Jez Humble et Gene Kim depuis 2014. La vélocité individuelle ne dit rien du débit organisationnel. C’est le lead time décomposé qui révèle où l’investissement produit de la valeur et où il l’enferme dans une optimisation locale.
En résumé : trois enseignements à retenir
Le billet de Frederick Van Brabant fournit trois enseignements opérationnels. Premièrement, la grille goulot-versus-non-goulot, héritée de Goldratt, reste le meilleur outil pour évaluer l’impact d’un nouvel outillage. Deuxièmement, l’exemple canonique du courriel de confirmation montre que la chaîne réelle se compose d’une douzaine d’étapes dont une majorité sont des attentes. Troisièmement, l’instrumentation fine du lead time est la condition pour distinguer un gain réel d’une optimisation locale dissipée. Pour aller plus loin sur les mesures de productivité logicielle, voir notre dossier sur les indicateurs DORA en 2026 et notre analyse de la transformation Lean dans les équipes IA.
Encadré sources
- Frederick Van Brabant, I don’t think AI will make your processes go faster, 15 mai 2026 — https://frederickvanbrabant.com/blog/2026-05-15-i-dont-think-ai-will-make-your-processes-go-faster/
- Eliyahu Goldratt, The Goal, North River Press, 1984.
- Taiichi Ohno, Toyota Production System: Beyond Large-Scale Production, Productivity Press, 1988.
- James Womack, Daniel Jones, Daniel Roos, The Machine That Changed the World, Free Press, 1990.
- Mary Poppendieck, Tom Poppendieck, Lean Software Development, Addison-Wesley, 2003.
- Nicole Forsgren, Jez Humble, Gene Kim, Accelerate, IT Revolution Press, 2018.
- Patrick Debois, DevOpsDays, conférences fondatrices depuis 2009.
