Outils d'IA en SEO : ma boîte à outils et les tests qui l'ont façonnée

Ma boîte à outils d'IA en SEO se compose de modèles de langage, de données payantes sur les résultats de Google, d'un programme de crawl de sites et de scripts maison. Un modèle organise bien les données, les décrit et écrit du code. Le résultat d'un seul relevé de résultats ou d'une seule réponse d'un modèle peut toutefois être dû au hasard. C'est pourquoi je montre les tests qui ont changé ma façon d'utiliser ces outils. Je ne dresse pas de classement de 1 à 10, car je n'ai pas comparé ces outils côte à côte sur les mêmes données.

Que fait bien l'IA en SEO, et que fait-elle mal ?

Un modèle de langage lit, organise les données et écrit bien, mais il calcule mal de mémoire et ne voit pas les données qu'on ne lui donne pas. Les 26 et 27 septembre 2026, j'ai testé des modèles de langage sur 17 types de tâches SEO, chacun à un niveau facile et à un niveau difficile. J'ai construit une partie des types à partir de 103 offres d'emploi de spécialistes SEO. Les offres citaient le plus souvent l'audit technique, le reporting et l'analyse de données. Parmi les outils, elles citaient le plus souvent la Search Console, Google Analytics 4 (GA4), Ahrefs, Semrush et Screaming Frog.

Les modèles les plus forts avaient presque 100 % dans presque chaque type de tâche, et seuls les modèles plus faibles ont donc fait apparaître des différences. Parmi les modèles de tête figuraient notamment Claude Opus 5.5, Fable 5.1, Codex et Gemini 3.1 Pro. Pour le calcul à partir d'un fichier au niveau difficile, Claude Haiku 4.5 a obtenu 2 points sur 10. Gemini 3.8 Flash avec un faible niveau de raisonnement a obtenu 1 sur 10, et Gemma 4 12B en local 0 sur 10. Dans les tâches où le modèle pouvait calculer les données avec un script Python, tous les modèles cloud testés ont obtenu le maximum de points. Même les plus faibles d'entre eux l'ont obtenu. Les données de ces tâches sont des exports de Screaming Frog, 45 000 événements GA4 et un log de serveur de 160 000 lignes. C'est pourquoi, dans mon travail, les chiffres sont calculés par un script que le modèle écrit et exécute.

Deux modèles ont évalué à l'aveugle des textes en polonais, et les écarts y étaient grands. Les évaluateurs ne savaient pas quel modèle avait écrit le texte. L'échelle avait 5 niveaux, et 5 signifiait un texte prêt à être envoyé au client sans corrections. Seuls Claude Opus 5.5 et Claude Sonnet 5 ont obtenu 5 sur la tâche d'écriture difficile. Gemini 3.1 Pro a obtenu 2, parce qu'il a inventé une « conversation de la veille » avec le destinataire. L'évaluateur Claude Opus a été plus sévère que l'évaluateur Gemini, tant pour les réponses de Claude que pour celles des autres modèles.

Un même modèle peut donner un autre résultat à la répétition du même test. Claude Haiku 4.5 a obtenu en deux passages 62 et 39 points sur 102. Dans le texte sur l'audit SEO, j'ai décrit pourquoi un modèle d'IA ne fera pas seul un audit complet d'un site.

Ma boîte à outils : quel outil pour quel usage ?

Je répartis les outils en six usages dans mon travail, et non selon les éditeurs. Un même modèle figure parfois dans plusieurs usages, car je ne l'emploie pas de la même façon pour lire des données et pour contrôler. Pour chaque usage, je donne le test après lequel j'ai changé ma façon de travailler.

Quels modèles de langage est-ce que j'utilise, et pour quoi ?

Je fais l'essentiel de mon travail dans Claude Code, c'est-à-dire dans Claude qui fonctionne dans le terminal avec accès aux fichiers, aux scripts et aux données. Claude écrit et exécute des scripts, lit des exports et prépare des brouillons de rapports. Codex (OpenAI) et Gemini (Google) reçoivent les mêmes documents pour un second contrôle.

Je fais relire les textes et les rapports par un second modèle d'un autre éditeur, en deux tours. Le premier tour cherche les erreurs de faits et les lacunes. Le second tour ne vérifie que les corrections, car en corrigeant on fait naître de nouvelles erreurs. En octobre 2026, dans un projet, le second tour a trouvé dans un guide un mauvais nombre total de liens, à partir duquel était calculée une part : 79 au lieu de 76. Cette erreur n'était apparue qu'au moment des corrections. Mon script de contrôle ne l'a pas trouvée.

