[!WARNING] Ce qui suit s’est produit dans des conditions spécifiques. Une petite équipe senior, vingt ans de contexte accumulé, et une infrastructure suffisamment stable pour absorber le changement rapide. Ce n’est pas un mode d’emploi universel. C’est ce qui s’est passé quand l’exécution a cessé d’être le goulet d’étranglement.

Pendant des décennies, les organisations logicielles ont été façonnées par une contrainte dominante : le développement était lent et coûteux. Chaque processus, chaque rituel, chaque couche de validation existait parce que livrer du code prenait du temps, et les erreurs coûtaient cher à corriger.

Les roadmaps regroupaient le travail par trimestres et les sprints par semaines. Les backlogs s’accumulaient parce qu’il y avait toujours plus à construire que de capacité pour le construire. La faisabilité servait de filtre naturel : si quelque chose était difficile à implémenter, souvent ça ne se faisait pas.

Cette contrainte est en train de s’effondrer.

Le basculement

En six mois, je suis passé de l’écriture de code à la planification et la validation de productions générées par l’IA. Ce qui nécessitait auparavant plusieurs relecteurs et des jours d’allers-retours se résout désormais en une seule passe. Claude est devenu notre premier contributeur GitHub. Nous sommes passés d’une ou deux PR par semaine à plusieurs par jour.

Quand le code prend des minutes au lieu d’heures, le travail reporté se débloque soudainement. Les refactors se font. Le backlog cesse d’être un stock pour devenir un flux.

Mais ce n’est pas qu’une question de vitesse. C’est ce que la vitesse révèle.

Les questions qui restent

Quand l’exécution était coûteuse, la faisabilité répondait à la plupart des questions de priorisation à notre place. On ne construisait pas certaines choses parce qu’on ne pouvait pas, et ça ressemblait à de la stratégie.

Maintenant, la faisabilité ne répond presque plus à rien. Les questions difficiles ont migré en amont : devrait-on construire ça ? et qu’est-ce que ça remplace ? et, peut-être le plus important, qu’est-ce qu’on choisit d’ignorer ?

Ce ne sont pas des questions d’ingénierie. Ce sont des questions de jugement. Et elles ne se compriment pas comme le code.

Le nouveau goulet d’étranglement

La ressource rare n’est plus le temps des développeurs. C’est l’attention humaine et la qualité des décisions.

Par exemple, un week-end, notre CMO a construit et déployé un site web entier toute seule. Avec notre ancien processus, cela aurait pris des semaines de coordination. La première réaction de notre CTPO n’a pas été la célébration. C’était la confusion : “Qu’est-ce que je fais de ça ?”

La question comptait plus qu’il n’y paraissait. Notre système était conçu pour autoriser le travail avant qu’il n’existe, pas pour absorber du travail déjà fait. L’organisation ne pouvait pas métaboliser la production au rythme où elle était produite.

C’est le nouveau problème. Non pas comment aller plus vite ? mais comment décider plus vite, et mieux, sans épuiser ceux qui décident ?

Pourquoi “aller plus vite” n’est pas une stratégie

Dans le monde des startups, la vitesse était un avantage concurrentiel parce qu’elle était rare. Quand tout le monde peut livrer vite, la vitesse devient le minimum requis. La différenciation se déplace ailleurs : vers le goût, vers le focus, vers la qualité des problèmes qu’on choisit de résoudre.

Les organisations optimisées pour le débit continueront d’optimiser le débit, et elles se demanderont pourquoi ça n’aide pas. Le goulet d’étranglement a migré en amont, mais les tableaux de bord mesurent toujours la vélocité.

Les entreprises qui s’adapteront ne seront pas celles qui livrent le plus. Ce seront celles qui apprennent à dire non plus vite, avec plus de conviction, et avec des raisons plus claires.

L’exécution était la contrainte qui justifiait nos structures.

Cette contrainte est en train de disparaître. Et avec elle, l’excuse pour ne pas poser les questions les plus difficiles.