Arrête de rassembler manuellement les preuves d'audit : génère-les à chaque déploiement

Dans chaque programme de conformité, il y a forcément quelqu’un qui passe la semaine précédant un audit à extraire des journaux de plusieurs systèmes différents, à reconstituer qui avait accès à quoi, et à espérer que les captures d’écran correspondent à ce que l’auditeur demande réellement. Aucun de ces travaux ne rend le système plus sûr. Ça rend simplement la sécurité existante visible pour celui qui vérifie.

C’est dans cet écart, entre les contrôles réellement en place et les preuves qui le démontrent, que s’investit la majeure partie du temps de préparation à l’audit. Combler cet écart n’est pas un problème de documentation. C’est une question de savoir où les preuves sont générées dès le départ.

Pourquoi les preuves d’audit impliquent généralement une reconstitution manuelle

Point clé : la plupart des preuves de conformité existent déjà quelque part dans tes systèmes. Le travail ne consiste pas à les créer, mais à les trouver, à les mettre en forme et à t’assurer qu’elles correspondent bien à ce qui s’est passé.

Les journaux d’accès se trouvent dans un outil. L’historique des déploiements se trouve dans ton système de CI. Les modifications de configuration peuvent être dans Git, dans une console où quelqu’un a cliqué, ou encore dans un fil de discussion Slack où quelqu’un a approuvé une exception il y a trois mois. Il ne s’agit pas d’informations manquantes. Ce sont des informations dispersées, et les rassembler pour en faire un ensemble qu’un auditeur peut réellement examiner est une tâche manuelle, répétitive et tout à fait évitable que quelqu’un refait à chaque cycle d’audit.

Le mode de défaillance prévisible, ce n’est ni la fraude ni la négligence. C’est la dérive. Un contrôle correctement configuré en janvier est ajusté en mars pour une exception ponctuelle, et personne ne met à jour le document indiquant que ce contrôle est toujours appliqué. Au moment de l’audit, les preuves rassemblées par quelqu’un ne sont qu’un instantané de ce dont les gens se souviennent comme étant vrai, et non un enregistrement de ce qui était réellement vrai tout au long de la période.

Ce qui change quand la conformité est une propriété de la plateforme, et non une étape du processus

Point clé à retenir : déployer sur une infrastructure déjà certifiée pour les principaux référentiels signifie que les contrôles fondamentaux ne sont pas quelque chose que tu configures projet par projet. Ils sont déjà en place, même si la conformité au niveau de l’application reste de la responsabilité de ton équipe.

Upsun Cloud est certifié ISO/IEC 27001:2022, dispose d’un rapport SOC 2 Type 2 annuel couvrant la sécurité, la disponibilité et la confidentialité, et est un prestataire de services PCI DSS de niveau 1. Les charges de travail HIPAA sont prises en charge dans le cadre d’un accord de partenariat commercial (Business Associate Agreement) pour la région US-4. Ça va bien au-delà du certificat en lui-même. 

Selon le rapport 2026 d’IBM sur le coût des fuites de données, le coût moyen mondial d’une fuite a atteint le chiffre record de 4,99 millions de dollars, soit une hausse de 12 % par rapport à l’année précédente. Le secteur de la santé reste le plus coûteux, avec 6,64 millions de dollars par violation, contre 7,42 millions l’année précédente. La certification d’une infrastructure déjà conçue selon ces référentiels n’est pas juste une case à cocher pour la conformité. C’est une couche de moins que ton équipe doit mettre en place, exploiter et justifier toute seule.

Il s’agit d’un modèle de responsabilité partagée, et ça vaut le coup d’être précis sur la répartition. Le projet hérite de la posture certifiée de la plateforme sous-jacente pour les contrôles d’infrastructure fondamentaux : sécurité physique, correctifs du système d’exploitation, chiffrement des données en transit, journalisation d’audit de base. Ton équipe reste responsable de ce qui se trouve au-dessus : le code sécurisé des applications, la logique d’autorisation des utilisateurs, l’authentification des API et la sécurité de tes propres dépendances. Au lieu qu’une équipe doive monter son propre dossier de conformité pour les contrôles d’infrastructure de base à partir de zéro, cette couche fondamentale est déjà assurée. Ce qui nécessite encore le jugement de ton équipe, c’est tout ce qui est spécifique à ton application.

D’où proviennent réellement les preuves d’audit

Point clé : chaque déploiement, chaque poussée de code et chaque modification de configuration est automatiquement consigné dans le cadre du fonctionnement normal, et non comme un exercice distinct de suivi de la conformité, même si les preuves les plus solides consistent à associer ces journaux à ton processus de validation existant.

