Depuis 2022, il est difficile d'assister à une conférence GRC sans entendre la proposition suivante : « Pour garantir l'immuabilité de votre piste d'audit, utilisez la blockchain. » L'argument semble solide. Les journaux d'audit doivent être inviolables, la blockchain est par définition résistante à la modification — la conclusion paraît logique. Sauf qu'elle ne l'est pas, dans la majorité des contextes réels. Dans les cinq cas d'usage les plus fréquemment cités par les équipes de conformité, la blockchain résout un problème théorique tout en en créant plusieurs pratiques. Voici l'analyse.
Le problème de départ : l'immuabilité est mal définie
Avant d'évaluer les cas d'usage, il faut clarifier ce que « immuabilité » signifie dans un contexte d'audit réglementaire. Pour NIS2, DORA, et le RGPD, l'exigence n'est pas que les logs soient techniquement impossibles à modifier. C'est qu'ils soient conservés de manière intègre, avec une traçabilité qui permettrait de détecter toute altération et d'en établir la responsabilité. Ces deux définitions mènent à des solutions très différentes.
Un log horodaté, signé cryptographiquement, stocké en WORM (Write Once Read Many) dans un cloud souverain avec contrôle d'accès strict et journalisation des accès répond à l'exigence réglementaire. Il est auditable, défendable devant un contrôleur, et son intégrité est vérifiable. Une blockchain privée avec trois nœuds gérés par la même entreprise ne répond pas à l'exigence — parce que l'immuabilité d'une blockchain privée est aussi solide que la gouvernance de ceux qui la contrôlent.
Cas 1 — Journaux de conformité RGPD (registre des traitements, consentements)
Le registre des traitements et les logs de consentement sont les candidats les plus fréquemment cités pour une solution blockchain. L'argument : en cas de litige avec la CNIL, prouver qu'un consentement a bien été recueilli à une date précise devient irréfutable. En pratique, trois problèmes émergent.
Premier problème : la blockchain stocke des hashes, pas les données. Pour prouver le consentement d'un utilisateur spécifique, vous devez toujours conserver les données correspondantes off-chain et démontrer que le hash correspond. La preuve repose donc sur la chaîne de custody des données off-chain — exactement ce qu'une bonne base de données relationnelle avec audit log signé offre, sans la complexité supplémentaire.
Deuxième problème : le droit à l'effacement (Article 17 RGPD) est structurellement incompatible avec l'immuabilité blockchain. Vous ne pouvez pas inscrire une donnée personnelle — même hashée — dans une structure immuable sans créer un conflit de conformité potentiel. Les workarounds (chiffrement + destruction de clé) fonctionnent, mais ajoutent une couche d'ingénierie qui annule le bénéfice perçu de simplicité.
Troisième problème : la CNIL n'a jamais reconnu la blockchain comme preuve de consentement supérieure à un audit log conventionnel. Ce qui compte dans un contrôle, c'est la qualité de la documentation et la traçabilité opérationnelle — pas la technologie sous-jacente.
Cas 2 — Piste d'audit DORA pour les accès ICT critiques
DORA impose une traçabilité des accès aux systèmes ICT critiques, notamment pour les arrangements tiers. Plusieurs fournisseurs proposent des solutions blockchain pour « garantir » cette piste d'audit aux régulateurs. Le problème fondamental : DORA exige que la piste d'audit soit complète et accessible aux autorités de contrôle dans des délais définis. Une blockchain privée gérée par un prestataire tiers crée une dépendance critique sur l'accès à cette infrastructure pour satisfaire aux obligations de reporting. Si le prestataire cesse son activité ou si l'accès est interrompu, votre piste d'audit disparaît.
La solution réglementairement solide : un SIEM on-premise ou cloud souverain, avec rétention longue durée, chiffrement au repos, contrôle d'accès strict, et export standardisé. L'ABE (Autorité Bancaire Européenne) dans ses guidelines DORA ne fait aucune référence à la blockchain comme technologie préférée — elle parle de « systèmes robustes de journalisation ».
Cas 3 — Traçabilité de la chaîne d'approvisionnement (supply chain)
C'est le cas d'usage où la blockchain a le plus de sens — et pourtant, même ici, les résultats empiriques sont décevants. Le projet TradeLens (IBM + Maersk), abandonné en 2022 après six ans de développement, est l'exemple canonique : la technologie fonctionnait, mais la gouvernance multi-parties (qui contrôle les nœuds ? qui valide les transactions ?) était insoluble sans un niveau de confiance inter-organisationnelle que la blockchain était censée rendre superflu.
Pour les directions GRC en PME et mid-market, le problème est encore plus direct : vos fournisseurs de rang 2 et 3 ne vont pas implémenter un nœud blockchain pour participer à votre réseau de traçabilité. Une API standardisée avec signature des livraisons et stockage centralisé résout le problème pratique sans nécessiter l'adhésion de l'ensemble de votre supply chain à une infrastructure commune.
Cas 4 — Preuves d'audit interne pour les comités et conseils d'administration
Plusieurs DSI présentent la blockchain comme un moyen de « prouver au conseil » que les contrôles ont bien été exécutés. C'est confondre la question technique (est-ce que les logs sont intègres ?) avec la question de gouvernance (est-ce que le conseil fait confiance à la DSI ?). Si un conseil d'administration exige une blockchain pour croire que ses contrôles internes fonctionnent, le problème n'est pas technologique — c'est un problème de gouvernance et de confiance organisationnelle qu'aucune technologie ne résout.
Les frameworks d'audit interne reconnus (IIA, COSO) évaluent la qualité des preuves sur leur traçabilité, leur complétude, et leur indépendance — pas sur la technologie de stockage. Un rapport d'audit signé par un commissaire aux comptes ou un auditeur externe indépendant a plus de valeur probante qu'un hash sur une blockchain privée.
Cas 5 — Conformité NIS2 : notification et preuve d'incident
NIS2 impose une notification à l'ANSSI dans les 24 heures suivant la détection d'un incident significatif. Certaines solutions proposent d'enregistrer cette notification sur blockchain pour en prouver le moment précis. Le problème : l'ANSSI dispose de ses propres systèmes de réception horodatés. La preuve d'une notification NIS2 dans les délais s'établit via l'accusé de réception de l'autorité — pas via une blockchain que vous contrôlez vous-même. Un timestamp blockchain généré par vos propres systèmes n'a aucune valeur probante supérieure à un email envoyé au bon destinataire avec en-têtes de messagerie complets.
Ce qui fonctionne réellement
L'immuabilité des pistes d'audit ne nécessite pas de blockchain. Elle nécessite trois choses : une architecture de stockage en écriture seule (WORM, object lock S3, etc.), une signature cryptographique des logs à la création, et une gouvernance d'accès qui sépare les équipes opérationnelles des équipes de sécurité. Ces trois éléments combinés produisent une piste d'audit défendable devant n'importe quel régulateur européen, sans la complexité de gouvernance, les coûts d'infrastructure, et les dépendances technologiques d'une solution blockchain.
La question à poser avant tout projet blockchain n'est pas « est-ce que la blockchain pourrait résoudre ce problème ? » — elle pourrait, dans un sens technique. La question est : « quel problème spécifique de gouvernance ou de confiance inter-organisationnelle une infrastructure conventionnelle ne peut-elle pas résoudre ? » Si la réponse n'est pas précise, la solution conventionnelle est presque toujours la bonne.
Presidio intègre une piste d'audit réglementaire conforme NIS2/DORA sans blockchain — voir notre analyse sur les exigences contractuelles DORA. Pour évaluer l'architecture de votre piste d'audit : contactez-nous.
Conclusion
La blockchain est une réponse à un problème de confiance entre des parties qui ne se font pas confiance. Dans un contexte GRC interne ou réglementaire, le problème de confiance est différent : il s'agit de prouver à une autorité externe que vos systèmes ont fonctionné comme prévu. Pour ce problème, les solutions conventionnelles — bien implémentées — sont plus robustes, plus accessibles, et plus défendables. Les organisations qui investissent dans une blockchain de conformité avant d'avoir une architecture de logs signés, chiffrés, et à rétention longue durée ont inversé les priorités.