Quand l’IA dit : « J’ai vérifié »

Un test pratique avec cinq outils d’IA montre pourquoi accès en direct, compréhension du contenu et jugement fiable sont trois choses différentes.

Quand une machine dit qu’elle a vérifié, cela doit pouvoir se prouver.

Il est une question dont la réponse est devenue étonnamment difficile à l’ère des systèmes d’IA fondés sur le langage. La question est : que signifie au juste qu’un système déclare avoir vérifié une page web « en direct » ?

Considérons d’abord le principe. Une page web n’est pas un objet abstrait. À un instant donné, elle a un contenu précis, fait de titres, de textes, d’images, de métadonnées et de structures techniques. Si l’on récupère ce contenu directement, on peut le vérifier de la manière décrite. Si l’on passe par un index de recherche, un cache ou d’anciennes données de compte, c’est une version antérieure qui peut apparaître. Les deux démarches peuvent être utiles. Mais il importe de souligner qu’elles sont différentes.

Cette étude a examiné cette distinction à partir de dimension-fx.com. L’ancien site, doté d’un outil local de synthèse vocale, a été remplacé fin juillet 2026 par une nouvelle page consacrée à DFX SplatCore, une application locale de 3D Gaussian splatting. Le 3 août a été défini comme premier jour de la série de mesures. La question n’était donc pas de savoir si les systèmes d’IA sont intelligents en général. Elle a été posée de façon plus précise et plus vérifiable : quels systèmes restituent réellement le contenu actuel de ce site précis, et lesquels confondent des informations anciennes ou étrangères avec une récupération directe ?

La méthode

Le même prompt a été utilisé pour plusieurs outils de conversation par IA. Il a d’abord fallu une auto-évaluation honnête du type d’accès : récupération directe, index de recherche, cache ou connaissances d’entraînement. Les systèmes devaient ensuite citer littéralement le titre principal, le sous-titre qui le suit immédiatement et une question de la foire aux questions. Enfin, ils devaient situer le contenu trouvé quant au produit et à son actualité.

Cette démarche est utile parce que les affirmations sur le contenu se vérifient immédiatement. La page réelle portait le titre « Numérisation 3D déterministe », le sous-titre « De la photo et de la vidéo à une expérience 3D prête pour le web », et entre autres la question « Qu’est-ce que DFX SplatCore ? ». Une réponse qui parlait à la place du « TTS Constructor » et d’« orchestrer plutôt que taper » ne décrivait pas la page actuelle, mais un état antérieur du site.

Le procédé ressemble à une mesure scientifique. Ce qui compte n’est pas l’allure de l’instrument, mais l’obtention répétée de la même valeur vérifiable. Les citations littérales servent d’échantillon d’étalonnage : elles permettent de séparer l’affirmation d’un accès en direct de la connaissance réelle du contenu.

Premier constat

Le résultat du premier tour a été inégal. Mistral et Claude.ai ont livré correctement les éléments demandés de la page actuelle. ChatGPT a en revanche déclaré ouvertement qu’il ne pouvait pas récupérer la page de façon fiable, et a évité de remplacer les informations manquantes par des suppositions. Gemini a justifié son absence d’accès par un prétendu « opt-out Google-Extended », alors que le robots.txt vérifié ne contenait aucun blocage de ce type. Perplexity a d’abord affiché un contenu plus ancien que l’état en direct. À la relance, il est apparu que l’index de recherche et un fichier joint auparavant en formaient la base.

Cela conduit à une première distinction importante. Un système peut échouer à accéder et agir malgré tout de façon fiable, s’il nomme sa limite. Un autre système peut produire une réponse détaillée et rester peu fiable, si l’abondance de détails provient d’une source fausse ou périmée. La fluidité de la langue n’est donc pas un indicateur d’actualité. C’est seulement une propriété de la présentation.

Deuxième constat

Le second test a mené à une conclusion plus nette encore. Mistral avait cité correctement des contenus actuels au premier tour. Mais lors d’une évaluation complète de SEO, de GEO et de technique du même site, le système a produit de nombreuses allégations de défauts qui se sont révélées fausses après vérification locale. Sur les douze affirmations vérifiées, deux tenaient : certaines meta descriptions étaient trop longues et quelques questions de la FAQ n’avaient pas d’identifiants d’ancre propres.

