diff style-original-2016.css style.css : cette seule commande, lancée avant toute autre étape d’une reprise de projet, a révélé 340 lignes modifiées sur un total de 1 800, dans un thème que personne dans l’équipe cliente ne savait avoir été retouché depuis sa livraison initiale. Le client parlait d’un site « qui n’a jamais bougé » ; le fichier de style racontait une tout autre histoire, faite de correctifs ponctuels accumulés sans jamais être documentés.
Cette comparaison ne vise pas à quantifier une dette technique globale sur plusieurs années de suivi : elle sert un objectif plus modeste et plus immédiat, celui de mesurer objectivement l’écart entre ce que le client croit savoir de son thème et ce que le code révèle réellement, avant toute reprise.
Retrouver une version d’origine à comparer
La première difficulté consiste à mettre la main sur une version de référence du thème. Trois sources permettent généralement d’y parvenir : une archive du thème premium encore disponible sur le site de son éditeur, une sauvegarde ancienne retrouvée chez l’hébergeur précédent, ou, à défaut, l’historique d’un dépôt de versionnement si le projet en possédait un dès son origine. Sans aucune de ces sources, la comparaison devient impossible et l’agence doit se contenter d’un audit du code en l’état, sans référence historique.
Ce que révèle un diff bien mené
Une fois les deux versions en main, la commande diff ou un outil de comparaison visuelle en ligne donne une première image chiffrée de l’écart. Sur ce projet précis, l’analyse des 340 lignes modifiées a permis de classer les changements en trois catégories, chacune racontant une histoire différente sur la vie réelle du thème :
- Des correctifs de compatibilité ajoutés au fil des montées de version de WordPress, reconnaissables à des commentaires isolés du type
/* fix pour WP 5.x */. - Des surcharges visuelles ponctuelles, demandées par le client à différentes périodes, sans lien entre elles.
- Des règles dupliquées, ajoutées en fin de fichier plutôt que corrigées à la source, signe d’interventions pressées sans relecture du fichier existant.
Un exemple représentatif trouvé dans ce diff
< .site-header { background: #1a2b3c; }
---
> .site-header { background: #1a2b3c; }
> .site-header { background: #24354a !important; } /* demande client 03/2019 */
> .site-header.sticky { background: #24354a !important; } /* correctif menu collant 11/2021 */
Trois règles concurrentes pour définir la même couleur de fond, empilées au fil du temps sans qu’aucune n’ait jamais été retirée : ce schéma, répété à plusieurs endroits du fichier, explique une partie des 340 lignes de différence et donne une idée concrète du travail de nettoyage à prévoir avant toute nouvelle évolution visuelle du site.
Traduire ce diff en éléments de devis
Ce travail de comparaison ne reste pas un exercice académique : il alimente directement le chiffrage de la reprise. Chaque catégorie de modification identifiée correspond à un poste de travail différent, avec un niveau de risque propre :
| Catégorie de modification | Risque pour la reprise |
|---|---|
| Correctifs de compatibilité WordPress | Faible, souvent encore valides |
| Surcharges visuelles ponctuelles | Moyen, à vérifier une par une |
| Règles dupliquées non nettoyées | Élevé, source de bugs futurs |
Ce que ce constat change dans la discussion avec le client
Présenter ce diff au client, plutôt qu’une simple affirmation orale sur l’état du thème, change la nature de la conversation : le chiffre de 340 lignes modifiées sur 1 800 devient un fait vérifiable, pas une opinion de prestataire. Cette objectivité facilite l’acceptation d’un devis de reprise plus élevé qu’anticipé, puisqu’elle repose sur une preuve tangible plutôt que sur une estimation générale.
Un thème qui n’a « jamais bougé » selon son propriétaire a presque toujours bougé, discrètement, correctif après correctif : le diff ne ment jamais sur ce point, contrairement à la mémoire humaine.
Notre verdict
Comparer un style.css ancien à sa version d’origine coûte peu de temps et transforme une impression vague sur l’état d’un thème en données concrètes, exploitables pour cadrer une reprise. Ce réflexe simple mérite d’être systématisé dès qu’une version de référence existe, avant même d’ouvrir functions.php ou de tester le site en conditions réelles.
