Construire un journal d'audit conforme à DORA avec les webhooks Didit (FR)

Le Digital Operational Resilience Act (DORA) pose aux entités financières une question d'une difficulté trompeuse : pouvez-vous prouver ce qui s'est passé ? Lorsqu'un superviseur enquête sur un incident, lorsqu'un auditeur échantillonne vos contrôles, ou lorsqu'un client conteste une décision d'intégration, vous avez besoin d'un enregistrement — complet, horodaté et infalsifiable — de chaque événement dans vos systèmes de Technologies de l'Information et de la Communication (TIC). La vérification d'identité est l'un de ces systèmes, et elle génère précisément les événements que vous devez capturer.

Ce billet est le plus pratique : comment transformer les webhooks de vérification et de transaction de Didit en un journal d'audit conforme à DORA, quoi stocker, et comment le rendre résistant à l'examen. Il comprend un exemple de webhook détaillé sur lequel vous pouvez vous baser dès aujourd'hui.

Points clés à retenir

• DORA attend des preuves — un enregistrement fiable des événements TIC pour la réponse aux incidents, les tests de résilience et l'examen de la supervision.
• Didit émet des événements webhook à chaque changement d'état significatif : status.updated, data.updated, transaction.status.updated et business.status.updated.
• Chaque événement est un fait discret et horodaté que vous ajoutez à un journal immuable — la pierre angulaire d'un journal d'audit.
• Vérifiez la signature de chaque webhook, stockez la charge utile brute et ne modifiez jamais un enregistrement journalisé — la règle est l'ajout seul.
• Les propres contrôles de Didit soutiennent le journal : SOC 2 Type 1 (ATOM), ISO/IEC 27001:2022 (cert n° ES144068) et iBeta Level 1 PAD — assurance au niveau du fournisseur pour votre registre des tiers TIC.
• Le résultat satisfait à la fois l'enregistrement des événements que DORA souhaite et la preuve d'identité qui sous-tend le contrôle d'accès.

Ce que la norme exige

DORA repose sur cinq piliers : la gestion des risques TIC, la déclaration des incidents, les tests de résilience opérationnelle numérique, le partage d'informations et la gestion des risques des tiers TIC. Un journal d'audit est le tissu conjonctif qui les relie. Plus précisément, les entités financières doivent :

• Détecter, enregistrer et signaler les incidents liés aux TIC — ce qui présuppose un enregistrement suffisamment granulaire pour reconstituer ce qui s'est passé.
• Tester la résilience, y compris la capacité à tracer les transactions et les événements à travers le système.
• Gérer les risques liés aux tiers, y compris les enregistrements provenant d'un fournisseur comme un fournisseur de vérification d'identité.
• Conserver les enregistrements sous une forme que les superviseurs peuvent demander et sur laquelle ils peuvent se fier.

