Mettre à jour un CMS encore jeune : la méthode avant les commandes

EmDash est publié depuis avril 2026. Ceux qui l’ont installé au lancement arrivent maintenant à la question suivante : comment monter de version sans casser un site en production. La réponse tient en quatre temps — sauvegarder, lire les notes de version, tester ailleurs, prévoir le retour arrière — et le dernier point est celui qu’on néglige toujours. Cet article décrit la méthode ; les commandes exactes, elles, doivent être relues dans la documentation officielle du projet au moment où vous mettez à jour.

Pourquoi la mise à jour d’un CMS jeune se traite autrement

Un CMS installé depuis dix ans a une propriété que le nouveau venu n’a pas : ses chemins de mise à jour ont été empruntés des millions de fois. Quand quelque chose casse, quelqu’un l’a déjà rencontré, documenté et corrigé avant vous.

Sur un produit publié il y a quelques mois, cette réserve d’expérience collective n’existe pas encore. Trois conséquences pratiques en découlent.

Les interfaces publiques évoluent encore. Un jeune projet stabilise ses contrats — schémas, API de plugins, conventions de thème — au fil des premières versions majeures. C’est sain, mais cela signifie que des changements de rupture peuvent survenir plus souvent que sur un produit figé.

L’écosystème tiers suit avec du retard. Un plugin ou un thème publié par la communauté n’est pas nécessairement testé contre la dernière version du cœur le jour de sa sortie. C’est le point de friction le plus fréquent, et il ne dépend pas de vous.

Enfin, la documentation bouge en même temps que le code. Une procédure trouvée dans un article de blog daté de trois mois peut décrire un état révolu. Y compris celui-ci : considérez-le comme une méthode, pas comme une recette figée.

Rien de tout cela ne disqualifie le produit — c’est le prix normal de l’avance technique dont nous parlions dans notre article sur les raisons d’essayer EmDash dès maintenant. Cela impose simplement une discipline de mise à jour que beaucoup n’appliquent plus par habitude.

Sauvegarder trois choses, pas une

La sauvegarde est la seule étape non négociable, et elle échoue le plus souvent parce qu’on n’a sauvegardé qu’une partie de l’ensemble. Un site EmDash tient sur trois briques distinctes, généralement stockées à trois endroits différents.

La base de données contient le contenu, les utilisateurs, les paramètres. C’est ce que tout le monde pense à sauvegarder. La méthode dépend du moteur retenu à l’installation : la procédure d’export n’est pas la même selon que vous êtes sur une base gérée par votre hébergeur ou sur une base que vous administrez vous-même.

Les médias vivent dans un stockage objet, séparé de la base. Un export de base ne les contient pas : il ne contient que les références qui pointent vers eux. Restaurer une base sans les fichiers correspondants produit un site dont chaque image est cassée.

Le code et la configuration — le dépôt du projet, les variables d’environnement, les secrets, les paramètres de déploiement. C’est la brique la plus souvent oubliée, parce qu’elle semble reproductible. Elle ne l’est pas : une variable d’environnement absente d’un dépôt Git ne se retrouve pas, et personne ne se souvient de sa valeur six mois plus tard.

Une sauvegarde dont on n’a jamais testé la restauration est une hypothèse, pas une sauvegarde. Avant une montée de version significative, restaurez l’ensemble sur un environnement jetable et vérifiez que le site s’affiche. C’est une heure de travail qui protège une journée de panique.

Lire les notes de version : ce qu’on y cherche exactement

Les notes de version publiées par le projet sont la seule source qui fasse autorité sur ce qui change. On ne les parcourt pas, on les lit avec quatre questions en tête.

• Y a-t-il des changements de rupture ? Ce sont les seuls qui demandent une action de votre part. Ils sont généralement signalés explicitement.
• Quelles versions sont concernées ? Si vous sautez plusieurs versions d’un coup, lisez les notes de toutes les versions intermédiaires, pas seulement celles de la cible. Les instructions de migration s’accumulent.
• Y a-t-il une étape de migration à exécuter ? Certaines montées de version impliquent une transformation des données stockées. Cette étape est décrite dans les notes ; elle n’est pas toujours automatique, et elle est rarement réversible.
• Quelles versions minimales sont exigées ? Une nouvelle version peut relever le plancher côté environnement d’exécution ou côté base de données. Vérifiez avant, pas pendant.

Notez au passage la version dont vous partez et celle que vous visez. Cela paraît trivial, mais c’est la première information qu’on vous demandera si vous ouvrez un ticket, et la première qu’on ne retrouve plus après une mise à jour ratée.

Tester ailleurs avant de basculer