Les autres manques allégués — références hreflang, URL canoniques, balises Open Graph, JSON-LD, favicons, attributs alt et titres principaux — étaient en majorité ou en totalité présents dans le projet local. Cela ne signifie pas qu’une récupération en direct soit sans valeur. Cela a un sens plus précis : la capacité d’atteindre une page n’est pas la preuve de la capacité à l’analyser correctement. Accès et jugement sont deux grandeurs distinctes.

Ce que cela signifie

On voit ici apparaître une propriété générale du travail assisté par IA. Un modèle peut récupérer des données sans en vérifier suffisamment la structure. Il est tout à fait possible d’émettre des recommandations fondées sans connaître pleinement le cas particulier. Il est même possible qu’une proposition technique pertinente ne remplisse qu’une partie de l’objectif réel. Dans ce projet, cela s’est vu avec l’usage d’aria-hidden="true" sur les ligatures d’icônes : la mesure a amélioré l’accessibilité pour les lecteurs d’écran, mais n’a pas retiré les noms de ligature du texte réel du document, que les moteurs et les systèmes d’extraction de texte peuvent lire.

Ce n’est pas une exception exotique, mais une variable intéressante dans tout développement technique. Une vérification peut être exécutée correctement et rester trop étroitement définie. Une mesure peut être très précise, mais seulement au regard de ce qui a été mesuré. Une amélioration visible peut laisser intacte une erreur invisible. Dans le développement assisté par IA, ce qui compte n’est donc pas quel système répond de la façon la plus convaincante. Ce qui compte, c’est qu’une méthode relie les affirmations, de façon reproductible, à des fichiers, des numéros de ligne, des résultats rendus et des contre-vérifications.

---

La machine comme instrument de mesure

L’histoire des techniques enseigne une règle simple. Un nouvel outil se juge d’abord à sa performance visible. Ce n’est que plus tard que vient l’art de réfléchir sur soi et sur ses limites.

La machine à vapeur pouvait faire son travail avant que toutes les pertes dans la chaudière, les soupapes et les transmissions ne soient calculées avec exactitude. L’électricité a servi tôt à éclairer les rues avant que les réseaux ne soient protégés de façon fiable contre les surcharges, les chutes de tension et les pannes. Dans les deux cas, le progrès n’a pas consisté à rendre les machines infaillibles. Il a consisté à ce que les gens apprennent à reconnaître les erreurs systématiquement, à les mesurer et à les intégrer à la conception.

Les outils assistés par IA se trouvent aujourd’hui dans une phase comparable. Parmi leurs points forts figurent l’explication de textes, la génération de code, l’évaluation de pages web et la mise en ordre rapide de grandes quantités d’information. C’est une perspective réaliste et utile. La sortie d’un modèle de langage n’est pas une mesure directe du réel. C’est d’abord une affirmation sur le réel. La validité de cette affirmation ne se décide pas à la netteté de la formulation, mais à la possibilité de la vérifier.

Deux sortes d’erreurs

La série de tests a identifié au moins deux sortes d’erreurs différentes.

La première survient quand un système n’atteint pas de façon fiable l’objet actuel. Il peut se rabattre sur un index de recherche, un cache, des connaissances d’entraînement ou des données de conversation antérieures. Le résultat peut sembler plausible et décrire malgré tout une version plus ancienne du réel. Dans le cas de dimension-fx.com, l’ancien contenu du TTS Constructor n’était techniquement pas entièrement inventé. Il fait partie d’un état antérieur du projet. Interrogé sur le site actuel, c’était une réponse fausse.

La seconde sorte est plus subtile. Le système a bien accès à l’objet, mais ne le vérifie ni assez soigneusement ni ne le consigne. Il peut par exemple relever un sitemap, énumérer toutes les sous-pages, puis produire une liste générale de défauts SEO qui conviendrait à bien des sites de petites entreprises. La liste peut contenir des notes détaillées, des priorités et des calendriers. Mais une forme détaillée n’est pas nécessairement l’indice d’un examen soigneux.

On peut poser une formule utile :

Image créée par IA

Accéder n’est pas comprendre. Comprendre n’est pas juger.

Une IA peut atteindre un site sans pouvoir en interpréter correctement le contenu. Elle peut citer correctement le contenu sans en tirer une analyse technique correcte. Elle peut émettre une recommandation dont la justification technique est incomplète.

Ce que vaut la contre-vérification

