WordPress chez Digitz
On rencontre deux WordPress. Celui qui fait tourner une part énorme du web sérieux, journaux, institutions, grandes marques éditoriales, et celui qu'on installe un dimanche soir avec un thème du commerce et une pile d'extensions trouvées au hasard. Le second donne au premier sa mauvaise réputation. Quand on parle de WordPress chez Digitz, on parle du premier : un CMS construit, tenu, dont on maîtrise chaque brique. La différence ne se voit pas le jour de la mise en ligne. Elle se voit au bout de deux ans, quand le site a doublé de pages et que la personne qui l'a fait est partie.
On documente ce qu'on produit. Pas l'inverse.
Le terrain de WordPress, c'est l'éditorial. Un site où le contenu est le produit : un média qui publie plusieurs articles par jour, une collectivité avec des centaines de pages de service, une marque qui anime un magazine, un office qui décrit un territoire entier. Là où il y a du volume, des contributeurs multiples et un besoin de publier vite sans rappeler un développeur à chaque fois, WordPress est difficile à battre. Son back-office est connu, la prise en main est rapide, et une rédaction y travaille en autonomie une fois les gabarits posés. C'est rare et ça compte : la plupart des outils obligent à arbitrer entre liberté de publication et structure tenue. WordPress bien construit donne les deux. Il sait aussi distribuer les rôles : un rédacteur qui propose, un relecteur qui valide, un administrateur qui publie. Sur un site à plusieurs mains, ce circuit de relecture évite qu'une coquille parte en ligne et garde une trace de qui a fait quoi. C'est un détail tant qu'on est seul, c'est vital dès qu'on est dix.
Bien construit, justement. Tout part du thème. La voie facile consiste à acheter un thème générique et un page builder, puis à tout monter à la souris. Ça marche le premier mois. Ensuite la dette s'accumule : pages lourdes, mise en page qui dérive d'un contributeur à l'autre, mises à jour qui cassent la composition, et un site qu'aucune autre équipe ne peut reprendre sans tout démonter. On code le thème à la main. La structure, les gabarits et le design system vivent dans le code, versionnés et relus. Le contributeur garde la main sur ce qui doit bouger, le texte, les images, l'ordre des sections, et n'a aucune prise sur ce qui doit rester stable. C'est cette frontière qui fait qu'un site tient dans la durée.
Gutenberg, l'éditeur de blocs de WordPress, change la donne quand on l'utilise pour ce qu'il est. On ne livre pas une page blanche où le rédacteur recompose tout. On taille des blocs au plus près du projet, un par modèle de contenu utile : un bloc fiche produit, un bloc chiffre clé, un bloc citation, un bloc appel à projet. Chaque bloc a ses champs, ses règles et son rendu déjà codé. La rédaction assemble ces briques comme un jeu de construction, sans jamais pouvoir casser la cohérence visuelle. On obtient la souplesse d'un page builder sans sa dette, parce que la liberté est bornée par avance. Pour des champs structurés répétitifs, fiches, annuaires, listes filtrables, on s'appuie sur des champs personnalisés afin que la donnée reste propre et réutilisable, dans le site comme ailleurs.
Le multisite et le multilingue font partie du terrain naturel de WordPress, et c'est souvent ce qui décide du choix. Un groupe avec plusieurs marques, une collectivité avec ses satellites, une enseigne présente dans plusieurs pays : on gère un réseau de sites depuis une seule administration, avec des gabarits partagés et des contenus propres à chacun. Le multilingue se traite sans dupliquer un site par langue à la main. Ce sont des chantiers où d'autres stacks demanderaient un développement lourd, et où WordPress arrive avec une réponse déjà rôdée, à condition de l'outiller correctement dès le départ.
Reste le sujet qui fâche, la sécurité. WordPress est le CMS le plus attaqué du monde, pour une raison simple : c'est le plus répandu. Mais l'immense majorité des sites compromis le sont par une extension abandonnée, un thème jamais mis à jour ou un mot de passe faible, à la périphérie du cœur de WordPress lui-même. Notre réponse tient à la discipline. On limite le nombre d'extensions au strict nécessaire, on ne retient que celles qui sont maintenues, et tout ce qui peut être codé proprement l'est directement dans le thème. Moins de surface, moins de risque. Les mises à jour sont suivies, testées avant d'être passées en production, et le site est sauvegardé pour qu'un retour en arrière soit toujours possible. La sécurité d'un WordPress se tient dans le temps, en continu.
La performance suit la même logique. Un WordPress lent, c'est presque toujours un WordPress trop chargé : un thème qui appelle des ressources inutiles, des extensions qui s'ajoutent les unes aux autres, des images servies dans leur poids d'origine. On part du thème sobre, on met en cache ce qui peut l'être, on sert les images au bon format et à la bonne taille, et on mesure les vrais chiffres. Un site éditorial à fort trafic peut très bien tenir la charge sous WordPress quand l'assise est saine. La lenteur vient d'une installation laissée à elle-même, et le CMS y est pour rien. Sur les gros volumes, on surveille aussi la base de données, qui grossit avec les années et les contenus. Des requêtes mal écrites par une extension, une table qui enfle sans entretien, et le back-office rame avant le site public. On nettoie ce qui doit l'être, on indexe ce qui le mérite, et on vérifie que l'administration reste rapide même avec des dizaines de milliers d'articles. C'est le genre de travail invisible qui décide si un site vieillit bien.
Là où WordPress devient encore plus intéressant, c'est qu'il sait sortir de son rôle de site monolithe. On peut s'en servir comme back-office de contenu pur et exposer les données à un front développé à part, en headless, quand le projet réclame une vitesse ou des interactions que le rendu classique ne donne pas. La rédaction garde l'outil qu'elle connaît, l'équipe technique récupère un front libre. On ne le propose pas par principe, mais quand un projet a un socle éditorial déjà sain et des besoins d'affichage particuliers, c'est une voie qui évite de tout refaire. C'est aussi par là que l'IA se branche le plus naturellement : assistance à la rédaction dans le back-office, recherche augmentée sur un fonds documentaire dense, génération de variantes de pages à partir de données structurées. La couche IA vient se poser sur un socle de contenu propre, elle ne le remplace pas.
Un mot sur la longévité, parce que c'est souvent l'angle mort des choix de stack. WordPress existe depuis 2003 et fait tourner une part majeure du web. Le code est ouvert, la communauté énorme, et on trouve sans peine quelqu'un pour reprendre un site bien fait. Vous restez libre de tout éditeur et de toute licence qui pourrait changer ses tarifs ou fermer du jour au lendemain. Quand on livre un WordPress propre, on livre un site qui ne dépend ni de nous ni d'une plateforme tierce, et c'est exactement ce qu'un dirigeant doit pouvoir exiger. À l'inverse, un site monté sur un outil de niche ou un page builder propriétaire peut devenir un piège le jour où l'outil disparaît ou cesse d'être mis à jour.
Le choix de la stack se fait sur le besoin réel du projet. WordPress est le bon outil quand l'éditorial commande, quand le volume de contenu est élevé et que des équipes non techniques doivent publier sans dépendre de nous. Il l'est moins, voire pas du tout, quand le projet repose sur une logique métier dense, des règles de gestion qui s'empilent, des workflows à plusieurs étapes, des calculs serrés ou un besoin de temps réel. Là, on bascule sur Symfony, taillé pour la logique métier qu'on bâtit cas par cas. De même, pour une boutique au catalogue lourd, aux promotions complexes et aux contraintes de paiement fortes, une plateforme dédiée comme Shopify ou Prestashop est souvent plus juste qu'un WordPress équipé d'une extension marchande. On vend du e-commerce léger adossé à du contenu sous WordPress sans hésiter, mais on ne force pas un CMS éditorial à devenir une place de marché.
C'est cette honnêteté sur les bords qui rend le reste crédible. On place WordPress là où il gagne et on le retire là où il perd. Quand il est le bon choix, on le construit pour durer : thème codé, blocs taillés au projet, extensions tenues à l'œil, performance mesurée et un back-office qu'une rédaction garde sans nous. Quand il ne l'est pas, on le dit avant de signer. Un site qu'on doit reprendre soi-même dans trois ans n'a pas le droit d'être un château de cartes, et c'est exactement ce qu'on évite. Un bon WordPress se reconnaît à ça : la personne qui le reprend après nous comprend en une journée comment il tient, parce qu'il a été pensé pour être lu autant que pour fonctionner.