> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/fr/2026/w21-the-inflection-point-of-software-engineering.md).

# W21-Le point de bascule de l'ingénierie logicielle

La semaine dernière, j'ai regardé une intervention de l'ingénieur Google Adam Bender à Google I/O 2026, [Software engineering at the tipping point](https://io.google/2026/explore/workshop-2). Il y examine l'impact de l'IA sur l'ingénierie logicielle et les seuils que l'écosystème existant atteindra quand la génération de code sera multipliée par dix, voire davantage.

Cette intervention m'a rappelé [Software Engineering at Google](https://abseil.io/resources/swe-book/html/toc.html), souvent appelé le Flamingo book. Il rassemble les leçons essentielles de plus de vingt ans de pratique chez Google : monorepo, développement sur le tronc principal, changements à grande échelle, revues de code, tests et culture d'ingénierie. Je le lisais autrefois comme un recueil de bonnes pratiques des grandes entreprises. Aujourd'hui, je vois qu'il traite moins d'un outil particulier que de la manière dont un logiciel continue d'évoluer dans le temps et à grande échelle.

C'est là que réside la principale différence entre programmation et ingénierie logicielle. La programmation vise à écrire du code pour résoudre le problème présent. L'ingénierie logicielle demande si, quelques années et quelques centaines de personnes plus tard, le système restera compréhensible, modifiable, vérifiable et capable d'évoluer sans danger. Écrire le code n'est que le début. Le plus difficile est de le maintenir durablement dans un écosystème maîtrisé.

Beaucoup de pratiques de Google construisent, au fond, un destin commun. Le monorepo fait partager les mêmes actifs logiciels à toute l'entreprise. Le développement sur le tronc principal aligne continuellement chacun sur une même version. Les modifications à grande échelle permettent de corriger automatiquement bibliothèques fondamentales et failles de sécurité. Les revues de code et les rétrospectives sans recherche de coupable transforment l'expérience individuelle en capacité collective. Il ne s'agit pas d'un simple culte des outils, mais d'un système sociotechnique : les outils traitent l'échelle, la culture d'ingénierie traite la collaboration.

Le plus intéressant chez Bender est qu'il situe l'IA dans cet écosystème, au lieu de demander seulement si elle sait écrire du code. Avec l'IA, les anciens problèmes de l'ingénierie ne disparaissent pas ; ils s'amplifient. Je partage une formulation de DORA : [l'IA est un amplificateur](https://dora.dev/capabilities/user-centric-focus/). Elle augmente l'amplitude sans fixer la direction. Si les tests, l'architecture et la collaboration d'une équipe sont sains, elle amplifie l'efficacité. Si ces fondations sont fragiles, elle amplifie le désordre.

Quand une personne écrivait quelques dizaines ou centaines de lignes par jour, beaucoup de problèmes apparaissaient lentement. Demain, plusieurs agents modifieront simultanément le code et la vitesse de génération pourra être multipliée par dix ou cent. Les systèmes d'ingénierie atteindront plus vite leurs limites. Quand le code devient bon marché, le mauvais code s'accumule plus facilement et les actifs logiciels se transforment vite en passifs. Les systèmes de compilation et de tests subiront une pression accrue. Une suite de tests aujourd'hui praticable pourra devenir insoutenable avec l'expansion du code et des dépendances. La revue de code rencontrera elle aussi un goulot de débit. Des experts humains épuisés à examiner des masses de changements générés par IA seront facilement contraints de baisser leurs exigences.

Plus grave, sans contraintes globales, les agents pourront modifier mutuellement leur code. L'un voudra une refonte, l'autre reviendra en arrière, jusqu'à produire une sorte de guerre interne des modifications entre agents. Cela ressemble à une plaisanterie, mais une production de code plus rapide et moins coûteuse rend ce scénario possible. Sans frontières d'abstraction claires ni mécanismes de retour, le désordre s'automatisera lui aussi plus vite.

L'ingénierie logicielle à l'ère de l'IA ne peut donc se limiter à faire écrire davantage de code aux modèles. Écrire devient moins coûteux ; les contraintes systémiques, la vérification et le jugement architectural deviennent rares. Nous devons passer de la gestion d'un arbre à celle d'une forêt. Hier, nous examinions une fonction, un module, une revue. Demain, il faudra davantage considérer les frontières de l'écosystème, ses boucles de retour et l'ordre de son évolution.

Plusieurs directions me semblent mériter une préparation dans les équipes.

Premièrement, les tokens et les ressources de calcul pour les tests deviendront des ressources d'ingénierie à part entière. Il ne faut pas les considérer comme un service de fond illimité.

Deuxièmement, la stratégie de vérification doit devenir plus intelligente et ne plus reposer uniquement sur des tests exhaustifs et des revues humaines.

Troisièmement, le système doit mieux isoler ses composants pour empêcher le code expérimental produit par IA de contaminer facilement les circuits essentiels.

Quatrièmement, les humains doivent reprendre la maîtrise de la compréhension du système. La valeur majeure de l'IA ne consiste pas seulement à écrire du code, mais à aider à comprendre des systèmes complexes, produire des diagrammes architecturaux dynamiques, explorer les dépendances et analyser les effets de second ordre.

Cela rejoint notre réflexion récente sur l'ingénierie AI-Ready. Il ne suffit pas de brancher quelques outils ou d'écrire davantage de prompts. Il faut rendre les systèmes d'ingénierie capables de supporter une production plus rapide, plus concurrente et plus incertaine. Infrastructures, conventions de code, tests, documentation, représentation de l'architecture et mécanismes de revue : ces activités qui paraissaient lentes deviendront au contraire plus importantes.

Les principes de l'ingénierie logicielle n'ont pas changé. Le niveau de productivité et la pression sur les systèmes, oui. Plus le code est généré vite, plus il faut revenir aux fondamentaux. La véritable force d'une équipe résidera peut-être moins dans sa capacité à produire davantage de code avec l'IA que dans celle à concevoir un écosystème où l'IA participe sans danger, où la vérification est continue et où l'évolution reste maîtrisée.