Depuis janvier 2025, le règlement sur la résilience opérationnelle numérique (DORA) s’applique aux banques, assureurs, entreprises d’investissement, établissements de paiement et à la plupart de leurs prestataires ICT critiques dans l’UE. On présente souvent DORA comme un texte de cybersécurité. En pratique, une grande partie de ses exigences atterrit directement sur votre plateforme data, parce que c’est là que l’information critique vit, circule et se transforme.
Ce que DORA demande vraiment à une plateforme data
Une fois le langage juridique décanté, il reste quatre exigences :
1. Connaître et maîtriser ses tiers ICT. L’article 28 impose un registre de tous les contrats de services ICT et un examen sérieux du risque de concentration. Une plateforme data qui vous enferme chez un fournisseur non européen, sans sortie réaliste, est exactement la dépendance que DORA vous demande de gérer.
2. Prouver la résilience opérationnelle. Vous devez comprendre comment une panne se propage, récupérer dans des délais définis, et tester cette récupération. Cela suppose de savoir précisément quels jeux de données alimentent quelles fonctions critiques : autrement dit, du lineage.
3. Tenir une piste d’audit qui satisfait un superviseur. Quand le régulateur demande qui a accédé à quoi, quand, et ce qui en a été fait, « on peut sortir les logs via un ticket » n’est pas une réponse. Un audit continu, requêtable et exportable, oui.
4. Avoir une stratégie de sortie crédible. L’article 28(8) est explicite : les contrats ICT critiques exigent des plans de sortie documentés. Si vos données sont piégées dans un format propriétaire à l’intérieur du périmètre d’un éditeur, votre plan de sortie est une fiction.
Le test de la stratégie de sortie
Le moyen le plus rapide d’évaluer une plateforme face à DORA tient en une question : que se passe-t-il le jour où vous décidez de partir ?
- Si la réponse implique un projet de migration pluriannuel, des outils d’export propriétaires et la bonne volonté de l’éditeur, vous avez un risque de concentration à déclarer.
- Si la réponse est « nos tables sont en Apache Iceberg ouvert sur notre propre stockage objet, n’importe quel moteur les lit demain », vous avez un plan de sortie que vous pouvez réellement écrire.
Sous DORA, les formats ouverts ne sont pas une préférence technique. Ce sont un instrument de conformité.
Checklist DORA pour votre stack data
| Attente DORA | Ce qu’il faut chercher |
|---|---|
| Registre ICT & risque de concentration | Bring-your-own-cloud, entités opératrices européennes, aucun point unique de défaillance juridictionnelle |
| Résilience & récupération | Snapshots et time travel sur les tables, runs reproductibles, RTO documenté |
| Audit | Journal complet des actions avec acteur et horodatage, exportable vers un stockage qui vous appartient |
| Lineage | Capturé automatiquement depuis les requêtes et les jobs, pas maintenu à la main |
| Stratégie de sortie | Formats de tables ouverts, données sur votre propre bucket, offboarding documenté |
Où se situe Polnor
Polnor a été conçu avec ces réponses intégrées plutôt que rajoutées. La plateforme tourne sur votre propre compte OVHcloud ou Scaleway : la dépendance d’infrastructure reste sous votre contrat et votre juridiction. Chaque action atterrit dans un journal d’audit exportable toutes les heures vers votre propre S3. Le lineage au niveau colonne est enregistré automatiquement depuis chaque requête, job et notebook. Et comme vos tables sont en Iceberg ouvert sur votre bucket, le chapitre « stratégie de sortie » de votre dossier DORA s’écrit tout seul.
Si DORA est sur votre feuille de route cette année, demandez une démo : nous passerons vos flux critiques au crible de la checklist ci-dessus.