Faire passer un portail public à Drupal 11

Il s'agit d'un portail national d'information publique de l'État, une plateforme citoyenne rattachée aux services du Premier ministre. Le trafic dépasse 2 millions de visites mensuelles pour un référentiel de plus de 200 000 contenus : c'est l'une des plus vastes installations Drupal du secteur public français.

J'ai assuré la responsabilité technique de la mission : conduite des montées de version Drupal, cadrage du projet, coordination des intervenants côté client et contrôle de chaque livraison avant sa mise en ligne. La plateforme fonctionne sans interruption, vingt-quatre heures sur vingt-quatre, ce qui interdit toute page de maintenance.

La situation de départ

Drupal publie en continu des correctifs de sécurité, des versions mineures et des versions majeures. Sur ce portail, la cadence d'application variait selon la nature de la livraison :

• Versions majeures (par exemple le saut Drupal 10 vers 11) : mises en production en moins de deux mois
• Versions mineures (du type 11.1 vers 11.2) et patchs (11.3.x) : embarqués dès l'ouverture du sprint courant, afin de repérer toute régression le plus tôt possible
• Correctifs de sécurité : déployés en moins de vingt-quatre heures

J'ai gravi l'escalier complet, de Drupal 9 jusqu'à Drupal 11, palier par palier, sans jamais sauter une étape intermédiaire. Sur un site de cette criticité, repousser une montée à plus tard n'était tout simplement pas une option.

Les contraintes à tenir étaient les suivantes :

• Une plateforme étatique qui ne peut en aucun cas basculer sur un écran d'indisponibilité
• Des obligations d'accessibilité RGAA et de respect du DSFR, le système de design de l'État
• Plusieurs dizaines de modules sur mesure à réauditer à chaque nouvelle release
• Un moteur de recherche ElasticSearch à migrer de sa version 7 vers la version 8
• La coordination avec les pôles internes du client : développement, DevOps, recette, product owner et rédaction
• Des environnements de test à mettre à disposition pour que les PO valident chaque livraison avant son passage en production

Ma façon de procéder

Le pilotage technique jour après jour

En tant que référent technique, je tenais la feuille de route, je rédigeais les User Stories dans JIRA avec les product owners et le pôle produit du client, j'estimais les charges et je calibrais la portée de chaque sprint.

Aucune livraison ne partait sans son cahier de recette circonstancié. La recette déroulait les scénarios, le pôle produit confirmait le fonctionnel, les rédacteurs s'assuraient que l'éditorialisation tenait toujours, et l'exploitation attestait de la stabilité. Tant que chacun n'avait pas validé son périmètre, rien n'était considéré comme acquis.

Les montées de version Drupal

Un site de cette ampleur ne se migre jamais d'un seul bloc. À chaque release, je rejouais la même séquence : inventaire des dépréciations, revue des modules contrib et sur mesure, ajustement du code, batterie de tests de non-régression, puis déploiement par étapes. La cible des deux mois par version a été respectée du premier au dernier palier.

Côté technique - Le processus de montée de version

Le point de départ, c'est un composer outdated drupal/* pour cartographier ce qui évolue. Vient ensuite l'examen des modules contrib : disposent-ils d'une version compatible ? Certains, abandonnés par leurs mainteneurs, doivent-ils être remplacés ? Pour les modules sur mesure, nombreux ici, je lance Rector qui réécrit automatiquement le code obsolète, chaque transformation étant ensuite relue à la main. Je mets à jour le composer.json, je tranche les conflits de dépendances, et aucune merge request n'est ouverte tant que la suite de tests n'est pas verte.

L'infrastructure et le DevOps

Faire monter Drupal ne règle qu'une partie de l'équation. Chaque version impose ses propres prérequis serveur : Drupal 11 réclame ainsi PHP 8.3 au minimum. Il faut surveiller les fins de vie de PHP, de MariaDB et des extensions indispensables. J'ai orchestré l'ensemble avec le pôle infrastructure du client : passages de PHP 8.1 à 8.2 puis 8.3, mise en place d'environnements de test pour les PO et le pôle produit, et refonte des pipelines Jenkins.

