# Reprendre un site Elementor hérité : notre grille d’audit technique

> Versions, addons tiers, CSS dispersé, templates orphelins, poids des pages : la checklist que nous appliquons avant de chiffrer la reprise d'un site Elementor.

- Auteur : Clément Hadrot
- Publié le : 2022-06-08
- Mis à jour le : 2022-06-08
- Catégorie : Elementor
- URL : https://wpmoderne.dev.wordpress-developpement.fr/elementor/reprendre-site-elementor-herite-grille-audit/

## L’essentiel

- Un inventaire des plugins d'addons évite les mauvaises surprises de licence
- Les templates non assignés à aucune condition alourdissent la base sans bénéfice
- Le poids moyen des pages donne une idée fiable du travail de nettoyage à prévoir

« On a un site Elementor, plus personne ne sait qui l'a fait, il rame et on veut le faire évoluer » : c'est à peu près la formulation exacte d'un appel reçu la semaine dernière. Reprendre un site Elementor construit par une autre agence, ou par un développeur parti depuis, est un exercice fréquent, et il ne se chiffre jamais sérieusement sans un audit préalable structuré. Improviser ce chiffrage au feeling mène presque toujours à sous-estimer le travail réel.

Voici la grille que nous appliquons systématiquement avant de proposer un devis de reprise, avec les sept points qui, dans notre expérience, concentrent la majorité des mauvaises surprises.

## 1. Versions d'Elementor, Elementor Pro et PHP

Premier réflexe : **Elementor > Réglages > Général** et le pied de page de l'administration WordPress donnent les versions installées. Un site resté bloqué sur une version d'Elementor vieille de plusieurs années, sur un PHP 7.4 en fin de vie, signale souvent une maintenance interrompue depuis longtemps — et donc un chantier de mise à jour à part entière avant même de parler de nouvelles fonctionnalités.

## 2. Inventaire des addons tiers et de leurs licences

Un site Elementor hérité contient presque toujours un ou plusieurs plugins d'extension de widgets (Essential Addons, PowerPack, Ultimate Addons…), parfois plusieurs en parallèle pour des besoins qui se recoupent. Il faut vérifier lesquels sont réellement utilisés dans le contenu — un widget d'un addon désactivé casse l'affichage de la page qui l'utilisait — et si les licences premium sont encore valides et transférables au nouveau prestataire.

- Lister chaque plugin d'addons actif et sa version.
- Vérifier, via une recherche dans le contenu des pages, quels widgets de chaque addon sont réellement en usage.
- Confirmer avec le client la propriété des licences premium.

## 3. CSS personnalisé dispersé

Comme souvent sur un site jamais audité, le Custom CSS se retrouve dispersé entre widgets, pages et réglages globaux, sans logique de centralisation. Un rapide sondage sur quelques pages représentatives donne une idée du volume de nettoyage à prévoir avant toute évolution sereine du design.

> L'essentiel à retenir : Un inventaire des plugins d'addons évite les mauvaises surprises de licence ; Les templates non assignés à aucune condition alourdissent la base sans bénéfice ; Le poids moyen des pages donne une idée fiable du travail de nettoyage à prévoir

## 4. Templates orphelins dans le Theme Builder

Il est fréquent de trouver, dans **Templates > Theme Builder**, des templates créés puis jamais assignés à aucune condition, ou des conditions qui pointent vers des catégories supprimées depuis. Ces templates orphelins n'affectent pas directement l'affichage, mais alourdissent la base de données et compliquent la compréhension du site pour quiconque le reprend.

### Comment les repérer

1. Ouvrir chaque template du Theme Builder et vérifier l'onglet Conditions.
2. Noter ceux dont la condition référence un élément supprimé (catégorie, page, type de contenu désinstallé).
3. Confirmer avec le client avant suppression, certains pouvant être des brouillons volontairement mis de côté.

## 5. Poids moyen des pages

Un rapide passage dans les outils de développement du navigateur, onglet Réseau, sur trois ou quatre pages représentatives, donne une mesure fiable du travail de nettoyage à prévoir : nombre de requêtes, poids total transféré, présence de scripts d'addons chargés sur des pages qui ne les utilisent pas.

| Indicateur | Seuil d'alerte observé |
| --- | --- |
| Poids total de page | Supérieur à 3 Mo sur une page de contenu simple |
| Nombre de requêtes CSS/JS | Plus de 25 fichiers distincts chargés |
| Version Elementor | Plus de deux versions majeures de retard |

## 6. Base de données et révisions

Elementor stocke la structure complète de chaque page en JSON dans les métadonnées du post, plus l'historique des révisions WordPress standard. Sur un site jamais nettoyé, ces révisions peuvent représenter un volume conséquent de la base de données, à purger avec l'outil natif ou un plugin de nettoyage avant toute migration.

## 7. Sécurité et comptes d'accès

Dernier point, souvent oublié : vérifier la liste des comptes administrateurs actifs, et si des accès FTP ou d'hébergement de l'ancien prestataire sont toujours valides. Une reprise de site s'accompagne systématiquement d'une rotation complète des accès sensibles.

> Un audit bien mené change souvent le devis initial du client, en bien comme en mal : mieux vaut annoncer un chiffrage réaliste après ces sept points qu'un chiffrage optimiste découvert faux après la première semaine de travail.

## En résumé

Reprendre un site Elementor hérité sans audit préalable revient à chiffrer à l'aveugle. Les sept points de cette grille — versions, addons et licences, CSS dispersé, templates orphelins, poids des pages, base de données, sécurité des accès — couvrent la quasi-totalité des mauvaises surprises que nous avons rencontrées sur ce type de mission, et permettent un devis qui tient réellement la route une fois le projet démarré.