Un modèle servant de juge de qualité peut mesurer autre chose qu'une personne ; je le vérifie donc sur des textes que j'ai déjà évalués. Le 7 octobre 2026, j'ai donné à deux modèles 87 descriptions de brevets Google à évaluer. Parmi elles, il y avait 8 descriptions que j'avais moi-même jugées prêtes auparavant, ce que les juges ignoraient. Fable, un modèle d'Anthropic, en a jugé 5 prêtes sur ces 8. Codex avec un niveau de raisonnement élevé en a jugé 1 sur 8.

Ces deux résultats ne concernent que les textes que j'ai moi-même jugés prêts. Je n'ai pas évalué les 79 autres descriptions ; je ne sais donc pas combien de rejets étaient justifiés. Codex en a rejeté au total 51 sur 87, car il comparait chaque phrase de la description aux revendications, c'est-à-dire à l'étendue juridique du brevet. L'accord des juges entre eux était proche du hasard. Le kappa de Cohen valait 0,06, où 0 signifie un accord dû au hasard et 1 un accord complet.

J'utilise des modèles locaux sur mon propre ordinateur avec carte graphique pour l'étiquetage en masse, car je ne paie pas chaque élément traité. Le 1er octobre 2026, j'ai testé des modèles locaux sur quatre tâches simples. Les données étaient des pages de trois boutiques en ligne polonaises. Gemma 4 31B a reconnu le type de page dans 98,5 % des 403 pages. Les types de pages sont : produit, liste de produits, article ou autre. Un script à règles tombait juste sur 84 % de ces pages.

Gemma a lu presque sans erreur les prix et jugé la concordance des nombres, mais une partie des références de ce test venait d'un modèle, et non d'une personne. La référence du type de page, c'étaient les étiquettes d'un script corrigées par le modèle Claude Opus. Gemma a lu correctement le prix sur les 177 fiches produit. La référence était le prix des données structurées, conforme au texte de la page. Dans 99,3 % de 134 cas, Gemma a correctement jugé si le nombre d'une phrase concordait avec les données. La moitié de ces phrases avait un nombre volontairement modifié. Gemma a aussi reconnu le type de demande d'une expression (offre, hors offre ou conseil) dans 97,7 % des 218 expressions. La référence était ici formée des étiquettes du modèle Claude Opus.

La même famille de modèles a échoué lors de la comparaison de nombres entre deux fichiers dans une vraie offre. Le 12 octobre 2026, deux versions de Gemma 4, 26B et 31B, ont comparé 63 lignes et n'ont signalé que de fausses contradictions. Elles ont par exemple jugé que « -34 % » et « un tiers » étaient des valeurs contradictoires. Le seul vrai problème de ce texte ne concernait pas les nombres, mais un mot excessif à côté d'un résultat du tableau. Il n'entrait donc pas dans la tâche de Gemma. Désormais, un script vérifie que chaque nombre d'un fichier figure dans l'autre. C'est un contrôle de présence des nombres ; leur sens est vérifié par une personne ou par un second modèle.

Quels outils est-ce que j'utilise pour les données de positions et de demande ?

Je prends les données sur les résultats de Google chez DataForSEO, dans la Search Console et chez Ahrefs, et chacune de ces sources a son piège. DataForSEO vend des relevés des résultats de Google et des données de demande, avec un paiement par requête. Du 17 septembre au 14 octobre 2026, j'y ai commandé 17 076 tâches pour 99,89 USD. Parmi elles, il y avait 13 085 relevés de résultats Google.

Un seul relevé de résultats ne suffit pas pour mesurer la position, car les relevés successifs d'une même expression ne se ressemblent pas. Le 7 octobre 2026, j'ai récupéré les résultats de 94 expressions trois fois à une heure d'intervalle et deux fois dans la même minute, pour 1,57 USD. J'ai ensuite comparé les domaines des dix premiers résultats dans deux relevés de la même expression. Les domaines communs représentaient en médiane environ 15 % de tous les domaines différents des deux relevés. Dans les relevés de la même minute, c'était environ 8 %. Une expression avait en médiane 4 variantes de résultats. C'est pourquoi, au lieu de la position, je calcule la part de relevés dans lesquels le domaine figure dans les dix premiers résultats. Il y a environ 10 relevés, et je les envoie en même temps.

