SEO grande entreprise : décider, déployer, arbitrer

Dans une petite structure, le SEO tient dans une seule tête : la même personne écrit le contenu, corrige les balises et parle directement au développeur qui a construit le site. Dans un grand groupe, cette personne n'existe pas. Il y a plusieurs marques, parfois plusieurs CMS hérités de rachats successifs, une agence sous contrat, une équipe interne, un directeur marketing qui découvre ce qu'est une balise canonical en réunion, et un product manager dont la feuille de route ne contient aucune ligne SEO. La difficulté n'est plus de savoir quoi faire, les listes d'audit disent la même chose depuis des années, mais de savoir qui a le pouvoir de le faire, dans quel ordre, et qui tranche quand deux équipes ne sont pas d'accord.

Cet article ne traite ni de priorisation d'audit ni de liste de tactiques : il traite de la couche organisationnelle qui décide si ces tactiques voient un jour le jour, et de ce qui reste quand la personne qui savait tout est partie.

Le template appartient au dev, la page appartient à l'éditorial

Sur un site unique, on peut se permettre de traiter chaque page comme un cas particulier. À l'échelle d'un groupe, ce réflexe coûte cher : une balise title mal formée sur un gabarit de fiche produit n'est pas une erreur isolée, elle est répliquée sur douze mille pages en même temps. La première distinction à établir, avant même de parler de process, est donc technique : qu'est-ce qui vit dans le template, et qu'est-ce qui vit dans la page elle-même ?

Un gabarit définit une structure partagée, par exemple un pattern de title du type h1 suivi de la marque puis de la catégorie, une logique de canonical, un schéma de données structurées, une règle de pagination. Modifier cette structure change instantanément toutes les pages qui l'utilisent, en bien comme en mal. Une page, elle, porte ce qui est propre à elle : le corps du texte, le texte alternatif d'une image, un maillage interne ajouté à la main par un rédacteur, un bloc de questions fréquentes rédigé pour cette page précise. Cette distinction explique pourquoi tant de tickets SEO restent bloqués des mois entiers : une demande formulée comme changer le title de cette page est en réalité une demande de champ de dérogation dans le template, donc un chantier dev qui doit passer par un sprint, pas une simple correction de contenu qu'un rédacteur peut faire seul.

• Niveau gabarit : structure d'URL, logique de canonical, pagination, données structurées, patterns de title et de meta description.
• Niveau page : texte du corps, alt d'image, liens internes ajoutés manuellement, contenu de FAQ propre à la page.
• Zone grise à trancher explicitement : hreflang, règles de redirection, directives robots — techniquement au niveau du gabarit, mais avec des exceptions au cas par cas qui doivent avoir un chemin défini à l'avance.

Faire entrer un correctif SEO dans la feuille de route dev

Un correctif SEO n'est pas prioritaire par nature : il est en concurrence directe avec toutes les autres demandes qui atterrissent dans le même backlog de développement. Sans allocation permanente ou sans interlocuteur nommé côté dev, un ticket SEO se fait doubler indéfiniment par des fonctionnalités produit dont l'impact est plus facile à chiffrer pour un product manager habitué à raisonner en métriques business.

Ce qui fait avancer un ticket, ce n'est pas la justesse du principe SEO invoqué, c'est sa traduction dans le langage que l'équipe produit utilise déjà au quotidien. Dire que les H1 dupliqués nuisent au référencement ne dit rien de concret à quelqu'un qui n'est pas du métier. Dire que la Search Console signale deux cents URL en couverture comme dupliquées sans canonical, ce qui les exclut purement et simplement de l'index, est vérifiable indépendamment de qui le dit, et se rattache à un signal que l'équipe dev peut elle-même consulter sans avoir à faire confiance à un tiers. Un correctif scopé au niveau du gabarit, qui répare des centaines de pages en une seule modification livrée en un sprint, se défend presque toujours mieux qu'une série de corrections page par page, parce que le ratio pages corrigées par heure de dev est exactement l'argument que comprend un product manager habitué à arbitrer entre plusieurs demandes concurrentes.

