Migration d’un site institutionnel de Drupal 9 vers Drupal 10, sans perte ni régression

Le problème : un Drupal 9 en fin de vie

Drupal 9 n’est plus maintenu : rester dessus, c’est accumuler une dette de sécurité et se couper des évolutions. Mais migrer un site institutionnel vivant vers Drupal 10 fait peur, à juste titre — modules qui cassent, API supprimées, thème à reprendre, risque de perdre du contenu ou de dégrader l’accessibilité. L’enjeu n’est pas « d’installer Drupal 10 », mais de faire traverser la version à un site en production sans casse et sans régression.

Auditer avant de toucher au code

Une migration réussie commence par un diagnostic, pas par une mise à jour. Nous cartographions l’existant avec les bons outils : upgrade_status (l’outil officiel qui inventorie modules et thèmes et signale ce qui n’est pas prêt pour Drupal 10) et une analyse statique ciblée sur les API dépréciées (règles de dépréciation PHPStan). On obtient une carte claire : ce qui migre tel quel, ce qui a une version compatible, ce qui doit être patché, et ce qui doit être réécrit. Ce diagnostic devient le plan de migration priorisé.

Le vrai travail : les dépendances

L’essentiel de l’effort se joue sur les modules contribués. Chacun doit être amené à une version compatible Drupal 10 ; certains ont été absorbés par le cœur et doivent être retirés ; d’autres n’ont pas encore de version stable et nécessitent un patch tracé (correctifs Composer documentés et rejouables). Ce travail est méthodique : on avance dépendance par dépendance, en gardant un composer.json propre et une installation reproductible — pas un grand saut hasardeux.

Corriger le code sur-mesure

Le code maison — modules et thème — utilise souvent des API qui ont disparu entre Drupal 9 et 10. Plutôt que de les découvrir en production, on les traque à la source avec l’analyse statique, puis on les corrige : signatures mises à jour, services remplacés, appels dépréciés réécrits. Le thème est repris pour rester compatible et propre. Objectif : zéro API dépréciée résiduelle à la mise en production.

Configuration et contenu : ne rien perdre

Un site institutionnel, c’est des années de contenu et une configuration fine. La configuration est versionnée et gérée par environnement (config split), ce qui permet de la rejouer proprement sur la nouvelle version plutôt que de la reconstruire à la main. Le contenu est préservé et vérifié. La règle est simple : après migration, l’éditeur retrouve son site — mêmes contenus, mêmes gabarits, mêmes droits — mais sur un socle à jour.

Prouver que rien n’a cassé

La question qui angoisse tout le monde dans une migration : « est-ce que quelque chose a cassé ailleurs ? » On y répond par la preuve — des tests fonctionnels (Codeception / PHPUnit) qui rejouent les parcours clés, exécutés en intégration continue, et une chaîne qualité (revue de code outillée, analyse statique) qui bloque toute régression avant la mise en production. La migration n’est validée que lorsque le site est démontré iso-fonctionnel.

Garder la conformité pendant la migration

Sur un site public, la montée de version ne doit pas dégrader l’accessibilité ni la conformité au DSFR. Nous maintenons le Système de Design de l’État à une version compatible, vérifions que les composants restent conformes après migration, et traitons l’accessibilité comme un critère de recette, pas comme un angle mort. On sort de la migration avec un site plus moderne — et toujours conforme.

Reprendre ou déléguer une migration Drupal

Beaucoup d’agences ont un parc de sites Drupal 9 à faire migrer et cherchent un renfort capable de le faire proprement et à la chaîne. C’est exactement notre terrain : on audite avec upgrade_status, on priorise, on traite les dépendances et le code sur-mesure, on rejoue la configuration, on prouve par les tests, et on livre un Drupal 10 conforme. Que la migration soit à démarrer ou déjà entamée, on sait prendre la main sans casse.

Questions fréquentes

En clair : une migration Drupal 9→10 réussie, c’est de la méthode, pas de la chance — auditer, traiter les dépendances, corriger les dépréciations, rejouer la configuration et prouver l’iso-fonctionnel par les tests. Le résultat : un site à jour, sûr, conforme, et prêt pour la suite.