Reprise d’un site WordPress développé avec Sage et Bedrock : comment préparer l’audit avant de changer de prestataire

1. Récupérer tous les accès du site WordPress : la checklist

Transférer la gestion d'un WordPress commence par un inventaire précis. L'enjeu consiste à vous assurer que votre structure détient réellement les clés de son infrastructure technique.

Vérifier d'abord si le client est propriétaire des comptes

Si votre agence ou votre freelance précédent reste le titulaire officiel du nom de domaine, du serveur ou de l'organisation Git, lui seul dispose du droit légal de modifier ou couper les abonnements. Un simple compte administrateur dans le back-office ne suffit absolument pas. Comme le précise la documentation de WordPress.org, les rôles internes organisent les droits sur les contenus, mais n'offrent aucun contrôle sur l'hébergement lui-même.

Demandez une preuve de propriété au nom de votre entreprise pour chaque brique du système. Selon les recommandations de la CNIL, bannissez tout envoi de mot de passe par simple messagerie électronique et privilégiez un coffre-fort de mots de passe partagé.

Remplir la grille de transfert ligne par ligne

Passez en revue chaque élément dans un tableau de suivi :

La délibération n° 2022-100 de la CNIL encadre la rotation des secrets d'accès et proscrit les comptes partagés génériques. Ne validez aucune ligne sans preuve formelle. Si votre business dépend de votre trafic organique, faites-vous assister par une agence SEO WordPress qualifiée pour sécuriser vos positions pendant le transfert.

2. Tester une sauvegarde sur un environnement de staging

Une sauvegarde non testée ne constitue qu'un vœu pieux. Un test de restauration sur un environnement de staging (un serveur miroir privé) confirme que les données restent utilisables sans exposer votre site vitrine ou e-commerce. Cet exercice préventif isole d'éventuels bugs sans impacter vos clients.

Cartographier les environnements et valider la restauration

Avant la moindre intervention, recensez chaque instance : la production en ligne, la préproduction et les environnements de travail locaux des développeurs.

Récupérez une archive intégrale associant la base de données et l'arborescence des fichiers (dossier d'uploads, extensions, gabarits). Jouer la restauration sur le staging permet de contrôler :

• L'intégrité de la base de données et des contenus éditoriaux ;
• Le bon fonctionnement des extensions et du thème compilé ;
• La validité des chemins d'accès, des médias et des requêtes du moteur de recherche interne.

Le site doit fonctionner à l'identique, sans alertes cachées.

Sécuriser la procédure de retour arrière

Le plan de rollback détaille comment rétablir l'état initial en cas d'imprévu. Il fixe l'archive de référence, le contact responsable de la décision et l'infrastructure de repli.

Cette précaution évite les pannes prolongées sur votre nom de domaine principal. Si vous souhaitez budgétiser ces opérations techniques récurrentes, consultez notre repère sur le tarif de maintenance WordPress.

3. Contrôler l'architecture Bedrock du projet repris

L'architecture Bedrock renforce la sécurité globale en séparant nettement le code applicatif des répertoires accessibles aux internautes, ce qui change la donne par rapport à une installation classique.

Document root et variables d'environnement

Le dossier racine configuré sur le serveur web doit pointer vers web/ et non vers la racine globale du projet. La documentation officielle de Bedrock rappelle que cette structure bloque tout accès direct aux fichiers sensibles depuis un simple navigateur.

Penchez-vous ensuite sur le fichier .env, qui contient les identifiants de base de données et les clés d'authentification :

• Le fichier .env ne doit jamais être versionné dans le dépôt Git ;
• La variable WP_ENV doit indiquer l'environnement exact (production ou staging) ;
• Aucun mot de passe ne doit subsister en clair dans le code source.

Gestion des dépendances avec Composer

Le cœur de WordPress, les extensions et les bibliothèques logicielles doivent être pilotés par le gestionnaire Composer :

• Les fichiers composer.json et composer.lock doivent être présents et synchronisés ;
• Le répertoire vendor/ reste exclu du versionnement ;
• Les extensions installées manuellement ou non déclarées doivent être isolées et documentées.

Pour explorer les spécificités de cette stack, parcourez notre article sur Bedrock et Sage sous WordPress.

Pour vérifier l'état de votre architecture Bedrock avant de changer d'équipe, détaillez-nous votre site actuel afin d'évaluer ce qui est faisable.

4. Vérifier que le thème Sage se compile sur une machine propre

Le véritable test d'indépendance consiste à cloner le dépôt Git sur une machine vierge et à lancer la compilation du thème. Si la procédure échoue sans la machine du développeur sortant, votre entreprise reste dépendante de son ancien prestataire.

Organisation des templates Blade et des vues

Les gabarits Blade du thème Sage séparent l'affichage graphique de la logique métier PHP. Concrètement, les vues se trouvent dans le répertoire resources/views/, tandis que les classes fonctionnelles sont regroupées dans app/.

Durant l'audit, assurez-vous que les variables soient transmises proprement aux blocs graphiques sans code désordonné dans les templates. Pour approfondir le sujet, reportez-vous à notre comparatif opposant Sage à un thème WordPress classique.

Compilation des assets et test de reproductibilité

Pour des déploiements fluides, la chaîne de compilation doit fonctionner de manière totalement autonome :

• Le gestionnaire de paquets et son fichier de verrouillage doivent être présents dans le dépôt Git ;
• Les assets compilés du dossier public/ ne doivent pas être modifiés à la main ;
• Les commandes de construction doivent générer les fichiers finaux sans dépendances manquantes, conformément à la documentation de Sage.

Si une erreur bloque la génération des fichiers sur un poste neutre, intégrez ce point dans la liste des corrections prioritaires.

