Divi, Elementor et la dette technique : le vrai coût sur 3 ans

Un constructeur de pages produit sa mise en page par des conteneurs imbriqués et stocke le contenu dans un format propre à l'outil. Trois conséquences se paient dans le temps : des pages plus lourdes que nécessaire, un contenu qui n'existe pas hors de l'extension qui l'a créé, et une dépendance à une licence commerciale. Ces coûts sont invisibles la première année, sensibles la deuxième, décisifs la troisième, quand une refonte devient plus économique qu'une reprise.

Ce qu'ils font bien, et il faut le dire

Ils tiennent leur promesse principale. Une entreprise sans budget de développement obtient un site présentable en deux semaines, modifiable par quelqu'un qui n'écrit pas de code, sans dépendre d'un prestataire pour changer un texte ou ajouter une section.

Pour une TPE, une association, un projet à petit budget, c'est un service réel. Nous n'avons rien contre ces outils dans ce cadre, et une partie de la critique qu'on en fait est snob.

Ce qui suit concerne les entreprises pour lesquelles le site est un canal commercial, avec un trafic, des objectifs et un budget.

Coût 1, le poids des pages

Une section simple, un titre et deux colonnes de texte, sort du constructeur en cinq ou six niveaux de conteneurs, chacun avec ses classes et parfois ses styles en ligne. Le HTML fait plusieurs fois ce qu'il devrait faire.

S'ajoutent la bibliothèque du constructeur, chargée sur chaque page, et les modules complémentaires installés pour obtenir un effet particulier. Ces modules suivent la même logique et ajoutent leurs propres fichiers.

Le résultat se mesure : sur les sites que nous auditons, la différence de poids entre une page construite ainsi et la même page écrite proprement est d'un facteur trois à cinq. Le sujet plus large de la dégradation est traité dans notre article sur les sites WordPress qui ralentissent.

Coût 2, l'enfermement du contenu

C'est le coût le plus important, et le moins visible.

Le contenu d'une page construite avec ces outils est stocké dans un format propriétaire, mêlé à des marqueurs de mise en page. Il n'existe pas comme texte structuré : le titre, le paragraphe et le bouton sont dans la même soupe.

Trois conséquences.

Désactiver l'extension rend le site illisible. Ce n'est pas une dégradation d'apparence, c'est du contenu qui ne s'affiche plus.

Migrer demande de reconstruire. Il n'existe pas d'export propre. Le contenu se récupère par extraction depuis le HTML rendu, ce qui produit une conversion à nettoyer page par page.

Changer de constructeur revient à refaire le site. Passer de Divi à Elementor n'est pas une migration, c'est une reconstruction.

Un site construit ainsi est donc lié à son outil pour toute sa vie. C'est acceptable si on le sait. Ça ne l'est pas si on l'apprend au moment de la refonte.

Coût 3, la licence et la maintenance

Ces outils sont commerciaux, avec un abonnement annuel qui donne droit aux mises à jour et au support. Sans abonnement, le site continue de fonctionner et cesse d'être mis à jour, ce qui devient un risque de sécurité.

À cela s'ajoutent les modules complémentaires, souvent payants eux aussi, et souvent moins bien maintenus que le constructeur lui-même. Un module abandonné bloque une mise à jour, et c'est une situation fréquente sur un site de trois ans.

Coût 4, la cohérence

Celui-là n'est ni technique ni budgétaire, et il est réel.

La liberté totale produit des sites incohérents. Chaque page est composée séparément, souvent par des personnes différentes à des moments différents. Au bout de deux ans, les titres n'ont plus la même taille d'une page à l'autre, les boutons n'ont plus la même forme, les marges varient.

C'est le contraire de ce que fait un système de composants, où changer une définition change toutes les occurrences. Cette liberté, vendue comme un avantage, est la raison pour laquelle beaucoup de sites vieillissent mal visuellement alors qu'aucune ligne de code n'a bougé.

Le calcul sur trois ans

Posons-le simplement, sans chiffres inventés.

Année 1. Le constructeur gagne largement. Site livré vite, coût faible, autonomie de l'équipe.

Année 2. Les écarts apparaissent. Le site s'est alourdi, la cohérence se dégrade, les mises à jour demandent des précautions. Le coût de maintenance devient non nul.

Année 3. Le point de bascule. Les performances sont en dessous des seuils, personne n'ose mettre à jour, et chaque modification structurelle demande de contourner l'outil. La question d'une refonte se pose, et le contenu n'est pas récupérable proprement.

L'économie de l'année 1 est réelle. Elle est reprise à l'année 3, avec les intérêts, sous forme d'une refonte qui doit tout reconstruire au lieu de tout reprendre.

Quand ils restent le bon choix

Quatre cas, sans ironie.

• Un site dont la durée de vie prévue est courte : événement, campagne, phase de test d'un marché.
• Une structure sans budget de développement et sans prestataire, pour qui l'autonomie complète prime sur tout le reste.
• Un site où le trafic organique n'est pas un enjeu.
• Un besoin de mise en ligne en quelques jours.

Dans ces cas, le calcul sur trois ans ne s'applique pas, parce que le site n'a pas vocation à durer trois ans dans cet état.

Que faire d'un site existant

Trois options selon l'état.

Vivre avec, en entretenant. Nettoyer les modules inutilisés, alléger les images, optimiser l'hébergement. Cela repousse l'échéance de un à deux ans, avec un coût modeste.

Reconstruire progressivement. Sortir les pages les plus importantes du constructeur, une par une, en gabarits propres. Le site reste hybride pendant la transition. C'est faisable, c'est plus long, et cela évite un chantier unique.

Refondre. Quand les trois signaux sont réunis : vous n'osez plus mettre à jour, les performances restent en dessous des seuils malgré les optimisations, et chaque modification demande un contournement.

Questions fréquentes

Elementor et Divi ralentissent-ils vraiment un site ?

Oui, mesurablement, à cause du HTML imbriqué et des ressources chargées sur chaque page. L'ampleur dépend du nombre de modules complémentaires installés et du soin apporté à la construction. Un site bien construit avec un constructeur peut passer les seuils de performance, mais il part avec un handicap structurel qu'un site écrit proprement n'a pas.

Peut-on migrer un site Elementor sans tout réécrire ?

Le contenu se récupère par extraction depuis le HTML rendu plutôt que par un export propre, et cette conversion demande une relecture page par page. Sur un site de vingt pages, c'est faisable. Sur deux cents pages, c'est un chantier à part entière, qu'il vaut mieux réduire en décidant d'abord quelles pages méritent d'être reprises.

Un thème classique vaut-il mieux qu'un constructeur ?

Un thème sobre avec l'éditeur natif de WordPress produit un HTML nettement plus léger et un contenu qui reste lisible si le thème change. C'est un compromis intéressant pour qui veut rester sur WordPress sans en payer le coût structurel. La limite : moins de liberté de mise en page, ce qui est précisément l'argument de vente du constructeur.

Combien de temps avant que la dette devienne un problème ?

Dans notre expérience, entre dix-huit et trente-six mois selon le rythme de modification du site. Un site qui ne bouge pas vieillit moins vite. Un site où l'on ajoute des pages tous les mois atteint le point de bascule plus tôt, parce que chaque ajout empile un peu plus.

Pour aller plus loin

Si votre site montre ces signes, la question suivante est de savoir ce qui le remplace, et notre article sur Next.js pour un site vitrine pose la comparaison sans caricature. La méthode de migration est décrite dans l'article sur la migration WordPress vers Next.js, et nous menons ces chantiers, c'est l'objet de notre page migration WordPress vers Next.js.