• Rattacher la demande à un signal vérifiable, Search Console ou logs serveur, plutôt qu'à un principe SEO général et abstrait.
• Scoper la demande au niveau du gabarit quand c'est possible, pour maximiser le nombre de pages corrigées par ticket ouvert.
• Nommer la personne qui validera le résultat après déploiement, un ticket sans validateur désigné ne se referme jamais vraiment dans les faits.

Agence sous contrat, équipe interne : où tracer la frontière

Le doublon le plus fréquent observé dans un grand groupe : l'agence produit un audit trimestriel, l'équipe interne produit le sien de son côté sans le savoir, les deux listes se recoupent aux deux tiers, et personne n'implémente ni l'une ni l'autre parce que chacune attend que l'autre bouge en premier. Le partage de mandat qui fonctionne réellement ne se fait pas par tâche, l'agence fait l'audit et nous faisons le contenu finit presque toujours par se chevaucher au bout de quelques mois, mais par type d'artefact et par ce que cet artefact requiert comme accès techniques.

Une agence peut produire tout ce qui ne nécessite pas d'accès au code ou au CMS de production : analyse concurrentielle, briefs de contenu détaillés, listes de prospection pour le netlinking. Tout ce qui touche au déploiement effectif, modification de gabarit, redirections, données structurées, revient nécessairement à qui détient les accès, en général l'équipe interne ou le service dev. Le point de friction classique apparaît quand l'agence répond au directeur marketing et le dev répond au directeur technique : les recommandations de l'agence n'ont alors aucun chemin naturel vers le backlog technique, parce que personne côté dev n'a de compte à rendre au sponsor qui a signé le contrat d'agence. La solution n'est pas politique, elle est procédurale : faire passer toute recommandation externe par le backlog interne déjà existant, jamais en parallèle de lui, avec un seul interlocuteur désigné qui filtre et priorise des deux côtés à la fois.

Empêcher deux marques du même groupe de se cannibaliser

La cannibalisation à l'intérieur d'un groupe ne ressemble pas à la cannibalisation classique observée sur un seul site. Sur un site unique, deux pages qui visent le même mot-clé se résolvent par une redirection ou un canonical, une opération techniquement triviale une fois identifiée. Entre deux domaines de marques différentes, cette solution simple n'existe tout simplement pas : on ne peut pas canonicaliser la page d'une marque secondaire vers une page de la marque principale sans effacer purement et simplement l'identité de la marque secondaire, et personne dans l'organisation ne l'acceptera jamais.

Le mécanisme du problème est simple à décrire : si le groupe possède trois sites de marques distinctes et que trois équipes de contenu travaillent chacune de leur côté sans se coordonner, il est presque garanti que deux d'entre elles publient un jour une page sur le même terme de tête, souvent alimentées par des backlinks issus de la même équipe relations presse, ce qui, aux yeux du moteur, ressemble à une entité qui se fait concurrence à elle-même sur sa propre requête. La résolution doit avoir lieu avant la publication, jamais après, parce qu'une fois publiées, défaire deux pages qui rankent déjà coûte du trafic réel aux deux marques en même temps.

• Attribuer chaque terme de tête à une seule marque et une seule URL, avant que le brief de contenu ne soit même écrit.
• Faire puiser les deux équipes de contenu dans la même base de mots-clés partagée, jamais dans deux fichiers séparés.
• Quand une page sur un terme voisin existe déjà sur un autre site du groupe, y faire un lien plutôt que d'en écrire une nouvelle qui la concurrence.

Le document de standards : ce qu'il doit contenir pour survivre à un départ

