SEO et développeurs web : comment collaborer

La plupart des recommandations SEO ne meurent pas dans l'audit. Elles meurent au moment où quelqu'un doit les coder. Un consultant liste vingt points à corriger, le document part dans un backlog, et six mois plus tard la moitié des lignes n'ont jamais été touchées — non par mauvaise volonté, mais parce que personne n'a traduit « corriger les balises canonical » en quelque chose qu'un développeur peut réellement prendre, estimer et livrer.

Cet article ne traite pas de technique SEO au sens habituel : il n'explique pas ce qu'est une balise canonical ou comment fonctionne un sitemap XML. Il traite de la relation de travail entre le SEO et l'équipe qui construit le site — les décisions prises pendant le développement qui deviennent ensuite coûteuses à changer, la manière de formuler une demande pour qu'elle soit vraiment traitée, et les pièges qui reviennent sans cesse entre un environnement de recette et la mise en production.

Le fossé entre l'audit et le code livré

Un audit SEO est écrit par quelqu'un qui regarde le site depuis l'extérieur : le rendu du navigateur, le code source, quelques outils de crawl. Le développeur, lui, regarde le site depuis l'intérieur : la base de données, le framework, les contraintes d'infrastructure, et surtout les vingt autres tickets déjà dans son sprint. Ces deux points de vue ne se rencontrent presque jamais spontanément.

Le problème n'est pas que les développeurs refusent le SEO. C'est que la recommandation, telle qu'elle est écrite, ne dit rien de ce qu'elle coûte à mettre en œuvre. « Ajouter des balises hreflang sur toutes les pages » peut être une ligne dans un template si l'architecture d'internationalisation est propre, ou un chantier de plusieurs semaines si chaque langue vit dans un sous-domaine différent avec sa propre base de contenu. L'audit ne fait pas cette distinction. Le développeur, lui, la voit immédiatement — et s'il n'a personne à qui expliquer pourquoi ce n'est pas « juste une ligne », la tâche reste en bas de la pile, sprint après sprint.

Les décisions de construction qui coûtent cher à inverser

Certaines décisions prises dans les premières semaines d'un projet sont presque gratuites à ce moment-là et deviennent ensuite parmi les plus chères à modifier de tout le site. Ce ne sont pas des détails esthétiques : ce sont des choix qui déterminent combien coûtera chaque futur ajustement SEO pendant toute la vie du produit.

Aucune de ces décisions n'est mauvaise en soi ; le problème est qu'elles sont souvent prises sans que personne ne pose la question SEO au moment où elle ne coûte encore rien. Une fois le site en production avec du trafic réel, chacune devient un projet à part entière plutôt qu'un simple paramètre à ajuster.

• La structure des URL. Passer de /produit?id=482 à /produits/nom-du-produit après indexation impose des redirections permanentes sur chaque page existante, une perte temporaire d'autorité, et un risque réel si la table de correspondance est incomplète.
• La stratégie de rendu. Choisir un rendu entièrement côté client sans réfléchir à la façon dont le contenu sera découvert revient, des mois plus tard, à reconstruire une bonne partie du pipeline d'affichage plutôt qu'à l'ajuster.
• Le système de templates. Un template qui fige le titre, la meta description et le H1 dans le code interdit toute variation sans intervention développeur — pour chaque article, chaque fiche produit, indéfiniment.
• Le routage et les redirections. Un site sans mécanisme central de redirection impose, à chaque restructuration, un travail manuel page par page — ou pire, l'absence pure et simple de redirection quand une URL change.
• Le contenu modifiable sans déploiement. Si corriger une faute dans un titre de page nécessite un déploiement de code, chaque correction SEO devient un ticket, une revue et une mise en production pour un changement qui devrait prendre trente secondes.

Le rendu, expliqué par ses conséquences plutôt que par le jargon

Le rendu est probablement le sujet où le vocabulaire technique fait le plus écran entre SEO et développeurs. Voici ce qui compte réellement, sans les sigles comme point de départ.

Quand une page est rendue côté serveur, le serveur assemble le HTML complet — texte, liens, structure — avant de l'envoyer au navigateur ou au robot qui la demande. Ce que le robot reçoit est déjà le contenu final. C'est la situation la plus simple à auditer et la plus prévisible : ce que vous voyez dans le code source est ce que le moteur de recherche voit.

