Un article un peu plus léger que d’habitude sur les raisons qui nous poussent à utiliser sur ce site une version en cours de développement de WordPress au lieu de la dernière version stable publique.
Au moment de l’écriture de cet article (août 2025), ce site tourne en effet sur WordPress 6.9, alors que cette version ne verra le jour que dans plusieurs mois, plus précisément le 2 décembre 2025 si tout va bien [1].
En fait, ce site utilise une version WordPress 6.9-alpha, c’est à dire qu’il s’agit d’une version de développement du CMS.
Mais pourquoi ? Ils sont fous chez Whodunit Consulting ou quoi ?
Et bien non, c’est voulu !
Pour le plaisir, par jeu, par intérêt stratégique, mais surtout par conviction 🙂
#1 Parce que WordPress est fiable
Pour faire partie de l’équipe des Core Committers de WordPress (les gens qui ont l’autorité pour valider les modifications de code source de WP), je peux assurer que l’inclusion de code nouveau dans ce CMS ne se fait pas « à l’arrache ».
Toute proposition de modification est relue, testée, mise en pratique et documentée, de façon systématique. Dès lors qu’un nouveau hook est ajouté, qu’une fonction est modifiée ou qu’une classe est dépréciée, des tests unitaires couvrant l’ensemble des fonctionnalités du CMS sont lancés pour éviter un maximum de risques de régressions.
Mon site personnel tourne depuis 10 ans sur la version en cours de développement de WP, et je n’ai jamais connu de vrai downtime. Je n’ai jamais rencontré de problème m’ayant conduit à revenir sur une version « officielle » du CMS.
Globalement, on peut dire que le processus de développement de WP fait preuve d’une grande fiabilité sur le long terme.
Tout commit effectué sur le cœur de WP passe par les tests unitaires et E2E (en anglais end-to-end, c’est à dire des tests simulant les interactions de l’internaute) intégrés au code source.
Une fois le commit effectué, celui-ci est passé au crible de la suite (confidentielle) de tests unitaires de sécurité, gérée par l’équipe de sécurité du CMS. Chaque modification est donc assurée d’être testée en regard de toute l’expérience que possède ce CMS en matière de sécurité.
Chaque « soir », une version « nightly build » est automatiquement mise à disposition. C’est cette version qui est utilisée par tous les sites qui veulent faire tourner la version en cours de développement.
Le processus de développement de WordPress comprend une méthodologie éprouvée, avec une revue de code systématique qui permet de garantir que le logiciel reste stable à tout moment.
#2 Pour ne pas avoir à mettre à jour manuellement le cœur du CMS
Ok, c’est une fausse bonne raison, mais profitons-en pour parler de la gestion des mises à jour sur WP :)
Nous avons chez Whodunit une méthodologie de gestion des mises à jour standardisée et une politique de maintenance robuste, dont ce site pourrait évidemment profiter. Notre PSSI nous engage à mettre à jour « au fil de l’eau » les sites que nous maintenons, c’est-à-dire que nous effectuons ces mises à jour au maximum dans un délai d’une semaine après leur sortie, ou immédiatement lorsqu’une mise à jour de sécurité est disponible [2].
Ce site est quant à lui constamment à jour de version puisque chaque nuit, il récupère la dernière « nightly build » fournie par les serveurs WordPress.org.
Lorsque WordPress 6.9 sortira officiellement, ce site passera automatiquement en version WP 7.0 alpha, et ainsi de suite.
Tout cela se fait de façon automatique, ce qui nous amène au point suivant.
#3 Parce que c’est facile à mettre en œuvre via l’extension WordPress Beta Tester
L’extension WP Beta Tester est une extension proposée et maintenue par des contributrices et contributeurs de WordPress.org.
Elle vous permet de choisir un canal permettant, au choix :
- Installer la version en cours de développement (« nightly build ») et de paramétrer la mise à jour automatique de votre site chaque jour pour récupérer les dernières modifications de code.
- Installer une version beta ou release candidate (RC), si vous souhaitez simplement tester une version à venir de WordPress sur votre site, avant sa sortie officielle.
Dans le cas de ce site, nous avons choisi la première option.
Si vous développez des thèmes ou des extensions et que vous souhaitez tester la compatibilité de votre travail avec la version à venir de WordPress, il est recommandé d’installer les versions beta ou RC avant la sortie définitive de la version. Cela vous permet d’éviter les mauvaises surprises le jour J.
Dans tous les cas, il est plus que recommandé de suivre régulièrement les notes de développement publiées par l’équipe Core de WP [3].
#4 Pour tester les changements à venir en avant première et sur le terrain
Bien entendu, il serait plus simple de disposer de sites de test pour essayer les versions à venir de WP. D’ailleurs pour tester les nouvelles versions de WP avant l’heure, je dispose personnellement de plusieurs instances très différentes, qui tournent en local sur la version alpha de WP :
- Une installation simple utilisant un thème natif et beaucoup de contenus générés à l’aide du Theme Unit Tests Data, une collection de contenus utilisée par l’équipe de validation des thèmes sur WordPress.org afin de s’assurer que tout le contenu imaginable s’affiche bien correctement [4].
- Une installation multisite avec différents thèmes et extensions du répertoire officiel.
- Une installation contenant toutes les extensions que j’ai développées ainsi que celles développées par d’autres salariés de l’agence.
- Une installation complexe avec les extensions premium utilisées régulièrement par l’agence Whodunit, comme Gravity Forms ou ACF ainsi que du faux contenu.
Tout cela permet de tester chaque nouvelle version de WP avant leur sortie. C’est assez efficace, mais cela reste des tests de laboratoire : nous ne sommes pas dans un environnement réel de production.
C’est pourquoi WordPress.org tourne constamment sur la version alpha du CMS : rien ne vaut la mise à l’épreuve sur un vrai site en production pour s’assurer que tout fonctionne correctement. Concernant WP.org, on parle tout de même d’un réseau de réseaux (une installation multisite imbriquée) de milliers de sites WP.
De la même façon, mon site perso et le site Whodunit.Consulting tournent eux aussi sur la version alpha. Rien de tel qu’un vrai site en production pour s’assurer que la version à venir de WP n’introduit pas des incompatibilités avec certaines extensions.
Bien entendu, cela ne doit pas être mis en place sur n’importe quel site : il faut être en capacité de déboguer celui-ci au cas où une incompabilité apparaîtrait, et monitorer le site un minimum pour éviter d’avoir une grosse coupure de disponibilité – ce qui ne m’est cependant jamais arrivé en 10 ans !
#5 Pour le frisson…
Dernière raison : j’ai beau être Core Committer de WordPress, je ne peux pas suivre les dizaines de commits réalisés chaque jour sur le code source du CMS. Et il m’arrive évidemment de couper totalement pendant quelques semaines.
Savoir que ce site tourne impeccablement en mon absence, sur une version en cours de développement est un joli pari, qui pour l’instant a toujours été relevé. Je n’aurai peut-être plus le même discours le jour où je trouverai un site à moitié cassé en revenant de congés, mais pour l’instant ce jour n’est pas arrivé.
Cela pourra peut-être aussi contribuer à diminuer la pression et la crainte des mises à jour pour les prestataires de maintenance de savoir qu’un site puisse tourner impeccablement en mode automatique. Bien entendu il s’agit d’un site très propre et très minimaliste, basé sur le Full Site Editing de WordPress. Mais cette stabilité à toute épreuve a quand même quelque chose de rassurant.
Est-ce que vous être prêt·e à passer votre site sur la version de développement de WordPress ?
Aucune obligation bien entendu, mais je pense que pour un site d’agence, l’exercice peut se révéler plutôt pertinent.
Sources :
Laisser un commentaire