Cette mesure a invalidé mon test précédent, dans lequel j'avais comparé la position d'un seul relevé aux citations de cinq relevés. Le résultat « réussi » du test s'est révélé faux ; j'ai donc suspendu le test. L'AI Overview, c'est-à-dire la réponse de l'IA au-dessus des résultats de Google, était stable dans cette mesure : il apparaissait dans 97-99 % des relevés, et la liste des pages citées ne changeait pas.

La Search Console montre les clics mesurés par Google lui-même, mais l'export depuis l'interface limite le tableau à 1 000 lignes. Mille requêtes triées par clics, c'est la partie la plus cliquée des données. Le 20 septembre 2026, sur un site, l'export depuis l'interface indiquait un CTR de 4,28 % pour les positions 1-3 aux États-Unis. Le CTR est la part des impressions qui se terminent par un clic. Les données de 16 mois récupérées sans la limite de 1 000 lignes, soit 123 498 requêtes, ont donné 1,40 %. Je récupère de telles données par l'API de la Search Console, c'est-à-dire l'interface pour les programmes. L'autre moyen est un rapport dans Looker Studio, l'outil gratuit de Google pour les rapports, avec le connecteur Search Console.

J'utilise Ahrefs pour les liens, les expressions et la concurrence, mais je vérifie ses estimations de trafic dans la Search Console. La colonne de trafic du Rank Tracker d'Ahrefs est une estimation : une demande estimée multipliée par un taux de clic supposé. Sur un site, cette estimation était 10 à 50 fois supérieure aux clics de la Search Console, et sur un autre environ 3 fois inférieure. Le Rank Tracker compte aussi comme des positions les blocs de la page de résultats. Dans un cas, une chute de la 1re à la 13e place signifiait seulement qu'un AI Overview était apparu au-dessus des résultats.

Quels outils est-ce que j'utilise pour l'audit technique ?

Pour l'audit, j'utilise Screaming Frog et le navigateur Chrome sans fenêtre, et un modèle d'IA lit les résultats mais ne remplace pas le crawl du site. Screaming Frog parcourt le site comme le fait un robot de moteur de recherche. Chrome lancé sans fenêtre montre la page après exécution de JavaScript ; je compare donc les deux versions de la page. Dans un audit, des crawls avec et sans JavaScript lancés en parallèle ont donné un faux signal sur le rendu. Depuis, je les lance l'un après l'autre.

Quand le pare-feu d'un site audité bloque mon programme de crawl, je récupère les adresses isolées par le service Apify Web Fetch. Dans un test du 12 octobre 2026, le service a lu 8 pages sur 8 que je ne pouvais pas récupérer depuis mon adresse IP. Deux d'entre elles appartenaient à des sites de clients, et six à des sites publics d'avis, des comparateurs et des boutiques en ligne. Cela a coûté 0,00155 USD par adresse. Le service signalait toutefois parfois une récupération réussie avec le code 200, alors qu'il n'avait récupéré qu'une page de vérification. Je considère donc un texte très court ou un texte de vérification comme un blocage, et je relance la récupération.

Ce service ne montre pas ce que voit le vrai robot de Google ou un robot d'IA. Il se connecte depuis une autre adresse IP, et même quand j'indique le nom d'un robot, les autres en-têtes trahissent un navigateur Chrome ordinaire. Je vérifie donc les blocages des robots dans la Search Console et avec mon propre script qui compare les réponses du serveur pour différents robots. Dans le texte sur le fichier llms.txt, j'ai décrit comment je vérifie par l'adresse IP si la requête a été envoyée par un vrai robot.

J'ai construit un assistant d'audits techniques à partir des audits de mon agence de 2020-2026, et j'évalue ses résultats sur des audits réalisés auparavant par une personne. L'assistant est un agent d'IA qui collecte des données sur le site et les vérifie d'après un catalogue de règles tirées de ces audits. Je valide moi-même le périmètre de l'audit et les priorités, au début du travail et avant l'envoi de l'audit. J'ajouterai ici le résultat de la mesure après la deuxième mesure sur un nouveau site.

Quels outils est-ce que j'utilise pour le contenu et la sémantique ?

J'associe une expression à une page par la recherche hybride, car la version précédente de mon outil ne tombait juste que sur un tiers des expressions. Le 14 octobre 2026, j'ai pris les expressions de la Search Console de deux sites, sans les expressions contenant un nom de marque. Pour chaque expression, la référence était la page qui avait reçu au moins 60 % des clics de cette expression et qui figurait parmi les pages explorées du site. La version précédente de l'outil utilisait le modèle MiniLM pour les embeddings, c'est-à-dire la transformation d'un texte en un vecteur de nombres. Elle a désigné la page de référence en premier pour 34 % des expressions.