5. Lancer composer audit et compléter le contrôle des plugins

Pour lever les doutes sur l'infrastructure PHP, la commande composer audit compare les versions inscrites dans composer.lock aux vulnérabilités connues répertoriées publiquement.

Dépendances PHP et limites de l'audit automatique

Cette analyse programmée examine les paquets déclarés via Composer. Cependant, elle ne couvre pas l'intégralité du site : vos extensions et votre thème demandent une vérification complémentaire basée sur les bulletins d'alerte de WordPress.org. Comme l'explique la documentation Bedrock sur l'audit des vulnérabilités avec Composer, composer audit couvre les paquets PHP, mais pas nativement les vulnérabilités des plugins et thèmes WordPress. L'articulation entre Composer et WordPress offre toutefois la possibilité de verrouiller chaque version et de repérer immédiatement toute modification suspecte dans le code.

Extensions, licences et hiérarchisation des risques

L'audit manuel des modules complémentaires permet de jauger la santé de votre CMS :

• Repérer les plugins abandonnés dans le répertoire officiel, qui ne reçoivent plus de correctifs ;
• Contrôler les licences premium afin de vérifier que votre organisation en détient la propriété pour les prochaines mises à jour ;
• Supprimer les comptes des anciens prestataires et vérifier le chiffrement HTTPS intégral.

Triez ensuite la dette technique par degré d'urgence : colmatez d'abord les failles critiques et isolez les modules obsolètes, mettez à jour les versions dépassées de PHP ou du cœur, puis rédigez le document d'exploitation technique.

Réduire le risque de rupture pendant la passation

Un transfert de compétences bien orchestré réduit considérablement le risque d'incident technique. La règle d'or reste invariable : aucune modification n'atterrit sur votre site de production sans avoir été testée au préalable sur une préproduction isolée. Ce sas évite qu'une extension défaillante ne pénalise vos utilisateurs.

L'opération suit une chronologie stricte : relevé des identifiants, audit des dépendances, validation sur le staging et bascule définitive. Un protocole de retour arrière (rollback) doit exister pour revenir à l'état antérieur à la moindre alerte. Sans filet de sécurité, une mise en ligne ratée paralyse votre visibilité en ligne.

Protocole méthodique et répartition des rôles

Ce passage de témoin s'articule autour de neuf actions coordonnées :

1. Centralisation et vérification des accès hébergeur, DNS et back-office ;
2. Sauvegarde complète et validation de sa restauration ;
3. Inventaire exhaustif des environnements et des secrets techniques ;
4. Définition des critères de déclenchement du rollback ;
5. Audit du code et des configurations ;
6. Exécution des tests fonctionnels ;
7. Bascule des flux vers la nouvelle infrastructure ;
8. Révocation des accès de l'ancien prestataire et renouvellement des clés d'API ;
9. Livraison de la documentation d'exploitation.

Votre mission se focalise sur la centralisation administrative et le contrôle des parcours d'achat ou de contact. Les développeurs entrants assument les sauvegardes, l'analyse du code et la bascule technique.

Recette sur staging et continuité opérationnelle

Avant d'ouvrir les vannes, vérifiez sur le serveur de staging la soumission des formulaires, les emails automatisés, le rendu responsive sur mobile et le balisage SEO, notamment les redirections. Toute friction doit être corrigée sur cet environnement clos.

Dès que la bascule est effective, renouvelez l'ensemble des clés et mots de passe pour verrouiller l'infrastructure. Une transmission propre débouche naturellement sur la tierce maintenance applicative (TMA), ce contrat de suivi technique qui assure les mises à jour et la surveillance continue de votre écosystème WordPress.

7. Évaluer si une agence WordPress à Paris peut reprendre le site

Jugez vos futurs partenaires techniques sur des preuves concrètes d'expertise plutôt que sur des arguments commerciaux, en questionnant directement les développeurs sur les rouages internes de votre stack.

Maîtrise de la stack et méthodes de test

Interrogez l'agence entrante sur sa pratique quotidienne :

• L'utilisation de Composer et le respect de l'autoloading PSR-4 ;
• La manipulation des gabarits Sage et l'injection de données via les view composers ;
• La fourniture d'un livrable d'audit type et d'un plan de retour arrière documenté.

Voici un test rapide : demandez-leur d'expliquer comment ils compilent le thème Sage sans l'aide du développeur historique, en s'appuyant uniquement sur les sources et la documentation technique. Une équipe compétente maîtrise cette routine sans hésiter.

Organisation du suivi et garanties d'exploitation

Vérifiez comment l'équipe structure ses opérations de support : cloisonnement strict entre staging et production, blocage de l'indexation sur les serveurs de test et fréquence des sauvegardes.

Pour fixer vos critères avant de missionner une agence web à Paris, demandez à consulter des modèles d'audits et vérifiez que leurs réalisations en ligne illustrent exactement l'environnement technique attendu sur votre projet.

Pour aller plus loin

• Refonte du blog de LaGrowthMachine
• Mise à jour WordPress
• TMA WordPress
• Refonte site e-commerce Hormeta

Confier la reprise et la maintenance de votre WordPress aux Yétis

Reprendre un site WordPress sur mesure exige de la rigueur technique et une vision d'ensemble, depuis l'audit de l'architecture jusqu'au suivi opérationnel en production. Les Yétis conçoivent, développent et maintiennent votre site avec une seule et même équipe : WordPress, Next.js ou Payload CMS selon le besoin, avec la performance et le SEO pensés dès le cadrage. Parlez-nous de votre projet ou de votre site actuel, nous vous disons honnêtement ce qui est faisable.

FAQ