Conformité & Audit : le registre immuable
SchemaBridge Team · 2026-01-24 · Compliance, SOC2, GDPR, Security
Atteindre la conformité SOC2 et RGPD par défaut. Un historique d'exécution traçable.
La taxe de conformité : pourquoi les audits vous ralentissent
Si vous êtes déjà passé par un audit SOC2, ISO27001 ou HIPAA, vous connaissez la douleur. L'auditeur demande : « Montrez-moi la preuve que chaque demande de offboarding 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 logs d'e-mails.
- Vous faites un grep dans Splunk à la recherche d'un message « Deleted User ».
- Vous prenez des captures d'écran d'un ticket JIRA.
- Vous croisez des horodatages dans un tableur.
Cette collecte manuelle de preuves prend des semaines de temps d'ingénierie. C'est la taxe de conformité. Elle détourne vos meilleurs éléments de la construction de fonctionnalités. Et pire, les preuves sont souvent circonstancielles. Vous pouvez prouver qu'un script s'est exécuté, mais pouvez-vous prouver exactement quelles données il a touchées ?
Le registre immuable : l'audit par défaut
Chez SchemaBridge, nous pensons que la conformité devrait être un effet de bord de l'exécution, et non une activité séparée. Comme notre moteur repose sur un journal d'événements en ajout seul (append-only) (partie 1), chaque action, chaque décision et chaque changement de variable est enregistré dans un historique immuable.
La puissance de l'Event Sourcing
Nous ne stockons pas seulement l'état courant ; nous stockons l'historique complet de la façon dont nous y sommes arrivés.
- Append-only : nous n'écrasons jamais un enregistrement dans la table d'historique. Chaque changement d'état est une nouvelle ligne.
- Traçabilité : vous pouvez rejouer un workflow du début à la fin et voir exactement quelles étaient les entrées, ce que la logique a décidé, et quelles étaient les sorties à chaque étape.
- Preuve d'altération : comme le journal est séquentiel et immuable, tout écart ou toute modification ressort immédiatement.
Le RGPD et le « droit à l'oubli »
L'un des défis les plus difficiles de l'event sourcing est le « droit à l'oubli » (article 17 du RGPD). Si votre journal est immuable, comment supprimer les données personnelles (PII, Personally Identifiable Information) d'un utilisateur ?
Masquage de champs et politiques de rétention
SchemaBridge résout ce problème grâce à des politiques de rétention strictes.
1. Isolation des PII : nous encourageons les développeurs à signaler les champs sensibles dans le contexte de leur workflow.
2. Purge automatisée : vous pouvez définir des politiques de rétention (par exemple « conserver les logs pendant 30 jours ») au niveau du workflow. Le moteur purge automatiquement les anciennes données d'historique de DynamoDB pour satisfaire les exigences de confidentialité.
3. Masquage de champs : dans les logs exposés aux développeurs, les champs sensibles peuvent être masqués (***) par défaut, garantissant que les PII ne sont pas consultées à la légère pendant les sessions de débogage.
Automatiser la collecte de preuves SOC2
Vous pouvez utiliser les workflows SchemaBridge pour automatiser l'audit lui-même.
Le « bot auditeur »
Plutôt que de collecter manuellement des captures d'écran, vous créez un workflow spécialisé de « collecte de preuves » qui s'exécute tous les lundis.
1. Scan : il interroge l'API GitHub pour lister toutes les PR fusionnées la semaine précédente.
2. Vérification : il vérifie que chaque PR dispose d'une review « Approved » d'un code owner.
3. Snapshot : il prend un instantané JSON du statut de conformité.
4. Archivage : il écrit un rapport signé dans un bucket S3 WORM (Write Once, Read Many).
Lorsque l'auditeur arrive, vous lui donnez simplement un accès en lecture au bucket S3. Votre temps de préparation d'audit passe de plusieurs semaines à zéro.
Étude de cas : onboarding patient conforme HIPAA
Nous avons travaillé avec une startup HealthTech qui devait automatiser les formulaires d'admission des patients.
Le défi
Ils devaient prouver que :
1. Seuls des médecins autorisés consultaient l'historique du patient.
2. Chaque accès était journalisé.
3. Les données n'étaient jamais exposées à des outils de logging tiers (Splunk/Datadog).
La solution SchemaBridge
1. Logs d'accès : chaque fois qu'un sommet de workflow accédait à la variable patient, un « événement d'accès » générique était écrit dans le registre.
2. Logging sous coffre-fort : les données brutes n'étaient jamais envoyées vers stdout. Elles n'étaient visibles dans le dashboard SchemaBridge que par les utilisateurs disposant du rôle HIPAA_OFFICER, et même dans ce cas, chaque consultation était journalisée.
Le résultat
Ils ont réussi leur audit HIPAA sans aucune non-conformité. L'auditeur a été impressionné par la capacité à rejouer l'historique exact des accès aux données d'un patient sans jamais exposer les données elles-mêmes.
Comparaison : logging traditionnel contre conformité SchemaBridge
| Caractéristique | Syslog / Splunk | Tables d'audit en base de données | Registre SchemaBridge |
| :--- | :--- | :--- | :--- |
| Immuabilité | Faible (peut être supprimé) | Moyenne (le DBA peut modifier) | Élevée (append-only) |
| Contexte | Ligne unique | Changement de ligne | Contexte complet du workflow |
| Gestion des PII | Masquage manuel | Chiffrement de colonne | Masquage automatique |
| Rétention | Limitée (coûteuse) | Limitée (performance) | Politiques configurables |
Checklist d'expert pour l'architecture de conformité
1. Ne journalisez pas les PII : faites attention à ce que vous imprimez sur stdout. Laissez le moteur gérer la persistance de l'état de manière sécurisée.
2. Automatisez les preuves : si vous le faites manuellement, vous ferez une erreur. Scriptez l'audit.
3. Séparez les responsabilités : 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 « fausses demandes RGPD » pour vérifier que vos politiques de rétention fonctionnent réellement.
Conclusion : la confiance est une API
La conformité, ce n'est pas de la paperasse ; c'est une question de confiance. En construisant vos systèmes sur une base d'historique vérifiable et immuable, vous passez de « faites-moi confiance, je suis un bon ingénieur » à « faites confiance au système ».
Dans la partie 15, nous conclurons notre série en explorant le « Future of Integration » et la façon dont les agents IA écriront et géreront bientôt ces workflows pour nous.