La recherche hybride combine trois listes de pages et tombait sur la page de référence dans 80,5 % et 77,1 % des expressions. La première liste vient du modèle e5-large. La deuxième est une recherche par les mots du contenu, et la troisième par les mots du titre, du titre de niveau H1 et de l'adresse. Je combine les listes par la méthode RRF, qui récompense les pages placées haut sur plusieurs listes à la fois. Le meilleur modèle d'embeddings seul était différent sur chacun des sites, et l'hybride a gagné sur les deux.

Lors de ce test, j'ai trouvé une erreur dans mon propre outil : le modèle ne voyait pas la fin de la plupart des fragments de texte. Le script découpait le texte en fragments de 80 mots, alors que le modèle accepte 128 tokens, c'est-à-dire des morceaux de mots. Les mots polonais se découpent en plus de tokens que les mots anglais, si bien que 89-98 % des fragments étaient tronqués. Le résultat de 34 % concerne donc la version précédente de l'outil avec cette erreur, et non le modèle MiniLM lui-même. Le test mesure la concordance avec les clics dans Google, et non la page qui répond le mieux à la requête.

J'extrais les entités, c'est-à-dire les noms d'entreprises, de produits, de personnes et de notions, des textes avec le modèle local GLiNER2. Dans mon test de juillet 2026, le modèle avait sur des textes polonais un F1 de 0,94, autant que sur des textes anglais. Le F1 combine la précision et le rappel, et 1 signifie un résultat parfait. Ce résultat concerne des étiquettes qui ne se recouvrent pas. Quand une même requête contenait à la fois les étiquettes « entreprise » et « marque », le F1 tombait à 0,85. Le modèle tourne sur un processeur ordinaire, environ 20 paragraphes par seconde, sans frais par page.

Je n'utilise pas GLiNER2 pour reconnaître l'intention des expressions, car dans mon test il ne tombait juste que dans 33-42 % des cas. Il se trompait souvent avec une confiance de 0,99, c'est-à-dire presque la plus haute qu'il indique lui-même.

J'ai fait la carte des sujets de cette série de textes à partir d'entités sur 71 pages de concurrents de Pologne et des États-Unis. Le script a extrait 110 entités et 1 764 triplets, c'est-à-dire des enregistrements de la forme entité, attribut et valeur. Les données ont coûté 0,072 USD. La carte a montré les rôles des textes, les paires de textes à relier par des liens et les sujets qui manquent sur ce site.

Quels outils est-ce que j'utilise pour le link building ?

Pour l'analyse des liens, j'utilise Ahrefs, mais je vérifie en direct les liens marqués comme perdus avant qu'ils n'entrent dans les conclusions. En octobre 2026, sur un projet, Ahrefs montrait 360 domaines polonais comme perdus. 140 d'entre eux faisaient toujours un lien vers la même adresse. Environ 70 adresses répondaient par une erreur 403 à la récupération par un programme ordinaire ; je les ai donc vérifiées dans un navigateur piloté par un script (Playwright).

Je codirige Linko, une plateforme de liens, et je ne la décris donc pas ici comme l'outil d'une autre entreprise. Dans le texte sur le link building, j'ai décrit comment j'évalue les sites avant d'acheter une publication. Dans le texte sur le link building à l'ère de l'IA, j'ai décrit comment l'IA aide à préparer les publications et le contact avec les éditeurs.

Quels outils est-ce que j'utilise pour mesurer la visibilité dans l'IA ?

Les outils de mesure de la visibilité de la marque dans l'IA, je les ai décrits dans un texte à part ; je ne donne donc ici que le principe. Je compte séparément la mention de la marque dans la réponse et la citation de sa page. Je pose chaque question plusieurs fois, car les réponses des assistants changent. Dans le texte sur la visibilité d'une marque dans l'IA, j'ai décrit la mesure, le nombre de répétitions et les pièges des outils. Dans le texte sur le GEO et le SEO IA, j'ai décrit ce que je fais sur le site pour que les assistants d'IA puissent le citer.

Quels outils SEO avons-nous construits nous-mêmes ?

Quand aucun outil ne répond à ma question, j'écris avec l'aide de l'IA mon propre script. La plupart de ces scripts servent au travail interne : crawl, récupération de données, entités, contrôle des textes et des nombres. Avant de commencer à utiliser un script dans mon travail, je le vérifie sur des données pour lesquelles je connais la bonne réponse.

