Auditer un site avec un assistant outillé
Un audit de site classique rend des scores. Un assistant à qui on tape « audite ce site » rend des réponses plausibles. Cette méthode produit autre chose : un rapport dont chaque chiffre a été mesuré par un instrument nommé, livré avec ses corrections déjà calculées et la liste de ce qui n'a pas été vérifié.
À la fin, vous savez produire un audit qu'un tiers peut reproduire, et que son destinataire peut appliquer sans vous rappeler. Comptez une heure trente à trois heures par site. Rien ici ne promet que le site ira mieux : la méthode répond de la qualité du diagnostic, pas du geste du patient.
Passé au TIQ, tester, itérer, qualifier, le 25/08/2026 · Testé · 3 h sur les 50 URL du sitemap de markentiq.com · avec Claude Opus 5, 25/08/2026 · non couvert : parcours authentifiés, mobile réel, mesures de terrain. Lire le compte rendu d'exécution.
Le mode d'emploi complet part dans votre presse-papier. Collez-le dans une conversation avec Claude, ChatGPT ou Vibe, puis donnez cette consigne : « Déroule cette méthode sur [URL du site], commence par l'étape 01 et écris le périmètre avant toute mesure. »
Ex-professeur d'histoire reconverti dans l'IA, dirigeant d'Ethica Society, solutions et formations IA sur mesure. Je travaille avec un agent outillé qui a une mémoire, des règles et un journal de ses erreurs, et je publie ce que je mesure, y compris quand ça me contredit. On peut me solliciter pour des audits outillés, la conformité RGPD et IA Act, et des formations.
Cette méthode est publiée sous la signature de son auteur et dans sa voix. Elle a été rédigée par Phrasti, l'agent outillé de Jules Thomas, sur ses directives, à partir de l'audit du 6 août et des règles de son dispositif ; Jules l'a relue et validée sans retouche. Une méthode sur les audits par assistant outillé, écrite par l'assistant outillé : le contraire aurait été étrange.
Ce que la méthode produit
Un rapport structuré : ce qui marche (mesuré), les défauts avec leurs valeurs corrigées, les contradictions entre le discours du site et son comportement, les limites déclarées.
Un bloc exécutable : le message prêt à coller dans l'assistant du destinataire, avec les valeurs exactes, pour que les corrections se fassent sans vous.
Une liste « non couvert » : ce que l'audit n'a pas regardé, écrite avant qu'on vous le demande.
Prérequis
| Prérequis | Pourquoi |
|---|---|
| Un assistant outillé : accès au rendu réel de la page (navigateur ou requêtes HTTP) et capacité de calcul. ChatGPT, Claude, Vibe ou un autre assistant font l'affaire s'ils sont outillés. | Sans instrument, l'assistant estime. Cette méthode interdit l'estimation. |
| L'URL du site, et l'accord de son propriétaire si le rapport doit circuler | Un audit non sollicité est un cadeau ; publié sans accord, c'est une attaque. |
| 1 h 30 à 3 h | Le poste le plus long n'est pas la mesure, c'est la réfutation de vos propres trouvailles (étape 06). |
La méthode, étape par étape.
Mise à jour du 30/08/2026 : la méthode passe en v4. Une seule étape s'ajoute, 05 bis, née d'un défaut trouvé lors d'une exécution tierce de la méthode. Le reste est inchangé.
Les outils de l'auteur sont disponibles depuis le 03/09/2026. L'étape 05 bis nomme diff-page-servie.py : il fait partie d'un kit de trois outils que Jules Thomas publie sous licence MIT, et que nous mettons en téléchargement libre. Ils sont utiles et jamais obligatoires : les huit étapes s'exécutent entièrement à la main, avec un rechargement forcé ou curl. Voir le kit et le télécharger →
Écrire le périmètre avant de commencer
Ce qui sera audité (quelles pages, quels angles), et ce qui ne le sera pas.
Comment on vérifie. La liste « non couvert » existe avant la première mesure, et elle se retrouve telle quelle à la fin du rapport.
Le piège. Le périmètre qui gonfle en cours de route et finit non déclaré : on a regardé une page de plus, on l'a critiquée, et le rapport laisse croire qu'on a tout vu.
Établir d'abord ce qui marche, en le mesurant aussi
Dérouler les contrôles standard (langue déclarée, hiérarchie de titres, textes alternatifs, étiquettes de formulaires, données structurées, temps de chargement, nombre de requêtes) et ouvrir le rapport par les réussites.
Comment on vérifie. Chaque « bon point » vient d'un contrôle réellement passé, pas de l'absence de plainte. « Zéro image sans alt » veut dire qu'on a compté les images. Et tout contrôle d'accessibilité, liens comme champs, retire d'abord ce qui est volontairement sorti de l'arbre d'accessibilité : un élément en aria-hidden="true" ou tabindex="-1" n'est pas un défaut. Les deux cas courants sont les pièges à robots des formulaires et les vignettes de couverture doublées d'un lien titré juste en dessous. Presque tous les sites en portent : sans cette exclusion, l'étape produit une fausse alerte à chaque audit.
Le piège. Le procès à charge. Un audit qui ne dit que ce qui rate apprend au destinataire à se méfier de vous, pas de son site. Et il vous prive de l'effet le plus utile : quand la première page dit du bien mesuré, la critique qui suit devient crédible.
Mesurer chaque défaut avec son instrument
Les contrastes par la formule de luminance relative WCAG, appliquée aux couleurs réellement rendues. Les cibles tactiles par leurs dimensions rendues et par leur distance au voisin le plus proche : l'exception d'espacement de la règle de décision se mesure, elle ne se suppose pas, et une cible sous le seuil reste conforme si rien ne se trouve dans son cercle de 24 px. Les requêtes tierces en observant le réseau dans un profil vierge (navigation privée : un cookie de consentement déjà posé fait mentir la mesure), doublé du contrôle le plus robuste : lire le HTML servi (un curl) : aucun script tiers dans la source veut dire aucune requête tierce possible avant consentement, quel que soit l'état du profil. Le droit en consultant la source, avec sa date. Pour le DOM : lire textContent, jamais innerText : le second renvoie vide sur tout contenu replié ou masqué, et fabrique des défauts qui n'existent pas. Pour tout ce qui touche à un chemin (liens relatifs, scripts, le lien « mentions légales » d'un bandeau), vérifier à deux profondeurs au minimum, depuis la racine et depuis une page en sous-dossier : la plupart des défauts de chemin ne se voient qu'au deuxième niveau. Et connaître l'angle mort de son instrument : une extension de navigateur voit le DOM mais pas les variables JavaScript de la page, et conclut « script non chargé » là où tout marche ; pour lire l'état réel, injecter un script dans la page et récupérer son résultat dans un attribut du document.
Comment on vérifie. Chaque chiffre du rapport est accompagné de son instrument, et un tiers équipé du même instrument retrouverait le même chiffre.
Le piège. Déduire au lieu de lire. Une classe CSS nommée text-muted ne dit pas la couleur rendue. Un élément replié dans le DOM ment sur ce que voit l'utilisateur : mesurez à l'état ouvert. L'explication plausible qui dispense de mesurer est l'ennemi principal de cette étape, précisément parce qu'elle tient debout.
Calculer la correction, pas le conseil
Pour chaque défaut chiffré, chercher la valeur corrigée la plus proche qui passe le seuil : un contraste se corrige par recherche par pas sur la couleur, une cible tactile par le padding manquant, en pixels.
Comment on vérifie. La valeur proposée repasse le seuil par le même calcul qui l'a condamnée, et dans tous les contextes où la couleur apparaît : une couleur de charte vit sur plusieurs fonds, clair et sombre, et une correction validée sur l'un peut échouer sur l'autre. Quand c'est le cas, la correction juste tient en deux valeurs par variable, une par fond, avec surcharge dans le mode sombre. Vérifier ensuite les éléments qui portent un fond sombre sans porter la classe du mode sombre (un pied de page, typiquement) : la surcharge ne les atteint pas. Et re-mesurer après avoir forcé le rechargement : une feuille de style servie depuis le cache fait conclure qu'une correction ne marche pas. Le rapport montre les nouveaux rapports de contraste obtenus, fond par fond.
Le piège. La correction qui casse la charte. « Passez ce doré en noir » règle le contraste et détruit l'identité. Viser le plus petit écart qui passe : de #ca8a04 à #9e6c03, pas de #ca8a04 à #000000.
Chercher la contradiction entre la promesse et le comportement
Lire ce que le site déclare (manifeste, bandeau, mentions), puis observer ce qu'il fait (requêtes qui partent, murs qui se ferment, parcours réels). Les écarts entre les deux valent plus cher que tous les pixels.
Comment on vérifie. La contradiction est citée mot pour mot des deux côtés : la phrase du site, et le comportement mesuré qui la dément.
Le piège. Confondre l'illégal et l'incohérent. Une pratique peut être parfaitement légale et contredire le positionnement du site, et c'est souvent la contradiction qui coûte le plus : le visiteur qui la remarque ne conclut pas « infraction », il conclut « comme les autres ». L'inverse aussi : avant d'écrire « interdit », vérifier la source juridique à sa date, avec le cas par cas qu'elle prévoit.
Relire chaque citation dans la page servie, sans cache, avant d'en faire un défaut
Tout défaut fondé sur « la page dit X » se vérifie en rouvrant la page telle qu'elle est servie au moment de l'audit : rechargement forcé, ou lecture du HTML par curl, et comparaison de la citation avec le texte réellement servi. Un outil de récupération peut rendre une copie ancienne d'une page, et rien à l'écran ne le dit.
Comment on vérifie. Chaque citation du rapport porte la date et l'heure de sa relecture sur la page servie, et l'instrument de relecture : rechargement forcé du navigateur, ou curl. diff-page-servie.py, du kit de l'auteur, rend ce contrôle automatique : il compare la page servie à sa source phrase par phrase et rend un code non nul en cas d'écart. Il n'est pas nécessaire pour exécuter l'étape.
Le piège. Réfuter l'interprétation et jamais la lecture. Le 29 août 2026, un assistant tiers exécutant cette méthode a rapporté qu'une page Ressources annonçait « trois méthodes » alors qu'elle en disait « quatre » depuis trois jours, avec le même instrument et la même confiance que pour un défaut vrai. Son étape 06 avait interrogé « la page exclut-elle volontairement les contributions ? », jamais « ai-je bien lu la page telle qu'elle est servie aujourd'hui ? ». La réfutation doit commencer par la lecture, l'interprétation vient après.
Tenter de réfuter ses propres trouvailles avant de livrer
Chaque critique du brouillon passe par la question « qu'est-ce qui la tuerait ? », et on refait la mesure correspondante. Idéalement dans une session fraîche, sans le contexte de production.
Comment on vérifie. Au moins une critique du brouillon est morte avant livraison. Si toutes ont survécu, la réfutation n'a probablement pas eu lieu.
Le piège. Garder une critique morte parce qu'elle était belle. La règle inverse paie : une critique retirée publiquement (« j'allais vous reprocher X, j'ai vérifié, c'était faux ») achète plus de crédibilité que trois critiques justes.
Livrer exécutable, et borné
Le rapport se termine par deux choses : le bloc prêt à coller dans l'assistant du destinataire, avec les valeurs exactes et l'interdiction d'y reformuler quoi que ce soit, et la section « ce que je n'ai pas fait ».
Comment on vérifie. Quelqu'un d'autre peut appliquer les corrections sans vous appeler, et personne ne peut vous attribuer une vérification que vous n'avez pas faite.
Le piège. La recommandation-conseil. « Améliorez le contraste » remet le travail chez le destinataire ; #ca8a04 devient #9e6c03 le termine.
La re-passe, et la transmission de ses propres corrections
Après la première livraison, élargir d'un cran (une page de plus, un angle de plus) et transmettre ce que la re-passe change, y compris quand elle corrige vos propres chiffres.
Comment on vérifie. Les chiffres revus sont annoncés comme tels (« je vous ai dit 2, c'est au moins 43, et voici pourquoi je m'étais trompé »).
Le piège. Lire la mauvaise propriété du DOM. Sur un contenu replié (accordéons, menus), innerText renvoie vide quand textContent renvoie le texte réel : le premier fabrique des « liens sans nom » qui n'existent pas. La consigne qui protège : textContent, jamais innerText, et elle dispense de déplier pour les contrôles de contenu. Et l'ancien piège reste entier pour tout ce qui dépend du rendu : mesurer un état replié ne dit rien de ce que voit l'utilisateur. Un accordéon fermé, un menu non déployé, et les contrastes comme les dimensions se mesurent sur un écran que personne ne regarde. Déplier avant de mesurer, pour ces contrôles-là. Les deux pièges cohabitent : le premier porte sur la propriété lue, le second sur l'état de la page. C'est une erreur que j'ai commise sur ce site même, avec un instrument, et que l'exécuteur de la méthode a reproduite avec un autre : le compte rendu d'exécution documente les deux.
Ce qui tranche, quand deux lectures sont possibles
Les seuils : contraste 4,5:1 pour le texte courant (WCAG 2.1) · cible tactile 24 × 24 px (WCAG 2.5.8, niveau AA), avec son exception d'espacement : une cible plus petite reste conforme si un cercle de 24 px centré sur elle ne chevauche le cercle d'aucune autre cible : sans cette exception, une page ordinaire produit une dizaine de faux positifs · toute requête vers un domaine tiers partant avant consentement se signale, sans exception (mesurée en profil vierge, voir étape 03).
L'ordre de traitement, quand tout ne peut pas être corrigé : d'abord ce qui part chez un tiers sans consentement, ensuite la contradiction promesse/comportement, ensuite les défauts à correction groupée (un gabarit corrigé, quarante occurrences réglées), le cosmétique en dernier.
L'échelle de preuve : mesuré (instrument nommé) vaut plus qu'observé (lu dans la page), qui vaut plus qu'estimé. Un chiffre estimé n'entre pas dans le rapport final : il se remplace par sa mesure, ou il disparaît. C'est la même logique que l'échelle N1/N2/N3 de ce site, et les deux règles d'héritage s'appliquent aussi ici.
Une critique sans tentative de réfutation documentée ne part pas.
La checklist de contrôle
- Chaque chiffre du rapport porte son instrument
- Chaque citation de page a été relue dans la page servie, sans cache, à une heure notée (étape 05 bis)
- Chaque critique a survécu à une tentative de réfutation, et au moins une y est morte
- Chaque défaut chiffré a sa valeur corrigée, recalculée au même seuil
- Chaque couleur corrigée a été re-mesurée sur chacun des fonds où elle sert
- Le rapport s'ouvre sur du positif mesuré
- Le bloc exécutable est autonome : valeurs exactes, zéro reformulation permise
- La section « ce que je n'ai pas fait » est écrite et couvre le périmètre de l'étape 01
- Les corrections faites en cours de route restent visibles dans le document final
Ce que la méthode ne fait pas
Les parcours authentifiés. On ne crée pas de compte à la place de quelqu'un ; on vérifie ce qui est accessible sans compte, et on l'écrit.
L'ergonomie réelle. Des dimensions rendues ne sont pas un pouce sur un écran. Le rapport le dit quand il n'a pas pu tester au doigt.
Les mesures de terrain. Les temps de laboratoire ne sont pas les Core Web Vitals de vos visiteurs réels.
Le jugement éditorial. La méthode évalue des comportements mesurables, pas la qualité de votre prose.
Un avis juridique. Elle cite des sources datées et leurs critères ; elle ne remplace pas un juriste.
La reproductibilité parfaite. Deux assistants différents ne trouveront pas exactement la même chose. Les instruments imposés bornent l'écart, ils ne le suppriment pas : c'est pourquoi la ligne de niveau de test devrait toujours nommer le modèle et sa date.
Ce que la méthode a donné quand nous l'avons exécutée
Qui écrit ce bloc. Tout ce qui précède est de Jules Thomas, sous sa signature. Cette section est de nous, MarkenTIQ : notre exécution de sa méthode, sur notre propre site. C'est elle qui justifie la ligne de niveau de test en haut de page. Jules l'a lue avant publication.
Méthode exécutée le 25/08/2026 avec Claude Opus 5. Environ trois heures. Les huit étapes ont été déroulées, dans l'ordre, sans poser une seule question à l'auteur.
Le périmètre, écrit avant la première mesure
Huit pages mesurées au navigateur, dont les quatre gabarits du site, puis les 42 autres contrôlées par requête HTTP et analyse du HTML servi : les 50 URL du sitemap.
Prévu sur trois pages, le périmètre a été étendu en cours d'exécution à sept, puis aux cinquante. C'est le piège de l'étape 01 ; il n'est évité que parce que l'élargissement est écrit ici.
Pourquoi les 42 dernières sans navigateur. Les contrôles de rendu (contraste, cibles tactiles) dépendent d'une feuille de style unique, partagée par toutes les pages. Les mesurer cinquante fois n'aurait rien appris de plus.
Ce qui marche, mesuré
Sur les 50 pages : langue déclarée partout, un seul titre de niveau 1 par page sans exception, zéro image sans texte alternatif, zéro lien sans nom accessible sur 1 896 liens comptés, zéro champ de formulaire réellement sans étiquette. Sauts de niveau de titre : 2 pages sur 50.
Les défauts réels, et leurs corrections calculées
| Usage | Couleurs | Ratio | Seuil | Valeur corrigée |
|---|---|---|---|---|
| Texte bleu sur blanc | #4F6EF0 sur blanc | 4,36 | 4,5 | #4D6CEB (4,51) |
| Texte blanc sur fond bleu | blanc sur #4F6EF0 | 4,36 | 4,5 | #4D6CEB (4,51) |
| Petit texte gris | #8A8A92 sur blanc | 3,43 | 4,5 | #76767D (4,51) |
Plus petit écart qui repasse le seuil, conformément à l'étape 04 : neuf points sur 765 pour le bleu. La charte n'est pas touchée, elle est ajustée d'un cran.
Quatre pages sur cinquante n'ont aucune donnée structurée : contribuer.html, ressources.html, mentions-legales.html, licence.html. Les quarante-six autres en portent une à trois.
Ce que la réfutation a tué, et c'est le plus utile
L'étape 06 demande de tenter de réfuter ses propres trouvailles, l'étape 08 de transmettre les chiffres qu'on a soi-même corrigés. Nous avions quatre annonces. Les quatre étaient fausses.
| Ce que nous annoncions | Ce qui est vrai | Ce qui nous avait trompés |
|---|---|---|
| 36 liens sans nom accessible sur le glossaire | 0 | innerText renvoie vide sur du contenu replié, et la page porte 54 accordéons fermés ; textContent les lit. Deuxième occurrence documentée du piège : l'auteur l'avait rencontré le 6 août, avec un autre instrument, sur les liens repliés du glossaire. |
| 12 cibles tactiles sous 24 px | 0 | Le seuil de 24 px appliqué sans son exception d'espacement. Distance minimale au voisin : 53,7 px, pour 24 requis. |
| 9 requêtes tierces avant consentement | 0 | Un cookie de consentement déjà posé dans le navigateur de mesure. Nous mesurions notre propre consentement passé. |
| 4 champs de formulaire sans étiquette | 0 | Quatre pièges à robots, aria-hidden="true" et tabindex="-1", volontairement retirés de l'arbre d'accessibilité. |
Seul le défaut de contraste survit. Les quatre faux défauts venaient de l'outil, pas de la méthode.
La contradiction entre promesse et comportement
La première mesure annonçait neuf requêtes vers cinq domaines tiers au chargement : fausse, pour la raison ci-dessus. Reprise sur le HTML servi, puis sur le script de consentement, puis en navigation privée à froid : 14 requêtes, zéro domaine tiers, zéro cookie, bandeau présent à l'écran. Deux instruments indépendants concordent.
Conforme. Aucune requête tierce avant consentement, et aucune contradiction entre promesse et comportement sur le périmètre audité.
Le bloc exécutable
L'étape 07 impose de livrer un message autonome, à coller tel quel, sans reformuler aucune valeur. Voici celui que cette exécution a produit.
Sur le site markentiq.com, applique exactement ces trois corrections. 1. Dans assets/style.css, remplace la couleur #4F6EF0 par #4D6CEB partout ou elle sert de couleur de texte sur fond blanc ou de fond avec du texte blanc. Raison : ratio de contraste 4,36 pour un seuil WCAG 2.1 de 4,5. La valeur #4D6CEB donne 4,51. Ne change aucune autre couleur. 2. Dans assets/style.css, remplace la couleur de texte #8A8A92 par #76767D. Raison : ratio 3,43 pour un seuil de 4,5. La valeur #76767D donne 4,51. 3. Ajoute un bloc JSON-LD aux pages qui n'en ont aucun : contribuer.html, ressources.html, mentions-legales.html et licence.html. Prends comme modele celui de qui-sommes-nous.html et adapte le type et les champs au contenu. Ne fais rien d'autre. Ne reformule aucune valeur hexadecimale.
Les deux corrections de couleur ont été appliquées le 25/08/2026, avec un ajustement : #4D6CEB est juste sur fond clair, mais le mode sombre et le pied de page gardent #4F6EF0, qui y reste conforme. Une correction globale aurait cassé le contraste là où il était bon. Les données structurées manquantes ont été ajoutées depuis sur les quatre pages.
Ce que nous n'avons pas fait
Parcours authentifiés. Mobile réel : toutes les mesures de rendu viennent d'une fenêtre de 961 px de large. Mesures de terrain : aucun Core Web Vitals de visiteur réel. Jugement éditorial. Rendu contrôlé sur huit pages seulement, les quarante-deux autres sur leur structure.
Notre verdict sur la méthode
Recevable. Elle se reproduit sans son auteur. Elle trouve un défaut réel qu'il n'avait pas vu, sur des pages qu'il n'avait pas auditées. Surtout, elle nous a évité de publier quatre faux défauts : c'est sa vraie valeur.
Nous lui avons adressé cinq retours, tous nés de l'exécution ; la version publiée ici en tient compte.
L'exemple, avant de vous lancer
L'exemple est un audit réel, pas une reconstitution : celui de markentiq.com, réalisé le 6 août 2026 par l'agent outillé de l'auteur, et publié ici avec son accord. Vous y verrez la forme livrable du rapport, l'effet de l'ouverture par le positif mesuré, le bloc exécutable, et une critique retirée en cours de route.
Votre retour compte
Vous avez fait tourner cette méthode ? Racontez-nous ce qui a marché et ce qui a coincé : chaque retour améliore la version suivante, et il est transmis à son auteur. Le formulaire est ouvert aux personnes qui ont déjà reçu un pack, avec la même adresse ; l'email marche aussi : contact@markentiq.com.
Cette page vous a servi ? Partagez-la sur LinkedIn. Pour retrouver nos publications dans vos résultats Google, ajoutez MarkenTIQ à vos sources préférées.