Pourquoi la conformité continue de ralentir tes mises en production (et par quoi commencer pour y remédier)

Une équipe déploie à un rythme régulier pendant la majeure partie de l’année. Puis un audit approche, et les livraisons ralentissent. Les ingénieurs sont détournés de leur travail sur les fonctionnalités pour soutenir l’audit, en produisant les exportations de configuration, les journaux et les vérifications d’environnement dont dépendent les preuves. Ce ralentissement dure aussi longtemps que l’audit.

On pourrait facilement en conclure que l’équipe doit travailler plus vite ou être plus nombreuse. En général, ce n’est ni l’un ni l’autre. Le retard vient du travail manuel de conformité qui entoure chaque mise en production, et ajouter du monde à cette tâche ne fait que la multiplier.

On sous-estime facilement l’ampleur du problème. La première année de mise en conformité SOC 2 mobilise généralement entre 100 et 500 heures de travail des ingénieurs sur des tâches de conformité, au détriment de la feuille de route du produit : un coût qui n’apparaît jamais sur une facture, mais qui se paie en fonctionnalités livrées plus tard. C’est le travail lui-même qui pose problème, pas les personnes qui le font, et la majeure partie de ce travail n’existe que parce que la conformité doit être vérifiée manuellement, version après version.

Le goulot d’étranglement, ce n’est pas la rapidité de ton équipe

Point clé : la livraison ralentit à l’approche des audits parce que les ingénieurs sont détournés vers un travail manuel de justification, pas parce qu’ils livrent le code trop lentement.

Lorsque les cycles de livraison ralentissent en raison des obligations PCI DSS ou SOC 2, la contrainte réside rarement dans la rapidité avec laquelle les ingénieurs écrivent du code. C’est le travail nécessaire pour prouver que le code a été livré dans le respect des règles qui pose problème.

En pratique, une période d’audit fonctionne comme un gel des fonctionnalités. Tes ingénieurs seniors cessent de livrer et se mettent à rassembler des preuves : ils exportent l’historique des pull requests pour montrer que les modifications ont été revues, extraient les journaux d’accès pour prouver qui a pu accéder à l’environnement de production, font des captures d’écran de la configuration pour démontrer qu’un contrôle était en place, et confirment que l’environnement de staging examiné par l’auditeur correspond bien à ce qui a été livré. Aucune de ces tâches ne fait avancer une fonctionnalité. Ce travail est effectué par les mêmes personnes sur lesquelles tu comptes pour respecter la feuille de route, et il doit être réalisé à chaque cycle d’audit.

C’est pourquoi ce ralentissement donne l’impression d’être un problème d’équipe alors qu’il s’agit en réalité d’un problème de processus. L’équipe n’est pas en sous-performance. Elle est détournée de ses missions de livraison pour effectuer manuellement des tâches de conformité.

Pourquoi la préparation aux audits ralentit les livraisons

Point clé à retenir : le retard vient du travail manuel et répétitif de collecte de preuves et de réconciliation des environnements, qui sont autant de coûts liés aux processus plutôt que des défaillances techniques.

Pour la plupart des organisations, ce n’est pas un événement qui se produit une seule fois par an. Dans le rapport de référence 2026 d’A-LIGN sur la conformité, 97 % des organisations ont déclaré mener au moins deux audits ou évaluations par an, et une étude de référence antérieure de ce cabinet a révélé que près des deux tiers y consacraient au moins trois mois par an. Le retard provient d’une poignée de tâches spécifiques et répétitives, et chacune d’entre elles est un artefact du processus plutôt qu’un signe de faiblesse de l’équipe.

• La collecte de preuves est manuelle et répétitive. L’auditeur demande un échantillon des modifications apportées au cours de la période et la preuve que chacune a été vérifiée avant sa mise en production. Quelqu’un reconstitue tout ça à partir de l’historique des pull requests, des exportations de tickets et de captures d’écran, car aucun système ne l’a enregistré en temps réel. Au cycle suivant, cette reconstitution recommence à zéro.
• Les environnements dérivent, ce qui rend difficile la démonstration de la parité. L’auditeur te demande de prouver que ce que tu as testé correspond bien à ce que tu as déployé. Si les environnements de staging et de production ont discrètement divergé — une version de bibliothèque par-ci, un indicateur de configuration par-là —, répondre à cette question se transforme en une journée d’enquête avant même que tu puisses donner une réponse.
• Les contrôles sont validés manuellement. Quand tu développes sur une infrastructure brute, tu es responsable du renforcement de la sécurité du système d’exploitation, de l’application des correctifs et de l’isolation du réseau, et tu dois fournir toi-même les preuves de tout ça.
• La traçabilité des changements est reconstituée a posteriori. Qui a changé quoi, quand et pourquoi ? On reconstitue tout ça à partir de souvenirs et de tickets épars, plutôt que de consulter un historique unique et fiable.
• Le périmètre d’audit est plus large qu’il ne devrait l’être. Sans distinction claire entre ce qui relève de la plateforme et ce qui relève de ton application, les contrôles dont une plateforme pourrait être responsable dans le cadre d’un modèle de responsabilité partagée – segmentation du réseau, renforcement de l’infrastructure, sécurité physique – restent dans ton périmètre d’audit.

