Audit de site par IA sur 500 pages : combien de sessions de chat ?

Selon le modèle de cet article, auditer un site de 500 pages en chat avec une IA demande environ 21 sessions et près de 15 heures de votre propre temps pour un seul passage. Le coût le plus lourd est ailleurs : ces 21 résultats ne forment pas un audit. Chaque session démarre sans les éléments vus par les autres, examine des choses différentes sur des pages différentes et formule ses verdicts à sa manière ; il n'existe donc aucune méthode commune à fusionner, ni à reproduire le mois suivant. Les sessions d'IA excellent pour expliquer et corriger des problèmes ; elles donnent leur meilleur lorsqu'elles partent d'un inventaire complet des constats.

Que vous auditiez un site avec ChatGPT, Claude ou un autre assistant, le calcul ci-dessous reste le même, car il découle du fonctionnement des sessions de chat et non d'un produit en particulier. Le premier article de cette série, pourquoi une seule session d'IA ne peut pas auditer tout un site, décrivait ce qu'une session peut couvrir et modélisait le nombre de sessions par site à 25 puis à 100 pages par session. Celui-ci fait le compte de ce qui se passe lorsque vous continuez à en ouvrir de nouvelles : vos heures, et la dérive entre les sessions.

Un site de 500 pages fait partie du quart supérieur, et reste courant

Dans ce modèle, tout dépend de la taille du site ; il part donc de tailles réelles. Parmi 29 sites externes audités par SEOReport entre mai et octobre 2026 dont le sitemap XML contenait au moins une URL, le sitemap médian listait environ 90 URL ; un quart en listait 20 ou moins, un quart plus de 440, et le dixième le plus volumineux plus de 3 000.

Il s'agit de sites soumis à un audit SEOReport, pas d'un échantillon aléatoire du web. Un site de 500 pages se situe juste à l'intérieur de leur quart supérieur : en général une entreprise établie, avec un blog, des pages de services ou de produits, et parfois plusieurs langues. Un sitemap liste les pages qu'un site demande aux moteurs de recherche de trouver ; les URL de tags, de filtres et d'archives peuvent ne pas y figurer, si bien que le nombre d'URL du sitemap est un plancher pour ce qu'un audit doit couvrir.

Le modèle : des pages par session, puis des sessions par site

Ceci est un modèle, pas une mesure. Chacun de ses chiffres découle de 4 hypothèses explicites, et vous pouvez modifier chacune d'elles.

1. 25 pages par session. C'est la plus basse des deux capacités retenues dans le premier article de la série. L'examen attentif d'une page va bien au-delà du texte visible : le code d'état, les en-têtes de réponse, les balises du head, les données structurées, et la relation de la page avec le sitemap et avec les autres pages. Sur 45 sites externes audités par SEOReport entre mai et octobre 2026, 94 % des 506 problèmes signalés se trouvaient à un endroit qu'un lecteur de la page ne voit jamais, et le site médian présentait des problèmes dans 5 emplacements de preuve différents. Garder autant d'éléments en tête pour chaque page tout en répondant avec soin place une session à la capacité basse, pas à la haute. Des pages simples en permettent davantage ; des templates lourds, moins.
2. 1 session supplémentaire pour les fichiers communs à tout le site. Le robots.txt, le sitemap XML, et les redirections entre HTTP et HTTPS ainsi qu'entre le nom d'hôte avec www et sans www.
3. 20 minutes de votre temps par session. Environ 10 minutes pour réexpliquer la méthode et transmettre la liste des pages, et 10 pour enregistrer le résultat et le fusionner dans une liste principale.
4. 1 minute de votre temps par page. Récupérer ou coller la page avec ses en-têtes, et vérifier que la session l'a bien lue. Les outils de récupération des assistants renvoient souvent la page convertie en texte, sans ses en-têtes, d'où cette étape ; ce que voit un agent IA lorsqu'il vérifie votre page montre la différence.

Les formules : sessions = pages ÷ 25, arrondi à l'entier supérieur, plus 1. Vos minutes = 20 × sessions + pages.

Les heures dépendent moins de l'hypothèse de capacité par session que le nombre de sessions, car les minutes consacrées à chaque page ne diminuent pas quand une session s'agrandit. À 10 pages par session, le site de 500 pages demande 51 sessions et environ 25 heures. À 100 pages par session, la capacité généreuse du premier article, il en demande 6, et toujours environ 10 heures.

Ces heures laissent aussi 3 choses de côté : le temps de travail de l'assistant, les corrections elles-mêmes, et tout second passage destiné à vérifier le premier.

Pourquoi 21 sessions ne font pas un audit

