« Vérifié » ne veut rien dire si personne ne vérifie le vérificateur

Il y a quelques semaines, j'ai validé un correctif d'affichage mobile. J'avais ouvert le site dans Chrome, réduit la fenêtre, regardé le rendu, tout semblait bon. Sauf que ma fenêtre réduite n'était pas la bonne résolution. Le bug était toujours là, sur de vrais téléphones, et j'avais coché la case « testé » avec une conviction totale. Personne ne m'avait menti. Je m'étais menti tout seul, avec un test qui avait l'air rigoureux et qui ne l'était pas.

En creusant pourquoi je m'étais planté, j'ai trouvé une deuxième couche à l'erreur : mon référentiel du responsive datait de dix ans, d'une époque où ça voulait dire « empiler les blocs proprement sur une largeur plus étroite ». Ce n'est plus la définition du mobile-first en 2026.

J'avais un test qui vérifiait la mise en page. Je pensais avoir vérifié l'usage mobile. Ce n'est pas la même chose.

Ce qui a fini par révéler le vrai problème n'était même pas prémédité. J'ai montré le site à des amis designers, dans un bar, et quelqu'un a sorti son téléphone. Rien n'allait. Ce n'est pas moi qui ai retesté plus sérieusement : c'est quelqu'un d'autre, sur un vrai device, dans un contexte que je ne contrôlais pas, qui a fait remonter en une minute ce que j'avais raté pendant des semaines. Le même point aveugle touchait d'autres personnes du design qui avaient déjà vu le site avant, sur ordinateur : elles aussi avaient un vérificateur, leurs propres yeux sur desktop, avec exactement le même angle mort que le mien.

C'est ce détail qui m'intéresse en ce moment, plus que la question habituelle « l'IA code-t-elle bien ou mal ». Parce que le vrai sujet, en 2026, n'est plus la génération. C'est la vérification. Et la vérification a le même problème que le code qu'elle est censée surveiller : elle peut avoir l'air propre et être fausse.

Le buzz : « j'ai vérifié, ça marche »

Sur LinkedIn, la promesse a changé de forme mais pas de fond. On ne dit plus « l'IA écrit le code », on dit « l'IA vérifie le code », comme si le mot suffisait à garantir le résultat. Un agent qui relit une PR, un test qui passe au vert, un score Lighthouse qui grimpe : tout ça a l'apparence de la preuve. C'est exactement cette apparence qui m'a fait valider un bug mobile en pensant l'avoir corrigé.

Ce que ça cache : la vérification hérite des angles morts du vérificateur

Le problème n'est pas que l'outil ment. C'est qu'un vérificateur qui travaille dans les mêmes conditions, avec les mêmes biais, que celui qui a produit le résultat, ne voit pas ce qu'il ne sait pas regarder. Mon navigateur n'a pas menti, il a fidèlement affiché la mauvaise résolution que je lui avais demandée. Le test a réussi. Il mesurait juste la mauvaise chose.

