Migrer un portail gouvernemental vers Drupal 11

vie-publique.fr est le portail d'information citoyenne de la DILA (Direction de l'Information Légale et Administrative), rattaché au Premier Ministre. Plus de 2 millions de visiteurs par mois, plus de 200 000 contenus. L'un des plus gros sites Drupal du secteur public en France.

AdevWeb est intervenu en tant que lead technique. Pilotage des montées de version Drupal, encadrement de l'équipe de développement, structuration du projet, et validation de chaque livraison. Le site tourne 24h/24, pas de fenêtre de maintenance possible.

Le contexte

Drupal sort des versions mineures, majeures et des patchs de sécurité régulièrement. Sur vie-publique.fr, le rythme de mise à jour dépendait du type de release :

• Versions majeures (ex. Drupal 10 à 11) : passage en prod sous 2 mois
• Versions mineures (ex. 11.1 à 11.2) et patchs (11.3.x) : intégrés dès le début du sprint en cours pour détecter d'éventuelles régressions au plus tôt
• Correctifs de sécurité : en production sous 24h

On a fait le chemin de Drupal 9 à Drupal 11 en passant par chaque version intermédiaire. Pas le droit au "on verra plus tard".

Les contraintes :

• Un site gouvernemental qui ne peut pas afficher une page de maintenance
• Des exigences d'accessibilité RGAA et de conformité DSFR (Système de Design de l'État)
• Des dizaines de modules custom à passer en revue à chaque release
• Un moteur de recherche ElasticSearch à faire passer de la version 7 à 8
• Encadrement d'une équipe de 4 développeurs et coordination avec les autres pôles : DevOps, QA, cheffe de produit, rédaction
• Des environnements de tests à provisionner pour que les PO puissent valider avant chaque mise en prod

Comment on a travaillé

Pilotage technique au quotidien

Le lead tech tient la roadmap technique, rédige les User Stories dans JIRA en collaboration avec les PO, la cheffe de produit et l'équipe projet, estime les charges, dimensionne les sprints.

Chaque livraison passait par un cahier de recette détaillé. L'équipe QA testait, la cheffe de produit validait le fonctionnel, les rédacteurs vérifiaient que l'éditorialisation fonctionnait toujours, l'infra confirmait la stabilité. Personne ne signait avant d'avoir vérifié sa partie.

Montées de version Drupal

On ne migre pas un site de cette taille en une fois. À chaque nouvelle release Drupal, on lançait le même processus : audit des dépréciations, passage en revue des modules contrib et custom, adaptation du code, tests de non-régression, déploiement progressif. L'objectif de 2 mois par release a été tenu sur toute la durée du projet.

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

On commence par un composer outdated drupal/* pour voir ce qui bouge. Ensuite, les modules contrib : est-ce qu'ils ont une version compatible ? Est-ce que certains ne sont plus maintenus et doivent être remplacés ? Pour les modules custom (il y en a des dizaines), on passe Rector pour réécrire automatiquement le code déprécié, mais chaque transformation est relue manuellement. On met à jour le composer.json, on résout les conflits de dépendances, et rien ne part en merge request sans que la suite de tests soit passée.

Infra et DevOps

Monter Drupal, ça ne suffit pas. Chaque version apporte des prérequis côté serveur. Drupal 11, par exemple, exige PHP 8.3 minimum. Il faut aussi vérifier les EOL de PHP, MariaDB, les extensions requises. On a coordonné tout ça avec l'équipe infra : montées de version PHP (8.1, 8.2, 8.3...), provisionnement d'environnements de test pour les PO et la cheffe de produit, adaptation des pipelines Jenkins.

Côté monitoring, on suivait les métriques avec Grafana et Graylog pour détecter toute régression de performance après chaque déploiement.

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

On ne surveille pas que Drupal. On maintient un suivi des dates de fin de vie de chaque brique : version PHP, MariaDB/MySQL, extensions PHP, modules contrib critiques. L'objectif est de ne jamais avoir un composant en fin de support en production. Ce tableau est partagé avec l'infra et mis à jour à chaque sprint de maintenance.

Côté technique - Le pipeline CI/CD

Jenkins adapté à chaque version : tests PHPUnit, analyse statique SonarQube (couverture, vulnérabilités, code smells), validation des coding standards avec phpcs et phpstan, puis déploiement automatisé sur staging. Aucune merge request ne passait si SonarQube n'était pas au vert.

Recette et validation

Chaque livraison avait son cahier de recette couvrant tous les scénarios fonctionnels impactés. L'équipe QA passe les parcours utilisateurs, la cheffe de produit vérifie la cohérence fonctionnelle, les rédacteurs testent l'éditorialisation (Paragraphs, blocs, médias), l'infra valide la stabilité.

Résultat : aucune régression en production sur toute la durée du projet.

Documentation

Tout est documenté. Doc technique des modules custom (architecture, API, dépendances), doc fonctionnelle pour les PO et les rédacteurs, guides de déploiement pour l'infra. Quand un nouveau développeur arrive sur le projet, il peut être opérationnel rapidement. Et quand on revient sur un module 6 mois plus tard, on sait pourquoi il a été conçu comme ça.

Refonte du moteur de recherche

ElasticSearch 7 vers 8, ça ne se fait pas en un composer update. On a refait le mapping des champs, reconfiguré les requêtes, et développé une interface interne qui permet aux équipes métier d'ajuster le ranking et les filtres elles-mêmes, sans avoir besoin d'un développeur.

Côté technique - ElasticSearch 7 → 8

ES 8 supprime les types de mapping. Ça impose de reprendre toute l'indexation. Chaque champ a été re-mappé, les analyseurs français (accents, synonymes) reconfigurés, les requêtes bool / multi_match réécrites. On a validé le tout sur le corpus réel de 200 000 contenus avant de passer en prod.

Accessibilité et DSFR

Chaque template Twig a été revu : rôles ARIA, hiérarchie des headings, navigation clavier, contrastes. Le thème a été adapté au DSFR composant par composant.

Les résultats

• Zéro coupure de service sur toutes les montées de version, de Drupal 9 à 11
• Chaque release en production sous 2 mois
• Site conforme DSFR et RGAA
• Moteur de recherche refondu, géré en autonomie par les équipes métier
• Code nettoyé, modules dépréciés supprimés, SonarQube au vert
• CI/CD Jenkins opérationnelle avec tests automatisés
• Documentation technique et fonctionnelle à jour
• Zéro régression en production

Ce qu'on en retient

Ce qui a fait tenir ce projet, c'est la méthode. Roadmap technique claire, US bien rédigées, cahiers de recette exhaustifs, coordination réelle entre dev, infra, QA et métier.

On applique la même approche sur tous nos projets.