Sur le volet observabilité, je gardais un œil sur Grafana et Graylog pour repérer la moindre dégradation de performance dans la foulée de chaque déploiement.

Côté technique - Suivre les EOL de toute la stack

Drupal n'est pas le seul élément à surveiller. Je tiens un registre des échéances de fin de support de chaque composant : version de PHP, MariaDB ou MySQL, extensions PHP, modules contrib sensibles. L'idée directrice est de ne jamais laisser une brique non maintenue tourner en production. Ce tableau est partagé avec l'infrastructure et réactualisé à chaque sprint de maintenance.

Côté technique - Le pipeline CI/CD

Le pipeline Jenkins était recalibré pour chaque version : exécution des tests PHPUnit, analyse statique via SonarQube (couverture, failles, code smells), contrôle des conventions de code avec phpcs et phpstan, puis déploiement automatique vers la préproduction. Si SonarQube affichait le moindre voyant rouge, la merge request restait bloquée.

La recette et la validation

Chaque livraison s'accompagnait de son propre cahier de recette, balayant tous les scénarios fonctionnels concernés. La recette rejouait les parcours utilisateurs, le pôle produit contrôlait la cohérence métier, les rédacteurs éprouvaient l'éditorialisation (Paragraphs, blocs, médias) et l'exploitation attestait de la stabilité.

Le bilan : pas une seule régression en production sur l'intégralité de la mission.

La documentation

Rien ne reste implicite. Je documente les modules sur mesure (architecture, API, dépendances), je rédige une documentation fonctionnelle pour les PO et les rédacteurs, ainsi que des procédures de déploiement pour l'exploitation. Un intervenant qui rejoint le projet devient vite autonome, et lorsque je rouvre un module six mois plus tard, je retrouve immédiatement la logique qui a présidé à sa conception.

La refonte du moteur de recherche

Passer ElasticSearch de la version 7 à la 8 ne se résume pas à un composer update. J'ai repensé le mapping des champs, retravaillé les requêtes et conçu une interface d'administration interne qui laisse les équipes métier régler elles-mêmes le classement et les filtres, sans solliciter un développeur.

Côté technique - ElasticSearch 7 → 8

ElasticSearch 8 abandonne les types de mapping, ce qui contraint à rebâtir toute l'indexation. J'ai re-mappé chaque champ, reparamétré les analyseurs français (gestion des accents et des synonymes) et réécrit les requêtes bool et multi_match. L'ensemble a été éprouvé sur le corpus réel de 200 000 contenus avant la mise en production.

L'accessibilité et le DSFR

J'ai repris chaque gabarit Twig un à un : attributs de rôle ARIA, hiérarchie des titres, navigation au clavier, contrastes. Le thème a été aligné sur le DSFR, composant après composant.

Le bilan

• Aucune interruption de service sur la totalité des montées, de Drupal 9 à Drupal 11
• Une mise en production sous deux mois pour chaque version
• Une plateforme alignée à la fois sur le DSFR et le RGAA
• Un moteur de recherche reconstruit, piloté en autonomie par les équipes métier
• Une base de code assainie, débarrassée des modules obsolètes, avec SonarQube au vert
• Une chaîne CI/CD Jenkins en place, dotée de tests automatisés
• Une documentation technique et fonctionnelle tenue à jour
• Pas une seule régression constatée en production

Mon enseignement

Si ce projet a tenu la distance, c'est grâce à la rigueur de la démarche : une feuille de route technique limpide, des User Stories soignées, des cahiers de recette complets et une coordination effective entre développement, exploitation, recette et métier.

C'est exactement la même exigence que j'applique sur chacune de mes missions.