Les heures sont visibles, et vous pouvez les budgéter. La dérive se voit moins, et c'est elle qui rend le résultat combiné peu fiable.

Chaque session démarre sans les constats des autres. La session 14 ignore que la session 3 a déjà relevé la même balise canonical manquante sur le template du blog. Elle la signale de nouveau comme une découverte, ou traite un problème de template présent sur 180 pages comme une remarque sur une seule page. Les fichiers de projet et les fonctions de mémoire reportent les notes précédentes, ce qui aide, mais ces notes sont des conclusions. Elles n'amènent pas la session 14 à appliquer les critères de la session 3.

Chaque session choisit ce qu'elle examine. Face à un lot de pages à passer en revue, un assistant choisit les signaux à vérifier sur chacune. Une session lit les données structurées ; une autre les saute parce que la page semblait correcte. À la fin, vous savez quelles pages ont été ouvertes, mais pas quelles vérifications ont porté sur quelle page.

Chaque session formule ses verdicts différemment. « Canonical manquante », « aucun lien rel=canonical » et « balise canonical absente » désignent un même constat écrit de 3 façons. La gravité varie elle aussi : le même problème est « critique » dans une session et « mineur » dans la suivante. Le chiffre qui fixe la priorité, à savoir le nombre de pages concernées par un problème, n'existe qu'une fois chaque ligne harmonisée à la main.

Les problèmes entre pages tombent entre les sessions. Parmi ces mêmes 45 sites externes audités par SEOReport entre mai et octobre 2026, 32 (71 %) présentaient au moins un problème invisible sur une URL prise isolément : il n'apparaît qu'en comparant le sitemap aux pages qu'il liste, en comparant les pages entre elles, ou en lisant l'ensemble des articles. Découper un site en lots de 25 pages coupe précisément ces comparaisons. Deux articles quasi identiques examinés dans les sessions 4 et 19 ne se croisent jamais ; c'est l'une des façons dont les pages en double à l'origine du statut Page en double sans URL canonique sélectionnée par l'utilisateur échappent à un examen page par page.

Le mois suivant n'est pas reproductible. La même question posée deux fois peut recevoir une réponse formulée autrement et, parfois, un jugement différent. Si vous refaites les 21 sessions en décembre et trouvez moins de problèmes, vous ne pouvez pas savoir si le site s'est amélioré ou si les sessions ont changé d'avis. Sans méthode fixe, il n'y a pas de référence à laquelle comparer.

flowchart TD
    subgraph many["De nombreuses sessions de chat"]
        A["Choisir les 25 pages suivantes"] --> B["Nouvelle session : réexpliquer la méthode"]
        B --> C["La session vérifie ce qu'elle veut, avec ses propres mots"]
        C --> D["Copier ses constats dans vos notes"]
        D --> E{"Reste-t-il des pages ?"}
        E -->|oui| A
        E -->|non| F["Fusionner 21 jeux de notes à la main"]
        F --> G["Aucune trace à reproduire le mois suivant"]
    end
    subgraph one["Un audit, puis l'IA constat par constat"]
        H["Un audit : même méthode à chaque exécution"] --> I["Inventaire des constats avec preuves"]
        I --> J["Une session d'IA par constat"]
        J --> K["Audit ultérieur, même méthode"]
        K -->|"constat toujours ouvert"| J
    end

Ce qu'un audit change, et ce qu'il ne change pas

Un audit procède lui aussi par échantillon. Un diagnostic complet SEOReport examine la page d'accueil, les pages listées dans votre sitemap et les pages vers lesquelles pointent vos liens internes. Il ne lit pas toutes les pages, et chaque constat tiré d'un échantillon indique le nombre de pages examinées : le périmètre de chaque résultat est consigné.

Ce qui change, c'est la méthode. Chaque diagnostic exécute le même ensemble défini de vérifications, de la même manière, et consigne les preuves de chacune ; deux rapports sur le même site sont donc comparables constat par constat. Les comparaisons qui tombent entre les sessions de chat ont lieu au sein d'une même exécution : entrées du sitemap qui contredisent les pages listées, liens internes vers des pages manquantes, articles quasi identiques, dates d'articles contradictoires et pages vers lesquelles aucun lien ne pointe. Le résultat est un inventaire unique : des constats avec preuves et URL concernées, un plan de correction priorisé avec étapes de vérification, et des exports en PDF, Markdown et JSON. Le contenu d'un rapport SEO noté détaille cette structure.

Cela change aussi l'ampleur de la tâche confiée à l'IA. Sur 249 sites externes audités par SEOReport entre le 23 août et le 4 octobre 2026, le rapport médian signalait 14 problèmes distincts (constats en échec ou en avertissement), et un quart des sites en comptait 17 ou plus. Un problème peut toucher de nombreuses pages, mais il reste une tâche bien définie. Une liste d'environ 14 tâches accompagnées de leurs preuves n'a rien à voir avec 21 sessions d'exploration sans limite.

