Transmettre un site WordPress ne devrait pas se résumer à envoyer un compte administrateur. Le nouveau développeur doit comprendre où se trouvent le code, les données, le domaine, les sauvegardes et les services externes. Une passation structurée réduit le temps de diagnostic, évite les interruptions et permet de distinguer clairement les anomalies existantes des changements réalisés après la reprise.
Pour relier ce guide à une mise en œuvre concrète, consultez notre support technique pour agences et graphistes : cette page explique le cadre d’intervention, la marque blanche, la recette et la transmission.
Identifiez le propriétaire du site, le contact côté agence ou entreprise, l’ancien prestataire et le nouveau développeur. Définissez qui autorise les accès, les dépenses, les modifications de production et une éventuelle coupure. Si le développeur travaille en marque blanche, précisez s’il peut communiquer avec le client final et sous quelle identité.
Listez les sites, sous-domaines et environnements concernés. Un compte d’hébergement peut contenir des projets qui ne font pas partie de la mission. Pour toute intervention, notamment de sécurité, le nouveau prestataire doit disposer d’une autorisation explicite et respecter ce périmètre.
Préparez les accès WordPress, hébergement, SFTP ou SSH, base de données, gestion du domaine et DNS. Ajoutez le CDN, le service SMTP, les sauvegardes, l’outil d’analyse, la Search Console et les plateformes connectées selon le besoin. Utilisez un gestionnaire de mots de passe ou un canal convenu plutôt qu’un document partagé en clair.
Créez des comptes nominatifs lorsque c’est possible. Évitez de transmettre le compte personnel de l’ancien prestataire. Après vérification de la reprise, révoquez les accès devenus inutiles et renouvelez les secrets sensibles selon une procédure coordonnée, sans bloquer les services.
Indiquez le fournisseur, l’offre, les échéances, les versions de PHP et de la base, les limites particulières et l’emplacement des journaux. Documentez les tâches cron, règles serveur, certificats, caches et sauvegardes. Mentionnez les autres sites présents sur le même compte lorsqu’ils peuvent partager des ressources ou un risque.
Pour le domaine, précisez le bureau d’enregistrement, les titulaires et les personnes capables de modifier la zone DNS. Les enregistrements de messagerie doivent être identifiés : déplacer WordPress ne déplace pas automatiquement les boîtes e-mail.
Le dépôt de code doit contenir les développements spécifiques et un historique exploitable. Expliquez les branches, la procédure de mise en production, les variables d’environnement et ce qui est volontairement exclu du dépôt. Si aucun dépôt n’existe, fournissez au minimum une copie datée et distinguez le code personnalisé des composants téléchargeables.
Signalez toute modification directe d’un thème parent, d’une extension ou du cœur WordPress. Elle risque d’être écrasée lors d’une mise à jour. Le nouveau développeur pourra alors décider de la déplacer vers un thème enfant ou un plugin spécifique avant de reprendre la maintenance.
Inventoriez les extensions et thèmes premium, leur titulaire, leur date de renouvellement et les domaines autorisés. Indiquez quelles licences appartiennent au client, à l’agence ou à l’ancien prestataire. Une fonction critique ne doit pas cesser sans avertissement parce qu’une licence personnelle a été retirée.
Ajoutez les moyens de paiement, API, CRM, formulaires, stockage, polices, consentement, analytics et services d’envoi. Pour chacun, précisez le compte propriétaire, l’usage, le mode de test et le contact de support. Ne placez pas les secrets directement dans la documentation générale.
Rassemblez les tickets récents, incidents connus, choix techniques, incompatibilités et travaux en attente. Notez les symptômes sans présenter une hypothèse comme un fait. Les erreurs PHP, journaux serveur et rapports de tests permettent au repreneur de prioriser sur des éléments observables.
Fournissez les maquettes, spécifications, règles métier et parcours critiques : connexion, formulaires, paiement, génération de documents ou synchronisations. Indiquez ce qui doit être testé après une mise à jour et qui valide le résultat.
Avant la passation, réalisez une sauvegarde complète des fichiers et de la base, conservée dans un emplacement convenu. Vérifiez qu’elle est accessible et documentez sa date. Si possible, testez la restauration sur un environnement isolé. La présence d’un fichier d’archive ne suffit pas à garantir sa restauration.
Organisez un état des lieux commun : versions, alertes, pages importantes, formulaires et fonctions métier. Le nouveau développeur peut ensuite produire un diagnostic d’admission et signaler les actions nécessaires avant maintenance.
Une passation complète donne au nouveau développeur les moyens de travailler sans créer de dépendance supplémentaire. AdnProg peut réaliser l’état des lieux et la reprise via son offre de support technique pour agences et graphistes.
AdnProg peut analyser l’existant, préciser le périmètre et réaliser les changements nécessaires. La prestation associée est présentée sur la page Support technique pour agences et graphistes.