Pourquoi les industries réglementées ne peuvent pas faire l’impasse sur le release management

Cet article a été rédigé par Filip de Release Management Apps

Au cours de la dernière décennie, l'Union européenne a considérablement élargi son paysage réglementaire dans des secteurs tels que la banque, l'assurance, la santé, l'iGaming et la défense.

Des réglementations telles que GDPR, DORA, NIS2, AI Act, Cyber Resilience Act, Digital Services Act (DSA) et Digital Markets Act (DMA) exercent désormais une profonde influence sur la manière dont les entreprises modernes conçoivent, exploitent et gèrent leurs systèmes informatiques.

Parallèlement, la pression concurrentielle n'a jamais été aussi forte. On attend des entreprises qu'elles innovent en permanence, qu'elles réduisent les délais de mise sur le marché et qu'elles fournissent de nouvelles capacités numériques plus rapidement que jamais.

Cette situation crée une tension fondamentale : comment les entreprises peuvent-elles aller vite tout en restant sûres, conformes et résilientes ?

L'architecture moderne résout le problème de la rapidité, mais introduit de nouveaux risques

Les récentes tendances technologiques, telles que l'éclatement des applications monolithiques en microservices modulaires, l'adoption de plateformes natives du cloud et l'utilisation de l'automatisation comme colonne vertébrale de DevOps, ont considérablement amélioré la vitesse et l'évolutivité de l'ingénierie.


Cependant, ces avancées ne sont pas toujours alignées sur les exigences réglementaires par défaut. Dans les environnements hautement réglementés, la complexité augmente de façon exponentielle :

• Un seul changement en direction du client peut nécessiter des mises à jour coordonnées sur des dizaines, voire des centaines de systèmes.
• Les systèmes appartiennent à des équipes réparties entre les départements, les pays et les fuseaux horaires.
• Les fonctionnalités multiples sont souvent regroupées dans desversions coordonnées.

Avant d'être mise en production, la solution doit être validée de bout en bout. Cela inclut non seulement les tests fonctionnels, mais aussi les exigences non fonctionnelles (NFR) critiques telles que la sécurité, la conformité, la performance, la disponibilité et la résilience.

Sans la bonne discipline de mise en production, l'architecture moderne peut involontairement augmenter le risque de conformité.

Le coût caché : La perte d'autonomie des équipes

Lorsque les contrôles réglementaires sont mal introduits, ils se répercutent souvent directement sur les équipes d'ingénieurs sous la forme de.. :

• de barrières d'approbation manuelles
• Exigences supplémentaires en matière de documentation
• de processus fragmentés entre les outils et les départements.

Cela peut nuire à l'autonomie de l'équipe et ralentir les livraisons.

L'histoire a montré que cette approche est contre-productive. Les équipes d'ingénieurs sont plus performantes lorsqu'elles sont responsabilisées, qu'on leur fait confiance et qu'elles sont capables d'innover dans des limites claires. Les frictions excessives ne réduisent pas seulement la vitesse, elles augmentent aussi le risque opérationnel, car les équipes travaillent autour de processus défaillants.

Un point de vue essentiel : Les réglementations ne ciblent pas l'ingénierie, elles ciblent les rejets.

Un examen plus approfondi des réglementations européennes modernes révèle un point important :

La plupart des exigences réglementaires ne dictent pas la manière dont les équipes écrivent le code.
Elles se concentrent sur la manière dont les modifications sont examinées, approuvées, publiées et auditées.

Dans les cadres GDPR, DORA, NIS2 et autres, les contrôles fondamentaux s'articulent toujours autour des éléments suivants :

• des processus de révision structurés (le principe des "quatre yeux")
• la gestion formelle des changements
• l'assurance que seuls les artefacts autorisés et approuvés atteignent la production
• la garantie que les artefacts ne sont pas modifiés entre l'approbation et le déploiement
• des pistes d'audit de bout en bout couvrant les changements, les vérifications et les approbations.

En d'autres termes, la charge réglementaire repose principalement sur la couche de gestion des versions, et non sur le travail de développement quotidien.

Pourquoi la gestion des versions devient-elle compliquée ?

De nombreuses organisations tentent de répondre aux exigences réglementaires en ajoutant des contrôles directement dans les flux de travail des équipes. Il en résulte souvent des processus fragmentés et des efforts redondants.

Une approche plus efficace consiste à introduire une capacité centralisée de gestion des versions qui se situe au-dessus des équipes de livraison et qui coordonne les versions sans restreindre la façon dont les équipes construisent les logiciels.

Cette "plaque tournante des versions" devient l'endroit unique où :

• les dépendances entre les systèmes et les équipes sont gérées
• Les approbations de l'architecture, de la sécurité, du risque et de la conformité sont orchestrées.
• Les preuves pour les audits sont collectées automatiquement
• Les versions sont suivies, communiquées et exécutées de manière cohérente.

Étude de cas : Une banque de détail internationale s'adapte aux nouvelles technologies et aux nouvelles réglementations

Un groupe mondial de banque de détail s'est récemment engagé dans une transformation vers une architecture basée sur les microservices et orientée vers le cloud, tout en se préparant à la conformité avec la loi DORA.

Les avantages des microservices et des plateformes d'hébergement en nuage ont été immédiats : les équipes ont gagné en rapidité, en autonomie et en évolutivité. Mais de nouveaux points douloureux sont apparus tout aussi rapidement.

