# Ce qu’une agence sécurise avant de rendre la main sur un thème en fin de vie > Mettre fin à un contrat de maintenance ne se résume pas à cesser de facturer : une transition mal préparée laisse le client démuni face à son propre thème. - Auteur : Clément Hadrot - Publié le : 2026-08-15 - Mis à jour le : 2026-08-15 - Catégorie : Thèmes - URL : https://wpmoderne.dev.wordpress-developpement.fr/themes/ce-qu-agence-securise-avant-rendre-main-theme-fin-de-vie/ ## L’essentiel - L'accès aux comptes et aux identifiants doit être transféré, pas seulement listé - La documentation du thème doit survivre au départ de l'équipe qui l'a écrite - Un client informé du niveau de risque restant décide en connaissance de cause Que doit recevoir un client le jour où son agence met fin à un contrat de maintenance sur un thème arrivé en fin de vie ? Cette question, souvent traitée à la légère dans la précipitation d'une fin de collaboration, mérite une réponse aussi rigoureuse que celle donnée au démarrage d'un projet. Un client qui se retrouve, sans préavis réel, sans accès ni documentation sur son propre thème, se trouve dans une position bien plus fragile que celle qu'il occupait avant même de signer un premier contrat. Cette checklist ne porte pas sur la migration vers un nouveau thème, qui reste une décision et un chantier distincts : elle porte sur ce qu'une agence doit sécuriser avant de cesser toute intervention sur un thème qu'elle a maintenu, que ce thème continue ou non d'être utilisé après la fin du contrat. ## Les accès techniques, transférés et vérifiés - Les identifiants d'hébergement, de nom de domaine et de base de données doivent être transmis au client ou à son nouveau prestataire, avec une vérification effective de leur fonctionnement, pas une simple transmission déclarative. - Les accès à tout compte tiers utilisé par le thème (service d'envoi d'e-mails transactionnels, outil d'analytics, service de paiement) doivent être listés avec leurs identifiants respectifs, ou transférés vers un compte propre au client s'ils appartenaient jusqu'ici à l'agence. - Toute clé d'API codée en dur dans le thème, plutôt que stockée en variable d'environnement, doit être signalée explicitement, car sa rotation deviendra impossible sans réintervention sur le code une fois l'agence partie. ## La documentation, pensée pour survivre au départ de l'équipe Un thème maintenu pendant plusieurs années accumule une connaissance informelle, rarement écrite, détenue par les personnes qui l'ont fait évoluer. Cette connaissance disparaît avec le départ de l'agence si elle n'a pas été formalisée à temps. Un document de transition doit reprendre, a minima, la liste des personnalisations majeures du thème, les dépendances externes identifiées, et les incidents récurrents déjà rencontrés par le passé. > L'essentiel à retenir : L'accès aux comptes et aux identifiants doit être transféré, pas seulement listé ; La documentation du thème doit survivre au départ de l'équipe qui l'a écrite ; Un client informé du niveau de risque restant décide en connaissance de cause ## Le code source, complet et lisible sans contexte oral Le dépôt de code transmis au client ou à son nouveau prestataire doit être complet, avec son historique de versions si un système de gestion de versions a été utilisé pendant le contrat. Un export de fichiers sans historique prive le repreneur d'une information précieuse : la chronologie des modifications, souvent la seule trace de la raison d'être d'un correctif ancien qui semblerait autrement arbitraire. 1. Vérifier que le dépôt transmis contient bien l'intégralité de l'historique, pas seulement l'état final du code. 2. Retirer, avant transmission, tout identifiant ou clé sensible qui aurait pu être committé par erreur dans l'historique du dépôt. 3. Confirmer que le client dispose bien des droits d'administration sur ce dépôt, et non d'un simple accès en lecture temporaire. ## Un état des lieux honnête sur le niveau de risque restant La dernière étape, souvent la plus inconfortable pour une agence, consiste à formuler clairement au client le niveau de risque qu'il assume en poursuivant l'utilisation du thème sans contrat de maintenance actif : absence de correctifs de sécurité futurs, incompatibilité prévisible avec une prochaine version majeure de WordPress, ou fonctionnalités qui cesseront de fonctionner à moyen terme. Cette transparence protège autant le client, qui décide en connaissance de cause, que l'agence elle-même, qui documente avoir rempli son devoir d'information au moment de la rupture du contrat. > Une fin de contrat bien préparée ne cherche pas à convaincre le client de rester : elle lui donne simplement les moyens de continuer seul, ou avec un autre prestataire, sans perte d'information. ## Le format du document de passation ``` # Passation — Thème Client Y Accès transférés : hébergement, domaine, base de données, compte API du service d'envoi d'e-mails Dépôt de code : lien + historique complet vérifié Personnalisations majeures : liste des fonctionnalités développées sur mesure Risques identifiés : absence de mise à jour prévue après la fin du contrat Date de fin de responsabilité de l'agence : à préciser explicitement ``` ## Ce qu'il faut retenir Sécuriser une fin de contrat de maintenance demande une rigueur comparable à celle d'un démarrage de projet, mais dans le sens inverse : transférer plutôt que collecter, documenter pour un futur inconnu plutôt que pour soi-même. Les six éléments de cette checklist, appliqués systématiquement, réduisent le risque que le client se retrouve démuni face à un thème qu'il ne comprend plus, une fois l'agence partie.