# Que doit contenir la documentation SEO laissée à un client en fin de mission

> Un rapport d'audit ne suffit pas à rendre un client autonome. Voici ce qu'une documentation de fin de mission doit couvrir pour qu'il comprenne réellement ses choix techniques.

- Auteur : WordPress Développement
- Publié le : 2024-06-29
- Mis à jour le : 2024-06-29
- Catégorie : SEO & GEO
- URL : https://www.wpmoderne.fr/seo/documentation-seo-livrable-client-fin-mission/

## L’essentiel

- Le pourquoi compte autant que le quoi dans une documentation de transmission
- Chaque décision technique doit être reliée à un effet observable
- Un glossaire évite les malentendus des mois plus tard

Que reste-t-il, six mois après la fin d'une mission, quand un client rouvre le dossier de livraison pour comprendre pourquoi telle page a un `noindex`, ou pourquoi le sitemap exclut une catégorie entière ? Trop souvent, rien d'exploitable : un rapport d'audit initial, quelques échanges d'e-mails dispersés, et une mémoire collective qui s'est déjà partiellement effacée. La documentation de fin de mission existe précisément pour combler ce vide, à condition d'être pensée comme un outil de compréhension durable, pas comme une formalité administrative.

Une bonne documentation SEO ne recopie pas le rapport d'audit initial : elle raconte ce qui a été décidé, pourquoi, et ce que le client doit savoir pour ne pas défaire, par inadvertance, un choix technique qui avait sa raison d'être.

## Le pourquoi avant le quoi

La tentation naturelle, en rédigeant une documentation technique, consiste à lister exhaustivement les modifications apportées : telle règle de redirection, tel filtre ajouté, telle extension configurée. Cette liste seule ne rend personne autonome. Ce qui compte, pour un client qui n'a pas de compétence technique approfondie, c'est de comprendre le raisonnement derrière chaque décision, formulé en termes d'effet observable plutôt que de mécanisme interne.

Une entrée de documentation utile ressemble à ceci : « Les pages de résultats de recherche interne sont exclues de l'indexation (balise `noindex`) parce qu'elles créaient des milliers de variantes d'URL sans contenu propre, un phénomène qui diluait l'attention des robots d'exploration sur les vraies pages de contenu. » Cette formulation permet au client de comprendre pourquoi il ne doit pas demander à retirer cette exclusion sans en mesurer les conséquences.

## Les six sections d'une documentation complète

1. **État des lieux au moment de la livraison** : nombre de pages indexées, structure des URL, extensions actives liées au référencement.
2. **Décisions techniques et leur justification** : chaque choix relié à un problème constaté, jamais présenté comme une simple préférence.
3. **Ce qui ne doit pas être modifié sans avis technique** : listes explicites des réglages sensibles (structure des permaliens, règles de redirection, exclusions de sitemap).
4. **Procédures de contrôle courantes** : comment vérifier qu'un sitemap est à jour, comment lire un rapport de couverture dans Search Console.
5. **Glossaire des termes techniques employés** : canonical, balisage structuré, budget de crawl, expliqués simplement.
6. **Contacts et procédure en cas d'anomalie** : que faire, qui contacter, quelles informations rassembler avant de solliciter un support technique.

> L'essentiel à retenir : Le pourquoi compte autant que le quoi dans une documentation de transmission ; Chaque décision technique doit être reliée à un effet observable ; Un glossaire évite les malentendus des mois plus tard

## Le glossaire, souvent négligé

Un glossaire peut sembler accessoire face à des sections plus techniques, mais c'est souvent lui qui évite le plus de malentendus. Un client qui lit, des mois plus tard, le mot « canonical » dans un e-mail d'une nouvelle agence, sans définition à portée de main, risque de mal interpréter une recommandation ou de s'inquiéter d'un problème qui n'en est pas un. Un glossaire de fin de mission, même de dix entrées, réduit ce risque de manière disproportionnée par rapport à l'effort de rédaction qu'il demande.

### Un format qui vieillit bien

Privilégier un document texte structuré (Markdown ou traitement de texte classique) plutôt qu'une présentation animée : dans six mois, personne ne voudra rouvrir un diaporama de quarante diapositives pour retrouver une seule information précise. La structure doit permettre une recherche rapide par mot-clé, avec des titres explicites correspondant au vocabulaire que le client emploiera lui-même pour chercher une réponse.

## Ce qu'il ne faut pas inclure

- Des détails d'implémentation qui n'ont aucun effet observable pour le client (nom exact des variables internes, choix d'architecture logicielle secondaires).
- Des recommandations vagues du type « continuer à optimiser le SEO », sans action concrète associée.
- Des captures d'écran d'interfaces susceptibles de changer rapidement (les tableaux de bord d'outils tiers évoluent souvent visuellement, rendant la capture obsolète en quelques mois).

> Une documentation de transmission réussie se reconnaît à un critère simple : le client doit pouvoir répondre lui-même, six mois plus tard, à la question « pourquoi cette page n'est-elle pas indexée » sans avoir besoin de rappeler qui que ce soit.

## En résumé

La documentation de fin de mission n'est pas un exercice de style ni une formalité contractuelle : c'est l'outil qui détermine si un client reste dépendant indéfiniment de son prestataire, ou s'il devient capable de comprendre, de vérifier et de faire respecter les choix techniques qui protègent son référencement. Le temps investi dans sa rédaction se rembourse largement en évitant les régressions accidentelles causées par une décision reprise sans en connaître le contexte d'origine.