C’est cette partie-là qui te fait réellement gagner les heures que quelqu’un passe actuellement la semaine précédant un audit. Sur Upsun Cloud, chaque déploiement, chaque push de code et chaque modification de configuration est automatiquement consigné au fur et à mesure. Il ne s’agit pas d’une fonctionnalité de conformité rajoutée à la plateforme, mais de la plateforme faisant ce qu’elle fait de toute façon : enregistrer ce qui a changé, quand et qui l’a modifié.

Concrètement, ça veut dire que les certifications, les matrices de responsabilité et les rapports d’audit demandés par un auditeur sont disponibles dans le Trust Center ou sur simple demande, au lieu d’être rassemblés à partir de plusieurs systèmes pendant des semaines. Les preuves ne sont pas reconstituées après coup à partir de souvenirs et de journaux épars. C’est un enregistrement continu qui existe déjà, parce que la plateforme a tout suivi depuis le début. Quand un auditeur demande un historique de toutes les modifications de configuration apportées à un environnement sur une période donnée, cet historique est récupérable via l’API et l’interface en ligne de commande (CLI), plutôt que d’être reconstitué. Les activités périmées sont supprimées du journal d’activité du projet au fil du temps ; les équipes qui ont besoin de preuves sur plusieurs années doivent donc transférer les journaux vers leur propre système de conservation. 

C’est de plus en plus important chaque année : une étude d’IBM de 2026 a révélé que 68 % des entreprises victimes de violations de données n’avaient pas mis en place de politique de gouvernance de l’IA ou étaient encore en train d’en élaborer une.

Il est important de préciser ce que cela remplace et ce que ça ne remplace pas : les journaux de la plateforme prouvent ce qui a changé, quand et par qui. Ils ne prouvent pas en eux-mêmes qu’un changement a été approuvé avant qu’il ne se produise. Associer les journaux de déploiement automatiques à ton processus de révision existant basé sur Git, où une pull request doit être approuvée par une autre personne avant d’être fusionnée, comble cette lacune : c’est à la fois le journal et la piste d’approbation que les auditeurs recherchent réellement lorsqu’ils posent des questions sur la gestion des changements, pas seulement le journal.

Les sauvegardes comme preuve de conformité, pas seulement pour la reprise après sinistre

Point clé : une posture de conformité défendable doit prouver en continu la protection des données et démontrer qu’elles peuvent réellement être restaurées, et pas seulement décrire une politique de sauvegarde sur le papier.

La capacité de sauvegarde et de restauration est un contrôle que la plupart des référentiels, y compris SOC 2 et PCI DSS, attendent d’une organisation qu’elle démontre, et pas seulement qu’elle affirme, et la démontrer signifie bien plus que simplement montrer qu’une sauvegarde a été effectuée. Les auditeurs, dans le cadre des critères de disponibilité de SOC 2, attendent la preuve que les procédures de restauration ont bel et bien été testées, et pas seulement qu’une tâche de sauvegarde s’est terminée dans les délais. 

Le rapport 2026 d’IBM souligne pourquoi c’est important : seules 37 % des organisations victimes de violations ont déclaré crypter leurs données sensibles à la fois au repos et en transit, et seulement 34 % avaient une visibilité sur leurs actifs cryptographiques. C’est justement au niveau des pratiques de base, sauvegardes comprises, que la plupart des organisations restent exposées.

Upsun Cloud effectue par défaut une sauvegarde automatisée par jour des environnements de production, conservée pendant deux jours. L’intervalle et le nombre de sauvegardes conservées sont configurables en fonction du type d’environnement ; le calendrier peut ainsi être adapté à tes obligations de conformité spécifiques plutôt que de rester sur les paramètres par défaut. 

Comme le processus de sauvegarde est automatique et cohérent, la preuve qu’il a bien eu lieu, et qu’il s’est déroulé comme prévu, découle naturellement du fonctionnement normal de la plateforme ; ce n’est pas une tâche manuelle dont quelqu’un doit se souvenir et qu’il faut consigner séparément. Les tests de restauration eux-mêmes, qui prouvent qu’une sauvegarde peut effectivement être récupérée, méritent d’être intégrés à ton propre rythme de vérification, plutôt que de partir du principe que tout est couvert par le simple fait que la sauvegarde s’exécute.

C’est un petit exemple d’une tendance plus large : un contrôle automatisé produit ses propres preuves. Un contrôle qui dépend du fait que quelqu’un se souvienne d’exécuter un script ne produit de preuves que si cette personne pense aussi à documenter qu’elle l’a exécuté.

Ce que ça signifie pour la vitesse de déploiement