La plupart des documents de standards SEO meurent en dix-huit mois environ, pas parce que les règles qu'ils contiennent deviennent fausses, mais parce qu'ils ont été écrits comme des notes personnelles pour la personne qui les a rédigées, pas comme des instructions destinées à un inconnu qui arrive après elle. Un document qui survit vraiment contient, pour chaque règle listée, quatre choses distinctes : la règle elle-même, la raison en une phrase courte, l'endroit exact où elle s'applique concrètement, un champ de CMS précis, un fichier de template, une étape d'un checklist de publication, et un chemin d'exception clairement balisé.

Le détail qui fait le plus souvent la différence sur la durée : nommer un rôle, jamais une personne en particulier. Un document qui dit qu'en cas d'exception il faut contacter une personne nommément désignée devient inutilisable la semaine même où cette personne quitte l'entreprise. Un document qui dit qu'en cas d'exception il faut escalader vers le rôle de responsable SEO, actuellement tenu par telle personne, survit largement au départ, parce que le pointeur est la fonction et non l'individu, et que le nom qui suit peut être mis à jour sans jamais réécrire la règle elle-même.

Second détail tout aussi décisif : un changelog daté. Un document sans historique de modifications est, par défaut, considéré comme abandonné par quiconque en hérite plus tard, impossible de savoir si la règle qu'on lit reflète encore la réalité actuelle du site ou date d'avant une refonte oubliée. Une simple ligne datée à chaque changement de règle suffit à faire toute la différence entre un document de référence vivant et une relique qu'on n'ose plus vraiment citer en réunion.

Le comité d'arbitrage : qui tranche quand deux équipes ne sont pas d'accord

Certains conflits ne se résolvent jamais par un document de standards, aussi bon soit-il, parce qu'ils opposent deux logiques toutes les deux légitimes. Le service juridique veut un bandeau de consentement qui se charge en JavaScript après le rendu initial de la page, ce choix nuit directement à l'indexation de tout ce qui se trouve en dessous du bandeau. L'équipe produit veut restructurer les URL d'une section entière pour un lancement à venir, ce choix casse potentiellement dix ans de backlinks pointant vers les anciennes adresses. Aucune règle écrite à l'avance ne couvre vraiment ce genre d'arbitrage, parce que chaque cas mélange un impératif SEO et un impératif qui n'a rien à voir avec le SEO.

Sans instance clairement nommée pour trancher, ces conflits se résolvent par défaut, c'est-à-dire par celui qui escalade le plus fort ou le plus longtemps, ou par l'absence totale de décision, ce qui revient concrètement à laisser gagner le statu quo. Un comité d'arbitrage efficace n'a pas besoin d'être lourd ni formel : une cadence fixe, un rôle qui a le dernier mot en cas d'impasse persistante, et un critère clair pour savoir ce qui mérite vraiment d'y être porté plutôt que réglé directement entre deux équipes voisines. Sans ce dernier critère, le comité devient un point de passage obligé pour tout, ce qui le ralentit jusqu'à le rendre pratiquement inutile.

Plusieurs CMS, une seule logique SEO

Un groupe qui grandit par acquisition hérite rarement d'un système technique homogène : une marque tourne sous WordPress, une autre sur un CMS maison construit par l'équipe qui l'a rachetée des années plus tôt, une troisième sur une plateforme e-commerce hébergée par un tiers. Chacun de ces systèmes gère les canonical, les redirections et les données structurées d'une manière différente, avec des interfaces et des limites propres à chacun.

La conséquence pratique pour le document de standards : la colonne où c'est appliqué ne peut absolument pas rester générique. Une instruction du type poser un canonical vers la version https est inapplicable telle quelle sur un CMS où ce champ n'existe pas dans l'interface d'édition standard et doit passer par un plugin tiers, un fichier de configuration serveur, ou une requête directe à l'équipe dev. Documenter la règle une seule fois, puis documenter séparément, pour chaque CMS effectivement utilisé dans le groupe, l'endroit précis où elle s'applique, évite qu'une rédactrice familière d'un seul système ne conclue, à tort, que la règle est techniquement impossible à appliquer chez elle.