WordPress est utilisé par 22% des nouveaux sites
Un récent article sur TechCrunch explique que 22 pourcents des nouveaux sites web aux Etats-Unis sont réalisés sur base de WordPress.
Ce n’est pas vraiment une surprise si on regarde l’évolution de cette plate-forme, initialement conçue pour gérer un Blog, mais rapidement devenue une véritable alternative a des systèmes établis comme Joomla, Drupal, et ezPublish. On peut certainement discuter sur la notion de “meilleur CMS”, sujet qui donne parfois lieu à des véritables fan wars sur des forums Internet, et je ne souhaite pas rentrer dans ce jeu parce que je pense que toute solution est toujours à un moment la meilleure, en fonction de l’utilisation que l’on souhaite en faire – la solution miracle, qui puisse répondre optimalement à toute sorte de besoins, n’existe pas.
Là où WordPress semble gagner les faveurs de manière concrète, c’est dans la simplicité d’utilisation pour les utilisateurs. Comme l’écrit Grégoire dans son article , WordPress a été conçu pour faire plaisir aux utilisateurs, et non aux développeurs et créateurs de sites. De nouveau, tous les outils ne répondent pas à tous les besoins, et il ne faut donc pas en faire une fixation.
Cela me mène à une réflexion qui va un peu au-delà de la question du choix du CMS : celle qui oppose l’utilisation d’un CMS existant, ou la création d’un CMS “fait maison”. Sur ce point, j’ai un avis assez précis.
Il y a 10 ans, les CMS existants ne bénéficiaient pas vraiment de la stabilité, sécurité, et maintenabilité requise dans un environnement professionnel; cette catégorie d’outils en était à ses débuts. Le choix de développer un CMS en interne, en partant de zéro, pouvait donc être justifié par un besoin de créer quelque chose d’adapté et d’en avoir la maîtrise complète, à défaut de pouvoir se servir parmi deux ou trois CMS matures et clairement établis.
Aujourd’hui, 10 ans plus tard, les systèmes de gestion de contenu prêts à l’emploi, sont nombreux à répondre aux besoins cités ci-dessus, et (re)-développer toutes ces fonctionnalités en interne ne serait qu’une perte de temps et un mauvais investissement d’efforts. Développer des composants standards comme les accès à la base de données, la gestion des utilisateurs, la gestion de cache, d’optimisation SEO, etc. ne fait qu’augmenter artificiellement le coût final pour le client, sans apporter de véritable valeur ajoutée, sauf si on accepte l’argument “C’est mieux parce que c’est nous qui l’avons fait!” …
C’est, somme toute, la même discussion que celle sur l’utilisation d’un Framework pour les développements applicatifs, par exemple : pour pouvoir se concentrer sur la logique métier et créer de la valeur, plutôt que de recréer de l’existant et perdre du temps à le maintenir et le faire évoluer.
Certes, comme avec toute solution open source, il y a des risques de sécurité qu’il faut identifier et gérer, mais ces risques existent bel et bien aussi dans toute solution développée en interne, sauf que là, personne n’en parle. Personnellement, je préfère qu’on me notifie d’un problème dans le code et que derrière, il y a des milliers de développeurs de la communauté open source qui peuvent corriger le tir, plutôt que de me reposer sur une fausse impression de sécurité parce que c’est du propriétaire.
Finalement, la bonne approche en termes de sécurité reste la même dans les deux cas, et doit être gérée par une politique de mises à jour et de veille adéquate plutôt que par une politique de l’autruche.
Il reste encore du chemin à faire à WordPress, notamment dans le domaine de l’industrialisation des processus, par exemple. La gestion des mises à jour sur des installations multiples reste difficile, même s’il y a des solutions qui se profilent . La grande communauté de développement WordPress, ainsi que sa montée en puissance récente, l’aideront à aller dans la bonne direction.
Disclaimer : xSentio, la solution de site web de VAlain, utilise WordPress comme base technologique.
