Blog · Ingénierie IA

Coder plus vite n’est pas livrer plus vite.

17 juillet 2026 · 5 min de lecture · Nicolas Pieper

Une vidéo est arrivée dans mon fil qui dit tout haut ce que je dessine sans cesse sur des tableaux blancs : l’IA a rendu le codage spectaculairement plus rapide, et la livraison logicielle s’en est à peine aperçue. Cedric Clyburn, d’IBM Technology, explique pourquoi en douze minutes, et sa réponse résonne avec tout ce que je vois au travail.

Sticker détouré : deux chaînes de montage ; sur celle du haut, un seul poste orange travaille vite pendant que les blocs s’empilent et que les ouvriers attendent ; sur celle du bas, un petit robot aide à chaque poste et les blocs orange filent régulièrement jusqu’au drapeau d’arrivée

La vidéo#

AI in the SDLC · IBM Technology, juin 2026. Rien n’est chargé depuis YouTube avant que vous lanciez la lecture.

Elle s’ouvre sur un chiffre inconfortable : une étude contrôlée sur des développeurs open source expérimentés qui se croyaient environ 20 % plus rapides grâce aux outils d’IA, alors que les mesures les montraient à peu près 20 % plus lents. Se sentir plus rapide n’est pas être plus rapide. Ce seul constat mériterait d’être épinglé au-dessus de chaque tableau de bord d’ingénierie, juste à côté de la question honnête qu’il impose : si le modèle code si bien, pourquoi la livraison ne bouge-t-elle pas ?

Un cycle fait d’attente#

Clyburn dessine le pipeline classique : besoins, conception, code, test, livraison, exploitation. Puis il livre le secret que tout manager d’ingénierie apprend à ses dépens : l’essentiel du temps écoulé dans ce pipeline n’est pas passé à écrire du code. Il est passé à attendre. Les développeurs attendent que l’équipe produit clarifie une story. Les ops attendent la release. La QA attend un build, dans un environnement qui ne ressemble jamais tout à fait à la production, à travers un empilement d’outils fragmentés.

Alors quand l’IA accélère une case, les files d’attente autour absorbent le gain sans bruit. Codez trois fois plus vite : la pull request attend toujours ses relecteurs, le contrôle de conformité, l’environnement de test partagé. En pilotant un portefeuille de plateformes réglementées, je peux confirmer : la phase de code est rarement ma contrainte. La coordination, si.

Deux façons d’échouer#

La vidéo décrit l’adoption de l’IA comme un spectre avec un piège à chaque extrémité, et j’ai vu des équipes, la mienne comprise, marcher dans les deux.

La sur-délégation : confier à un modèle frontière un gros problème ambigu, « construis-moi une plateforme e-commerce », et le laisser courir. Chaque décision non formulée sur les paiements, l’authentification ou la livraison est prise en silence par le modèle, qui rend des milliers de lignes que personne n’a lues. La revue devient le goulot d’étranglement, et les allers-retours brûlent tout ce que la génération avait fait gagner.

La sous-délégation : l’ingénieur senior garde toute la planification et tend des miettes au modèle, écris cette fonction, scanne ce fichier pour les injections SQL. Le code rendu est bon, mais tout le travail intellectuel reste humain, et le cycle n’accélère presque pas. C’est le piège des équipes disciplinées, précisément parce que leur discipline les protège du premier. Nos propres garde-fous nous préservent de la sur-délégation ; la question honnête est de savoir s’ils ne nous gardent pas parfois trop du côté timide.

Repenser le cycle autour de l’IA#

Le cœur de la vidéo est un recadrage : cesser de coller l’IA sur le cycle existant et repenser le cycle autour d’elle. Phase par phase, cela ressemble à ceci :

Besoins et conception

Synthétiser la masse non structurée d’enquêtes, de retours utilisateurs et d’emails en user stories, et laisser des agents fouiller les logs de production et les rapports de bugs pour que l’itération suivante parte de ce qui échoue réellement.

Code

Des tâches petites et bien définies plutôt que des systèmes vibe-codés : une spécification que le modèle peut lire et suivre, des sous-agents pour la recherche, pour puiser des données via des serveurs MCP et pour l’édition, et des fichiers de contexte partagés pour des sorties cohérentes d’une équipe à l’autre.

Test

Générer les données de test directement depuis la user story, et laisser le modèle lire la stack trace de 3 h du matin sans la panique de 3 h du matin.

Livraison et exploitation

Les modèles parlent déjà couramment l’infrastructure as code, des playbooks Ansible aux manifestes Kubernetes.

Legacy

Expliquer et rétro-concevoir les systèmes que plus personne ne comprend vraiment, ce qui est une assez bonne description de mon quotidien.

Toute l’idée en une image#

Balayez horizontalement pour lire tout le cycle.

Accélérer une case nourrit les files d’attente autour. Repenser chaque case déplace le résultat.

Des résultats, pas des lignes#

La conclusion est la partie que j’encadrerais : le gain de productivité ne vient pas d’un meilleur modèle ni d’un meilleur outil, il vient, comme le dit Clyburn, du fait de « redessiner le cycle de livraison logicielle autour du modèle ». Le rôle humain passe de la frappe à la validation, exactement l’inversion que je décrivais dans Claude assisté par un humain, abordée ici par le côté organisation plutôt que par le côté clavier.

La loi d’Amdahl s’applique aussi aux organisations : accélérer une étape révèle surtout le coût de toutes les autres.

Et la mesure suit : pas les lignes de code générées, mais la santé des systèmes, la maintenabilité, et le temps qu’un changement met à atteindre la production. Ce sont déjà les chiffres dont je réponds devant mes parties prenantes, ce qui explique sans doute pourquoi cette vidéo m’a moins fait l’effet d’une leçon que d’un collègue d’accord avec moi, avec de bien meilleurs moyens de production. Elle vaut douze minutes de votre cycle de vie.