84 % des devs utilisent des outils de AI coding. Seulement 29 % font confiance à ce qui ship.

Les chiffres sont tombés le mois dernier. Le survey dev de Stack Overflow montrait que 84 % des devs utilisent désormais des outils de AI coding. L'usage a plafonné près de la saturation. La question de l'adoption est réglée.

Ce qui n'est pas réglé : la confiance. Seulement 29 % des devs font confiance au output de leurs outils IA. Ce chiffre a baissé de 11 points par rapport à l'année précédente. Usage stable, confiance en chute. Un marché de 12,8 milliards de dollars où les devs continuent de payer pour des outils auxquels ils ne croient pas.

La plupart des commentaires cadrent ça comme un problème de modèle. Meilleur raisonnement, moins d'hallucinations, plus grandes context windows. Attends assez longtemps et le gap se referme tout seul. Cela fait plus d'un an que je ship du code en production avec Claude Code. Je pense que cette analyse rate complètement le point.

Les données de production racontent une histoire plus dure

Stack Overflow mesure ce que les devs ressentent vis-à-vis des outils IA. Le rapport 2026 State of AI-Powered Engineering de Lightrun mesure ce qui se passe après que le code ship réellement. Ces données sont plus difficiles à balayer d'un revers de main.

43 % des changes de code généré par IA ont besoin de debug manuel en production. Pas pendant la code review. Pas en staging. Après déploiement sur des systèmes live qui servent des users réels.

88 % des teams ont besoin de deux à trois cycles de redéploiement complets pour confirmer qu'un seul fix suggéré par IA fonctionne. Personne ne ship du code IA une fois et ne s'en va. Cet overhead de vérification mange de vraies heures d'engineering chaque semaine.

Un point ressort au-dessus des autres : zéro pour cent des 200 SRE et DevOps leads que Lightrun a interrogés se sont décrits comme « très confiants » que le code généré par IA se comporterait correctement en production. Pas un seul.

Les conséquences sont arrivées vite. En mars, Amazon a eu deux outages majeurs tracés jusqu'à des changes de code assistés par IA déployés sans review humaine adéquate. Un outage a causé une baisse de 99 % du volume de commandes aux US. 6,3 millions de commandes perdues sur un seul incident. Pas une hallucination du modèle. Un gap de process : des changes générés par IA poussés en live sans la couche de review pour attraper les problèmes avant les users.

Pourquoi la confiance baisse pendant que l'usage monte

Ce pattern a du sens une fois que tu regardes comment la plupart des devs travaillent réellement avec ces outils.

La plupart des gens ont adopté les outils de AI coding comme de l'autocomplete avancé. Tab-complete une fonction, accepte une suggestion, passe à la suite. Ça marche pour le boilerplate, pour les test stubs, pour le code que tu comprends assez bien pour le scanner avant de committer.

Les problèmes commencent quand ce même workflow s'étend à du code complexe. Un composant qui interagit avec trois services. Une migration de données avec des edge cases. Un flow d'auth qui gère cinq états user différents. Du code qui a l'air correct, qui passe un scan visuel, qui passe même les tests unitaires. Puis qui casse en production sous des conditions que l'IA n'avait pas anticipées et que le dev n'avait pas pensé à vérifier.

J'ai vu ça en direct. Claude Code peut produire un output excellent sur une codebase qu'il comprend bien. Sur une codebase sans conventions, sans type safety, et sans guardrails d'architecture, le même modèle produit du code qui a l'air plausible et qui fail en production. Même outil. Conditions différentes. Résultats différents.

66 % des devs disent galérer avec des suggestions IA qui sont « proches mais qui ratent la cible au final ». Pas évidemment fausses. Subtilement fausses. Fausses d'une façon que tu découvres à 2h du mat' quand les alerts de monitoring commencent à tirer.

45 % disent que debug du code généré par IA prend plus de temps que de l'écrire eux-mêmes. C'est la boucle d'expérience qui tue la confiance. Tu gagnes 30 minutes à la génération. Tu passes 2 heures au debug. Net négatif. Fais ça assez de fois et la confiance s'érode, même si tu continues à utiliser l'outil parce qu'il reste plus rapide pour le travail de routine.

