[!WARNING] Ce qui suit s’est produit dans des conditions specifiques. Une petite equipe senior, vingt ans de contexte accumule, 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 passe quand l’execution a cesse d’etre le goulet d’etranglement.

Pendant des decennies, les organisations logicielles ont ete faconnees par une contrainte dominante : le developpement etait lent et couteux. Chaque processus, chaque rituel, chaque couche de validation existait parce que livrer du code prenait du temps, et les erreurs coutaient cher a corriger.

Les roadmaps regroupaient le travail par trimestres et les sprints par semaines. Les backlogs s’accumulaient parce qu’il y avait toujours plus a construire que de capacite pour le construire. La faisabilite servait de filtre naturel : si quelque chose etait difficile a implementer, souvent ca ne se faisait pas.

Cette contrainte est en train de s’effondrer.

Le basculement

En six mois, je suis passe de l’ecriture de code a la planification et la validation de productions generees par l’IA. Ce qui necessitait auparavant plusieurs relecteurs et des jours d’allers-retours se resout desormais en une seule passe. Claude est devenu notre premier contributeur GitHub. Nous sommes passes d’une ou deux PR par semaine a plusieurs par jour.

Quand le code prend des minutes au lieu d’heures, le travail reporte se debloque soudainement. Les refactors se font. Le backlog cesse d’etre un stock pour devenir un flux.

Mais ce n’est pas qu’une question de vitesse. C’est ce que la vitesse revele.

Les questions qui restent

Quand l’execution etait couteuse, la faisabilite repondait a la plupart des questions de priorisation a notre place. On ne construisait pas certaines choses parce qu’on ne pouvait pas, et ca ressemblait a de la strategie.

Maintenant, la faisabilite ne repond presque plus a rien. Les questions difficiles ont migre en amont : devrait-on construire ca ? et qu’est-ce que ca remplace ? et, peut-etre le plus important, qu’est-ce qu’on choisit d’ignorer ?

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

Le nouveau goulet d’etranglement

La ressource rare n’est plus le temps des developpeurs. C’est l’attention humaine et la qualite des decisions.

Par exemple, un week-end, notre CMO a construit et deploye un site web entier toute seule. Avec notre ancien processus, cela aurait pris des semaines de coordination. La premiere reaction de notre CTPO n’a pas ete la celebration. C’etait la confusion : “Qu’est-ce que je fais de ca ?”

La question comptait plus qu’il n’y paraissait. Notre systeme etait concu pour autoriser le travail avant qu’il n’existe, pas pour absorber du travail deja fait. L’organisation ne pouvait pas metaboliser la production au rythme ou elle etait produite.

C’est le nouveau probleme. Non pas comment aller plus vite ? mais comment decider plus vite, et mieux, sans epuiser ceux qui decident ?

Pourquoi “aller plus vite” n’est pas une strategie

Dans le monde des startups, la vitesse etait un avantage concurrentiel parce qu’elle etait rare. Quand tout le monde peut livrer vite, la vitesse devient le minimum requis. La differenciation se deplace ailleurs : vers le gout, vers le focus, vers la qualite des problemes qu’on choisit de resoudre.

Les organisations optimisees pour le debit continueront d’optimiser le debit, et elles se demanderont pourquoi ca n’aide pas. Le goulet d’etranglement a migre en amont, mais les tableaux de bord mesurent toujours la velocite.

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

L’execution etait la contrainte qui justifiait nos structures.

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