Point clé : lorsque les preuves de conformité sont continues plutôt que reconstituées, les mises en production n’ont plus à attendre un processus de validation manuel qui n’existe que parce que personne ne faisait confiance aux preuves déjà disponibles.

La raison pour laquelle les exigences de conformité ralentissent les mises en production n’est généralement pas l’exigence elle-même. C’est l’étape de vérification manuelle qui existe parce que les preuves ne sont pas facilement accessibles. Une mise en production est bloquée pour un contrôle de conformité parce que quelqu’un a besoin de temps pour confirmer que les bons contrôles d’accès sont en place, que la journalisation appropriée est effectuée et que les bonnes validations ont bien été enregistrées. Si ces preuves existent déjà en continu, et si les pistes de validation sont déjà liées à l’historique de déploiement, le contrôle n’est plus une tâche de recherche, mais une simple consultation.

Ça ne veut pas dire qu’il faut supprimer l’examen. Ça veut dire qu’il faut supprimer la semaine de collecte de preuves qui doit actuellement avoir lieu avant que l’examen puisse commencer. Le service chargé de la conformité coche toujours la case, il reste responsable des décisions concernant le périmètre, les exceptions et les risques. C’est juste qu’il n’est plus celui qui rassemble les sources.

• Consulte le modèle de responsabilité partagée et le périmètre de certification dans le Centre de confiance
• Estime le coût de ta plateforme grâce au calculateur de prix

Foire aux questions (FAQ)

Est-ce que ça remplace le besoin d’une équipe de conformité ? 
Non. Les référentiels comme SOC 2 et PCI DSS nécessitent toujours un jugement humain : interpréter le périmètre, définir la politique, gérer les exceptions et établir les attestations proprement dites. Ce qui change, c’est le travail de collecte de preuves qui sous-tend ces décisions. Une équipe de conformité passe moins de temps à reconstituer ce qui s’est passé et plus de temps sur les décisions qui nécessitent réellement son expertise.

Comment ça marche sur plusieurs environnements ou dans plusieurs régions ? Les contrôles de 
conformité qui se situent au niveau de la plateforme s’appliquent de manière cohérente, quelle que soit la région ou le fournisseur sur lequel une charge de travail s’exécute. Tu peux déployer sur AWS, Azure, Google Cloud, IBM Cloud ou OVHcloud dans des régions spécifiques pour respecter les exigences de résidence des données, même si le périmètre de certification varie selon la région et le fournisseur. Certaines certifications sont spécifiques à une région : les charges de travail HIPAA et TX-RAMP, par exemple, s’exécutent spécifiquement sur la région US-4 d’Upsun Cloud ; le choix de la région doit donc tenir compte des certifications dont une charge de travail donnée a réellement besoin.

Comment ça se passe lors d’un audit réel avec ce modèle ? Les 
auditeurs peuvent obtenir la documentation de conformité à jour, les politiques de sécurité et les rapports d’audit depuis le Trust Center ou sur simple demande, plutôt que de recevoir un document que ton équipe a spécialement préparé pour cet audit. Les journaux des déploiements, des poussées de code et des modifications de configuration sont disponibles à la demande, ce qui raccourcit la phase de collecte de preuves par rapport à la reconstitution manuelle de ces mêmes enregistrements. Les auditeurs s’attendront tout de même à ce que ces journaux s’inscrivent dans ton propre processus de validation et de gestion des changements, sans pour autant le remplacer.

Le calendrier de sauvegarde est-il le même pour tous les environnements ? 
Non, il est configurable. Les environnements de production peuvent suivre un calendrier de sauvegarde différent de celui des environnements de préproduction ou de développement, et ce calendrier peut être ajusté pour correspondre à l’objectif de point de reprise (RPO) requis par ton cadre de conformité spécifique ou ta politique interne. Les tests de restauration, qui permettent de vérifier qu’une sauvegarde peut effectivement être restaurée, constituent une pratique qu’il vaut la peine d’ajouter au calendrier lui-même.

La conformité automatisée signifie-t-elle moins de contrôle sur nos politiques spécifiques ? 
Non. Les contrôles de base issus de la certification au niveau de la plateforme (chiffrement, gestion des accès, application des correctifs) constituent le minimum requis, pas le maximum. Les équipes continuent de définir leurs propres politiques d’accès, leurs processus de validation et la gestion des exceptions par-dessus cette base, et restent responsables de la conformité pour tout ce qui se trouve au niveau de la couche applicative : ton propre code, ta logique d’autorisation, tes dépendances tierces. Ce qui change, c’est que la couche d’infrastructure fondamentale n’a plus besoin d’être mise en place et validée séparément par chaque équipe sur chaque projet.