Ce que l'audit ne fait pas, c'est remplacer le jugement ou rédiger les corrections. C'est là que les sessions d'IA trouvent leur place, comme l'expliquait sous l'angle inverse un article précédent sur les vérifications ponctuelles par IA.

Bien utiliser les sessions d'IA sur un grand site

Donnez à la session les constats, pas le site. Ouvrez chaque session avec un constat, ses preuves et ses URL concernées. Un agent peut aussi créer le rapport et lire lui-même chaque constat via l'API REST ou le serveur MCP, comme l'explique notre page consacrée aux agents IA : son travail part alors du diagnostic au lieu de redécouvrir le site.

Une correction par session. Une tâche ciblée maintient l'attention de la session sur une seule cause et rend sa réponse facile à relire. Un prompt de ce type fonctionne bien :

Finding: XML sitemap lists URLs that redirect.
Evidence: https://www.example.com/old-pricing -> 301 -> https://www.example.com/pricing
          https://www.example.com/team -> 301 -> https://www.example.com/about
Platform: [your CMS, sitemap generator and hosting]
Task: Explain the most likely reason the sitemap still lists these URLs on this
platform, and give the smallest change that makes it list only final URLs.
Address this finding only.

Si vous devez explorer en chat, rédigez d'abord la méthode. Collez la même checklist au début de chaque session, attribuez à chacune une liste de pages fixe et imposez un format de sortie unique : un tableau URL, vérification, valeur observée et verdict. La fusion devient alors mécanique. Cela réduit la dérive de formulation et de couverture ; cela ne rattrape pas les problèmes qui n'apparaissent qu'entre les pages.

Vérifiez avec un audit ultérieur et avec Google. Pour tout ce que signale la Search Console, corrigez d'abord toutes les URL concernées, puis lancez « Tester l'URL en direct » dans l'outil d'inspection d'URL sur l'une d'elles pour confirmer que Google peut récupérer la page modifiée. Le test en direct ne vérifie pas les décisions liées aux doublons ou à l'URL canonique : pour ces problèmes, il confirme seulement l'accès. Cliquez ensuite sur « Valider la correction » pour le problème. La documentation de Google sur le rapport sur l'indexation des pages (consultée en octobre 2026) indique que la validation prend généralement jusqu'à deux semaines environ, et parfois beaucoup plus. Un rapport ultérieur, ou une surveillance hebdomadaire via l'API décrite dans surveillance SEO continue, montre si le constat a disparu selon la méthode même qui l'a détecté.

Pour les petits sites, le tableau est plus clément : dans le modèle, un site de 20 pages représente 2 sessions et environ une heure, et une question sur une seule page ne nécessite aucun audit. Le coût augmente avec la taille du site, tout comme la valeur d'une méthode reproductible.

Questions fréquentes

Un assistant capable de naviguer sur le web peut-il auditer tout le site seul ?

La navigation supprime le copier-coller, donc le poste de 1 minute par page prévu par le modèle diminue. L'assistant ouvre pourtant toujours les pages une par une, choisit lesquelles ouvrir et reçoit souvent un texte converti plutôt que la réponse complète avec ses en-têtes. Le comportement des outils varie d'un assistant à l'autre, et rien de cela n'apporte une méthode fixe qui s'exécutera de la même façon le mois suivant.

Une fenêtre de contexte plus grande règle-t-elle le problème ?

Elle augmente le nombre de pages par session, ce qui réduit le nombre de sessions. Dans le modèle, 100 pages par session représentent encore 6 sessions et environ 10 heures pour un site de 500 pages, car le traitement de chaque page prend le même temps. Et la dérive d'une exécution à l'autre reste entière.

25 pages par session, est-ce réaliste ?

C'est une hypothèse, retenue pour une session qui lit les en-têtes, les balises du head et les données structurées en plus du texte. Adaptez-la à vos pages et appliquez la formule : sessions = pages ÷ pages par session, arrondi à l'entier supérieur, plus 1. Les conclusions sur la dérive n'en dépendent pas.

Faut-il conserver les transcriptions de chat comme trace de l'audit ?

Conservez-les comme notes de travail. Une transcription consigne ce qu'une session a conclu, en général sans les preuves brutes qu'elle a vues, comme le code d'état et les valeurs des en-têtes à ce moment-là. Une trace qui conserve les preuves avec chaque constat permet à quelqu'un de vérifier le verdict plus tard et de le comparer au prochain audit.