Le bon CMS, pour les mauvais contextes

Un projet institutionnel à lancer, une intégration SI digne d’un plat de nouilles froides, des attentes utilisateurs à la louche et un budget bien ficelé… La question revient toujours : quel CMS choisir ?

Je vous propose ici un retour d’expérience sur trois types de CMS que j’ai eus l’occasion de manier dans des contextes pas franchement détente : WordPress, Jalios, et quelques petites perles propriétaires. Spoiler : aucun n’est parfait, tous sont perfectibles, et le bon choix dépend toujours du contexte. Toujours.

📌 Le contexte : un CMS, oui, mais pour quoi faire ?

Derrière chaque projet digital, il y a des attentes : publier vite, facilement, en sécurité, avec de la flexibilité et de l’évolutivité. Jusque-là, tout va bien. Sauf que dans la vraie vie, on compose avec :

Un SI tentaculaire à intégrer
Une DSI qui veut de la sécu “niveau ANSSI +++”
Des équipes métiers qui veulent “un truc simple”
Un budget TMA déjà explosé l’année d’avant
Et un chef de projet UX (genre moi) qui ne veut pas juste mettre un skin sur un formulaire

Alors le CMS, ce n’est plus juste un outil, c’est un équilibre.

🧰 WordPress : le bon pote… tant qu’on ne lui demande pas la lune

WordPress, c’est ce pote hyper dispo et enthousiaste. Facile à installer, bourré de plugins, un back-office simple à prendre en main même pour un chef de produit qui n’aime pas cliquer plus de trois fois. Pour des sites vitrine, des blogs, des portails événementiels… c’est redoutablement efficace. Déploiement rapide, coûts maîtrisés, écosystème géant, communauté active : il coche beaucoup de cases.

Mais.

WordPress, c’est aussi un CMS qui peut vite devenir Frankenstein. Trop de plugins qui font doublons, des thèmes sur-personnalisés, des mises à jour qui cassent des briques (littéralement), et une sécurité qui repose sur une vigilance constante. Si tu veux faire du SSO avec ton SI, du versioning fin sur les contenus, ou un vrai workflow éditorial, il faut développer ou intégrer. Et là, tu t’éloignes du “CMS prêt à l’emploi” pour plonger dans la boîte noire de la bidouille.

Autre piège : la fausse promesse de la gratuité. Oui, WordPress en lui-même est gratuit. Mais si tu veux un hébergement costaud, un thème pro, un plugin de sécurité, un plugin multilingue, un backup fiable… la note monte vite. Et ce n’est pas toujours anticipé dans les projets publics ou institutionnels.

Donc WordPress, oui. Mais pour les bons contextes : communication, sites à impact simple, MVP à valider rapidement. Pas pour un intranet national ou une plateforme multisite branchée sur 12 API internes.

🧱 Jalios : l’armure pour projet blindé

Jalios, c’est l’armure du chevalier digital. C’est robuste, intégré, pensé pour la docu, la GED, les workflows, et tout ce qui fait mal à la tête en AMOA.

Je l’ai vu fonctionner comme une horloge dans des projets de portails RH, d’intranets collaboratifs, ou de réseaux d’agents publics avec une gouvernance très distribuée. Le CMS a tenu la charge, les rôles, la sécu, les ponts avec des outils obscurs… Pas sexy, mais ultra-fonctionnel.

Mais.
Il faut une équipe dédiée. Un vrai dev Jalios, un intégrateur Jalios, un chef de projet familiarisé Jalios pour expliquer tout ça aux équipes métiers. L’investissement humain peut être costaud en fonction du projet. Et côté budget, faut prévenir le DAF avant.

Il m’a permis néanmoins de proposer des sites semi-personnalisés graphiquement. Je m’explique ! Jalios propose de nombreux plugin pour répondre à de nombreux besoins et éventuellement s’interfacer avec d’autres outils métier. Ces plugins ont, disons, leur propre style par défaut. Fonctionnel et sobre certes, mais certainement pas le look & feel de la charte du site. Mais c’est tout de même une flexibilité intéressante financièrement, dans un contexte financier serré, le client aura pu avoir une charte graphique originale et sympa et aura pu choisir d’intégrer des plugins en faisant le choix pour certains de pousser la customisation ou de laisser tel quel (parce que la sobriété du plugin permet une intégration discrète).

🕵️ CMS propriétaires : la boîte noire sous licence

Le CMS propriétaire, c’est un peu le joker du projet : parfois imposé par un client, parfois proposé par mon agence du moment. J’en ai connu plusieurs, chacun avec ses particularités et souvent même bien pensés.

Leur force ? Un support dédié, une solution souvent bien câblée pour le métier (site vitrine, intranets métiers, extranets clients…), un socle solide et le label « open source » qui plait bien aux clients parce qu’ils se disent qu’ils pourront toujours aller voir ailleurs avec la doc technique sous le bras.

Le hic ?
Tu ne pilotes pas grand-chose. Chaque évolution tant front que back office est un ticket + un devis + un délai. Le CMS est ce qu’il est, on ne va pas le changer pour le client, même si j’ai vu pour certains CMS une certaine flexibilité dans l’ajout de modules complémentaires custom ou l’ajout de champs spécifiques aux modules existants pour s’adapter aux contraintes métier.

🎯 Ce qu’il faut retenir

À chaque fois qu’on m’a demandé : “Tu penses qu’on peut faire ça avec WordPress ?” ou “Jalios, ce n’est pas trop lourd pour notre projet ?”, ma réponse a été la même : ça dépend.

WordPress : efficace, rapide, mais pas pour des SI très complexes
Jalios : parfait pour des environnements complexes avec gestion fine des accès, de la doc, etc.
CMS propriétaires : souvent une obligation, à maîtriser dans leurs limites

Mais au fond, le vrai sujet n’est pas “quel CMS ?”, mais comment l’adapter intelligemment au contexte, comment embarquer les équipes et comment ne pas exploser en vol à la première évolution demandée.

💡 En bonus : mes petits réflexes de survie

Toujours cadrer les besoins réels et à venir. Ce qui “doit juste afficher trois actus”, deviendra vite un intranet full options. D’où l’importance de creuser avec le métier et de le challenger.
Ne jamais sous-estimer l’importance du back-office. C’est là que les métiers passent leur temps. J’en parlais précédemment dans l’importance d’embarquer un panel d’utilisateur finaux pour s’assurer que leur besoin est aligné avec la vision du métier.
Prévoir les extensions, la sécurité, la scalabilité dès la conception. Surtout sur WordPress, pour anticiper, alerter sur les coûts éventuels à venir.
Former les équipes en interne. Parce qu’un bon CMS, c’est un CMS qu’on maîtrise en autonomie.