Reprise et refonte
Reprendre la main sur un Divi hérité : le nettoyer, le documenter, le rendre maintenable.
Développeur Divi · France entière
Un site Divi, ça commence souvent bien : le builder est puissant, on assemble vite, le rendu est joli. Et puis, deux ans plus tard, la page met cinq secondes à charger, on n’ose plus lancer une mise à jour de peur que tout casse, et un module tiers installé un jour de rush bloque désormais l’éditeur. C’est presque toujours à ce moment-là qu’on me contacte.
Je suis développeur freelance, j’accompagne des sites internet depuis 2009, et Divi fait partie de mes outils quotidiens — en local comme à distance. Mais autant être honnête dès la première ligne, parce que c’est le fil de tout ce que je fais : Divi seul ne suffit jamais. Un beau site Divi qui n’est ni sécurisé, ni rapide, ni pensé pour convertir, c’est une vitrine sur du sable. Mon métier, ce n’est pas « faire du Divi » — c’est faire tenir l’ensemble : la sécurité, le référencement, les paiements, la conversion. C’est déjà ce que j’écrivais il y a plus de dix ans, et rien n’a changé sur ce point.
Les situations qui m’arrivent se ressemblent, et vous vous reconnaîtrez peut-être dans l’une d’elles :
Un site qui rame et dont personne ne sait pourquoi — parce que le vrai coupable est rarement là où on le cherche. Un site qu’on n’ose plus mettre à jour, figé sur de vieilles versions par peur de la casse, et qui accumule les failles pendant ce temps. Un builder poussé au-delà de ce qu’il encaisse : des dizaines de modules, des plugins Divi tiers empilés, un thème enfant bricolé au fil des ans. Ou simplement une reprise : vous héritez d’un site Divi fait par quelqu’un d’autre, sans documentation, et il faut le faire évoluer sans tout réécrire.
Dans tous ces cas, la première chose que je fais n’est pas de coder — c’est de diagnostiquer. Localiser la couche où ça coince avant de toucher à quoi que ce soit. Un site Divi lent peut souffrir de son hébergement, de sa base de données, d’un plugin, du thème lui-même, ou de la concurrence d’accès. Tant qu’on ne sait pas où, tout le reste est de la superstition.
Reprendre la main sur un Divi hérité : le nettoyer, le documenter, le rendre maintenable.
La demande d’entrée la plus fréquente — et rarement là où on croit qu’elle est.
Module par module, sans laisser le mode de compatibilité annuler les gains.
Le plugin tiers qui bloque l’éditeur, le module cassé après mise à jour, la page qui ne s’enregistre plus.
Autour de Divi, et c’est là que se joue la vraie valeur : la sécurisation (pare-feu, blocage d’intrusions, sauvegardes automatiques), le référencement technique, la mise en place des paiements, et l’optimisation de ce qui fait qu’un visiteur devient client. Le builder fait le visuel ; le reste fait le résultat.
Depuis février 2026, Divi 5 est disponible en version stable, après plus de trois ans de développement. C’est une réécriture complète, et elle mérite qu’on la comprenne avant de migrer.
Le changement de fond, c’est la fin des shortcodes. Divi 4 enregistrait vos pages sous forme de longues chaînes de shortcodes imbriqués — un format lourd que le serveur devait analyser et reconstruire à chaque chargement. Divi 5 adopte un format structuré, inspiré de l’architecture des blocs WordPress, bien plus léger à traiter. Le gain est réel et mesuré : sur une page équivalente, Divi 5 génère de l’ordre de 84 % de JavaScript en moins et 94 % de CSS en moins que Divi 4, avec des temps de chargement deux à quatre fois meilleurs selon la complexité de la page.
Anecdote au passage, parce qu’elle illustre exactement le problème des shortcodes : quand j’ai migré mon propre site, une ancienne page dont tout le contenu était enfermé dans les shortcodes d’un builder est arrivée… vide. Le texte existait, mais prisonnier d’un format que l’export ne savait pas lire. C’est précisément ce que Divi 5 corrige à la racine.
Mais il y a un piège, et il est important. Divi 5 embarque un mode de compatibilité avec Divi 4. Si une seule page de votre site contient un module Divi 4 ou un module tiers non converti, Divi 5 recharge l’ancien framework pour cette page — qui perd alors le bénéfice des gains de performance. Autrement dit : migrer ne suffit pas, il faut migrer proprement, en convertissant ou remplaçant les modules incompatibles. C’est là qu’une reprise faite à la main, module par module, fait la différence avec une mise à jour lancée en aveugle.
Je détaille tout ça, chiffres et procédure de migration à l’appui, dans mon article Passer de Divi 4 à Divi 5.
Voici la part que peu de prestataires vous diront, et c’est ma signature : un builder plus rapide ne répare pas un hébergement sous-dimensionné.
Divi 5 réduit le travail demandé au thème — c’est réel, c’est précieux. Mais si votre site rame parce que votre hébergement mutualisé plafonne en nombre de processus PHP simultanés, parce que votre base de données est lente, parce qu’un plugin lourd tourne en tâche de fond ou qu’un appel externe bloque le chargement, alors Divi 5 n’y changera rien. J’ai mesuré ce genre de plafond sur des hébergements mutualisés : au-delà d’une douzaine de traitements PHP concurrents, la page part en file d’attente, et aucun builder au monde ne corrige ça.
C’est pour ça que je diagnostique avant d’agir. Parfois la bonne réponse est de migrer vers Divi 5. Parfois c’est de changer d’hébergement. Souvent, c’est les deux — mais dans le bon ordre, et pour les bonnes raisons. Vous payer une migration Divi 5 alors que votre problème est un plafond FastCGI, ce serait vous faire dépenser de l’argent sans résoudre votre souci.
Au fil des projets, j’ai documenté plusieurs solutions Divi précises : ajouter un bouton « charger plus d’articles » au module Blog, construire un sous-menu sur deux colonnes sans plugin, régler un conflit de z-index entre menu principal et menu secondaire, ou débloquer l’erreur « Invalid User Action » au moment d’une mise à jour. Ce sont des interventions ponctuelles, mais elles disent le quotidien du métier : Divi marche bien, jusqu’au détail qui bloque tout — et c’est ce détail qu’on vient chercher chez un freelance.
Divi et Elementor sont solides et pérennes, faciles à prendre en main pour un client qui veut maintenir son site en interne, mais historiquement plus lourds dans leur code natif — un écart que Divi 5 réduit fortement. Oxygen Builder, à l’inverse, vise la performance et le contrôle du code : puissant pour un développeur, plus exigeant pour un débutant. Le bon builder dépend de qui maintiendra le site, et de ce qui compte le plus pour vous : autonomie ou performance brute.
Je commence toujours par un diagnostic sur une copie de préproduction, jamais directement sur votre site en ligne. J’identifie ce qui pèse, ce qui est à risque, ce qui est à jour ou non. Je vous propose ensuite un plan chiffré et priorisé — l’urgent d’abord, l’amélioration ensuite — et je n’interviens sur la production qu’une fois les tests validés. Vous gardez à chaque étape une trace écrite de ce qui est fait et pourquoi.
Si vous vous êtes reconnu dans l’une de ces situations — un Divi qui rame, qu’on n’ose plus toucher, ou dont vous héritez — le premier pas est toujours le même : un diagnostic honnête, avant tout devis. On regarde ce qui se passe vraiment, et on décide ensemble de la suite.