Chaque mise à jour destinée aux clients entraînait des changements dans des centaines de services dorsaux. La réussite des mises en production dépendait désormais d'un timing précis, d'une coordination entre les équipes et de plusieurs niveaux d'approbation impliquant l'ingénierie, l'architecture d'entreprise, la sécurité de l'information, le risque et la conformité.

Malgré des pipelines CI/CD matures, les retards étaient rarement dus à l'outillage. Ils provenaient plutôt d'un manque de coordination et d'un manque de clarté au niveau de la propriété.

L'organisation s'est efforcée de répondre à des questions élémentaires mais cruciales :

• Qu'est-ce qui est réellement prêt à être expédié ?
• Quelles modifications ont été approuvées - et par qui ?
• Dans quel ordre les composants doivent-ils être déployés ?
• Quelles sont les preuves disponibles pour l'audit et l'examen réglementaire ?

En l'absence d'un système central, les décisions de mise en production étaient dispersées dans des fils de discussion Slack, des courriels et des dizaines de projets Jira. Les jours de mise en production ressemblaient à des exercices d'évacuation. Dans un secteur hautement réglementé, ce n'était pas seulement inefficace, c'était dangereux.

La solution : Un centre de publication centralisé

Pour relever ces défis, la banque a mis en œuvre une approche de gestion des versions dédiée, construite autour d'un hub de versions centralisé dans Jira.

Ce hub fournit :

• Une source unique de vérité pour la préparation des versions
• Une visibilité sur les dépendances entre les systèmes
• Des flux de travail d'approbation orchestrés à travers toutes les fonctions de contrôle
• La collecte automatisée des preuves de conformité
• Intégration avec les pipelines de déploiement et la distribution des notes de mise à jour

Il est important de noter que les équipes de livraison ont conservé leur autonomie. Elles ont continué à développer et à tester des logiciels en utilisant des pratiques DevOps modernes, tandis que les contrôles réglementaires étaient appliqués de manière cohérente au niveau de la couche de publication.

Autonomie maintenue, responsabilité appliquée

Chaque équipe a conservé son autonomie mais a adopté une pratique standardisée : l'utilisation de Jira Fix Versions pour regrouper les changements à venir et identifier rapidement les dépendances en amont et en aval. Cela a permis de créer un contrat de livraison clair entre les équipes.

Un processus de livraison standard

Un flux de travail normalisé a été mis en place pour toutes les versions de correction. Les versions correctives de chaque équipe sont apparues sur un tableau unifié, regroupées par initiatives clés agissant comme des plans de navigation. Les relations nombreuses entre les initiatives et les versions correctives ont permis une meilleure visibilité, et les dépendances explicites ont aidé à orchestrer la séquence de livraison correcte.

Soudain, l'ensemble du paysage des versions est devenu gérable.

Intégration des flux d'approbation

Les processus d'approbation existants, alimentés par Jira Service Management (JSM), ont été intégrés directement dans le hub de publication. Au fur et à mesure que les versions de correction passaient en Approbation requise, le hub validait toutes les conditions préalables et créait automatiquement les tickets JSM correspondants.

Ces tickets contenaient toutes les informations nécessaires, à savoir
- le champ d'application de la version,
- dépendances,
- preuves de test,
- validation de la demande d'extraction,
- statut de la révision de l'architecture d'entreprise,
- des liens vers le hub de la version pour un contexte complet.

Cela a permis d'avoir une visibilité complète sur ce qui était en attente d'approbation - et pour combien de temps.

Intégration de CI/CD et de notes de publication automatisées

Les pipelines Bitbucket ont été connectés au hub, se déclenchant automatiquement une fois que les approbations étaient terminées et que les versions de correction passaient à l'état Prêt pour le déploiement. Il n'était donc plus nécessaire de créer manuellement des tickets DevOps.

Après le déploiement, le système demandait la création de notes de mise à jour à l'aide de modèles prédéfinis. Les notes générées étaient stockées dans un espace Confluence centralisé avec versionnement, et liées directement à la version de correction.

Ce qu'il faut retenir

Le release hub est devenu bien plus qu'une surcouche de CI/CD - il est devenu le système nerveux central du processus de livraison de logiciels de la banque. Il a permis des capacités qui n'étaient pas possibles auparavant :

• Collecte automatique des artefacts de test et de conformité
• Des barrières de révision renforcées avec des permissions basées sur les rôles
• Suivi transparent des points d'intégration entre les services
• Déclencheurs de déploiement automatisés et génération de notes de mise à jour

L'impact a été immédiat :

• Letemps de préparation de la mise en production a considérablement diminué, grâce à la réduction des vérifications manuelles et à une coordination plus claire.
• Lapréparation à l'audit s'est améliorée, les approbations et la documentation étant capturées directement dans le flux de travail.
• Les équipes se sont senties plus autonomes et moins réactives, soutenues par un processus qui a favorisé la collaboration au lieu d'ajouter des frictions.
• Lesversions sont devenues prévisibles et routinières, au lieu des urgences nocturnes et des appels de synchronisation ad hoc.

Plus important encore, les versions sont devenues fiables - uneopération prévisible, traçable et évolutive. Dans les secteurs où la conformité et le contrôle ne sont pas négociables, c'est un facteur de transformation.

Conclusion

Dans les secteurs réglementés, la gestion des versions n'est pas "simplement" un outil opérationnel, c'est une infrastructure stratégique. Lorsqu'elle est bien faite, elle s'efface, permettant des livraisons sûres, conformes et évolutives sans ralentir l'innovation.