Il est toujours délicat de s'avancer sur l'avenir dans un domaine aussi changeant que celui du web. Mais c'est toutefois un exercice intéressant, et tant qu'à s'y risquer, autant se débarrasser du conditionnel, qui est un style que je n'affectionne pas particulièrement. Voici donc une série d'affirmations sur lesquelles je ne peux offrir bien entendu aucune garantie.

Tous les CMS sont vieux

Typo3: 1997

Drupal: 2001

Plone: 2002

Wordpress: 2003

Joomla!: 2005 (fork de Mambo : 2000)

On travaille dans un domaine où tout a tendance à mal vieillir, mais pourtant les CMS les plus utilisés affichent tranquillement 10 ans au compteur.

Pourquoi ?

Parce que les CMS ont beau être de vieilles choses, ce sont des vieilles choses qui marchent bien. Bien entendu, il faut rester à jour, le monde du web apporte chaque jour son lot de nouveautés qu'il faut bien intégrer au CMS au risque (1) de décevoir les utilisateurs, (2) de frustrer les développeurs.

Mais les cas d'utilisation de base restent stables, et surtout restent valides, c'est-à-dire que les attentes et les usages ne changent pas beaucoup. Ok, aujourd'hui on peut faire son site en mode NoCMS, en écrivant du markdown pour générer un site statique sur GitHub Pages (et on peut même pousser cette approche très loin). Mais il reste beaucoup de cas où le besoin c'est de faire de la gestion de contenus.

Et là, il n'y a pas de demi-mesure: au début il faut juste pouvoir éditer des pages, puis on se rend compte qu'il faut aussi gérer les médias, ah et puis un workflow de validation, du coup il faut aussi pouvoir gérer les droits, il faudra aussi une newsletter, une zone de partage de documents en accès restreint, le multilingue, la possibilité de faire des sous-sites qui seraient exactement pareils sauf deux ou trois trucs, etc.

Et on déroule rapidement toute la pelote, et la conclusion c'est qu'il nous faut un CMS, et justement il en existe (voir liste ci-dessus), et ils font tout ça depuis longtemps.

Donc on les garde.

… et ça ne va pas changer

Cela ne changera pas, car il n'y aura pas de petit nouveau qui rafle tout le marché. Parce que faire un CMS from scratch c'est un travail énorme.

Cela demande d'abord de connaître les cas d'utilisation classiques (voir ci-dessus), ils sont nombreux, et en plus ils sont assez rigides, autrement dit, si on arrive avec des scénarios différents, les utilisateurs n'adhèrent pas facilement. Il faut donc une culture forte de ce qu'est un CMS, et la meilleure (la seule ?) façon d'apporter cette culture à un projet de construction de CMS, c'est de s'appuyer sur une communauté expérimentée.

Ensuite, le côté technique est colossal. L'infrastructure de base qui garantit les comportements standards est déjà très importante, mais en parallèle, il faut en plus être capable d'intégrer le flux permanent de nouveautés, ce qui est déjà très consommateur de temps sur un CMS existant. Cela ne s'arrête pas là, un CMS est un gros projet, qui va nécessairement contenir des centaines de composants, il faut donc avoir des pratiques pour gérer cela.

À titre d'exemple, dans un site Plone un peu standard, il y a facilement 350 packages (des eggs) qui ont des dépendances entre eux, quels projets Python rassemble autant de composants ? Très peu. Si on doit les déployer à la main, c'est impossible. C'est pourquoi Plone fait une utilisation intensive de buildout (côté Drupal, il y a Drush qui fait aussi ce genre de travail), cela fait souvent rire les Djangonautes qui lui préfèrent la simplicité (incontestable) de pip, mais clairement nous n'avons pas les mêmes besoins.

La gestion du déploiement n'est qu'un exemple, mais il y a énormément d'aspects pour lesquels on se rend compte qu'un CMS est nettement différent d'un projet habituel, et donc ceux qui s'y essayeraient sans avoir l'outillage adéquat risquent de vite déchanter.

Donc pour assurer la viabilité technique d'un CMS, il faut disposer d'un existant solide, et d'une communauté (très) productive.

Bref, ça risque d'être dur pour un nouvel arrivant.

WordPress ne pourra pas tout manger

WordPress tient une place particulière: plus de 60% des sites utilisant un CMS utilisent WordPress. Les autres se battent pour grapiller les miettes (aucun ne dépasse 3%).

Donc une évolution possible serait que WordPress prenne peu à peu toute la place.

Cela me paraît peu probable, car, même si (techniquement) n'importe quel CMS peut arriver à faire n'importe quel site, au fond, chaque CMS a son positionnement propre qui le rend plus adapté et plus séduisant dans un contexte bien précis.

Et je ne crois pas que le positionnement naturel initial de WordPress (c'est-à-dire un excellent CMS pour blog) puisse être gommé au point d'attirer à lui tout le marché.

Donc rien ne changera jamais ?

Si, bien entendu, les choses changeront.

"Plonger au fond du gouffre, Enfer ou Ciel, qu'importe ?
Au fond de l'Inconnu pour trouver du nouveau !" c'est notre maxime à nous, développeurs.

Mon point de vue est, comme je viens de l'expliquer plus haut, que les CMS majeurs vont garder leur place, en revanche, on se rend bien compte que le monde du front-end est en pleine effervescence, et on peut s'attendre à ce qu'il vienne bousculer le partage des tâches dans les CMS.

Je pense que les CMS vont de plus en plus séparer la partie back-end et la partie front-end, et la partie front-end va s'occuper de plus en plus de choses: l'UI d'édition des contenus (Create.js est un exemple intéressant), le rendu des formulaires, la validation, etc.; le back-end quant à lui va ressembler de plus en plus à un moteur exposant une API REST, mais sans se limiter à un simple service de persistance, car la complexité des cas d'utilisation ne va pas diminuer et il faudra nécessairement que le back-end sache correctement les traiter.

C'est le chemin qu'emprunte actuellement la société Gizra sur Drupal et je pense que le mouvement va s'accentuer partout.