Vous avez exporté des milliers de requêtes depuis la Search Console et vous voulez savoir lesquelles appellent une fiche produit, un guide ou un comparatif. Classer des mots-clés par intention de recherche avec l’IA permet de traiter ce volume avec constance, à une condition : écrire la grille, la consigne et le contrôle avant le premier appel au modèle. Voici la recette complète, telle que Julien Jimenez la monte sur des cas types.
entréesrequêtes avec impressions, clics et position
grilleintentions définies par l’équipe, avec exemples et contre-exemple
modèlemodèle de langage, température basse, sortie structurée
contrôlesscript de vérification, échantillon classé à la main
sortietableur : intention, confiance, justification, statut, relecteur
journaldate, lot, version de la consigne, modèle, décision
Pourquoi classer ses mots-clés par intention de recherche avant de produire
L’intention, c’est ce que la personne veut accomplir : apprendre, comparer, acheter, retrouver un site. Elle compte davantage que les mots, parce qu’elle détermine le type de page que Google juge utile d’afficher. « Chaussures de randonnée imperméables femme » appelle une liste de produits filtrable ; « comment entretenir des chaussures en cuir » appelle un guide. Se tromper de format revient à travailler contre la page de résultats.
Classer par intention avant de rédiger sert donc à décider : quelles pages créer, enrichir ou fusionner. Sans ce tri, deux pages finissent par se disputer la même attente, et aucune ne s’impose.
Un modèle de langage a ici un vrai intérêt : il reste constant sur des milliers de lignes, là où l’attention humaine s’use. Il a aussi deux limites. Il ignore votre métier tant qu’on ne le lui décrit pas, et il ne voit pas la page de résultats, qui montre l’intention retenue par Google. Toute la recette consiste à exploiter sa constance en neutralisant ces deux limites.
Définir sa grille d’intentions, des grands types aux cas propres au métier
La typologie classique (informationnelle, navigationnelle, commerciale, transactionnelle) explique bien le principe, mais elle est trop grossière pour bâtir un plan de pages. « Meilleure tente ultralégère » et « tente ultralégère » sont toutes deux commerciales ; la première appelle un comparatif, la seconde une catégorie. Une grille opérationnelle part donc des types de pages que le site sait produire. Voici celle d’un cas type :
| Intention | Définition | Exemple de requête | Page visée |
|---|---|---|---|
| Achat d’un produit précis | Modèle ou variante déjà choisis | sac à dos 30 litres dos ventilé | Fiche produit |
| Choix dans une catégorie | Besoin connu, produit à trouver | chaussures de randonnée femme | Catégorie filtrable |
| Comparaison | Plusieurs options à départager | meilleur réchaud de randonnée léger | Comparatif |
| Conseil d’usage | Utiliser, entretenir, réparer | comment régler les bretelles d’un sac | Guide pratique |
| Préparation de sortie | S’informer avant une activité | que mettre dans son sac pour la journée | Article et liste d’équipement |
| Service et marque | Commande, retour, contact | [nom de la boutique] retour colis | Page d’aide |
| À arbitrer | Aucune intention ne domine | chaussures de trail pour la randonnée | Décision humaine |
Quatre règles rendent la grille exploitable, par un modèle comme par un relecteur :
- Une intention, un type de page : deux intentions qui mènent au même gabarit se fusionnent.
- Des cases exclusives : les recouvrements se règlent dans la définition, pas au cas par cas.
- Une case « à arbitrer » et une case « hors sujet » : le modèle doit avoir le droit de ne pas trancher.
- Une définition, trois exemples, un contre-exemple : c’est le contre-exemple qui montre où passe la frontière.
Préparer la liste : nettoyage, dédoublonnage et normalisation
La préparation se fait par script, pas par modèle : c’est un travail déterministe, reproductible et vérifiable.
- Fusionner les sources : Search Console, de préférence par l’API qui restitue bien plus de lignes que l’export de l’interface, outil de mots-clés, recherche interne du site.
- Normaliser : minuscules, espaces et apostrophes unifiés, clé de dédoublonnage sans accents.
- Dédoublonner les variantes strictes en cumulant leurs impressions. Trier les mots de la clé rapproche les variantes d’ordre, mais vérifiez quelques collisions : « vol paris lyon » et « vol lyon paris » ne disent pas la même chose.
- Pré-classer par règles les requêtes de marque, de ville ou de suivi de commande : ce qu’une règle sait faire, le modèle n’a pas à le deviner.
- Commencer par les requêtes qui comptent, la longue traîne venant au lot suivant, une fois la consigne stabilisée.
Écrire la consigne : définitions, exemples et format de sortie imposé
La consigne se rédige comme un document destiné à un collègue brillant qui ne connaîtrait rien à votre site. Elle enchaîne cinq blocs : le contexte (ce que le site vend, pour qui, et ce qu’il ne vend pas), la grille reprise mot pour mot, une vingtaine d’exemples classés par un humain en insistant sur les cas limites, les règles de décision, et un format de sortie imposé. Voici l’ossature d’une consigne de prompt SEO de ce type :
Tu classes des requêtes pour une boutique d’équipement de randonnée.
Intentions autorisées : achat_produit, categorie, comparaison, conseil,
preparation, service_marque, a_arbitrer, hors_sujet.
Si aucune intention ne domine, réponds a_arbitrer. N’en invente aucune.
Réponds en JSON : [{"id": 0, "intention": "", "confiance": "haute|moyenne|basse"}]Une température basse stabilise les réponses d’un passage à l’autre, et la sortie structurée que proposent la plupart des API de modèles évite de réparer des réponses mal formées. Écrivez les identifiants sans accents ni espaces, pour que le script repère la moindre faute, et numérotez chaque version de la consigne : vous en aurez besoin dès l’étape suivante.
Traiter par lots, puis mesurer la fiabilité du classement par intention
Des lots courts, vérifiés et tracés
Sur une liste trop longue, un modèle saute des lignes, en duplique d’autres ou dérive. Découpez la liste en lots de quelques dizaines à quelques centaines de requêtes, chacune munie d’un identifiant, et faites vérifier chaque réponse par le script :
- autant de lignes reçues que de lignes envoyées ;
- chaque identifiant présent une fois, et une seule ;
- chaque intention prise dans la liste fermée ;
- tout lot rejeté relancé, puis signalé à un humain s’il échoue encore.
Chaque passage alimente le journal d’exécution : date, lot, version de la consigne, modèle, réponse brute. Ce journal devient indispensable le jour où le fournisseur met son modèle à jour et que les résultats changent sans prévenir.
Un échantillon classé à la main comme étalon
Avant de lancer toute la liste, faites classer quelques centaines de requêtes, tirées au hasard et complétées par les plus importantes, par une personne qui ne voit pas les réponses du modèle. Comparez ensuite avec trois outils : le taux d’accord global, la matrice de confusion, qui montre entre quelles intentions voisines se logent les erreurs, et au besoin le kappa de Cohen, un accord corrigé du hasard.
Fixez le seuil d’acceptation avant de regarder les résultats : un plan éditorial tolère quelques erreurs, un choix automatique de gabarit beaucoup moins. Corrigez la consigne là où la matrice montre des confusions, puis remesurez sur un second échantillon, pour vérifier que vous n’avez pas simplement appris au modèle les réponses du premier.
À retenir
Faites classer une partie de l’échantillon par deux personnes. Si elles ne tombent pas d’accord entre elles, le problème ne vient pas du modèle : c’est la grille qui est ambiguë, et c’est elle qu’il faut réécrire en premier.
Arbitrer les requêtes ambiguës : le rôle de la validation humaine
Une partie des requêtes reste ambiguë : « chaussures de trail pour la randonnée » peut appeler une catégorie, ou un guide qui dit si le trail convient à la marche. Le workflow envoie en relecture humaine les requêtes « à arbitrer » ou peu sûres, celles dont l’intention change entre deux passages identiques, et toutes les requêtes à fort enjeu.
Le relecteur suit une consigne simple : regarder la page de résultats. Les types de pages affichés par Google restent le meilleur arbitre de l’intention réelle, et une page de résultats mélangée signale une intention partagée. Chaque décision est inscrite au journal, et les cas les plus instructifs rejoignent les exemples de la consigne suivante : la validation humaine fait aussi progresser la recette.
Erreur fréquente
Supprimer la case « à arbitrer » pour obtenir un tableau complet. Le modèle répond alors toujours, avec la même assurance qu’il ait raison ou non, et les erreurs deviennent invisibles.
Exploiter le tableau final : regroupements, pages cibles et priorités
Le tableau étiqueté n’a de valeur que s’il débouche sur des décisions.
- Regrouper les requêtes d’une même intention qui partagent un sujet, par proximité sémantique (des embeddings font très bien ce travail) ou en comparant les résultats : deux requêtes qui affichent les mêmes URL peuvent être servies par une seule page.
- Rattacher chaque groupe à une page existante grâce aux données par page de la Search Console, ou le marquer « à créer ».
- Repérer les conflits : deux URL du site qui se relaient sur un même groupe signalent une cannibalisation probable.
- Prioriser en croisant le potentiel (impressions, position) et la valeur business, qu’aucun modèle ne connaît à votre place.
Chaque groupe reçoit une décision : créer, enrichir, fusionner ou ne rien faire. La machine la prépare, la personne qui porte la stratégie éditoriale la signe.
Questions fréquentes sur le classement des mots-clés par intention
Quel modèle d’IA choisir pour classer des mots-clés par intention ?
Un modèle de langage généraliste récent fait généralement l’affaire : la qualité dépend bien davantage de la grille, des exemples et du format de sortie. Le plus sûr est d’en tester deux sur le même échantillon classé à la main, de garder celui qui obtient le meilleur accord et de noter sa version exacte dans le journal.
Combien de requêtes envoyer au modèle en une seule fois ?
Moins qu’on ne le croit. Sur des listes très longues, oublis et doublons se multiplient. Des lots courts, chacun vérifié par un script, donnent un résultat plus fiable et permettent de relancer un seul lot en cas d’échec, sans tout recommencer.
Faut-il fournir la page de résultats de Google au modèle ?
Pas pour la plupart des requêtes, dont l’intention se lit dans les mots. Pour les cas ambigus ou à fort enjeu, indiquer les types de pages qui se classent aide à trancher. Une solution sobre consiste à réserver cette lecture aux requêtes que le workflow fait remonter vers un humain.
Le classement par intention remplace-t-il le regroupement sémantique ?
Non, les deux se complètent. L’intention dit quel type de page construire, le regroupement dit quelles requêtes une même page peut servir. On classe d’abord, puis on regroupe à l’intérieur de chaque intention, pour ne pas réunir une requête d’achat et une requête de conseil qui partagent les mêmes mots.
Conclusion : une recette qui se mesure avant de se déployer
Classer des mots-clés par intention avec l’IA n’a rien de magique : la grille vient du métier, la préparation d’un script, le classement d’un modèle encadré par une consigne versionnée, la fiabilité d’une mesure sur échantillon, et les décisions d’un humain qui lit les pages de résultats. Commencez par une gamme ou une rubrique, comparez au travail fait à la main, puis élargissez. Le tableau ne choisira pas les sujets à la place de votre équipe, mais il lui évitera d’écrire la mauvaise page.
Expert SEO français indépendant, Julien Jimenez pratique le référencement depuis 2009. Autodidacte, il a appris en créant ses propres sites et des dizaines de sites de test, une hypothèse et une mesure à la fois. Spécialiste de Google Discover et créateur de la formation « Disco », il conçoit des workflows d’automatisation par l’IA pour le SEO et le marketing de contenu, avec une règle constante : l’IA prépare, l’humain valide.
