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

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, sans interrompre les services existants ni dégrader la confiance des utilisateurs.

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

Le sujet visible pouvait être résumé à une migration Drupal 9 vers Drupal 10. Mais le vrai sujet Product Engineering était plus large : comment accompagner l'évolution d'une plateforme publique complexe tout en maintenant sa qualité, sa cohérence et sa capacité à évoluer.

Un produit numérique public ne vit pas seulement au moment de sa conception. Sa valeur dépend aussi de la manière dont il est maintenu, migré, testé et amélioré dans le temps.

Contexte

Le portail institutionnel de la Ville de Montréal constitue l'un des principaux points de contact numériques entre la ville et les citoyens.

Il centralise des contenus, services, informations publiques et parcours utilisateurs qui doivent rester disponibles, fiables et compréhensibles.

La mission s'inscrivait dans un contexte de maintenance évolutive, au sein d'une équipe pluridisciplinaire pilotée par Levio : développement backend et frontend, tests, analyse, coordination projet et besoins métier.

Le rôle ne consistait pas à concevoir une plateforme à partir de zéro.

Il consistait à intervenir sur un système déjà vivant :

• migration technique ;
• évolutions fonctionnelles ;
• reprises de données ;
• amélioration de la qualité logicielle ;
• corrections front et back-office ;
• prévention des régressions ;
• maintien de la stabilité en production.

Dans ce type d'environnement, chaque changement doit être pensé comme une intervention sur un système existant.

Les défis d'une plateforme publique en production

Une plateforme publique en production impose des contraintes particulières.

La première est la continuité de service.

Contrairement à une application interne, un portail public est visible en permanence. Une régression, une donnée incorrecte ou un comportement instable peut avoir un impact direct sur les citoyens.

La deuxième contrainte concerne la qualité des données.

Les informations publiées peuvent servir à effectuer une démarche, comprendre une procédure ou accéder à un service. La donnée n'est donc pas seulement un contenu : elle participe au service rendu.

La troisième contrainte est la durée de vie.

Une plateforme institutionnelle évolue pendant des années. Elle accumule des fonctionnalités, des adaptations, des choix historiques et parfois de la dette technique.

La difficulté n'est pas seulement de livrer une évolution.

La difficulté est de livrer une évolution sans affaiblir la plateforme.

Faire évoluer sans casser l'existant

Faire évoluer un système existant demande une posture différente de la construction d'un produit neuf.

Avant de modifier, il faut comprendre :

• pourquoi une implémentation existe ;
• quelles données elle manipule ;
• quelles dépendances elle implique ;
• quels usages elle supporte ;
• quels risques elle introduit ;
• quelles équipes peuvent être impactées.

La migration Drupal 9 vers Drupal 10 représentait un chantier important, mais elle ne pouvait pas être traitée comme une opération isolée.

Elle devait cohabiter avec les besoins quotidiens du portail : corrections, évolutions, publication, maintenance et stabilité.

L'arbitrage principal était donc clair : moderniser la base technique sans créer de rupture dans l'usage.

Les décisions de Product Engineering

Plusieurs décisions ont structuré l'intervention.

Réduire le risque avant d'ajouter de la complexité

Une migration majeure doit d'abord sécuriser le système.

L'objectif n'est pas de profiter de la migration pour tout réinventer. Sur une plateforme publique, cela augmenterait fortement le risque.

La priorité était donc de maintenir une base supportée, corriger les incompatibilités, préserver les comportements existants et limiter les régressions.

Automatiser les changements répétitifs, relire les cas sensibles

Des outils comme Drupal Rector ont permis d'accélérer une partie des transformations liées à la migration.

Mais l'automatisation ne remplace pas la compréhension du système.

Les changements répétitifs peuvent être assistés. Les cas liés au métier, aux données ou aux comportements spécifiques doivent rester relus et contrôlés.

L'approche retenue était donc hybride : automatiser ce qui est mécanique, garder une revue humaine sur ce qui peut affecter le produit.

Faire des données un objet de qualité

Une partie importante du travail concernait les données structurées.

Lorsqu'une plateforme expose ou transforme des données, il ne suffit pas que l'interface soit correcte.

Il faut aussi vérifier que les structures, champs, valeurs et contrats restent stables.

Cette logique a conduit à renforcer les tests automatisés JSON sur certains flux, notamment pour vérifier la cohérence des données exposées.

Améliorer progressivement l'architecture

La dette technique ne disparaît pas par une grande réécriture.