Ce sont toutes les conséquences d’un travail de conformité mal orienté : il repose sur des personnes et des routines manuelles plutôt que sur la plateforme sur laquelle le logiciel s’exécute.

Par quoi commencer : déplacer les contrôles vers la couche de la plateforme

Point clé : déplacer les contrôles vers la plateforme te permet de bénéficier de preuves d’infrastructure vérifiées et d’une piste d’audit automatique ; ainsi, la part des preuves liées à l’infrastructure devient un sous-produit du déploiement plutôt qu’un projet à part entière.

Le premier changement consiste à sortir les contrôles de conformité et les preuves des routines manuelles pour les intégrer à la plateforme sur laquelle ton logiciel s'exécute. Sur une plateforme sécurisée par défaut, les contrôles au niveau de l'infrastructure sont gérés et attestés par la plateforme elle-même ; tu hérites donc de cette partie de l'audit plutôt que de devoir la recréer.

Ça fonctionne grâce à un partage des responsabilités. La plateforme sécurise l’infrastructure et enregistre chaque modification. Ton équipe se charge de sécuriser son propre code d’application et ses accès. En prenant Upsun Cloud comme exemple de ce modèle, voici les conséquences concrètes :

• Les contrôles d’infrastructure sont déjà vérifiés dès le départ. Déployer sur une infrastructure certifiée signifie que tu commences l’audit avec des contrôles au niveau de l’infrastructure déjà vérifiés et documentés par la plateforme ; tu reprends donc les preuves existantes au lieu de les recréer. Upsun Cloud détient les certifications PCI DSS v4.0.1 Niveau 1, SOC 2 Type 2 et ISO/IEC 27001:2022, et prend en charge les charges de travail réglementées par la loi HIPAA dans le cadre d’un accord de partenariat commercial (BAA) signé. Le périmètre et les conditions actuels sont répertoriés dans le Centre de confiance.
• Chaque modification est automatiquement consignée. Chaque déploiement et chaque changement de configuration sont enregistrés en tant qu’activité, ce qui te fournit une piste d’audit intégrée plutôt qu’une piste constituée a posteriori.
• La configuration est du code soumis au contrôle de version. Ton environnement est défini dans le fichier `.upsun/config.yaml` et dans tout autre fichier YAML situé au niveau supérieur du répertoire `.upsun`. L’historique Git indique quand chaque modification a été effectuée et ce que la validation a enregistré, sans qu’il soit nécessaire de parcourir la console.
• Les environnements de test sont créés à partir de la même définition que leur parent. Comme chaque environnement est créé à partir de la même définition, vérifier que ce que tu as testé correspond bien à ce que tu as déployé ne nécessite plus d’enquête. Les environnements héritent également des données de leur parent ; veille donc à nettoyer toute base de données contenant des données personnelles avant d’ouvrir un environnement de test à un public plus large.

C’est ce qui a permis à Qombo, une fintech européenne vendant des API de vérification aux banques, de s’imposer avec crédibilité dans les discussions bancaires : hériter de la posture de conformité d’Upsun Cloud et de la résidence des données dans l’UE a raccourci les processus de diligence raisonnable et les contrôles de conformité effectués par ses clients bancaires, et une équipe de deux personnes a répondu aux attentes du secteur bancaire sans avoir à recruter de personnel DevOps.

Concrètement, ça te donne des preuves cohérentes d’un environnement à l’autre, sans avoir à rapprocher manuellement les données de différentes consoles. Ça ne veut pas dire que les preuves apparaissent d’un simple clic, ni que ça te décharge de ta responsabilité vis-à-vis de ton propre code. Ça signifie simplement que la partie infrastructure du travail est héritée, plutôt que reconstruite à chaque cycle.

Deux conditions méritent d’être vérifiées dès le départ. La certification PCI d’Upsun Cloud exclut actuellement les régions FR-1 et FR-3 ; vérifie donc le statut de ta région avant de lancer une charge de travail relevant de la norme PCI. Les charges de travail HIPAA ne fonctionnent que dans la région US-4 et nécessitent un accord de confidentialité (BAA) signé.

À quoi ressemble un cycle de publication conforme aux exigences de conformité

