Des expérimentations aux arbitrages
La période où le rôle d’une direction technique consistait à « lancer des expérimentations IA » est terminée. Les outils sont déployés, les budgets sont engagés, les équipes les utilisent quotidiennement. La question n’est plus l’adoption, le rapport DORA 2025 situe à 90 % la proportion de professionnels de la tech utilisant l’IA au travail.
La question est devenue : qu’est-ce qu’on en retire, et au prix de quoi.
Le chiffre le plus cité sur ce point vient du rapport State of AI in Business du MIT (2025), fondé sur l’examen de plus de 300 initiatives publiques, 52 entretiens et 153 réponses de dirigeants : 95 % des pilotes d’IA générative n’ont produit aucun impact mesurable sur le compte de résultat. Seules 5 % des organisations ont atteint un déploiement à l’échelle.
Le diagnostic du MIT mérite d’être retenu, parce qu’il est contre-intuitif : l’échec n’est pas dû à la qualité des modèles ni à l’infrastructure. Il est dû à ce que les auteurs appellent le learning gap, les systèmes déployés ne retiennent pas les retours, ne s’adaptent pas au contexte et ne s’améliorent pas avec l’usage. Ils restent des « projets scientifiques » à côté du flux de travail réel.
Ce n’est pas un problème technologique. C’est un problème d’arbitrage. En voici quatre.
Arbitrage 1 : Piloter sur des données, alors que le ressenti ment
Le premier obstacle est épistémologique, et il est sous-estimé.
L’étude contrôlée randomisée publiée par METR en 2025 a mesuré un ralentissement de 19 % chez des développeurs open source expérimentés travaillant avec des outils d’IA sur leurs propres dépôts. Le détail important n’est pas le ralentissement, l’échantillon est réduit et les auteurs en posent eux-mêmes les limites. Le détail important est la perception : les participants anticipaient un gain de 24 %, et après l’expérience, ils estimaient encore avoir gagné 20 %.
L’écart entre productivité perçue et productivité réelle est d’environ quarante points, et il persiste après l’expérience directe du contraire.
Conséquence pour une direction technique : toute décision fondée sur le retour d’expérience de l’équipe est fondée sur une donnée biaisée. Ce n’est pas un procès fait aux développeurs ; c’est une propriété de la situation. L’IA supprime des temps d’attente visibles et frustrants, chercher une syntaxe, écrire du code répétitif, et ajoute des temps de vérification diffus et peu mémorables. La mémoire ne pondère pas ces deux catégories de la même façon.
Ce qu’il faut mesurer à la place : les quatre indicateurs DORA, délai de mise en production, fréquence de déploiement, taux d’échec des changements, temps de rétablissement, complétés par deux indicateurs de qualité structurelle : taux de duplication et churn à deux semaines. Ce sont les seuls qui résistent à l’optimisme.
Ce qu’il ne faut pas mesurer : lignes de code, nombre de pull requests, tickets fermés, « taux d’adoption de l’outil ». Ces indicateurs étaient déjà médiocres ; ils sont désormais activement trompeurs, parce que l’IA les améliore tous sans garantie sur le résultat.
Arbitrage 2 : Outiller ou consolider
C’est l’arbitrage le plus structurant, et le rapport DORA 2025 lui donne un nom utile : l’effet amplificateur. L’IA ne transforme pas une organisation, elle amplifie ce qu’elle est déjà. Une équipe disposant d’une plateforme solide, de tests automatisés sérieux et d’une culture de revue exigeante en tire un levier considérable. Une équipe à l’outillage fragmenté et à la couverture de tests approximative accélère simplement sa propre dégradation.
DORA associe d’ailleurs une forte adoption de l’IA à une hausse simultanée du débit de livraison et de l’instabilité.
La question pour un CTO n’est donc pas « quel outil d’IA déployer » mais « mon organisation est-elle en état d’être amplifiée ? »
Le test est simple et se fait en quatre questions :
Un changement peut-il aller du commit à la production sans intervention manuelle ?
La suite de tests détecte-t-elle une régression fonctionnelle réelle, ou seulement une erreur de compilation ?
L’analyse de sécurité est-elle automatisée dans la chaîne d’intégration ?
Sait-on, en production, qu’un incident a lieu avant qu’un client n’appelle ?
Si la réponse est non à deux de ces questions, l’euro suivant est plus rentable en consolidation qu’en licence supplémentaire. Ce n’est pas un conseil de prudence : c’est la conclusion directe de l’effet amplificateur.
Arbitrage 3 : La pyramide des compétences
C’est l’arbitrage le plus lourd de conséquences, et le seul qui soit réellement irréversible à l’échelle d’une entreprise.
Les données françaises sont nettes. D’après l’étude Numeum, les effectifs du secteur numérique ont reculé de 1,8 % entre 2023 et 2025, deuxième année consécutive de baisse, et 33 % des ESN ont réduit leurs recrutements de jeunes diplômés au premier semestre 2026.
Le phénomène est international. Le laboratoire d’économie numérique de Stanford, dans la mise à jour d’août 2026 de son étude Canaries in the Coal Mine, mesure que l’emploi des 22-25 ans dans les métiers les plus exposés à l’IA se situe environ 19 % en dessous de sa trajectoire attendue, un écart passé de 15 % un an plus tôt. Le point méthodologique essentiel : l’ajustement se fait par la réduction des embauches, pas par les licenciements. Et les chercheurs ne constatent pas de destruction d’emploi généralisée dans l’économie.
Le raisonnement qui conduit à ne plus recruter de juniors est parfaitement rationnel à court terme. L’IA fait très bien le travail d’entrée de gamme. Un junior coûte cher en encadrement pendant douze à dix-huit mois. Supprimer ce poste améliore immédiatement la marge.
Le problème est que ce travail d’entrée de gamme n’était pas seulement de la production. C’était le dispositif de formation qui fabriquait les seniors. Or ce sont précisément les seniors dont le besoin explose : l’écriture de code étant devenue peu coûteuse, le goulot d’étranglement s’est déplacé vers la revue et la vérification, activités qui reposent sur un jugement technique qu’on n’acquiert qu’en ayant écrit et cassé du code pendant des années.
Addy Osmani formule la distinction de façon nette : les seniors utilisent l’IA pour accélérer ce qu’ils savent déjà faire ; les juniors l’utilisent pour apprendre quoi faire. Les résultats n’ont rien à voir.
L’arbitrage réel n’est donc pas « junior ou IA ». Il est temporel : une marge améliorée maintenant contre une capacité de jugement disponible dans quatre ans. Le coût de la seconde option n’apparaît dans aucun tableau de bord trimestriel, et c’est précisément pour cela qu’elle est systématiquement sacrifiée.
Une organisation qui décide de continuer à former doit alors changer le contenu de la formation : si le junior n’apprend plus en écrivant du CRUD, il doit apprendre en lisant, en critiquant et en corrigeant du code généré, sous supervision. C’est un autre métier d’encadrant, et il faut le doter.
Arbitrage 4 : Décider ce qui n’est pas généré
Le quatrième arbitrage est le plus simple à poser et le plus rarement formalisé : où la génération assistée est-elle interdite ?
L’argument n’est pas idéologique, il est actuariel. Les tests Veracode de 2026, portant sur plus de 150 modèles, situent à environ 55 % le taux de code généré passant les contrôles de sécurité sur des classes de vulnérabilités classiques, un niveau inchangé depuis deux ans, alors que la correction syntaxique passait de 50 % à plus de 95 %. Les modèles ont appris à écrire du code qui marche, pas du code qui résiste.
Une politique utile tient en une page et couvre quatre points : les zones où la génération est libre (outillage interne, tests, prototypes, scripts jetables) ; les zones où elle est autorisée sous revue renforcée (fonctionnalités clientes) ; les zones où elle est proscrite (authentification, gestion des données personnelles, logique de facturation, abstractions structurantes) ; et la règle de traçabilité, qui a validé, sur quelle base.
Cette page n’existe pas dans la majorité des organisations. Elle vaut pourtant plus qu’un comité IA.
Le piège du benchmark
Un dernier point, moins opérationnel mais déterminant.
La pression concurrentielle actuelle pousse à comparer sa vitesse d’adoption à celle des autres. C’est un mauvais repère, pour une raison que le chiffre du MIT rend évidente : si 95 % des initiatives ne produisent aucun impact mesurable, alors s’aligner sur la moyenne du marché revient à s’aligner sur l’échec.
La question pertinente n’est pas « où en sont les autres ». Elle est : sur quel processus précis, avec quelle mesure avant et après, pour quel gain vérifié. C’est une question moins confortable, parce qu’elle expose. C’est aussi la seule qui distingue les 5 % du reste.
Questions fréquentes
**Pourquoi la plupart des projets d’IA en entreprise échouent-ils ? ** D’après le rapport State of AI in Business du MIT (2025), 95 % des pilotes d’IA générative ne produisent aucun impact mesurable. La cause identifiée n’est pas la qualité des modèles mais le learning gap : les systèmes déployés ne retiennent pas les retours, ne s’adaptent pas au contexte et restent à côté du flux de travail réel.
**Quels indicateurs suivre pour piloter l’impact de l’IA sur une équipe technique ? ** Les quatre indicateurs DORA (délai de mise en production, fréquence de déploiement, taux d’échec des changements, temps de rétablissement), complétés par le taux de duplication de code et le churn à deux semaines. À éviter : lignes de code, nombre de pull requests, taux d’adoption de l’outil.
**Faut-il encore recruter des développeurs juniors en 2026 ? ** C’est un arbitrage temporel, pas technique. Le travail d’entrée de gamme est largement absorbé par l’IA, mais c’est aussi le dispositif qui formait les seniors, dont le besoin augmente puisque la revue et la vérification sont devenues le goulot d’étranglement. En France, 33 % des ESN ont réduit leurs recrutements de jeunes diplômés au premier semestre 2026.
**Sur quelles parties d’un système faut-il éviter la génération de code ? ** En pratique : authentification, gestion des données personnelles, logique de facturation et abstractions structurantes. Les tests Veracode 2026 situent à environ 55 % le taux de code généré passant les contrôles de sécurité de base, un niveau stable depuis deux ans.
Sources
MIT, State of AI in Business 2025 (synthèse des principaux résultats)
DORA, Balancing AI tensions (2025)
METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
Stanford Digital Economy Lab, Canaries in the Coal Mine, mise à jour août 2026
Numeum, Étude sur le marché du numérique français
Veracode, Spring 2026 GenAI Code Security Update
Addy Osmani, AI Won’t Kill Junior Devs, But Your Hiring Strategy Might