Dans un article précédent, je partageais ma transition de WooCommerce vers Shopify pour le commerce en ligne. Cette réflexion sur l’évolution de mes outils se poursuit ici avec mon approche des CMS — les systèmes de gestion de contenu.
Pour situer le débat : selon W3Techs, WordPress propulse environ 40 % de tous les sites web — soit près de 60 % du marché des CMS, loin devant son premier concurrent. S’éloigner d’un tel mastodonte n’est pas anodin. En pratique, je n’ai pas démarré de nouveau projet WordPress depuis quatre ans ; une décision vient toutefois d’être prise officiellement : il n’y en aura plus non plus. Les choix qui suivent sont le fruit de mes observations, enrichies par des discussions avec des collègues et des amis du milieu.
WordPress : une plateforme historique avec ses limites
WordPress existe depuis 2003. Conçu à l’origine comme moteur de blogue, il s’est transformé au fil des ans en CMS généraliste grâce à une multitude d’extensions et de thèmes. Cette évolution progressive a créé une architecture qui porte encore les traces de ses origines.
À ses débuts, j’en étais très enthousiaste. À l’époque, les sites se faisaient encore avec Mambo, PHP-Nuke ou SPIP — WordPress apparaissait comme une bouffée d’air frais. Ouais, je suis si vieux que ça : génération des pionniers d’Internet, celle des forums SMF, phpBB, vBulletin… Ça ne rajeunit personne. C’est précisément parce que j’y ai cru tôt que mon éloignement d’aujourd’hui n’est pas un caprice : c’est le fruit d’années d’usage, de projets, et de comparaisons avec d’autres outils.
Sa popularité a un revers : en tant que plateforme la plus utilisée, elle est aussi la plus ciblée. La sécurité devient un enjeu constant, qui pousse souvent à empiler des extensions de protection — ce qui peut paradoxalement augmenter la surface d’attaque.
Se faire défacer un site à cause d’un plugin mal fait, j’en ai été victime. Remettre le site en ligne depuis une sauvegarde, sans savoir si ce même backup ne sera pas à son tour défacé demain : voilà un suspense dont je me passerais volontiers. Le quotidien m’apporte déjà assez de défis au travail — pas besoin de courir sur des braises pour me sentir vivant.
L’interface d’administration s’est alourdie : notifications de mises à jour, suggestions d’extensions, promotions de versions premium… Cette surcharge peut dérouter les clients qui cherchent simplement à gérer leur contenu. Comme agence, il est gênant d’offrir un panneau rempli de publicités pour « passer au niveau supérieur ».
Dès la connexion, WordPress peut sembler lourd à un néophyte — une véritable usine à gaz. Le menu de gauche regorge de sections qui peuvent effrayer les utilisateurs moins techniques. Et les interfaces ne sont pas toujours alignées : un constructeur comme Elementor ou Divi transporte ailleurs, dans un autre univers, ce qui étourdit et déroute.
WordPress, ce n’est pas seulement des plugins : ce sont aussi des plugins pour des plugins. On joue littéralement aux échecs en 4D. Elementor, par exemple, ajoute une construction de pages par blocs — et une foule d’éditeurs tiers proposent leurs propres blocs, ou des variantes d’Elementor. C’est à la fois impressionnant… et le signe d’une incohérence dans la matrice. Autant WordPress a des limites, autant l’absence de limites au niveau des plugins forme un paradoxe que j’ai beaucoup de mal à expliquer.
Autant WordPress a des limites, autant l’absence de limites au niveau des plugins forme un paradoxe que j’ai beaucoup de mal à expliquer.
WordPress est souvent présenté comme gratuit, ce qui est vrai en apparence. Mais WordPress tout nu ne fait pas grand-chose. Un thème décent ou un constructeur comme Elementor se paie. Chaque extension soigneusement choisie peut être gratuite mais limitée, ou payante à plusieurs paliers. On se retrouve avec des barrières de paiement un peu partout, et une expérience fragmentée.
Le multilingue illustre parfaitement cette limite. Il est impensable de faire un site multilingue sérieux sans une extension tierce non officielle. La solution la plus populaire est dispendieuse, avec des sous-extensions pas toujours uniformes, ce qui dégrade l’expérience du développeur — et surtout celle de l’éditeur de contenu, le client. Pour une fonctionnalité aussi essentielle aujourd’hui, dépendre d’une solution tierce n’est tout simplement pas très sérieux.
La qualité des extensions : une perspective d’éditeur
Je suis moi-même éditeur d’extensions, ce qui me donne une vue des deux côtés de la médaille.
La boutique WordPress, vaste, présente des défis de qualité : plugins parfois obsolètes ou peu solides, bandeaux qui poussent sans cesse vers une version pro. WordPress fait un peu figure de Far West en ce sens.
Certains CMS modernes, à l’inverse, imposent des processus de validation plus proches des boutiques d’applications mobiles. Ce n’est pas qui veut qui y entre : règles, contrôle, refus si les standards ne sont pas atteints, corrections avant de resoumettre.
Ces plateformes ont des lignes directrices précises et une catégorisation sévère. Un écran de réglages doit être au bon endroit ; les interfaces du panneau doivent rester cohérentes. Si une extension devient problématique, gourmande ou peu sécuritaire, la communauté et les administrateurs des stores réagissent. L’écosystème reste plus professionnel et plus uniforme.
Gestion des licences : l’avantage de la centralisation
Les CMS modernes que j’utilise centralisent la vente de leurs extensions commerciales. Les licences suivent le même modèle et se paient au même endroit — ce qui simplifie considérablement ma gestion interne.
Avec WordPress, chaque éditeur commercial a sa propre plateforme : plusieurs fournisseurs, des factures dans différentes devises pour un même projet, des niveaux de détail inégaux. Un cauchemar comptable. Ça n’a pas d’impact direct sur mes clients, mais cette uniformisation a une valeur réelle pour mon efficacité opérationnelle.
Gouvernance et santé de l’écosystème
La récente controverse autour de la gouvernance de WordPress a aussi nourri ma réflexion. Des contributeurs historiques ont vu leurs comptes désactivés après avoir discuté d’alternatives, y compris l’idée d’un fork — une copie indépendante du code qui évoluerait séparément. Cet épisode pose des questions sur la santé à long terme de l’écosystème et sur sa tolérance envers la diversité des approches. Je préfère des plateformes où l’innovation et les débats constructifs sont encouragés plutôt que restreints.
Mon expertise : PHP et Laravel
Je me spécialise surtout en PHP et Laravel. Cette expertise influence naturellement mes choix. Quand j’évalue une plateforme, je cherche des solutions alignées avec mes technologies et ma façon de travailler.
Craft CMS, Statamic et Filament représentent des choix naturels. Statamic et Filament reposent déjà sur Laravel ; Craft CMS 5, la version courante, tourne encore sur Yii. Cette proximité — PHP, et de plus en plus Laravel — me permet de créer des fonctionnalités sur mesure sans multiplier les technologies.
Par exemple, pour un projet qui aurait besoin d’un site web et d’une application mobile, mon réflexe passé aurait été un CMS pour la vitrine — WordPress ou Craft selon le besoin — et une application Laravel distincte pour alimenter l’app via une API. Avec Statamic déjà sur Laravel, et Craft CMS 6 qui s’y dirige, le même socle pourra servir le site et l’application, sans duplication inutile ni incohérence technique.
Craft CMS : mon choix principal
Craft CMS répond directement aux défis que j’ai identifiés.
Sécurité intégrée. Les bonnes pratiques sont activées par défaut — protection CSRF, prévention de l’énumération d’utilisateurs, validation rigoureuse des entrées. Pas besoin d’extensions supplémentaires pour atteindre un niveau de sécurité satisfaisant.
Multilingue natif. La gestion des langues est au cœur du système, sans extension tierce. Chaque langue est un site à part entière, avec une vraie flexibilité sur la structure de contenu.
Interface focalisée. Le panneau est épuré et concentré sur l’essentiel. Pas de notifications intempestives, pas de promotions constantes — juste les outils pour gérer le contenu. Tous mes clients Craft ont rapidement compris et adopté cette interface claire et simple.
Workflows modernes. Staging et production avancent de pair, avec des outils solides pour les migrations de configuration et de contenu. Le développement s’intègre naturellement aux frameworks JavaScript actuels et aux outils de build modernes.
Vision à long terme. Craft CMS 5 est la version courante, toujours fondée sur Yii. Craft CMS 6, déjà en alpha et dont la sortie officielle est prévue cette année, passera sous Laravel — et ça me rend très enthousiaste. Le CMS que je connais le mieux rejoindra le framework avec lequel je crée le plus de solutions.
Une expérience éprouvée. Je travaille avec Craft depuis la version 2. Elle a franchement bien évolué et m’épate encore. Avoir un accès direct, via Discord, à l’équipe de développement — et même aux fondateurs — est agréable et rassurant. Je connais ce CMS par cœur, même si j’y découvre encore régulièrement de nouveaux bienfaits.
Ce qui change vraiment l’expérience client, ce n’est pas seulement l’interface, c’est la manière dont le site est bâti.
Avec WordPress, on se retrouve souvent avec un amalgame de plugins — un monstre de Frankenstein. Avec Craft, c’est une approche cohérente et réfléchie dès le départ.
Statamic : mon choix secondaire
Statamic est mon choix secondaire surtout parce que je le connais moins que Craft, mais sa philosophie m’attire. Approche différente, tout aussi moderne : il peut fonctionner entièrement sur des fichiers (flat-file), sans base de données traditionnelle, ou s’appuyer sur une base si besoin. Déjà ancré dans Laravel — comme le sera bientôt Craft CMS 6 — il s’aligne sur mon quotidien technique et une conception contemporaine.
Ce qui me plaît particulièrement, c’est son image un peu punk — une approche alternative qui ose remettre en question les conventions.
Sites statiques : Nuxt et SvelteKit
Pour certains projets, même un CMS est trop. Quand un site n’a besoin que de peu — ou pas — de panneau de gestion, je privilégie des approches statiques avec des frameworks comme Nuxt ou SvelteKit.
Ces solutions conviennent bien aux sites vitrines rarement mis à jour, aux landing pages, aux projets où les changements passent par Québec Studio plutôt que par le client, ou aux sites éphémères qui n’exigent pas beaucoup de flexibilité d’édition.
L’avantage principal, c’est la simplicité : pas de base de données, pas d’administration, du code qui génère des fichiers statiques rapides. Pour les clients qui n’ont pas à toucher leur contenu régulièrement, c’est léger, performant et économique.
Continuité pour mes clients WordPress
Ce virage ne signifie pas que j’abandonne mes clients WordPress. Je continuerai d’assurer la maintenance de leurs sites et les ajustements mineurs nécessaires à leur bon fonctionnement.
En revanche, je ne ferai plus évoluer ces sites de manière significative, ni ne démarrerai de nouveaux projets sur WordPress. Pour des évolutions importantes ou de nouvelles fonctionnalités, je discuterai des options — migration vers Craft ou Statamic selon les besoins, ou transition vers un autre développeur si c’est leur préférence. Je veux avant tout garder mes clients : je ferai tout mon possible pour les accompagner. S’ils choisissent de partir ou de laisser leur site tel quel, je respecterai leur décision et faciliterai la transition.
WordPress peut rester pertinent pour certains contextes : budgets modestes, besoins simples couverts par des extensions existantes, équipes qui préfèrent une courbe d’apprentissage plus douce. Mais Québec Studio l’a retiré de son éventail pour les nouveaux projets, pour les raisons expliquées ici.
Conclusion
Je ne cherche pas à dénigrer WordPress. Beaucoup d’agences en font de petites merveilles : elles s’y sont spécialisées, ont défini une recette gagnante et simple pour leurs clients, et ça fonctionne. Je n’ai simplement pas la même appréciation. En tant que développeur full stack, je préfère des CMS pensés pour la personnalisation et l’ajout de fonctionnalités — sans empiler des plugins que je ne maîtrise pas vraiment, qui m’échappent dès qu’il faut aller plus loin, et qui finissent par brider mes élans créatifs. Ajouter une fonctionnalité peut rendre un plugin incompatible ou dédoubler des structures ; bref, mieux vaut souvent ne pas tenter de les améliorer. Et tant qu’à développer en parallèle, autant le faire dans un écosystème qui le permet dès le départ.
La technologie évolue vite. WordPress a su traverser le temps, et il continue de servir d’innombrables sites — ce n’est pas rien. Mais pour moi, ce n’est plus le socle sur lequel j’ai envie de construire. Son architecture porte encore les traces des années 2000 : elle tient, elle a fait ses preuves, et pourtant elle ne colle plus à la manière dont je conçois et développe aujourd’hui. Ce n’est pas un jugement sur ceux qui s’y épanouissent ; c’est simplement mon choix d’outil. Craft CMS et Statamic sont devenus mes choix par défaut pour les nouveaux projets, parce qu’ils correspondent mieux à cette vision.
L’important, c’est de choisir la bonne plateforme pour chaque projet — selon les besoins techniques, le budget, les compétences et les objectifs à long terme. C’est cette approche pragmatique que je continue d’appliquer pour mes clients.