# Reprendre un site en éditeur de site d’une autre agence : l’audit

> Avant de toucher au moindre template, une grille d'audit pour comprendre ce qu'une autre agence a réellement laissé dans les fichiers et dans la base.

- Auteur : Clément Hadrot
- Publié le : 2026-01-01
- Mis à jour le : 2026-01-01
- Catégorie : FSE
- URL : https://wpmoderne.dev.wordpress-developpement.fr/fse/reprendre-site-editeur-site-audit/

## L’essentiel

- Comparer systématiquement les fichiers du thème et leurs surcouches en base
- Repérer les patterns orphelins avant de les supprimer à tort
- Ne jamais présumer qu'un dossier patterns/ propre reflète la réalité du site

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.

> L'essentiel à retenir : Comparer systématiquement les fichiers du thème et leurs surcouches en base ; Repérer les patterns orphelins avant de les supprimer à tort ; Ne jamais présumer qu'un dossier patterns/ propre reflète la réalité du site

## 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 dossier `patterns/` 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.