Le vrai coût de DORA, c'est le temps de votre CTO

Quand on discute DORA avec un CEO, un COO ou toute autre personne qui arbitre les priorités d'une fintech, la conversation ne part presque jamais du règlement. Elle part d'un constat plus terre à terre : « notre CTO passe un temps fou là-dessus, et je ne suis pas sûr que ce soit le meilleur usage de son temps ».

C'est le bon réflexe. La question à se poser sur DORA n'est pas d'abord « sommes-nous conformes ». C'est « qui porte ce sujet en interne, et à quel prix ».

Pourquoi ça retombe toujours sur la même personne

DORA a l'air d'un sujet technique : cartographier les prestataires TIC, mettre en place des tests de résilience, classifier des incidents. Il attire donc naturellement la personne la plus à l'aise avec ce vocabulaire, CTO, head of engineering, directeur technique, parfois le CEO lui-même dans une petite équipe. Le titre exact dépend de votre organisation ; pour la suite de cet article, on l'appelle CTO, mais c'est le rôle qui compte, pas son intitulé.

Sauf que DORA n'est pas un projet technique. C'est un exercice de gouvernance qui s'appuie sur de la matière technique : un registre à tenir à jour, des politiques à rédiger, des preuves à organiser pour un superviseur. Le CTO est souvent la seule personne dans l'entreprise à la fois assez technique pour comprendre ce qu'il faut documenter, et assez transverse pour voir l'ensemble des prestataires et des processus concernés. Ce qui en fait un mauvais point de passage obligé : il a la compétence, rarement le temps, et encore plus rarement le mandat de gouvernance pour porter ça seul sans que ça déborde sur autre chose.

Résultat, un schéma qu'on retrouve chez presque toutes les fintechs qui nous contactent : le sujet avance par à-coups, entre deux sprints, porté par une personne qui n'a jamais été recrutée pour ça.

Ce que ça prend réellement

Sans mettre de chiffre dessus, parce que ça dépend trop de votre organisation pour être honnête, voici la nature du travail que le règlement demande, et pourquoi aucun de ces points ne se traite en marge d'un planning déjà plein.

• Cartographier les prestataires TIC : identifier tous les fournisseurs technologiques dont vous dépendez, cloud, sous-traitants, éditeurs tiers, et évaluer leur criticité pour votre activité. Ce travail touche toutes les équipes, pas seulement l'infrastructure.
• Tenir le registre d'information : le document que DORA impose de maintenir à jour sur ces prestataires : contrats, niveaux de service, localisation des données, sous-traitance en cascade. Ce n'est pas un fichier qu'on remplit une fois, c'est un registre vivant.
• Construire un programme de tests de résilience : des scans réguliers jusqu'au test d'intrusion, proportionnés à votre profil de risque, avec des cycles à planifier et des résultats à exploiter.
• Formaliser la gestion des incidents : un processus de détection, de classification et de notification qui tient dans les délais imposés par le règlement, pas dans les habitudes actuelles de l'équipe.

Chacun de ces chantiers demande de la rigueur documentaire autant que de la compréhension technique. C'est précisément ce mélange de compétences qui manque dans la plupart des équipes produit.

Le vrai coût n'est pas le prestataire

Face à un devis d'accompagnement, le réflexe naturel est de le comparer à un coût de mise en conformité en interne, qu'on imagine souvent gratuit puisqu'il s'agit du temps de quelqu'un déjà salarié. C'est le mauvais calcul.

Le temps que votre CTO passe à cartographier des prestataires ou à rédiger un registre d'information est du temps qui ne va nulle part ailleurs : pas dans la revue d'architecture qui traîne, pas dans le recrutement technique en cours, pas dans la feature que vos clients attendent. Ce coût-là n'apparaît sur aucune ligne budgétaire, et c'est justement ce qui le rend facile à sous-estimer. Un devis de prestataire se compare à un autre devis. Un trimestre de roadmap perdu ne se compare à rien, parce qu'il ne se voit qu'après coup, dans les délais qui glissent et les priorités qui n'ont pas avancé.

Ni l'outil ni le cabinet généraliste ne suffisent

Beaucoup de fintechs ont déjà réagi en installant un outil de conformité type Vanta ou Sprinto. C'est une bonne base : automatiser la collecte de preuves, centraliser les procédures, connecter les alertes techniques. Mais l'outil ne sait pas laquelle de ses procédures génériques réduit vraiment un risque pour vous, et laquelle n'existe que pour rassurer un superviseur qui la lira sans la contester. Ce tri-là reste un jugement humain : sans lui, la procédure reste un fardeau administratif au lieu d'apporter la valeur qu'elle est censée produire : moins d'incidents, une reprise plus rapide, des prestataires mieux choisis.

