Une agence gérant un site e-commerce de taille conséquente, avec plus de deux cents gabarits de page différents accumulés sur cinq ans, s’est retrouvée face à un choix structurant après l’arrivée de l’éditeur V4 d’Elementor : migrer immédiatement l’ensemble du site vers les nouvelles classes globales et variables, ou laisser cohabiter ce nouveau système avec le design system CSS maison déjà en place, construit à la main au fil des années par plusieurs développeurs successifs.
Aucune de ces deux options n’est mauvaise en soi. Le choix dépend surtout de la taille du site, du rythme de développement de nouvelles fonctionnalités, et de la tolérance réelle de l’équipe à gérer temporairement deux systèmes de style en parallèle sans qu’ils n’entrent en collision.
Le cas de la migration totale immédiate
Sur un projet de taille modeste, moins d’une trentaine de gabarits, migrer d’un coup vers les classes globales V4 reste souvent l’option la plus simple à long terme : elle évite précisément la complexité de gestion à deux systèmes, au prix d’un effort concentré sur une période courte, généralement quelques jours de travail dédié selon la richesse du design system existant.
Le cas de la cohabitation maîtrisée
Sur un projet de la taille de celui évoqué en introduction, une migration totale immédiate aurait immobilisé l’équipe pendant des semaines, un luxe que le rythme commercial du site ne permettait pas. La cohabitation a donc été organisée selon une règle simple : toute nouvelle page créée après une date donnée utilise exclusivement les classes globales V4, tandis que les pages existantes conservent leur CSS maison jusqu’à leur prochaine refonte planifiée, sans migration forcée précipitée.
L’espace de noms comme garde-fou
Le vrai risque d’une cohabitation mal gérée n’est pas technique au sens strict, il est organisationnel : deux développeurs qui, sans le savoir, créent chacun une variable de couleur légèrement différente pour un même bleu de marque, l’un dans l’ancien système CSS maison, l’autre dans les nouvelles variables V4. Pour éviter cette dérive, un préfixe de nommage strict a été imposé : toute nouvelle variable V4 commence par v4-, ce qui rend immédiatement visible, dans le code comme dans l’éditeur, à quel système chaque valeur appartient.
Comparatif des deux approches
| Critère | Migration totale immédiate | Cohabitation maîtrisée |
|---|---|---|
| Taille de projet adaptée | Petit à moyen | Moyen à grand |
| Effort initial | Concentré, quelques jours | Étalé, sur plusieurs mois |
| Risque de double source de vérité | Faible (transition courte) | Réel, à gérer activement |
| Impact sur le rythme commercial | Interruption courte mais visible | Aucune interruption notable |
Signes qu’une cohabitation dérape
- Deux valeurs de couleur très proches mais différentes coexistent sans qu’aucun développeur ne s’en aperçoive avant un audit visuel poussé.
- Une même page mélange des classes globales V4 et des classes CSS maison sans logique claire de séparation entre les deux.
- Personne dans l’équipe ne sait plus, sans vérifier le code, si une nouvelle fonctionnalité doit utiliser l’ancien ou le nouveau système.
Sur le projet évoqué, ce dernier signe est apparu après quatre mois de cohabitation, révélant le besoin d’une règle écrite et documentée, pas seulement d’une convention orale transmise entre développeurs.
Une cohabitation entre deux systèmes de style n’est pas un problème en soi tant qu’elle reste une décision consciente, documentée et bornée dans le temps. Le vrai danger commence quand elle devient un état permanent par simple absence de décision.
Pour aller plus loin
Ce comparatif suppose que la décision de cohabiter ou de migrer entièrement se prend en amont, en connaissance de cause. Elle ne remplace pas la méthode pas à pas de migration technique elle-même, déjà traitée dans un article de cas dédié. Sur un grand projet, la vraie question n’est jamais « faut-il migrer », mais « à quel rythme, et avec quelles règles de garde-fou pour éviter la dérive silencieuse ».