Quand une page est rendue côté client, le serveur envoie une coquille HTML presque vide et un paquet de JavaScript. C'est ce JavaScript, exécuté dans le navigateur, qui construit le contenu réel. Un robot capable d'exécuter du JavaScript peut finir par voir ce contenu, mais avec un délai et une consommation de ressources supplémentaires — et certains outils, certains partages sur les réseaux sociaux et certains robots plus simples ne l'exécutent pas du tout. Le risque n'est pas binaire, invisible contre visible ; c'est un risque de fiabilité et de délai, ce qui est justement la nuance qui se perd dans la formule toute faite « le JavaScript, c'est mauvais pour le SEO ».

Le rendu statique, enfin, génère les pages HTML à l'avance, au moment de la construction du site plutôt qu'à chaque requête. Le résultat est aussi simple à lire pour un robot que le rendu serveur, avec l'avantage de servir des fichiers déjà prêts — au prix d'une reconstruction du site à chaque mise à jour de contenu, ce qui pose sa propre question : à quelle fréquence le contenu change-t-il, et qui déclenche cette reconstruction ?

Ce qui compte dans une conversation avec un développeur n'est pas de choisir un camp entre ces trois approches en général — chacune est légitime selon le produit — mais de savoir laquelle s'applique à vos pages qui doivent être trouvées par la recherche, et de vérifier concrètement ce qu'un robot reçoit avant de supposer un problème.

Une vérification simple, qui ne demande aucun outil : ouvrez le code source brut de la page, pas l'inspecteur du navigateur qui montre le DOM déjà construit, mais l'option qui affiche le code source tel qu'il arrive du serveur. Si le texte principal de la page n'y figure pas en clair, c'est qu'il est ajouté après coup par du JavaScript — une information utile à apporter à un développeur, plutôt qu'une affirmation générale sur le framework qu'il a choisi.

Écrire un ticket qu'un développeur peut vraiment traiter

La différence entre une ligne d'audit qui reste six mois dans un backlog et un ticket traité cette semaine tient rarement à l'importance du problème SEO. Elle tient à la façon dont la demande est formulée. Un ticket qu'une équipe de développement peut réellement prioriser et livrer contient quatre éléments.

Un ticket écrit ainsi prend plus de temps à rédiger qu'une ligne d'audit copiée-collée. C'est un investissement qui se rembourse : un développeur qui a compris une fois pourquoi les paramètres d'URL posent problème n'a plus besoin qu'on le lui réexplique la fois suivante, et commence même à repérer le problème de lui-même sur les fonctionnalités à venir.

• Le changement précis, pas le symptôme. « Les pages produit n'ont pas de balise canonical » n'est pas actionnable seul. « Ajouter une balise link canonical pointant vers l'URL sans paramètres de tri, dans le template de fiche produit, pour l'ensemble des pages produit » l'est.
• Des critères d'acceptation vérifiables. Comment sait-on que le ticket est terminé ? « La balise est présente et pointe vers la bonne URL sur un échantillon de dix pages produit variées » donne une définition claire, testable par n'importe qui, pas seulement par son auteur.
• Le pourquoi, dans des termes qui parlent à l'équipe technique. Pas « ça va aider le SEO », plutôt le mécanisme concret : sans cette balise, chaque combinaison de filtres de la même liste de produits est indexée séparément, ce qui dilue le signal sur la page qu'on veut réellement classer. Un développeur qui comprend le mécanisme prend de meilleures décisions que celui qui suit une instruction opaque.
• Une priorité assumée face au reste du sprint. Un ticket SEO n'est pas automatiquement plus urgent qu'une fonctionnalité facturée à un client ou qu'un correctif de sécurité. Dire honnêtement « ceci peut attendre le prochain sprint » ou, au contraire, « ceci bloque le lancement de la nouvelle catégorie la semaine prochaine » construit la confiance nécessaire pour que la prochaine urgence soit prise au sérieux.

Faire entrer le SEO dans la definition of done et la revue de code

La plupart des régressions SEO ne sont pas des erreurs délibérées. Ce sont des effets de bord d'un changement qui poursuivait un tout autre objectif : une refonte de template qui supprime discrètement les attributs alt, une migration de framework qui change la façon dont les liens internes sont générés, un correctif de bug qui ajoute involontairement une instruction noindex sur toute une catégorie de pages. Le problème n'est pas la compétence de l'équipe ; c'est que rien dans le processus n'était chargé de vérifier ce point précis avant la mise en production.