Résultat fréquent : les intégrations techniques tournent, la collecte de preuves remonte, mais personne n'a encore trouvé le temps de reprendre les procédures générées par l'outil pour qu'elles protègent vraiment votre activité, plutôt que de rester un modèle générique qui existe surtout pour remplir un questionnaire. Le chantier n'avance plus, et il retombe sur la même personne que celle qui a fait le déploiement initial.

Confier le sujet à un cabinet de conformité généraliste ne décharge pas non plus votre CTO. Ces cabinets savent produire les documents attendus par le régulateur, mais rarement cartographier vos risques TIC ou challenger un choix d'architecture, faute de comprendre assez finement votre technique. Le cabinet revient alors vers le CTO avec des questions qu'il est seul à pouvoir trancher, et la charge se retrouve juste déplacée d'un cran : au lieu de porter le sujet seul, le CTO le porte encore, en formant en plus le cabinet sur son propre système.

Ce qui change en 2026

Un point de contexte, pour poser les enjeux sans en faire un argument de peur. Après une année 2025 largement consacrée à la pédagogie, l'ACPR est entrée dans une phase de contrôle effectif de DORA : ses inspections combinent désormais analyse documentaire et tests techniques, et les premières sanctions formelles sont attendues sur l'année, avec un plafond pouvant atteindre 2 % du chiffre d'affaires mondial pour une entité financière.

Ce n'est pas une raison de paniquer. C'est une raison de ne plus traiter le sujet comme secondaire, ni de compter sur le fait que personne n'ira vérifier.

Ce qu'un accompagnement change concrètement

Ce n'est pas qu'on va plus vite. C'est qu'on déplace le travail hors du temps de votre CTO.

Nous appliquons à DORA la même méthode qui nous sert sur ISO 27001, HDS ou SOC 2 : un atelier d'une heure toutes les deux semaines, où nous cadrons ensemble ce qui doit être fait. Entre les ateliers, c'est nous qui cartographions les prestataires, rédigeons le registre d'information et les politiques, montons le programme de tests. Votre CTO valide, oriente, connecte le sujet à ses équipes quand c'est utile, mais il ne rédige pas seul un document de gouvernance en plus de tenir la roadmap.

C'est la différence entre porter le sujet et l'arbitrer. La seconde option laisse votre CTO concentré sur ce qu'il fait de mieux.

Questions fréquentes

Notre CTO ne peut-il pas simplement déléguer ça à un product manager ou un chef de projet ?

Partiellement. La coordination et le suivi documentaire peuvent être délégués, mais la cartographie des risques TIC et la classification des incidents demandent une compréhension technique réelle de votre architecture et de vos dépendances. Sans elle, on obtient un registre qui existe sur le papier mais qui ne reflète pas votre exposition réelle, ce qui ramène presque toujours la charge vers la même personne au moment où ça compte.

Sommes-nous vraiment une entité financière au sens de DORA, ou seulement un prestataire de nos clients financiers ?

Les deux cas existent, et les obligations diffèrent. Si vous êtes un établissement régulé (paiement, monnaie électronique, gestion d'actifs, assurance), vous êtes directement soumis au règlement. Si vous êtes un éditeur SaaS qui sert des clients financiers, DORA vous atteint indirectement, via les clauses contractuelles que ces clients doivent désormais vous imposer. Nous détaillons les deux situations sur notre page DORA.

Qu'est-ce qui change concrètement si on est accompagnés plutôt que seuls ?

La charge de rédaction et de veille documentaire change de mains. Vous gardez la décision et la validation, nous portons la production : cartographie, registre, politiques, préparation aux tests. Le rythme reste calé sur vos sprints, pas sur les nôtres.

Combien de temps ça prend ?

Comptez 6 à 12 mois selon votre statut et votre maturité initiale, un rythme nettement plus court si vous êtes déjà avancés sur ISO 27001, qui couvre une bonne partie des exigences de gestion des risques et d'incidents. Le détail est sur notre page tarifs.

La vraie question à trancher

Ce n'est pas de savoir si DORA vous concerne. C'est de décider où va le temps de votre CTO : sur un registre d'information, ou sur ce qui a fait signer vos derniers clients.

Si vous voulez en discuter concrètement, parlons-en.