Conformité et audit : la preuve comme effet de bord

SchemaBridge Team · 2026-01-24 · Compliance, SOC2, GDPR, Security

Faciliter la collecte de preuves SOC2 et l'effacement RGPD grâce à un historique d'exécution enregistré, en restant précis sur ce qu'il ne garantit pas.

La taxe de conformité : pourquoi les audits vous ralentissent

Si vous avez déjà traversé un audit SOC2, ISO27001 ou HIPAA, vous connaissez la douleur. L'auditeur demande : « Montrez-moi la preuve que chaque demande de départ d'un utilisateur a été traitée en moins de 24 heures. »

Dans un système traditionnel, cela déclenche une chasse au trésor frénétique.

Vous fouillez les journaux de messagerie.
Vous faites un grep dans Splunk à la recherche d'un message « Deleted User ».
Vous faites des captures d'écran d'un ticket JIRA.
Vous recoupez des horodatages dans un tableur.

Cette collecte manuelle de preuves peut engloutir des semaines de temps d'ingénierie. C'est la taxe de conformité. Elle détourne vos meilleurs éléments du développement de fonctionnalités. Pire encore, les preuves sont souvent indirectes. Vous pouvez prouver qu'un script a tourné, mais pouvez-vous prouver exactement quelles données il a touchées ?

La piste d'audit : la preuve comme effet de bord

Chez SchemaBridge, nous pensons que la preuve doit être un effet de bord de l'exécution, et non une activité distincte. Le moteur écrit une piste d'audit au fil de son travail : démarrages, rejeux et résolutions par un opérateur des exécutions, modifications des workflows, des vertices et des arêtes, déploiements, changements de configuration et de rétention, changements de permissions et de rôles, et décisions d'approbation.

Ce que la piste vous apporte

Transitions d'état enregistrées : l'état d'une exécution réside dans PostgreSQL et est mis à jour au fil de sa progression ; à côté, chaque transition d'état est ajoutée à une trace d'exécution, si bien que « comment en sommes-nous arrivés là ? » trouve une réponse après coup. La piste d'audit enregistre le démarrage de l'exécution et toute action d'un opérateur sur celle-ci, pas chaque transition.
Traçabilité : pour toute exécution, vous pouvez inspecter l'entrée et la sortie enregistrées de chaque étape (dans la limite de votre fenêtre de rétention). Notez la distinction : dans SchemaBridge, Replay réexécute un workflow sous une nouvelle exécution, effets de bord compris ; ce n'est pas une relecture historique en lecture seule.
Historique interrogeable : la piste d'audit est interrogeable par workspace et par workflow via l'API, et elle réside dans un stockage colonnaire dédié (ClickHouse, derrière un service d'audit interne), séparé de la base de données opérationnelle.

Ce qu'elle n'est pas

Soyez précis avec votre auditeur quant aux garanties. La piste d'audit est en ajout seul au niveau applicatif, mais elle n'est pas inviolable de manière vérifiable : il n'y a ni chaîne de hachage ni signature, et les écritures d'audit sont best-effort, si bien qu'un échec d'écriture n'apparaît pas comme une lacune détectable. Si vous avez besoin de preuves de niveau WORM, exportez la piste vers un stockage à écriture unique que vous contrôlez.

RGPD et le « droit à l'oubli »

L'un des défis les plus ardus pour tout système qui conserve un historique est le « droit à l'oubli » (article 17 du RGPD). Si vous conservez un historique, comment supprimez-vous les PII (données à caractère personnel) d'un utilisateur ?

Effacement et rétention

SchemaBridge aborde ce problème avec des chemins d'effacement et des fenêtres de rétention.

1. Effacement : la suppression d'un workspace emprunte un chemin d'effacement dédié, adossé à un registre d'obligations consigné avant la suppression irréversible et vérifié ensuite ; un chemin distinct efface les données d'un utilisateur individuel.

2. Purge automatisée : les fenêtres de rétention sont définies par workspace (ou héritées de votre plan). Les lignes d'exécution, traces et payloads arrivés à échéance sont supprimés automatiquement.

3. Masquage des identifiants : les champs ayant la forme d'identifiants (clés d'API, secrets, jetons) sont masqués sous la forme dans les journaux d'exécution. Le masquage des PII n'est pas* automatique ; la meilleure défense consiste donc à ne pas faire transiter de données personnelles par des étapes qui n'en ont pas besoin.