Deux leviers simples réduisent ce risque, sans transformer chaque développeur en spécialiste SEO. Le premier consiste à ajouter des critères SEO ciblés dans la definition of done pour les types de changement qui les concernent réellement — un changement de template déclenche une vérification des balises meta et de la hiérarchie des titres, une migration d'URL déclenche une vérification de la carte de redirections, un changement de méthode de rendu déclenche une vérification que le contenu principal est toujours présent dans le HTML servi. Le second consiste à inclure la même vérification dans la revue de code, au même titre que la logique métier ou la sécurité — un simple point dans la checklist de revue suffit souvent : ce changement touche-t-il aux URL, aux balises meta, au rendu ou aux redirections ?

Ce qui rend cette approche réaliste, c'est qu'elle ne demande pas à l'équipe de tout vérifier tout le temps — seulement de reconnaître les catégories de changement qui méritent un regard SEO avant de partir en production, plutôt que de le découvrir trois mois plus tard dans une baisse de trafic organique qu'il faut alors diagnostiquer a posteriori, sans savoir quel déploiement précis en est la cause.

Staging : les deux échecs classiques

Deux incidents reviennent avec une régularité remarquable dès qu'un site dispose d'un environnement de recette séparé de la production, et les deux sont évitables avec une seule ligne de configuration bien placée — à condition que quelqu'un pense à la vérifier.

Le premier est celui du site de recette qui se retrouve indexé. L'environnement de staging, accessible sur un sous-domaine public, n'a jamais reçu d'instruction claire pour bloquer les robots. Un lien externe, un partage accidentel, ou simplement le temps suffisent pour qu'un moteur de recherche découvre l'URL et commence à l'explorer. Le résultat est un doublon de tout le site en concurrence avec la version réelle — un problème de contenu dupliqué que l'équipe SEO doit ensuite diagnostiquer sans savoir, au départ, que deux copies du même site existent en parallèle.

Le second échec est presque le miroir inversé du premier, et généralement plus douloureux : le fichier robots.txt de staging qui part avec le déploiement en production. L'environnement de recette bloque volontairement tous les robots, et c'est le comportement voulu là-bas. Mais si ce fichier fait partie du dépôt de code déployé tel quel, sans distinction d'environnement, une mise en production embarque avec lui l'instruction qui interdit aux moteurs de recherche d'explorer le site entier. Le site continue de fonctionner normalement pour les visiteurs humains ; rien ne semble cassé. C'est seulement quelques semaines plus tard, quand le trafic organique s'effondre, que quelqu'un pense à vérifier le fichier robots.txt en production — et découvre une ligne qui interdit tout le site et qui n'aurait jamais dû quitter la recette.

La correction technique des deux problèmes est triviale une fois identifiée : générer le robots.txt, et l'en-tête noindex en complément, à partir d'une variable d'environnement plutôt que d'un fichier statique commun, pour que la recette et la production ne puissent jamais partager la même instruction par accident. La vraie protection, cependant, est humaine — que quelqu'un, côté SEO ou côté développement, considère cette vérification comme faisant partie du rituel de mise en production, et non comme une chose qu'on découvre après coup.

La relation de travail, honnêtement

Il est tentant, quand un ticket SEO reste des mois sans être traité, d'en conclure que les développeurs ne prennent pas le SEO au sérieux. C'est rarement la bonne lecture. Un développeur arbitre en permanence entre des demandes venues de plusieurs directions — produit, support client, sécurité, dette technique, et SEO — avec une capacité fixe et souvent déjà insuffisante pour tout ce qui est demandé. Le SEO n'a pas de droit de priorité automatique sur ces autres demandes ; il doit gagner sa place comme n'importe quelle autre.

Ce que l'équipe SEO ne voit généralement pas, ce sont les contraintes qui rendent une tâche apparemment simple beaucoup plus lourde qu'elle n'y paraît de l'extérieur : une dépendance à un service tiers qui limite ce qui est possible, une dette technique accumulée sur exactement la partie du code qu'il faudrait toucher, une release déjà figée pour un client important qui interdit tout changement de dernière minute sur le même module. Présumer la mauvaise volonté là où il y a en réalité une contrainte invisible est le moyen le plus sûr de construire une relation de travail qui empire avec le temps.

La collaboration qui fonctionne, sur la durée, ressemble moins à une liste de demandes qu'à un partenariat où chaque partie explique son raisonnement à l'autre : le SEO explique le mécanisme et l'impact réel derrière chaque demande plutôt que de se contenter d'une instruction, et le développeur explique honnêtement le coût et les contraintes plutôt que de laisser un ticket mourir en silence dans le backlog. Ni l'un ni l'autre n'a besoin de devenir expert du domaine de l'autre — juste de prendre au sérieux qu'il existe un domaine, avec sa propre logique, de l'autre côté de la conversation.