Faire évoluer une plateforme publique à grande échelle : retour d'expérience sur un portail Drupal 10

Contexte de la mission

Lorsque l'on parle de développement web, les discussions portent souvent sur la création de nouveaux produits.

La réalité des grandes organisations est souvent différente.

Une part importante du travail consiste à faire évoluer des systèmes déjà en production, utilisés quotidiennement par des milliers voire des millions d'utilisateurs, sans interrompre les services existants.

C'est dans ce contexte que s'inscrivait ma mission au sein de la Ville de Montréal.

Le portail web institutionnel constitue l'un des principaux points de contact numériques entre la ville et les citoyens. Il centralise un volume important de contenus, de services, d'informations publiques et de parcours utilisateurs.

L'enjeu n'était donc pas uniquement technique.

Chaque évolution devait préserver la stabilité de la plateforme, maintenir la qualité des données exposées et éviter les régressions susceptibles d'impacter les utilisateurs finaux.

Mon rôle portait principalement sur le développement backend Drupal, les évolutions fonctionnelles, les migrations techniques et l'amélioration de la qualité du système.

Situation de départ

À mon arrivée sur le projet, la plateforme reposait encore en partie sur Drupal 9 alors que la préparation de la migration vers Drupal 10 était devenue une priorité.

Comme souvent dans les projets institutionnels de longue durée, l'application avait évolué au fil du temps :

• ajout de nouvelles fonctionnalités ;
• évolution du modèle de contenu ;
• intégration de composants spécifiques ;
• adaptations liées aux besoins métier ;
• accumulation progressive de dette technique.

Le défi principal n'était pas uniquement la migration de version.

Il fallait également garantir que les évolutions réalisées pendant cette période continuent à fonctionner correctement après la transition.

Le portail devait rester disponible tout au long du processus.

Dans ce type de contexte, une migration n'est jamais un projet isolé. Elle doit cohabiter avec les besoins quotidiens des équipes produit, des éditeurs de contenu et des utilisateurs.

Les contraintes d'une plateforme publique

Un portail institutionnel présente plusieurs contraintes particulières.

La première concerne la continuité de service.

Contrairement à une application interne, une plateforme publique est exposée en permanence. Les interruptions ou dysfonctionnements deviennent rapidement visibles.

La deuxième contrainte concerne la qualité du contenu.

Les citoyens s'appuient sur les informations publiées pour effectuer des démarches, trouver des services ou comprendre certaines procédures administratives.

Une donnée incorrecte ou incomplète peut avoir des conséquences concrètes.

La troisième contrainte est liée à la gouvernance.

Les contenus sont produits par plusieurs équipes et doivent respecter des règles communes de publication, d'accessibilité et de structuration.

Enfin, la maintenabilité constitue une exigence permanente.

Les plateformes publiques ont souvent une durée de vie longue. Les décisions prises aujourd'hui doivent rester compatibles avec les évolutions futures.

La migration Drupal 9 vers Drupal 10

La migration représentait l'un des chantiers techniques majeurs.

Une première option aurait consisté à effectuer l'ensemble des corrections manuellement.

Cette approche offre un contrôle précis mais devient rapidement coûteuse lorsque le volume de code augmente.

Une autre possibilité était d'automatiser au maximum les transformations.

L'outil Drupal Rector s'est révélé particulièrement utile dans cette phase.

L'objectif n'était pas de laisser l'outil réaliser toute la migration, mais de réduire le volume des modifications répétitives.

Cette approche hybride présentait plusieurs avantages :

• accélération des mises à jour compatibles ;
• réduction du travail manuel ;
• meilleure visibilité sur les corrections restantes ;
• concentration des efforts sur les cas réellement complexes.

Cependant, l'automatisation ne résout pas tout.

Certaines parties du code nécessitaient des ajustements manuels, notamment lorsque des comportements métier spécifiques étaient impliqués.

L'arbitrage retenu consistait donc à utiliser Drupal Rector comme accélérateur de migration, tout en conservant une revue humaine systématique.

Pourquoi les migrations de données sont souvent plus complexes que prévu

Un autre aspect important du projet concernait les migrations de données.

Dans de nombreux projets, l'attention se concentre sur le code.

Pourtant, la donnée constitue souvent la partie la plus sensible.

Plusieurs scripts ont été développés afin de réaliser des transformations et des reprises de données via des update hooks et la Batch API.

L'utilisation de la Batch API répondait à une contrainte simple : certaines opérations pouvaient concerner un volume important d'éléments.

Exécuter l'ensemble du traitement en une seule requête aurait augmenté les risques :

• dépassement de temps d'exécution ;
• consommation excessive de mémoire ;
• difficulté à reprendre le traitement en cas d'échec.

Le découpage en lots permettait de rendre ces opérations plus robustes et plus prévisibles.