Ce n'est pas qu'un problème individuel non plus. Le marché des outils de AI coding a optimisé agressivement pour l'adoption : installs faciles, free tiers généreux, demos impressionnantes. Très peu de cet investissement est allé dans apprendre aux devs comment travailler avec ces outils de façon fiable. Les outils se sont améliorés. La méthodologie est restée où elle était.

Ce qu'ont compris les devs qui font confiance au output IA

Les 29 % qui font confiance à leurs outils ne sont pas naïfs. Ils n'utilisent pas un modèle secret. Ils ont construit un système différent autour des mêmes outils que tout le monde.

En faisant tourner Claude Code quotidiennement sur une app en production, j'ai vu trois choses qui séparent les workflows IA fiables des workflows non fiables.

La structure de la codebase fait l'essentiel du travail. Un repo avec des conventions claires, des interfaces typées, une organisation de fichiers qui a du sens, et un fichier CLAUDE.md qui dit à l'agent avec quoi il travaille produit un output nettement meilleur qu'un repo bordélique associé à un prompt malin. Ton agent lit la codebase avant d'écrire quoi que ce soit. Si ta codebase ne communique rien, le output le reflète. Pas un problème de prompting. Un problème d'infrastructure que la plupart des devs ne traitent jamais.

Les checkpoints de review transforment le risque en confiance. L'incident d'Amazon en mars est arrivé parce que du code IA a ship sans review adéquate. Les devs qui font confiance au output IA n'ont pas éliminé la review. Ils l'ont rendue structurelle, placée à chaque checkpoint qui compte. L'agent propose, l'humain décide. Quand cette discipline est en place, la confiance se gagne par vérification répétée, pas par foi.

Le design de session compte plus que le choix du modèle. Les longues sessions IA se dégradent. Context rot. Ton agent perd discrètement le fil des contraintes que tu as posées il y a 40 minutes. Les devs qui comprennent ça structurent leur travail en sessions focus avec un scope clair. Ils gèrent le budget de context. Ils savent quand repartir sur du frais au lieu de pousser une session périmée plus loin. Quasiment personne n'enseigne cette compétence parce qu'elle n'existait pas comme concept avant que les coding agents fassent partie du travail quotidien.

Aucune de ces choses n'est une technique avancée. Ce sont des décisions structurelles qui prennent des jours à mettre en place et qui tournent ensuite discrètement derrière chaque session. La plupart des devs ne les prennent jamais délibérément. C'est ça, le gap.

Je creuse le design de session, les budgets de context et la mise en place de process de review fiables dans le cours d'agentic coding.

Un gap de méthodologie, pas un gap de technologie

Les context windows vont continuer de grandir. Le raisonnement va s'améliorer. Les modèles vont devenir meilleurs sur les edge cases. Rien de tout ça ne referme le trust gap tout seul.

Autre chose est en train de se passer dans l'espace tooling en ce moment. Les devs stackent Cursor, Claude Code et Codex dans des workflows parallèles. Plus de capacités, plus de puissance. Mais plus d'outils sans méthodologie, ça veut dire plus de surface pour des failures subtiles. La couverture n'est pas le bottleneck. Le process l'est.

Une context window de 1M tokens ne sert à rien si tu ne structures pas tes sessions pour bien l'utiliser. Un modèle plus rapide ne fixe pas une codebase qui ne donne à l'agent rien de cohérent avec quoi travailler. Computer use et capacités agentic n'ont aucune importance si rien ne s'intercale entre le output de l'agent et la production.

Les devs qui vont refermer ce gap seront ceux qui arrêtent d'attendre un meilleur modèle et qui commencent à construire le système qui rend les modèles actuels fiables. Tes outils sont capables. Que tu aies construit les conditions pour qu'ils soient dignes de confiance, c'est une autre question.

C'est ça qui sépare les 84 % des 29 %. Pas le modèle. La méthodologie.

Le trust gap est un problème structurel avec un fix structurel. Construire le système qui rend le code généré par IA digne de confiance, c'est ce que couvre le cours d'agentic coding. Commencer le cours.