Point clé : lorsque les preuves et la parité de l’environnement sont générées automatiquement, les périodes d’audit ne t’obligent plus à geler les livraisons.

Ce changement est particulièrement visible lors d’une mise en production proche d’un audit.

Avant, une mise en production approchant d’une fenêtre d’audit déclenchait une course effrénée. Les ingénieurs interrompaient le développement des fonctionnalités pour rassembler les preuves, harmoniser les environnements qui s’étaient décalés et reconstituer un historique des modifications. La mise en production était bloquée, et ce blocage durait aussi longtemps que l’audit.

Désormais, les preuves relatives à l’infrastructure existent déjà, car la plateforme a enregistré chaque modification au fur et à mesure. Les environnements correspondent déjà, puisqu’ils sont construits à partir de la même définition. L’audit s’appuie sur ce qui existe déjà pour cette partie du travail, et le rythme des mises en production ne s’adapte plus au calendrier des audits.

On retrouve le même schéma dans les vérifications préalables au déploiement qu’une équipe soumise à la réglementation effectue à chaque déploiement. ROLLIN, une agence qui développe pour des clients du secteur public et de la santé, a remplacé une validation lente, manuelle et sujette aux erreurs par un pipeline automatisé relié à des environnements Upsun Cloud sous contrôle de version, et est ainsi passée à des déploiements plus rapides, plus sûrs et plus fiables, sans augmenter les risques liés au déploiement.

Par où commencer : intégrer la conformité dans la plateforme

Si la conformité ralentit tes mises en production, c’est le signe que le travail de conformité se situe au mauvais niveau, et non que ton équipe est trop lente. Le premier changement consiste à intégrer les contrôles d’infrastructure et leurs justificatifs dans la plateforme, afin que cette partie de la conformité soit héritée et générée automatiquement, plutôt que de devoir être reconstruite à la main à chaque cycle.

Les audits sont la manière la plus visible dont la conformité ralentit la livraison, mais ce n’est pas la seule. Les équipes soumises à une réglementation sont confrontées à des obligations liées aux versions, comme le DORA de l’UE, où la contrainte est d’ordre architectural : tu dois prouver que tu peux changer de fournisseur sans avoir à repenser le système. La même solution s’applique, puisque la configuration portable et gérée par contrôle de version donne à cette stratégie de sortie un élément concret sur lequel s’appuyer. 

Notre article sur la stratégie de sortie DORA aborde ce sujet en détail.

Foire aux questions (FAQ)

La conformité doit-elle forcément ralentir les livraisons logicielles ?
Non. Les livraisons ralentissent lorsque les preuves de conformité sont rassemblées manuellement et que cette tâche se répète à chaque cycle d’audit. Lorsque les contrôles d’infrastructure sont intégrés à la plateforme et que les preuves sont enregistrées automatiquement au fur et à mesure des changements, cette partie de la préparation aux audits cesse d’imposer une pause dans la livraison.

Pourquoi les audits ralentissent-ils les équipes d’ingénierie ?
Parce que les audits détournent les ingénieurs de leur travail sur les fonctionnalités pour qu’ils produisent manuellement des preuves : collecter des captures d’écran, vérifier la configuration et prouver que l’environnement de test correspond à la production. Le retard vient du travail manuel de collecte des preuves, pas de la vitesse à laquelle l’équipe écrit du code.

Qu’est-ce que la conformité héritée ?
C’est un modèle dans lequel une plateforme sécurisée par défaut gère et atteste les contrôles au niveau de l’infrastructure, de sorte que ton équipe est responsable de son propre code d’application, du contrôle d’accès et du traitement des données. Tu commences un audit avec cette partie de l’ensemble de contrôles déjà vérifiée et documentée, plutôt que de devoir la reconstituer.

Peux-tu respecter les exigences PCI DSS ou SOC 2 sans ralentir le déploiement ?
Tu peux supprimer la partie de l’audit liée aux preuves d’infrastructure en déployant sur une infrastructure déjà certifiée et en laissant la plateforme générer la piste d’audit. Ça réduit la charge de travail manuel liée aux preuves et restreint la portée de l’audit, même si le code de ton application, les contrôles d’accès et le traitement des données restent sous ta responsabilité.

Comment la DORA influence-t-elle la manière dont les équipes des services financiers développent leurs solutions ?
En vertu de l’article 28, paragraphe 8, la DORA exige des entités financières qu’elles mettent en place des stratégies de sortie documentées pour les services TIC qui prennent en charge des fonctions critiques ou importantes, et que celles-ci soient testées et révisées périodiquement. C’est difficile à prouver lorsque les déploiements sont liés à des services spécifiques à un fournisseur. Une configuration portable et gérée par versions offre aux équipes un plan de sortie concret, même si une stratégie de sortie complète nécessite également une planification de la migration.