Chez VerticalSEO, nous préparons 16 outils SEO qui seront disponibles via le site et via l'API, y compris pour les agents d'IA. Les outils ne sont pas encore publiés. Les tests du 8 octobre 2026 vérifiaient que les outils fonctionnent conformément à la spécification. Les 610 tests API sur 610 et les 325 tests d'outils pour agents dans le navigateur sur 325 ont réussi. Ces outils fonctionnent selon le standard WebMCP, qui met les fonctions d'un site à la disposition des agents d'IA. Les tests ne mesurent pas encore si les outils donnent des conclusions SEO pertinentes.

Le test de l'outil de vérification des entités a montré que le nom seul ne suffit pas pour désigner une entité. Je cherchais la plateforme commerciale polonaise Allegro, mais l'outil choisissait dans le Knowledge Graph de Google, c'est-à-dire sa base d'entités, une œuvre de Vivaldi. Sous mon nom et prénom, il choisissait un acteur. L'outil ne confirme désormais une entité que lorsque Google lui associe la page examinée. La confirmation passe aussi par un identifiant indiqué par Wikidata ou par les données structurées de la page.

Je prépare la publication en open source de LemmeGSC, mon tableau de bord pour les données de la Search Console. Le tableau de bord récupère les données de la Search Console sans la limite de 1 000 lignes. Il montre notamment la cannibalisation des expressions, c'est-à-dire plusieurs pages d'un même site pour la même expression.

Quels outils SEO gratuits suffisent pour commencer ?

Pour commencer, il suffit de la Search Console, de Looker Studio, de la version gratuite d'un assistant d'IA et de la version gratuite de Screaming Frog. Chacun de ces outils a un rôle différent :

• la Search Console montre les clics, les impressions et les requêtes de Google ;
• Looker Studio avec le connecteur Search Console récupère ces données sans la limite de 1 000 lignes ;
• la version gratuite d'un assistant d'IA regroupe des expressions, écrit des brouillons et des scripts, si vous lui donnez les données ;
• la version gratuite de Screaming Frog explore jusqu'à 500 adresses, ce qui suffit pour un petit site.

Il vaut la peine d'ajouter les outils payants pour les expressions et les liens seulement quand vous savez à quelle question ils doivent répondre. Un assistant d'IA gratuit ne connaît pas vos données de la Search Console. Il apporte le plus quand vous lui donnez un export et que vous lui demandez un script qui calculera le résultat.

Comment est-ce que je teste un outil d'IA avant de lui faire confiance ?

Je vérifie un outil sur des données dont je connais la bonne réponse. Certains tests de ce texte ne comportaient pas tous les éléments de la liste ci-dessous. Dans le test des modèles locaux, la référence du type de page a été corrigée par un modèle, et non par une personne. Aujourd'hui, un test comprend ces éléments :

• un jeu de référence issu de la décision d'une personne ou des données de Google, par exemple la page ayant la majorité des clics d'une expression donnée ;
• le résultat attendu consigné avant l'exécution du test ;
• la répétition du même passage, car un seul passage d'un modèle ou un seul relevé de résultats peut être dû au hasard ;
• des cas avec une erreur introduite, pour vérifier si le contrôle la détecte ;
• le coût et le temps par unité ;
• des nombres vérifiés par un script, et non par un modèle.

Les données de test m'ont peu coûté, et c'est le jeu de référence qui demande le plus de travail. Le test des relevés de résultats a coûté 1,57 USD, et les données de la carte des sujets de la série 0,072 USD. Le jeu de référence demande une évaluation préalable par une personne. Les coûts indiqués n'incluent pas ce travail.

Je consigne le résultat d'un test avec ce que le test n'a pas vérifié. Pour l'association expression-page, je connais la concordance avec les clics dans Google, mais je ne sais pas si la page indiquée est celle qui répond le mieux à la requête. Pour les modèles locaux, j'ai testé quatre tâches simples, et non des tâches complètes. Sans une telle note, on prend facilement le résultat d'un test pour plus large qu'il n'est.

Questions fréquentes sur les outils d'IA en SEO

Par où commencer ?

Commencez par une tâche que vous faites chaque semaine et par les données que vous avez déjà dans la Search Console. Donnez au modèle les données complètes et demandez-lui un script qui calculera ce que vous calculez aujourd'hui à la main. Comparez le résultat à une quinzaine de cas que vous aurez vérifiés vous-même. Ce n'est que lorsque les résultats concordent que vous lancez le script sur toutes les données. Dans le texte sur la stratégie SEO, j'ai décrit quelles données de la Search Console je vérifie au début du travail.