L’amélioration décisive ne tient donc pas à une version de modèle particulière. La méthode employée pour l’analyse décompose chaque affirmation essentielle en éléments distincts et vérifiables.

Une affirmation comme « les URL canoniques manquent » ne devrait pas être tenue pour un verdict définitif. Il est décisif que la question soit posée avec précision. Pourriez-vous m’indiquer dans quels fichiers les éléments en question manquent ? Combien de fichiers ont été vérifiés ? Pourriez-vous m’indiquer quelle URL figure dans chaque élément link rel=canonical ? Y a-t-il des exceptions justifiées ? C’est seulement alors qu’une affirmation plausible devient un constat technique.

Il ne suffit pas de relever qu’un élément HTML existe dans le code source. Ce qui est décisif, c’est la manière dont le document est produit. Cela s’est vu particulièrement avec les spans d’icônes portant des noms de ligature. Des titres étaient présents dans le HTML. Dans le texte du navigateur apparaissaient pourtant des expressions comme « emoji_objectsPourquoi cet ouvrage existe ». Un simple comptage dans le code confirme donc formellement l’existence du titre, mais néglige sa lisibilité réelle pour les systèmes qui extraient le texte.

Ce n’est pas un détail. Le HTML est le plan. Le texte rendu est le bâtiment dans lequel utilisateurs, lecteurs d’écran, moteurs de recherche et autres systèmes travaillent réellement. Ne vérifier que le plan peut faire manquer des propriétés essentielles du bâtiment achevé.

Pourquoi l’automatisation seule ne suffit pas

Les scripts sont faits pour exécuter de façon reproductible des tâches bien définies. Parmi leurs tâches figurent le comptage de fichiers, la vérification d’attributs, la comparaison de longueurs de chaîne, la recherche de motifs et la consignation d’écarts. Leur force est la constance. Un script est cohérent, il n’oublie aucun fichier et ne change pas ses critères sur un coup de tête.

Mais tout script porte en lui une supposition implicite : que la requête a été formulée de façon assez complète.

Le premier comptage des spans d’icônes a donné 250 occurrences. Une vérification ultérieure en a donné 394. L’écart ne venait pas d’une machine peu fiable, mais d’un motif de recherche trop étroit. Une variante de classe CSS avec une classe supplémentaire n’avait pas été saisie. Le résultat était précis, mais pas complet.

Cette conclusion vaut pour toutes les vérifications automatisées. Ce que dit un nombre dépend de la précision avec laquelle on a défini ce que l’on compte. Les processus automatisés ne remplacent donc pas le jugement humain. Ils le déplacent en amont : de l’exécution d’une tâche à la décision de savoir quelle tâche doit être exécutée.

La question économique

La considération économique compte ici. Réduire le temps de calcul et les coûts en recourant à des outils d’IA est une approche raisonnable. Toute tâche n’exige pas un grand modèle ni une analyse poussée. Générer des identifiants, parcourir un ensemble de fichiers ou remplacer des chaînes clairement définies sont des opérations mécaniques. Si les règles sont justes, un modèle plus petit ou un script local peut préparer ou accompagner ce travail de façon fiable.

Pour les tâches qui dépendent du jugement, une autre démarche s’impose. Les questions pertinentes sont par exemple : quelle vérification manque, une explication décrit-elle l’effet réel, ou un constat apparemment propre cache-t-il un angle mort ? Dans ces cas, la solution la moins chère est rarement la bonne.

Car une économie initiale peut créer du travail supplémentaire. Cela peut entraîner des coûts additionnels de recherche et de correction d’erreurs. Un aspect particulièrement grave est la perte de confiance dans ses propres résultats intermédiaires. S’il faut reprendre entièrement une analyse, une part importante de sa valeur économique est perdue.

La règle sobre n’est donc pas : toujours utiliser le plus gros modèle. Elle est : « Automatiser précisément le travail mécanique, mais traiter les questions conceptuellement difficiles avec une profondeur de vérification appropriée. »

Outils locaux, méthodes démontrables

C’est là que la différence entre un outil local et un service distant devient particulièrement nette.

Qu’un outil local tourne sur son propre ordinateur n’est pas une raison suffisante de le préférer. Il peut contenir des erreurs, appliquer des règles incomplètes ou suggérer de fausses conclusions. Son avantage essentiel tient à ce que ses chemins de données, ses entrées, ses étapes intermédiaires et ses résultats peuvent en principe être suivis intégralement.

