84% des Devs Utilisent l'IA. 29% Lui Font Confiance. La Compétence Manquante N'est Pas la Révision. C'est le Refus.

11 min read

Il y a deux jours, j'ai ouvert mon tableau de bord Claude Code. Je voulais voir combien de sorties j'avais tuées (tuées avant relecture, avant diff, tuées parce que trois secondes suffisaient pour voir que le truc n'était pas récupérable...). Le ratio m'a giflé. L'immense majorité des sorties brutes n'ont jamais passé mon premier filtre. Pas relisables. Pas réparables. Juste de la merde. (admettez-le, vous avez le même graphique qui vous attend)

En 2024 je réparais. En 2026 je refuse. Ce n'est plus le même métier.

TLDR : Stack Overflow a publié son enquête 2025. 84% des devs utilisent l'IA, 29% lui font confiance. Entre ces deux chiffres, un gouffre. Tout le monde l'a nommé. Sonar l'appelle le Verification Gap. Osmani l'appelle le Problème des 70-80%. Tout le monde a prescrit le même remède : mieux relire, plus relire, relire avec de meilleurs outils. Sauf que relire présuppose que la sortie soit relisable. Et quand elle ne l'est pas, chaque minute de relecture est une taxe. Il y a une compétence que personne n'a encore écrite. Celle qui arrive avant la relecture.

Développeur pointant avec assurance du code inventé sur son écran tandis qu'un collègue tient la vraie documentation API avec frustration ; illustration style BD cubicules années 90.
Quand votre IA compile mieux la fiction que la réalité.

Le Chiffre Que Je Ne Voulais Pas Voir

Un ami m'a demandé combien de sorties de Claude Code je garde réellement. J'ai dit "la plupart" parce que c'est ce que je supposais. Puis j'ai tiré /insights. La plupart n'était pas la réponse.

Le graphique montrait quelque chose que je faisais sans le nommer. Je ne "réparais" pas les sorties IA la plupart du temps. Je les refusais. Trois secondes de scroll, un coup d'œil à la liste des fichiers, un regard aux signatures de fonctions, et le truc partait en git reset --hard. Pas de relecture. Pas de diff. Pas d'investigation. Tué.

Ce qui m'embêtait n'était pas le taux de kill. C'était la réalisation que je faisais ça depuis des mois sans l'appeler quoi que ce soit. Il n'y a pas de section pour ça dans aucun article sur le coding IA que j'ai lu. Personne ne l'enseigne. Personne ne le benchmark. Le :wq de l'ère IA. Personne ne le ship comme feature parce que personne ne l'a encore vu.

Alors j'ai commencé à faire attention. Qu'est-ce qui rend une sortie refusable en trois secondes ? Quels signaux est-ce que je lis sans réfléchir ? Pourquoi les juniors continuent à "essayer de faire marcher" quand le bon move c'est reset --hard ?

Cinq signaux revenaient sans cesse. Même forme à chaque fois.

Tout Le Monde A Nommé La Même Chose

L'enquête 2025 de Stack Overflow est sortie avec les chiffres que tout le monde a cités. 84% des développeurs utilisent maintenant ou prévoient d'utiliser des outils IA, contre 76% l'année précédente. La moitié de la profession les utilise quotidiennement. La confiance dans la précision est tombée de 40% à 29%. Seulement 3% rapportent une confiance élevée. 46% se méfient activement de leurs propres outils. 66% disent que l'IA leur donne du code qui est "presque bon mais pas tout à fait." 45% trouvent que débugger du code généré par IA est plus lent qu'écrire from scratch.

Presque la moitié de la profession passe maintenant plus de temps à débugger l'IA qu'elle n'en passerait à écrire le truc elle-même. L'adoption grimpe quand même.

Sonar a mené sa propre enquête, publiée en janvier. Échantillon différent, même forme : 96% ne font pas entièrement confiance à la sortie, et seulement 48% la vérifient réellement. Ils ont inventé un terme pour le gouffre : Verification Gap. Nom propre, mauvais diagnostic.

Addy Osmani a théorisé le même phénomène sous un autre angle dans "The 80% Problem in Agentic Coding." L'IA résout 80% du problème en minutes. Les 20% restants coûtent exactement ce qu'ils coûtaient avant. Il a cité Karpathy disant : "Je programme vraiment surtout en anglais maintenant," décrivant le flip où le travail humain se réduit aux édits et retouches. Il a cité Boris Cherney, qui a construit Claude Code, disant qu'essentiellement tout le code d'Anthropic est maintenant écrit par Claude lui-même. C'est le plafond du paradigme actuel.

Tous ces morceaux pointaient vers un vrai problème. Tous ont prescrit le même remède. Mieux relire. Construire des outils de relecture. Embaucher des relecteurs AI-fluent. Ajouter des couches de vérification.

Sauf que le remède présume que le patient est traitable. J'ai écrit sur ce mauvais diagnostic exact quand Bloomberg a sorti son article de panique productivité le mois dernier : Bloomberg is diagnosing the wrong disease. L'industrie continue de nommer les symptômes et rate le traitement. La relecture ne marche que sur des sorties relisables.

Le Remède Relecture Scalait Pour Un Dev. Ça Casse À 150 Agents.

Le playbook relecture n'était pas faux. Il était juste pour la forme du travail en 2023.

Un dev, une sortie, une PR, un relecteur. Tu lis le diff. Tu comprends ce que le modèle a essayé. Tu corriges. Tu merges. Le coût était linéaire, et les chiffres d'Osmani disent qu'il a grandi : les PRs ont grossi d'environ 18% avec l'adoption IA, les incidents par PR ont grimpé d'environ 24%, les taux d'échec de changement up près de 30%. Douloureux, mais traitable. Tu pouvais embaucher plus de relecteurs. Tu pouvais ajouter des outils de diff. Tu pouvais resserrer les templates de PR.

Tout ce playbook présuppose que le dev est le goulot de lecture. Quand tu génères cinq sorties par jour, lire est faisable. Quand tu en génères cinquante, tu es déjà sous l'eau. Quand tu en génères plus que ça, lire chaque diff n'est pas juste lent, c'est physiquement impossible.

Alors le remède relecture change discrètement de forme. "Lire chaque ligne" devient "faire confiance à l'agent-relecteur pour lire chaque ligne pour toi." C'est comme ça qu'on finit avec /ultrareview et ses cousins. Relecture déléguée en aval. Mais la délégation n'est pas le même move que le refus, et j'y reviendrai.

Le goulot a arrêté d'être la lecture. Il a bougé vers la décision avant que la lecture arrive : est-ce que cette sortie vaut la peine d'être lue du tout ?

Le refus est la nouvelle étape de compilation. Ça tourne avant la lecture.

Les Cinq Signaux de Refus Immédiat

La plupart de mes refus rentrent dans cinq patterns. Aucun n'a besoin d'un diff. Aucun n'a besoin d'investigation. Ce sont des signaux qu'on apprend à lire en cramant des heures sur les sorties qui nous ont appris.

Signal 1 : API Fabriquée. Le modèle invente une fonction, un endpoint, une méthode de librairie. Une fois que ça arrive une fois dans la sortie, tout le truc est structurellement contaminé. L'appel halluciné est assis dans une logique qui a été construite en supposant que l'appel existe. La logique est donc façonnée par un mensonge. Réparer la ligne ne répare pas la sortie, ça répare le symptôme. Refuser. Re-prompter avec la vraie surface API en contexte. Prend deux minutes au lieu de vingt.

Signal 2 : Contrat Cassé. Tu as écrit une contrainte dans le prompt. "SQL seulement, pas d'ORM." "Ne touche pas au middleware auth." "Fonctions pures, pas d'effets de bord." Et la sortie le viole. Pas parce que le modèle a oublié. Parce que le modèle a décidé que sa façon était meilleure. Tu ne renégocies pas un contrat après livraison. Le point d'un contrat c'est qu'une violation n'est pas un bug que tu patches, c'est un trigger pour refus. J'ai écrit le framework complet de contrats de prompt autour de ce move exact. Le contrat est ce qui rend le refus rapide. Pas de contrat, pas de refus, seulement de la relecture sans fin.

Signal 3 : Time-to-Understand Dépasse Le Seuil. Tu fixes le diff depuis dix minutes. Tu ne peux toujours pas dire ce que le modèle essayait de faire. Depuis Opus 4.7, sorties confiantes ne veut pas dire sorties lisibles. Quand ton time-to-understand dépasse ton time-to-rewrite, refuse. Réécrire from scratch n'est pas un échec, c'est un move. Le modèle a généré un échafaudage que tu n'as pas demandé. Poubelle l'échafaudage. Demande encore avec une meilleure spec.

Signal 4 : Écritures Hors-Scope. Tu as demandé un fix sur un fichier. La sortie en touche trois autres. Ton cerveau fait laisse-moi juste checker ce qui a changé dans les autres. Cette phrase est un piège. Le modèle a choisi de réécrire des trucs que tu n'as pas autorisés. La question n'est pas "est-ce que les autres changements sont corrects." La question est "est-ce que je les ai autorisés." Non ? Refuse. Re-prompte avec un scope de fichier explicite. Et oui, tu vas perdre les bonnes parties qui étaient dans les écritures hors-scope. C'est la taxe pour ne pas avoir refusé plus tôt.

Signal 5 : "Laisse-moi tester et voir." Le modèle lance quelque chose, le regarde foirer, puis le "répare" en devinant. Pas de théorie sur pourquoi le fix devrait marcher. Pas d'explication sur pourquoi l'original a foiré. Juste du patching stochastique contre la sortie du dernier run. Ce n'est pas de l'engineering, c'est while true; do; pray; done. Refuse. Prompte encore avec la stack trace, la cause suspectée, et une demande de diagnostic, pas de patch.

Ces cinq couvrent facilement neuf kills sur dix. Le reste c'est juste des trucs bizarres. Des modèles qui ont une mauvaise journée. Des prompts auxquels j'aurais dû réfléchir plus longtemps. Pas la peine d'un framework.

Cinq signaux. Trois secondes chacun. Quinze secondes pour sauver une matinée.

Pourquoi Refuser Est Culturellement Dur

Le réflexe dev c'est "faire marcher." Trente ans de ce réflexe. Print statements à 2h du mat, onglets Stack Overflow empilés, la satisfaction de remettre en forme un truc cassé. C'est l'identité centrale de la profession pour beaucoup d'entre nous.

L'ère IA casse ce réflexe d'une façon spécifique. Avant, le code cassé était cassé parce que tu l'avais mal écrit. Le réparer t'apprenait quelque chose. Maintenant, le code cassé est cassé parce qu'un modèle stochastique a mal samplé. Le réparer ne t'apprend rien, parce qu'il n'y a pas de pattern répétable à internaliser. Tu ne débugges pas une erreur, tu polis à la main une pièce qui a été mal frappée.

Le réflexe senior, "je peux toujours sauver ça", c'est exactement le truc qui te coûte. Ton pattern matching est si bon pour mapper code cassé vers "voici le fix" que tu entres en mode sauvetage automatiquement. Tu ne remarques pas que tu sauves depuis quarante minutes sur un truc qui aurait pris trois minutes à re-prompter. Les 45% de devs qui disent à Stack Overflow que débugger l'IA est plus lent qu'écrire from scratch ? Beaucoup sont des seniors. Ils y sont arrivés parce que leur réflexe de sauvetage est trop fort pour laisser mourir une sortie.

Le muscle du refus fait mal parce qu'il va contre trois décennies de "les bons devs n'abandonnent pas." Tu ne tries pas un patient. Tu fermes un mauvais onglet.

Ce Que 150 Agents M'Ont Appris Sur Le Taux De Refus

Je fais tourner environ 150 agents IA sur ma stack. Certains génèrent du code. Certains écrivent de la copy. Certains classifient des signaux. Certains font de l'ops. À cette échelle tu ne peux pas tout relire. Tu ne peux même pas tout réparer. Tu peux seulement refuser vite et re-prompter.

Les maths sont brutales. Si tu acceptes une sortie qui devait être refusée, le coût n'apparaît pas aujourd'hui. Il apparaît trois semaines plus tard, quand un comportement bizarre en prod remonte à une ligne que personne n'a comprise quand elle a shippé. L'analyse multi-années de GitClear, qu'Osmani a citée, a vu la duplication de code bondir de 48% et le refactoring s'effondrer d'un quart de tous les changements à moins d'un dixième. C'est la dette silencieuse. Accepté-quand-ça-aurait-dû-être-refusé, shippé, oublié, qui explose plus tard.

Les devs qui refusent trop tôt ratent des wins. Le modèle peut faire du bon travail. Tuer sa première tentative sur chaque tâche est du gaspillage. Le sweet spot n'est pas "refuse tout" ou "répare tout." C'est refuse vite, re-spec, accepte. Le cycle était prompt → relecture → fix. À 150 agents c'est prompt → triage trois-secondes → refuse ou accepte. La relecture vient seulement dans la branche accepte, et à ce moment-là la plupart des mauvaises sorties ont déjà été tuées.

La relecture c'est ce que tu fais après le triage. Le triage c'est le job.

Le Piège : /ultrareview Comme Acceptation Blanchie

Anthropic a shippé /ultrareview avec Opus 4.7. Relecture de code multi-agent : plusieurs agents lisent le diff, flaggent les problèmes, rapportent. Ça sonne comme la réponse à l'explosion de relecture qu'Osmani a décrite. Ça ne l'est pas.

La mécanique va comme ça. Tu reçois une sortie. Tu ne lui fais pas confiance. Tu lances /ultrareview. Trois agents la lisent. Ils trouvent deux petits trucs. Tu répares les petits trucs. Tu ships. Tu te sens relu.

Sauf qu'aucun de ces trois agents ne peut invalider le paradigme. Ils peuvent trouver des bugs. Ils peuvent trouver des problèmes de style. Ils ne peuvent pas te dire "cette approche est fausse, refuse tout le truc." Ils sont entraînés à trouver des problèmes, pas à tuer des sorties. C'est une différence subtile qui compte énormément en production.

Ce qui arrive en pratique : tu délègues la décision de refus à un agent dont l'architecture ne peut pas refuser. C'est Karen de la Compta qui approuve la note de frais parce que les maths collent, sans vérifier si le voyage aurait dû avoir lieu du tout. Les chiffres s'équilibrent, le voyage était un désastre.

Le piège c'est que /ultrareview donne l'impression de due diligence. Tu as relu. Plusieurs agents ont relu. Tout le monde a relu. Personne n'a refusé.

Pour être fair, /ultrareview est utile sur les changements non-critiques. Tests internes, boilerplate, refactoring niveau format, le genre de trucs où le paradigme est évidemment correct et tu veux juste des yeux supplémentaires sur l'exécution. Utilise-le là. Sur les chemins critiques, argent, auth, écritures de données, la décision de refus reste avec un humain. Pas parce que les humains sont plus intelligents, mais parce que les humains ont le droit de dire "recommence" et les agents non.

Si tu ne peux pas refuser, tu ne peux que patcher. Les systèmes patchés shippent plus vite. Ils meurent aussi plus tôt.

Le Test De Séniorité 2026

Le test de séniorité dev était "peux-tu débugger ça." Plus tard c'est devenu "peux-tu architecturer ça." Pendant un moment dans les années 2020 on aurait dit que ça devenait "peux-tu prompter ça."

En 2026 c'est autre chose. Combien tu refuses, et à quelle vitesse.

Pas combien tu ships. Pas combien tu relis. Pas à quel point ta PR est épaisse. Combien tu tues avant que ça draine ta journée. C'est la métrique qui sépare le dev qui a shippé 22 PRs hier du dev qui a passé la même journée à polir à la main trois sorties qui n'allaient jamais marcher.

Stack Overflow dit que 69% des devs rapportent que l'IA a boosté leur productivité personnelle. Je le crois. Le hic c'est où va le boost. Pour la plupart ça va dans le temps de relecture, parce que c'est le seul muscle qu'on leur a appris à utiliser. Pour quelques-uns ça va dans une boucle de refus plus courte, et ces quelques-uns shippent significativement plus que les autres.

L'industrie va continuer à empiler des outils de relecture. /ultrareview, diff multi-agent, IA qui relit l'IA. Les prompts vont devenir des specs, les specs vont devenir des plans, les plans vont devenir des cérémonies. Tout le monde ajoute une couche pour se sentir rassuré sur ce qui sort du pipe.

Pendant ce temps les devs qui shippent auront lâché le réflexe "je peux sauver ce code." Trois secondes de regard sur la sortie. Kill. Re-spec. On y retourne. Pas de drame, pas de diff héroïque à 2h du mat. Juste triage, puis retour au travail. 🔥

Stack Overflow a compté ce qu'on accepte. Le vrai indicateur 2026 c'est ce qu'on refuse.

Écris moins. Relis moins. Refuse plus. Shippe mieux.

Sources