Reprendre un site conçu par une autre agence, en thème classique, se limitait souvent à lire le code PHP pour comprendre ce qui se passait. Avec l’éditeur de site, une partie de la réalité du site échappe totalement aux fichiers : elle vit uniquement en base de données, invisible tant qu’on ne sait pas où regarder. Voici la grille que je déroule avant tout devis de reprise.
1. Comparer les fichiers du thème et leurs surcouches en base
Tout template ou template part personnalisé depuis l’éditeur de site génère une entrée en base (wp_template, wp_template_part) qui prend le pas sur le fichier du thème correspondant, sans jamais le modifier. Un examen des seuls fichiers templates/*.html et parts/*.html du thème peut donc donner une image complètement fausse du rendu réel du site si des surcouches existent en base. Une requête wp post list --post_type=wp_template,wp_template_part --format=table en WP-CLI liste immédiatement ce qui a été modifié depuis l’interface, à comparer ensuite un par un avec les fichiers du thème.
2. Vérifier la cohérence entre theme.json et les styles utilisateur enregistrés
Comme pour les templates, les réglages du panneau Styles sont stockés à part, dans un article wp_global_styles, distinct de theme.json. Un audit sérieux compare les deux : un theme.json soigné mais jamais reflété dans les styles utilisateur réellement actifs indique souvent un projet abandonné en cours de route, ou une bascule de thème mal terminée par l’agence précédente.
3. Repérer les patterns orphelins avant toute suppression
La bibliothèque de patterns d’un site repris affiche souvent des entrées dont plus aucun template ni aucune page ne fait usage — restes d’essais, de campagnes terminées, de versions abandonnées d’une même section. Avant de les supprimer pour faire le ménage, une recherche du slug ou de l’identifiant du pattern dans le contenu des pages et des templates confirme qu’il n’est effectivement plus référencé nulle part, y compris dans des templates spécifiques à un terme de taxonomie ou à un type de contenu personnalisé, facilement oubliés lors d’une recherche rapide.
4. Localiser le CSS additionnel, souvent hors de vue
Le CSS additionnel du Customizer, hérité de l’époque pré-éditeur de site, continue d’exister indépendamment de theme.json et des styles globaux — stocké dans un article dédié du type custom_css. Une agence précédente a pu y accumuler des correctifs ponctuels jamais réintégrés proprement dans les styles du thème. Ce CSS reste actif même après une bascule complète vers un thème bloc, ce qui explique parfois des styles inattendus dont l’origine reste introuvable en ne regardant que theme.json.
5. Recenser les extensions qui enregistrent des blocs ou des patterns
- Lister les extensions actives qui déclarent des blocs personnalisés via
register_block_type(), pour identifier ce qui dépend d’un plugin tiers plutôt que du thème lui-même. - Vérifier si des patterns sont enregistrés depuis le code d’une extension via
register_block_pattern(), invisibles dans le dossierpatterns/du thème puisqu’ils vivent ailleurs. - Repérer les extensions désactivées mais toujours installées : leurs blocs, s’ils sont utilisés dans du contenu existant, se rendraient alors comme blocs non reconnus si l’extension venait à être supprimée par erreur pendant la reprise.
Ce que cette grille ne couvre pas
Cet audit porte exclusivement sur la cohérence structurelle du site en éditeur de site — pas sur ses failles de sécurité, ses droits d’accès aux comptes existants, ni la qualité de son hébergement, qui relèvent d’un audit de sécurité à part entière, mené séparément.
Un site qui « a l’air propre » en surface cache presque toujours, en base, des restes de plusieurs itérations passées. Le voir avant de signer le devis évite de découvrir, en cours de mission, un chantier deux fois plus large que prévu.
Pour aller plus loin
Une fois cette grille déroulée, le devis de reprise peut distinguer clairement ce qui relève d’un nettoyage rapide (patterns orphelins, CSS additionnel obsolète) de ce qui relève d’une refonte plus profonde (incohérence structurelle entre fichiers et base, dépendance à des extensions non maintenues). Cette distinction, posée dès l’audit, évite la plupart des mauvaises surprises budgétaires en cours de mission.