Les exigences implicites d'un journal d'audit utilisable en découlent : les événements doivent être complets (pas de lacunes silencieuses), précis (fidèles à ce qui s'est produit), classés par ordre chronologique (avec des horodatages fiables), attribuables (liés à un sujet et à un acteur) et infalsifiables (vous pouvez prouver qu'un enregistrement n'a pas été modifié après coup).

Pourquoi c'est important

Lorsqu'un incident se produit — une prise de contrôle de compte suspectée, une vérification contestée, une transaction signalée — la différence entre un événement maîtrisé et un problème réglementaire réside souvent dans la qualité de vos enregistrements. Un journal complet vous permet de reconstituer la séquence, de prouver que vos contrôles ont fonctionné comme prévu et de démontrer à un superviseur que vous avez géré la situation correctement. Un journal incomplet vous laisse dans l'incertitude et ne convainc pas le superviseur.

Les événements d'identité sont très importants ici car ils se situent à la frontière du système : le moment où une personne est vérifiée, revérifiée ou dont le statut change est exactement le moment où vous souhaitez le plus qu'un enregistrement soit fait. Capturer ces événements au fur et à mesure qu'ils se produisent — plutôt que de les reconstituer plus tard à partir des journaux d'application — transforme « nous pensons que c'est ce qui s'est passé » en « voici ce qui s'est passé ».

Comment Didit aide

Didit émet un webhook pour chaque transition d'état dans une session de vérification, de transaction ou d'affaires. Vous ne sondez pas ; vous recevez un événement signé au moment où quelque chose change.

Événement	Se déclenche quand	Valeur d'audit
status.updated	Le statut d'une session de vérification change (par ex. en Approuvé, Refusé, En révision)	Enregistre la décision et son horodatage
data.updated	Les données vérifiées d'une session changent	Enregistre ce qui a été capturé/modifié
transaction.status.updated	Le statut d'une transaction surveillée change	Enregistre les décisions de surveillance et les résolutions des analystes
business.status.updated	Le statut d'une entité commerciale KYB change (ACTIVE/FLAGGED/BLOCKED)	Enregistre les résultats de l'intégration commerciale

Chaque événement est un fait autonome. Votre tâche est de le vérifier, de le stocker tel quel et de ne jamais le modifier. Ensemble, ces événements forment un registre à ajout seul de tout ce que Didit a fait en votre nom — le journal d'audit que DORA souhaite pour la partie vérification d'identité de votre parc TIC.

Et parce que Didit lui-même est attesté — SOC 2 Type 1 (ATOM, au 09-04-2026), ISO/IEC 27001:2022 (Bureau Veritas, cert n° ES144068, valide jusqu'au 03-06-2027) et iBeta Level 1 PAD — le fournisseur derrière ces événements apporte ses propres preuves pour votre registre des tiers TIC DORA.

Approfondissement : transformer un webhook en enregistrement d'audit

Voici un webhook status.updated pour une session de vérification qui vient d'être résolue à Approved :

{
  "event": "status.updated",
  "session_id": "sess_7b21e0c4",
  "vendor_data": "user_4521",
  "status": "Approved",
  "previous_status": "In Review",
  "workflow_id": "wf_kyc_eu_substantial",
  "checks": {
    "id_verification": "passed",
    "passive_liveness": "passed",
    "face_match": "passed"
  },
  "created_at": "2026-05-21T10:32:04Z",
  "signature": "t=1747824724,v1=9f86d081884c7d659a..."
}

Pour en faire un enregistrement d'audit conforme à DORA, effectuez quatre actions à la réception :

1. Vérifiez la signature. Recalculez le HMAC sur le corps de la requête brute en utilisant le secret de signature de votre point de terminaison et comparez-le à l'en-tête signature avant de faire confiance à la charge utile. Rejetez tout ce qui échoue — un événement non vérifié n'a aucune valeur probante.
2. Stockez la charge utile brute verbatim. Persistez les octets exacts que vous avez reçus, ainsi que votre propre horodatage d'ingestion. Ne normalisez pas et ne reformatez pas avant le stockage ; l'événement brut est la preuve.
3. Ajoutez, ne mettez jamais à jour. Écrivez dans un magasin à ajout seul (ou une table sans droits UPDATE/DELETE pour le rôle de l'application). Si un événement ultérieur remplace un événement antérieur, écrivez une nouvelle ligne faisant référence à l'ancien session_id — ne jamais écraser.
4. Rendez-le infalsifiable. Hachez chaque enregistrement et chaînez le hachage au suivant (chaque ligne stocke le hachage de la ligne précédente), ou écrivez dans un magasin à écriture unique. Vous pouvez maintenant prouver que le journal n'a pas été modifié après coup.

Le résultat est un registre chronologique, attribuable et infalsifiable : pour tout session_id, vous pouvez rejouer chaque changement d'état, voir quels contrôles ont été réussis et montrer exactement quand la décision a été prise — et prouver que l'enregistrement n'a pas été modifié depuis. C'est la norme qu'un superviseur ou un auditeur recherche, et c'est le même modèle que vous appliqueriez à transaction.status.updated pour les décisions de surveillance et à business.status.updated pour les résultats KYB.

Cas d'utilisation

• Banques et EMI construisant un journal d'événements TIC conforme à DORA qui inclut les décisions d'identité.
• PSAN crypto qui doivent prouver les décisions d'intégration et de surveillance des transactions aux superviseurs.
• Équipes de conformité se préparant aux tests de résilience qui tracent les événements de bout en bout.
• Équipes d'ingénierie remplaçant le polling fragile par une ingestion d'événements signés et à ajout seul.

Questions fréquemment posées

Quels événements webhook dois-je capturer pour un journal d'audit ?

Au minimum status.updated et data.updated pour les vérifications ; ajoutez transaction.status.updated pour la surveillance des transactions et business.status.updated pour le KYB. Capturez chaque événement — la complétude est le but.

Dois-je vérifier les signatures des webhooks ?

Oui. Un webhook non vérifié pourrait être usurpé et n'aurait aucune valeur probante. Recalculez la signature sur le corps brut et rejetez les non-concordances avant de journaliser.

Pourquoi à ajout seul ? Ne puis-je pas simplement mettre à jour un enregistrement lorsque le statut change ?

DORA valorise l'infalsifiabilité. Si vous écrasez des enregistrements, vous ne pouvez pas prouver que l'historique n'a pas été modifié. L'ajout d'un nouvel événement pour chaque changement préserve la séquence complète et prouvable.

La capture des événements Didit satisfait-elle toutes les exigences de DORA ?

Non — DORA est vaste. Les événements de Didit couvrent la partie vérification d'identité et surveillance de votre parc TIC. Vous les combinerez avec les journaux du reste de vos systèmes pour un journal complet.

Didit dispose-t-il de ses propres attestations pour le registre des tiers DORA ?

Oui — SOC 2 Type 1 (ATOM), ISO/IEC 27001:2022 (cert n° ES144068, valide jusqu'au 03-06-2027) et iBeta Level 1 PAD, tous disponibles pour soutenir votre diligence raisonnable envers les fournisseurs.

Prêt à commencer ?

Consultez les attestations de Didit sur le centre de confiance, lisez les détails d'intégration des webhooks dans la documentation et examinez les tarifs transparents sur la page des prix. Lorsque vous êtes prêt, commencez gratuitement — 500 vérifications KYC gratuites chaque mois, avec un flux de vérification de base à partir de 0,33 $.