Ça rejoint quelque chose de plus large que mon anecdote. En juillet 2025, METR (une organisation de recherche sur l'évaluation des IA) a publié un essai contrôlé randomisé sur 16 développeurs open source expérimentés, environ 246 tâches réelles sur des dépôts matures qu'ils connaissaient déjà. Avec l'IA autorisée (Cursor Pro + Claude Sonnet), trois chiffres racontent trois histoires différentes :

Un seul de ces trois chiffres reflète ce qui s'est réellement passé, et ce n'est ni l'anticipation ni le souvenir.

Ce qui m'intéresse, c'est l'écart entre la perception et la mesure. Ces développeurs n'étaient pas négligents, ils avaient l'impression sincère d'avoir vérifié que ça allait plus vite. Exactement comme j'avais l'impression sincère d'avoir vérifié mon rendu mobile.

Pourquoi c'est plus complexe : celui qui produit est un mauvais juge de ce qu'il a produit

Il y a un nom pour ce biais dans la littérature récente sur les agents de code : la premature confidence. L'agent (ou le développeur) qui vient de produire un résultat est structurellement mal placé pour le remettre en cause, parce qu'il regarde sa propre production avec les hypothèses qui l'ont menée à ce résultat. Mon hypothèse de départ était « la fenêtre réduite du navigateur suffit » : je n'allais pas la remettre en question au moment de vérifier, c'est la même hypothèse qui pilotait le test.

C'est pour ça que « l'IA vérifie le code » ne veut rien dire tant qu'on ne sait pas qui vérifie et dans quelles conditions. Un modèle qui relit son propre patch avec le même contexte, le même prompt, la même compréhension de la tâche, n'est pas un vérificateur indépendant. C'est le même biais qui se retourne pour se féliciter.

Ce qui fonctionne : ne jamais laisser celui qui produit être celui qui valide

La réponse structurelle, ce n'est pas plus de tests, c'est une séparation nette des rôles. Ce n'est pas une idée neuve : la revue de code croisée entre humains, le test contre un environnement de staging distinct de la machine de dev, les tests de non-régression visuels automatisés, tout ça vise le même principe. Le pattern que j'utilise depuis plusieurs mois en est une instance appliquée aux agents IA, que j'ai appelé « générateur / critique », en clin d'œil aux GAN (Generative Adversarial Networks, réseaux antagonistes génératifs) : en apprentissage automatique, ce sont deux réseaux de neurones mis en compétition, l'un qui génère, l'autre qui juge, chacun progressant en essayant de déjouer l'autre. Transposé au code : un agent produit, un second agent, avec un prompt différent, parfois un modèle différent, a pour seul travail de chercher ce qui cloche, sans complaisance, jusqu'à ce qu'un score de qualité soit atteint. Le générateur ne note jamais sa propre copie.

Concrètement : sur un audit mobile récent, mon générateur avait validé des boutons d'appel à l'action entre 16 et 20 pixels de haut, une taille raisonnable à l'œil sur un écran d'ordinateur. Le critique, en session séparée, a chargé le site sur un vrai viewport mobile (375px, puis 320px), jamais en fenêtre desktop redimensionnée, et a mesuré chaque cible directement dans le DOM (getBoundingClientRect) plutôt que sur une capture d'écran : un screenshot ne révèle pas la taille réelle d'une zone cliquable. Il a immédiatement pointé que c'était sous les seuils WCAG et sous les référentiels Apple et Google cités plus haut. Correction : padding ajusté (avec un margin négatif pour ne pas changer le rendu visuel) pour remonter à 44 pixels de cible réelle sans agrandir le bouton à l'écran. Le générateur n'avait pas menti, il avait validé sa propre production avec le même point aveugle que celui qui l'avait écrite. Même défaut que dans l'anecdote d'ouverture, retrouvé sur un projet différent, avec un rôle explicitement séparé cette fois pour l'attraper.

Le même primat de la mesure sur l'intuition vaut pour la couleur : un contraste ne se valide jamais couleur par couleur, seulement en paire avec un fond précis, comme je le détaille ailleurs.

Il y a quelque chose d'assez amusant dans ce clin d'œil : les GAN datent de 2014, du papier fondateur d'Ian Goodfellow, bien avant l'ère des LLM. Le même principe, générateur contre discriminateur, s'applique aujourd'hui à une échelle différente : non plus deux réseaux entraînés ensemble sur des millions d'itérations, mais deux appels à un LLM déjà entraîné, l'un pour produire, l'autre pour critiquer, dans une seule session de travail.

Je ne suis visiblement pas le seul à être arrivé à cette conclusion. Anthropic a formalisé début 2026 un principe équivalent dans Claude Code : une équipe d'agents cherche les bugs en parallèle, puis une phase distincte de vérification filtre spécifiquement les faux positifs avant le classement par sévérité. Résultat mesuré et publié : moins de 1 % des signalements sont jugés incorrects par les ingénieurs qui relisent ensuite. Même logique que mon générateur/critique, avec une nuance importante : le vérificateur est délibérément séparé de la phase de détection, pour éviter d'hériter du même angle mort. Anthropic documente la même philosophie de séparation des rôles côté sécurité, dans sa description de la façon dont elle « contient » Claude.

Ramené à mon histoire de résolution mobile, la leçon tient en une phrase : un test qui vérifie dans les mêmes conditions que celles qui ont produit le bug ne vérifie rien, il confirme. La vraie vérification demande quelqu'un (ou quelque chose) qui n'a pas les mêmes présupposés que celui qui a fait le travail, et des conditions de test rendues explicites plutôt que supposées. Ça ne prend pas plus de temps. C'est juste la seule façon d'avoir une case « testé » qui veuille dire quelque chose.