L'objectif n'était pas seulement d'effectuer une migration.

Il fallait également garantir que le résultat final reste cohérent avec le modèle métier existant.

Contenu structuré et Serialization API

L'un des aspects les plus intéressants du projet concernait l'architecture de contenu structuré.

Le portail utilisait une approche fortement orientée objet pour modéliser certains éléments de contenu.

Cette architecture reposait notamment sur :

• des composants spécialisés ;
• des champs personnalisés ;
• des structures de données réutilisables ;
• la Serialization API de Drupal.

L'intérêt de cette approche est de séparer la représentation métier de la représentation finale.

Le contenu devient un ensemble d'objets structurés pouvant être exposés via différents canaux.

Mais cette flexibilité introduit également de nouvelles responsabilités.

Chaque évolution doit préserver la cohérence des structures existantes.

Une modification de champ peut avoir un impact sur :

• les exports ;
• les intégrations ;
• les APIs ;
• les consommateurs des données.

La conception de nouveaux champs personnalisés nécessitait donc une attention particulière afin d'éviter de fragiliser l'écosystème existant.

Tester les données plutôt que seulement l'interface

Un autre enseignement important de cette mission concerne les tests automatisés.

Une partie du travail consistait à mettre en place des tests JSON pour le projet Redacto.

Cette démarche répond à une problématique souvent sous-estimée.

Lorsqu'une plateforme expose des données structurées, vérifier uniquement l'interface utilisateur n'est plus suffisant.

Il devient nécessaire de contrôler :

• la présence des champs attendus ;
• la structure des réponses ;
• la cohérence des valeurs ;
• la stabilité des contrats de données.

Ces tests jouent un rôle important dans la prévention des régressions.

Ils permettent d'identifier rapidement les effets de bord introduits par une évolution ou une migration.

Dans certains cas, ils protègent davantage le système qu'un simple test visuel.

Les difficultés rencontrées

Comme dans tout projet de longue durée, plusieurs difficultés sont apparues.

La première concernait la compatibilité entre anciennes et nouvelles versions.

Une migration ne consiste pas uniquement à remplacer des API obsolètes.

Il faut comprendre pourquoi certaines implémentations existent et quelles dépendances elles impliquent.

La deuxième difficulté concernait les régressions.

Chaque correction peut introduire un comportement inattendu ailleurs dans le système.

Cette réalité est particulièrement présente lorsque plusieurs équipes interviennent simultanément sur une même base de code.

La troisième difficulté concernait la dette technique.

Certaines parties du projet avaient été conçues dans un contexte différent de celui d'aujourd'hui.

L'enjeu consistait alors à améliorer progressivement la situation sans remettre en cause la stabilité générale du portail.

Résultats obtenus

Les résultats les plus visibles concernent la capacité du projet à continuer d'évoluer tout en conservant un niveau de stabilité élevé.

La migration vers Drupal 10 a permis de maintenir la plateforme sur une base technologique supportée.

Les scripts de migration ont facilité certaines opérations de reprise de données.

Les tests JSON ont renforcé la confiance dans les données exposées.

Les évolutions backend ont permis d'accompagner les besoins fonctionnels tout en respectant les contraintes du portail.

Plus globalement, le projet a démontré qu'il est possible de faire évoluer une plateforme importante sans recourir à une réécriture complète.

Ce que je referais différemment aujourd'hui

Avec le recul, plusieurs points mériteraient probablement davantage d'investissement dès le départ.

La documentation des contrats de données pourrait être renforcée encore plus tôt.

Certains tests automatisés pourraient être introduits avant même le début de certaines migrations.

Une cartographie plus systématique des dépendances entre composants permettrait également de réduire certains risques de régression.

Ces améliorations restent toutefois des optimisations. Elles ne remettent pas en cause les principaux arbitrages réalisés.

Enseignements Product Engineering

Cette mission rappelle qu'une grande partie du Product Engineering consiste à gérer le changement plutôt qu'à créer du neuf.

Faire évoluer un système existant impose de comprendre :

• l'architecture ;
• les données ;
• les usages ;
• les contraintes métier ;
• les risques techniques.

Elle montre également qu'une migration réussie n'est pas celle qui modernise le plus de code.

C'est celle qui réduit le risque tout en préservant la capacité d'évolution du produit.

Enfin, elle confirme qu'au sein d'une plateforme publique, la qualité des données est souvent aussi importante que la qualité du code.

Les citoyens ne perçoivent pas les détails d'une migration Drupal.

Ils perçoivent la fiabilité du service qui leur est rendu.

Dans ce contexte, l'objectif n'est pas simplement de faire évoluer une technologie.

Il est de faire évoluer un système sans compromettre la confiance que ses utilisateurs lui accordent.