La règle est simple : on ne met jamais à jour directement l’environnement qui sert les visiteurs. Elle vaut pour tous les CMS, elle vaut doublement ici.

L’environnement de test doit ressembler à la production, sinon il ne prouve rien. Cela veut dire la même version de départ, la même base restaurée depuis la sauvegarde, les mêmes plugins dans les mêmes versions, le même thème, et si possible la même configuration de stockage. Un test conduit sur une installation vierge valide l’installation vierge, rien d’autre.

Une fois la mise à jour appliquée sur ce double, la vérification porte sur des points concrets plutôt que sur une impression générale :

• Le site se construit et se déploie sans erreur, et l’administration s’ouvre.
• Les contenus existants s’affichent, y compris les types les plus anciens et les plus riches.
• Les images se chargent depuis le stockage, et les vignettes se génèrent.
• Les plugins actifs se chargent tous, sans exception silencieuse.
• Les pages les plus visitées répondent, avec leurs balises canoniques et leur sitemap intacts.
• L’authentification fonctionne, y compris pour un compte non administrateur.

Un test réussi vous donne autre chose qu’une validation : il vous donne la durée réelle de l’opération. C’est ce qui permet de choisir une fenêtre de bascule honnête plutôt qu’un créneau optimiste.

Ce qui casse en pratique

Trois familles de problèmes reviennent, et elles ne se traitent pas de la même façon.

Les plugins tiers. C’est la cause numéro un, sur tous les CMS. Un plugin dépend d’une interface du cœur ; si cette interface évolue, le plugin cesse de fonctionner tant que son auteur ne l’a pas mis à jour. Le modèle d’isolation d’EmDash limite les dégâts — un plugin fautif ne compromet pas l’ensemble aussi facilement qu’ailleurs — mais il ne le fait pas fonctionner pour autant. Avant de monter de version, vérifiez l’état de maintenance de chaque plugin que vous utilisez, et acceptez l’idée d’en abandonner un. Les contraintes qui encadrent leur exécution sont détaillées dans notre article sur les limites du bac à sable des plugins.

Les schémas de contenu. Les collections que vous avez définies sont typées, ce qui est un avantage à l’exécution et une contrainte lors d’une montée de version : si la façon de déclarer un champ évolue, vos définitions doivent suivre. Le symptôme typique est une erreur au moment de la construction, avant même l’affichage — désagréable, mais préférable à un contenu perdu silencieusement. Vérifiez en priorité vos types de champs les moins courants.

Les thèmes personnalisés. Un thème que vous avez écrit ou fortement modifié dépend des conventions de rendu du cœur. Un thème installé tel quel se met à jour avec son auteur ; un thème modifié est à votre charge. Si vous avez patché un thème tiers sans isoler vos modifications, la mise à jour les écrasera.

Dans les trois cas, le réflexe utile est le même : remonter une version à la fois quand c’est possible. Un saut de plusieurs versions cumule les causes de panne et rend le diagnostic beaucoup plus long.

Le retour arrière se prépare avant, pas après

Une procédure de mise à jour n’est complète que si elle contient sa sortie de secours, écrite avant de commencer.

Concrètement, avant de basculer, vous devez pouvoir répondre à quatre questions. Quelle version exacte réinstalle-t-on en cas d’échec, et est-elle toujours disponible au téléchargement ? Où se trouve la sauvegarde des trois briques, et a-t-elle été restaurée avec succès au moins une fois ? La migration de données est-elle réversible — si les notes de version indiquent une transformation du contenu, la réponse est souvent non, et le retour arrière passe alors obligatoirement par la restauration de la base. Qui décide d’abandonner, et au bout de combien de temps ?

Ce dernier point est le plus utile en pratique. Fixez à l’avance une limite — trente minutes, une heure — au-delà de laquelle vous restaurez au lieu de continuer à chercher. C’est ce qui distingue une fenêtre de maintenance d’une soirée perdue.

Deux habitudes réduisent durablement le risque : mettre à jour régulièrement plutôt que rarement, parce que les petits écarts se franchissent plus facilement que les grands, et journaliser ce que vous faites — versions de départ et d’arrivée, plugins écartés, incidents rencontrés. Sur un produit jeune, ce journal devient rapidement votre meilleure documentation, et il vous servira à la mise à jour suivante.

Enfin, une évidence qui mérite d’être écrite : la source qui fait foi reste la documentation officielle du projet et ses notes de version, consultées le jour où vous mettez à jour. Le rythme de publication d’un CMS de cet âge rend toute procédure détaillée périssable. Si vous découvrez EmDash et que vous n’en êtes pas encore à ces questions, commencez plutôt par notre présentation générale du produit.