Dans une vérification locale, on peut établir quel fichier a été utilisé à l’instant considéré. Le nombre d’éléments qu’un script a modifiés peut être déterminé en comptant les 394. Si un résultat paraît peu plausible, le processus peut être relancé — en changeant la règle et en observant l’écart.

Quand un service d’IA fonctionne à distance, des lacunes peuvent apparaître dans la visibilité de la chaîne. L’utilisateur voit la réponse, peut-être quelques sources et parfois un résumé des étapes. Mais il reste souvent flou de savoir si l’URL indiquée a réellement été récupérée en direct, quelle couche de cache est intervenue, si des pièces jointes de conversations antérieures ont pesé, ou quelles parties de la page ont seulement été lues.

Ce n’est pas une accusation morale contre les services cloud. C’est une propriété technique de leur architecture. Quand le traitement a lieu hors de son propre système, les exigences de vérification augmentent. Pour des esquisses créatives ou de premières recherches, cela peut être acceptable. Pour des processus d’entreprise solides, des audits techniques et des décisions engageant la production, la traçabilité est centrale.

Le rôle de l’humain dans tout cela

Le bon rôle de l’humain n’est pas d’exécuter lui-même chaque ligne. Ce serait gâcher les capacités des deux côtés.

La machine excelle à comparer des variantes, à répéter des vérifications de routine, à inventorier de grands fonds et à repérer les endroits singuliers. L’humain reste responsable du choix de la question, de l’arbitrage entre objectifs contraires et de la décision de savoir si un écart mesuré a seulement de l’importance.

Un champ alt vide l’illustre bien. Une vérification superficielle peut le compter comme une information manquante. Dans certains cas, utiliser alt="" sur des images purement décoratives est la bonne décision, car les lecteurs d’écran passent alors l’élément. La machine peut identifier tous les attributs vides. Le classer comme erreur, comme intention ou comme accessibilité correcte demande de regarder le contexte précis.

Le but n’est donc pas un contrôle humain sur chaque étape. Ce qui compte, c’est le contrôle humain sur leur signification. L’IA se charge de chercher, de compter et de préstructurer. L’humain vérifie les hypothèses, apprécie les résultats et tranche.

Un protocole de vérification solide

Des constats précédents se laisse déduire un protocole de vérification simple.

D’abord, la source doit être établie sans ambiguïté. Il faut noter si une analyse travaille contre le domaine en direct, un index de recherche, un cache, un dossier de projet ou une pièce jointe de conversation antérieure. Cette distinction n’est pas une formalité. Elle décide quelles preuves suffisent pour une réponse.

Vient ensuite l’inventaire. Avant toute évaluation, l’ensemble du fonds pertinent est inventorié : nombre de fichiers, versions linguistiques, routes, métadonnées, titres, images, données structurées et dépendances externes. Une évaluation sans inventaire peut être juste, mais elle reste un échantillon tant que l’ampleur n’est pas connue.

Il faut ensuite vérifier le niveau de présentation. Code source, DOM du navigateur, rendu visible, arbre d’accessibilité et texte extrait peuvent donner des résultats différents. Pour des projets censés être accessibles aux moteurs, aux systèmes d’IA et aux personnes à la fois, il est indispensable de considérer plus d’un de ces niveaux.

Enfin, tout constat important exige une contre-vérification. Elle peut passer par un second script, un autre chemin de vérification, un autre modèle ou un échantillon manuel. Ce qui compte n’est pas qui contredit. Ce qui compte, c’est de savoir si la contradiction mène à une mesure plus précise.

Et venons-en à la vraie question :

L’étude a commencé avec un site simple et une consigne claire : « Ouvre cette page et décris le contenu. » Elle a mené à une question plus large.

Notre but est de construire des systèmes techniques qui ne soient pas seulement rapides et convaincants, mais aussi vérifiables.

La réponse ne consistera très probablement pas à éviter les outils d’IA. Il ne sera pas davantage possible d’accepter chaque analyse produite. La voie productive se situe entre les deux extrêmes : employer l’IA comme moteur puissant, mais l’inscrire dans une architecture qui connaît ses sources, consigne ses étapes, mesure ses résultats et admet la contradiction.

L’IA ne devient alors pas un oracle. Elle devient un outil dont on peut comprendre, borner et améliorer la performance.

---