Un site peut être beau le jour de la mise en ligne et déjà difficile à faire évoluer six mois plus tard. Ce n’est pas forcément une question de plateforme. C’est souvent une question de décisions prises dans le code : une option de trop, un markup imposé, une extension qui charge trois scripts pour afficher un chiffre.
Chez CINQ, la qualité du code n’est pas un badge. C’est ce qui décide si le site reste un actif, au sens où on l’entend dans notre article sur le sujet : quelque chose qu’on peut faire évoluer sans tout reprendre.
Voici comment on s’y prend.
1. Faire une chose. La faire proprement.
Un plugin qui calcule un temps de lecture n’a pas besoin d’une page de réglages, d’un shortcode et d’une feuille de style. Il a besoin de compter des mots, de stocker un entier, et de le rendre disponible.
C’est exactement le contrat de Reading Time : une fonction retourne un nombre de minutes. Le thème décide s’il l’affiche en badge, dans un chapô ou même nulle part. Pas de markup imposé, pas d’asset chargé sur le front, pas d’écran d’options.
Le même principe guide Table of Contents : des id sur les titres, un arbre de sommaire en données. Le HTML, encore une fois, reste dans le thème.
Quand un outil décide du rendu à votre place, vous héritez de ses choix. Quand il livre une donnée, vous gardez la main.
2. Séparer le métier du décor
Chez nous, la logique vit en PHP structuré (classes, namespaces, standards WordPress). La présentation vit dans Twig. Le design vit dans le CSS.
Le starter wp-cinquante-et-un formalise ça : chaque nouveau projet part de la même base, pas d’une copie d’une copie d’une copie.
Résultat : moins de copier-coller opaque, plus de patterns partagés, une dette qui ne grossit pas à chaque livrable.
3. Préférer les filtres aux usines à options
Une case à cocher dans l’admin a un coût : il faut l’afficher, la documenter, la migrer, la supporter. Un filtre WordPress a un autre coût : il faut savoir coder pour l’utiliser.
Pour un outil interne ou un plugin destiné à des thèmes maîtrisés, le filtre gagne. Sur Reading Time, le rythme (mots par minute) et les types de contenu passent par deux crochets. Pas de page Settings. Pas de valeurs magiques dispersées dans la base.
On réserve l’interface admin à ce qui doit vraiment être réglé sans toucher au code, comme les mises à jour de thème par exemple. C’est le rôle de notre outil Theme Updates.
4. Écrire pour la personne qui viendra après
Le code d’agence n’est pas écrit pour impressionner. Il est écrit pour être relu.
Concrètement :
- standards WordPress (WPCS) et lint automatisé,
- PHP moderne, typage quand il clarifie,
- documentation courte : comment installer, comment utiliser, comment étendre,
- peu de magie, des noms explicites.
Si demain une autre équipe reprend le projet, elle doit pouvoir comprendre sans nous appeler. C’est aussi ça, un actif.
5. Montrer le niveau sur des briques ouvertes
Nos plugins publics suivent la même démarche et les mêmes réflexes que sur les projets de nos clients : simplicité et évolutivité.
Reading Time en est l’illustration : un fichier, une méta, une fonction, deux filtres. Il a même sa page dédiée.
Pour vérifier où vous en êtes
- Une évolution simple demande-t-elle de toucher dix endroits ?
- Un plugin impose-t-il son HTML, son CSS ou son JavaScript sans que vous l’ayez choisi ?
- Pouvez-vous expliquer en une phrase ce que fait chaque extension active ?
- Un autre développeur pourrait-il reprendre le thème sans archéologie ?
Si plusieurs réponses sont non, le problème n’est pas « il faudrait plus de fonctionnalités ». C’est souvent l’inverse.