L'IA amplifie. Cinq fondamentaux décident dans quel sens.
En bref
- L’IA ne répare pas votre ingénierie : elle l’amplifie, le bon comme le mauvais.
- La vraie question n’est pas « sommes-nous matures en IA ? » mais « notre ingénierie est-elle prête à en tirer une vraie valeur ? ».
- Cinq fondamentaux d’ingénierie, antérieurs à l’IA, décident de ce que vous en tirez.
- Ce qui compte n’est pas votre niveau sur chacun, mais les déséquilibres entre eux.
Une équipe qui allait bien
Je me souviens d’une équipe qui venait de généraliser un assistant de code. Tout le monde était content.
Les développeurs parlaient de gain de temps. Le tableau de bord montrait plus de commits, plus de pull requests, plus de tickets fermés.
Puis on regarde de plus près :
- la file de revue s’allongeait ;
- les pull requests étaient plus grosses, et passaient parfois sans vraie revue « pour avancer » ;
- un senior ne saurait pas réécrire un module qu’il venait pourtant de livrer ;
- un junior produisait du code que personne, lui compris, ne comprenait vraiment.
La vélocité montait. La compréhension baissait. Et personne ne regardait la seconde courbe, parce que la première était si rassurante.
Ce n’était pas une équipe en échec. C’était une équipe en train de devenir fragile, à grande vitesse, sans s’en apercevoir.
J’ai vu cette scène se rejouer assez souvent pour penser qu’elle n’est pas un accident. Elle découle d’une question mal posée.
La mauvaise question
La plupart des organisations se demandent : « Sommes-nous matures en IA ? »
C’est une question de taux d’adoption : assez d’outils, assez souvent, par assez de monde ? Facile à mesurer, et dangereuse pour cette raison même. Elle rassure sans rien révéler.
Car l’IA ne s’adopte pas comme un outil neutre. Elle s’applique à un système qui a déjà ses forces et ses fragilités, bien avant le premier prompt.
La bonne question est : notre ingénierie est-elle prête à tirer de l’IA une valeur durable ?
On cesse alors de regarder l’outil, pour regarder le terrain sur lequel il agit.
L’IA révèle, elle ne répare pas
L’idée tient en une phrase : l’IA ne répare pas une ingénierie, elle multiplie ce qu’elle y trouve : les forces comme les faiblesses.
Longtemps une intuition de terrain, c’est aujourd’hui documenté. Le rapport DORA 2025 (près de 5 000 professionnels) le confirme : l’IA est un amplificateur, pas un correctif.
Il en tire d’ailleurs la même bascule que cet article : la question n’est plus s’il faut adopter l’IA, mais comment se préparer à en tirer de la valeur.
Le plus parlant tient dans une asymétrie. Voici ce que DORA observe quand l’adoption de l’IA augmente :
| Effet de l’adoption de l’IA (DORA 2025) | Tendance |
|---|---|
| Débit de livraison | en hausse |
| Performance produit et organisationnelle | en hausse |
| Temps passé sur du travail à valeur | en hausse |
| Qualité de code perçue | en hausse |
| Burnout et friction | inchangés |
| Stabilité de livraison | en baisse |
Presque tout s’améliore… en moyenne. Mais cette moyenne cache de grands écarts : les équipes solides progressent, les fragiles reculent (DORA 2025). Un débit qui monte ne dit donc rien, seul, de la santé du système.
Et un seul indicateur baisse pour tout le monde : la stabilité (DORA 2025). En accélérant, l’IA expose ce qui n’était pas solide en amont : tests, architecture, boucles de feedback.
Et 2024 ? DORA observait alors l’inverse : un débit en baisse (DORA 2024). La tendance s’est inversée en un an. Sur un sujet qui bouge aussi vite, les chiffres datent presque aussitôt ; ce qui dure, c’est le mécanisme, pas le pourcentage.
Plus de code, pas plus de valeur
Voici le chiffre qui résume tout.
Les développeurs qui utilisent l’IA au quotidien produisent environ quatre fois plus de code, mais la valeur réellement livrée ne progresse que d’environ 12 % (données GitClear, reprises par Addy Osmani, qui précise honnêtement qu’une part de ces 12 % tient à la surreprésentation des meilleurs développeurs parmi les utilisateurs d’IA).
Quatre fois plus de code à relire, pour un dixième de valeur en plus. Tout l’écart se loge dans la seule étape qui n’a pas accéléré : la revue.
Osmani le formule bien : la revue tenait par un hasard de vitesses : un senior lisait plus vite qu’un junior n’écrivait. Ce hasard a disparu. Un agent produit mille lignes propres en quelques secondes, quand la vitesse de lecture humaine, elle, n’a pas bougé.
Les chiffres suivent. Une télémétrie 2026 sur 22 000 développeurs (Faros AI, reprise par A. Osmani) montre des pull requests qui gonflent (+51 %), des temps de revue multipliés par cinq, et 31 % de changements en plus fusionnés sans aucune revue, un schéma baptisé « coup du lapin de l’accélération » (Faros AI, 2026).
C’est l’histoire de mon équipe : l’IA n’a pas créé ses problèmes, elle les a rendus plus rapides, et donc plus invisibles.
Cinq choses à regarder
Pour savoir si votre ingénierie est prête, cinq fondamentaux suffisent à se faire une idée. Aucun n’est propre à l’IA : c’est tout l’intérêt : ce qui décide de ce que vous en tirerez, ce sont de bonnes pratiques d’avant l’IA. Je les regroupe en m’appuyant sur des références reconnues (DORA, Accelerate, SPACE, DevEx, Team Topologies).
| Capacité | La question | Signal de fragilité | Inspiré de |
|---|---|---|---|
| Livraison durable | Accélérer sans dégrader ? | Gros lots, PR qui gonflent | DORA / Accelerate |
| Compréhension partagée | Comprend-on encore le système ? | Code accepté qu’on ne saurait réécrire | Team Topologies / DORA 2025 |
| Garde-fous qualité | Les pratiques tiennent-elles le choc ? | Revue allégée, dette qui grimpe | Accelerate / GitClear |
| Expérience productive | Gain réel, ou charge cachée ? | Temps gagné = temps de supervision | SPACE / DevEx |
| Adoption intentionnelle | Délibérée, ou subie ? | « Shadow AI », aucune mesure | DORA AI Capabilities Model |
Deux de ces points font le plus de dégâts quand ils manquent.
Les garde-fous qualité séparent une IA qui accélère d’une IA qui propage la dette. Le code généré est souvent bien présenté, écrit avec assurance… et subtilement faux. Sans filet (tests, revue), cette plausibilité trompeuse entre directement dans la base.
La compréhension partagée se dégrade en silence, et c’est l’angle le plus négligé. Tout le monde surveille la dette technique ; presque personne la dette cognitive.
Lionel Chaine, DSI de Bpifrance, en a fait le titre d’un article : l’écriture est résolue, la compréhension ne l’est pas, depuis son terrain : 600 développeurs, des dizaines d’agents en production. Son constat : même dans une organisation mature et régulée, produire du code est devenu un problème presque résolu, quand le comprendre coûte toujours aussi cher (Chaine, 2026).
Le mécanisme est insidieux : l’agent raisonne, puis jette son raisonnement en produisant le code. Le relecteur ne juge plus une intention, il la reconstitue.
Et en abaissant la barrière d’entrée, l’IA prive de la « lutte productive » nécessaire à l’apprentissage. Le risque est aigu pour les juniors, dont le compagnonnage s’érode quand l’IA fait à leur place (DORA 2025).
Le vrai signal : la tension, pas le niveau
Le piège des « modèles de maturité », c’est le score unique. Or le niveau de chaque point, pris isolément, ne dit presque rien.
Une équipe forte en livraison mais faible en compréhension est plus en danger qu’une équipe moyenne mais équilibrée. Ce qui révèle, ce ne sont pas les hauteurs : ce sont les tensions : les écarts entre une force et une faiblesse.
La plus parlante oppose la vitesse de livraison à la compréhension du système :
Le coin dangereux est en haut à gauche : livrer vite sans comprendre, c’est la dette cognitive, celle de mon équipe du début. Mais ce n’est qu’une tension parmi d’autres. Quatre reviennent sans cesse, chacune désignant un profil :
| La tension | Capacité forte | Capacité faible | Profil |
|---|---|---|---|
| Aller vite sans comprendre | Livraison | Compréhension | ● Dette cognitive |
| Accélérer sans filet | Livraison | Garde-fous | ● Dette technique amplifiée |
| Aimer l’outil sans cap | Expérience | Intention | ● Adoption opportuniste |
| Pousser sans bénéfice | Intention | Expérience | ● Adoption subie |
Deux profils, eux, ne sont pas des tensions mais des états d’ensemble :
- ● Système fragile : compréhension et garde-fous au plus bas. Un système qu’on ne comprend plus et qu’aucun filet ne protège : le plus à risque de tous.
- ● Accélérateur durable : les cinq points hauts et équilibrés. Le seul cas où l’IA tient vraiment ses promesses.
Lire sa situation, ce n’est donc pas additionner des points. C’est regarder une forme : quelles forces, quelles faiblesses, et surtout lesquelles sont en tension.
Ce que ça change, côté direction
L’implication est directe, et un peu inconfortable :
- Cessez de piloter l’IA par le taux d’usage. Licences, taux d’acceptation, volume de code généré peuvent monter pendant que le système se dégrade.
- Investissez dans les fondations. Qualité de la plateforme interne, petits lots, garde-fous, compréhension partagée. Le rapport DORA 2025 est net : les plus grands retours viennent des systèmes fondateurs (plateforme, données, workflows), pas des outils.
- Protégez l’apprentissage des juniors. Pairing, revue d’architecture, parfois du code écrit à la main. Une organisation qui délègue trop tôt l’apprentissage à l’IA se prive de ses seniors de demain.
Une réserve, par honnêteté : les fondations ne sont pas une assurance tous risques. DORA conclut qu’elles amplifient les bénéfices de l’IA ; mais la télémétrie Faros montre que même des équipes très matures voient leur revue saturer sous le volume généré. Les fondations transforment la vitesse en valeur : encore faut-il muscler, en aval, la capacité de revue et de test.
Les limites, parce qu’il en faut
- Ces cinq points sont une grille de lecture, pas une mesure. Ils aident à regarder au bon endroit ; ils ne remplacent pas le suivi réel de vos métriques (DORA et autres).
- Les profils sont des repères, pas des étiquettes définitives : une équipe réelle cumule souvent plusieurs tensions.
- Un profil n’est pas un verdict. Sa vraie valeur est dans la conversation qu’il ouvre, surtout quand, dans une même équipe, les réponses divergent.
Pour finir
L’IA n’est ni bonne ni mauvaise pour votre ingénierie : elle est un amplificateur.
Plus votre système est robuste, plus elle crée de valeur. Plus il est fragile, plus elle accélère sa dégradation, souvent derrière une courbe de vélocité parfaitement rassurante.
La vraie question n’a jamais été l’IA. Elle a toujours été votre ingénierie. L’IA n’a fait que la rendre urgente.
Dans un prochain temps, je proposerai un court auto-diagnostic, je l’appelle ERA, pour Engineering Readiness for AI, afin de situer ces cinq points et leurs tensions en quelques minutes. En attendant, la grille ci-dessus suffit déjà à se poser les bonnes questions, en équipe.
Sources
- DORA, State of AI-assisted Software Development (2025) : source principale de cet article (≈ 5 000 professionnels interrogés). L’édition 2024 n’est citée qu’à titre de comparaison : voir la mise en garde sur l’obsolescence rapide des chiffres.
- DORA, AI Capabilities Model (2025) : sept capacités organisationnelles qui amplifient les bénéfices de l’IA.
- Forsgren N., Humble J., Kim G., Accelerate (2018) : fondements du programme DORA.
- Forsgren N., Storey M.-A., et al., The SPACE of Developer Productivity (2021).
- Noda A., Storey M.-A., Forsgren N., Greiler M., DevEx: What Actually Drives Productivity (2023).
- Skelton M., Pais M., Team Topologies (2019).
- GitClear, AI Copilot Code Quality (churn et duplication du code, 2024-2025). Faros AI, The Acceleration Whiplash (télémétrie sur 22 000 développeurs, 2026).
- Addy Osmani, Agentic Code Review (2026) : synthèse de référence sur la revue de code à l’ère des agents (reprend les données GitClear et Faros) ; source de l’écart « 4× de code / +12 % de valeur ».
- Lionel Chaine (DSI Bpifrance), L’écriture est résolue, la compréhension elle ne l’est pas (LinkedIn, 2026) : écho côté dirigeant, en environnement régulé.
Les données chiffrées évoluent à chaque édition de ces rapports. Vérifiez-les à la source avant toute reprise publique.