Automatiser la collecte de preuves SOC2

Vous pouvez utiliser des workflows SchemaBridge pour automatiser une partie de l'audit lui-même.

Le « bot auditeur »

Au lieu de collecter des captures d'écran à la main, vous créez un workflow spécialisé de « Collecte de preuves » qui s'exécute selon une planification cron chaque lundi.

1. Analyser : il interroge l'API GitHub pour lister toutes les PR fusionnées la semaine précédente.

2. Vérifier : il contrôle que chaque PR a reçu une revue « Approved » d'un code owner.

3. Instantané : il produit un instantané JSON de l'état de conformité.

4. Archiver : il écrit l'instantané dans un stockage lisible par vos auditeurs (via un endpoint HTTP que vous contrôlez, idéalement un stockage à écriture unique).

Quand l'auditeur arrive, vous l'orientez vers l'archive plutôt que vers une pile de captures d'écran, et le temps de préparation de l'audit diminue d'autant.

{
  "week": "2026-W03",
  "mergedPullRequests": 42,
  "withCodeOwnerApproval": 42,
  "exceptions": []
}

Scénario illustratif : l'admission de patients dans un environnement réglementé

Prenons une startup HealthTech hypothétique qui doit automatiser ses formulaires d'admission de patients.

Le défi

Elle doit démontrer que :

1. Seul le personnel autorisé pouvait modifier ou exécuter le workflow d'admission.

2. Chaque modification du workflow et chaque résultat d'exécution ont été enregistrés.

3. Les données n'ont jamais été exposées à des outils de journalisation tiers (Splunk/Datadog).

L'approche

1. Accès basé sur les rôles : les rôles de workspace (admin, writer, reader) et les périmètres de permissions limitent qui peut modifier, déployer et exécuter le workflow, et chaque changement de rôle est consigné dans la piste d'audit.

2. Exécutions enregistrées : le démarrage de chaque exécution d'admission et toute résolution par un opérateur figurent dans la piste d'audit, l'historique complet des statuts réside dans l'historique des exécutions, et le payload de chaque étape est consultable dans la plateforme au lieu d'être écrit sur stdout.

3. Les lacunes qui leur incomberaient encore : SchemaBridge ne journalise pas qui a consulté un payload, ne propose aucun rôle spécifique à HIPAA et ne détient aucune certification HIPAA. La journalisation des accès par consultation et la paperasse réglementaire resteraient de leur responsabilité.

Le bénéfice probable

Une telle configuration rendrait nettement moins pénibles les volets d'un audit consacrés à la gestion des changements et à l'historique des exécutions, tout en restant honnête sur ce que la plateforme ne couvre pas.

Comparaison : journalisation traditionnelle vs piste d'audit SchemaBridge

| :--- | :--- | :--- | :--- |

Checklist d'expert pour une architecture de conformité

1. Ne journalisez pas de PII : faites attention à ce que vous affichez sur stdout et à ce que vous transmettez entre les étapes. Tenez les données personnelles à l'écart des payloads qui n'en ont pas besoin.

2. Automatisez les preuves : si vous le faites à la main, vous ferez des erreurs. Scriptez l'audit.

3. Séparez les fonctions : la personne qui écrit le workflow ne devrait pas être celle qui détient les clés d'administration.

4. Testez la suppression : exécutez régulièrement des « demandes RGPD fictives » pour vérifier que vos chemins d'effacement et de rétention fonctionnent réellement.

5. Connaissez les limites de votre plateforme : demandez à chaque fournisseur, nous compris, ce qui est enregistré exactement, pendant combien de temps, et si c'est inviolable de manière vérifiable. Intégrez les réponses à la description de vos contrôles.

Conclusion : la confiance est une API

La conformité n'est pas une affaire de paperasse ; c'est une affaire de confiance. En bâtissant vos systèmes sur un socle d'historique enregistré et interrogeable, et en étant précis sur ce que cet historique garantit ou non, vous passez de « Faites-moi confiance, je suis un bon ingénieur » à « Voici la preuve ».

Fait partie de notre série Building the Bridge. Voir aussi : L'avenir de l'intégration.