Sur une plateforme publique en production, l'amélioration doit souvent être progressive : corriger une zone, clarifier une responsabilité, stabiliser un flux, renforcer un test, documenter une dépendance.

Ce travail est moins spectaculaire qu'une refonte, mais il est essentiel pour la pérennité du produit.

Maintenir la qualité à grande échelle

La qualité logicielle ne repose pas sur une seule pratique.

Elle repose sur une combinaison de mécanismes :

• revues de code ;
• tests automatisés ;
• validation des données ;
• migrations contrôlées ;
• scripts de reprise robustes ;
• suivi des régressions ;
• coordination entre équipes ;
• attention portée aux impacts métier.

Dans le cas du portail, les tests de données avaient une valeur particulière.

Une interface peut sembler correcte alors qu'une structure JSON exposée a changé. Une donnée peut être présente mais mal formée. Un champ peut disparaître sans que cela se voie immédiatement à l'écran.

Tester les contrats de données permet de protéger le système contre des régressions moins visibles, mais parfois plus critiques.

Migrations et reprises de données

Les migrations de données sont souvent plus sensibles que les migrations de code.

Le code peut être relu, analysé, remplacé ou corrigé. Les données, elles, portent l'historique du produit.

Les scripts de reprise et transformations de données devaient donc être pensés avec prudence.

L'enjeu n'était pas seulement d'exécuter une opération technique.

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

Le découpage en traitements contrôlés permettait de limiter les risques :

• éviter les opérations trop longues ;
• rendre les traitements plus prévisibles ;
• faciliter la reprise en cas d'erreur ;
• isoler les cas problématiques ;
• vérifier le résultat après exécution.

Ce type de travail illustre bien la différence entre "faire passer une migration" et faire évoluer un produit en production.

Travailler dans une équipe pluridisciplinaire

Une plateforme publique de grande taille ne se maintient pas seul.

Chaque évolution implique plusieurs perspectives :

• développement backend ;
• développement frontend ;
• tests ;
• analyse fonctionnelle ;
• coordination projet ;
• contraintes éditoriales ;
• contraintes d'exploitation.

La collaboration devient donc un élément de qualité.

Une correction technique doit être comprise dans son contexte fonctionnel. Une régression doit être analysée avec les bons interlocuteurs. Une migration doit être planifiée en tenant compte du rythme de la plateforme.

Dans ce type d'environnement, la qualité dépend autant de la communication que du code.

Les difficultés rencontrées

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

Une migration ne consiste pas uniquement à remplacer des APIs 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, surtout lorsque plusieurs équipes interviennent 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. Il fallait améliorer progressivement la situation sans remettre en cause la stabilité générale du portail.

La quatrième difficulté concernait les données.

Les données structurées exposées par une plateforme publique doivent rester cohérentes dans le temps. Une modification de structure peut avoir un impact sur des consommateurs, des exports ou des traitements connexes.

Les résultats observables

Les résultats les plus importants sont liés à la capacité du portail à continuer d'évoluer avec stabilité.

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 automatisés JSON ont renforcé la confiance dans les données exposées.

Les évolutions backend et les corrections front/back-office ont permis d'accompagner les besoins fonctionnels tout en respectant les contraintes du portail.

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

La valeur est dans l'amélioration continue : réduire le risque, préserver la qualité et garder la plateforme capable d'évoluer.

Ce que je ferais différemment aujourd'hui

Avec le recul, plusieurs éléments mériteraient d'être renforcés encore plus tôt :

• documenter davantage les contrats de données ;
• introduire certains tests avant les migrations sensibles ;
• cartographier plus systématiquement les dépendances entre composants ;
• formaliser les zones à risque avant les changements majeurs ;
• rendre plus visibles les impacts fonctionnels des changements techniques ;
• renforcer les checklists de revue sur les évolutions sensibles.

Ces ajustements ne remettent pas en cause les arbitrages réalisés.

Ils visent surtout à rendre le changement plus prévisible.

Les 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 ;
• la dette accumulée ;
• les dépendances entre équipes.

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, au sein d'une plateforme publique, la qualité perçue par les utilisateurs dépend rarement des détails techniques.

Les citoyens ne perçoivent pas une migration Drupal.

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

Ce que je retiens aujourd'hui

Le principal enseignement de cette mission est qu'un Product Engineer ne construit pas seulement des produits.

Il accompagne aussi leur évolution dans le temps.

Sur une plateforme publique complexe, chaque décision doit préserver trois choses : la qualité actuelle, la cohérence du système et sa capacité à évoluer demain.

Drupal était le support technique.

Le vrai sujet était la pérennité d'une plateforme publique en production.