Si vous écrivez du logiciel au sein d'une banque, d'une assurance, d'une société d'investissement, d'un établissement de paiement ou d'une autre entité financière couverte par DORA (Digital Operational Resilience Act, Règlement (UE) 2022/2554), ce règlement est déjà en vigueur pour votre organisation. Si vous vendez des services TIC utilisés par ces entités, la situation est plus précise : DORA supervise directement les fournisseurs tiers critiques de TIC désignés, tandis que les autres fournisseurs répondent principalement aux obligations imposées par DORA via les contrats et la diligence raisonnable que leurs clients (entités financières) leur transmettent. Dans les deux cas, une grande partie des analyses publiques traitent DORA comme un problème de direction et de gestion des risques : cadres de risque TIC, tests de résilience, signalement des incidents aux superviseurs, dispositions contractuelles clés. Cette lecture est correcte pour la majorité du règlement. Elle est incomplète pour la partie que l'ingénieur livre effectivement.
La partie incomplète concerne l'ensemble des décisions de résilience qui résident dans le dépôt : un disjoncteur supprimé en tant que "code mort", une durée de conservation des sauvegardes réduite pour économiser de l'espace, une nouvelle API de détection de fraude intégrée au flux de paiements sans entrée dans le registre, une règle de vérification d'intégrité ou d'alerte supprimée car trop bruyante. Chacune de ces modifications semble être une opération d'ingénierie classique. Chacune affaiblit une obligation que DORA identifie au niveau des articles. Ce guide s'adresse aux développeurs qui doivent savoir quels articles apparaissent dans une pull request, sous quelle forme ces modifications se présentent et comment les détecter sans transformer chaque revue en un mémo juridique.
À qui ce guide s'adresse (et à qui il ne s'adresse pas)
Vous faites partie du public cible si votre code prend en charge une entité financière couverte par DORA, ou si votre produit est un service TIC utilisé en production par ces entités (que vous soyez un fournisseur tiers critique de TIC désigné sous supervision directe ou un fournisseur lié principalement par des contrats clients). Le champ d'application et la désignation dans le cadre du règlement relèvent de questions juridiques et de classification d'entités, et non de décisions prises lors d'une revue de code. Si votre équipe conformité ou juridique vous a déjà indiqué que DORA s'applique (directement ou par contrat), ce guide traite de la partie ingénierie de cette obligation. Si vous n'êtes pas sûr que DORA vous concerne, arrêtez-vous ici et demandez-leur : une mauvaise réponse peut entraîner soit un sous-investissement dans une obligation réelle, soit une sur-adaptation à un règlement qui ne s'applique pas.
Ce guide ne remplace pas un cadre de gestion des risques TIC, un programme de tests de résilience, un processus de signalement des incidents, un registre des tiers, ou les dispositions contractuelles clés avec les fournisseurs TIC. heygrc ne gère aucun de ces éléments. Il est conçu pour identifier le moment où une modification dans une pull request affaiblit ou introduit un contrôle pertinent pour la résilience, que ces programmes supposent toujours exister.
Les articles qui apparaissent réellement dans un diff
La majeure partie de DORA n'apparaîtra jamais sous forme de ligne de code applicatif. Ce qui a tendance à se retrouver dans une pull request se concentre sur une courte liste d'articles. Art. 9 (protection et prévention) : une modification affaiblit le contrôle d'accès, le chiffrement, la segmentation réseau ou une autre mesure qui maintient une fonction TIC critique isolée. Art. 10 (détection) : la journalisation, les alertes ou la détection d'anomalies sur lesquelles une entité s'appuie pour identifier rapidement un problème TIC sont supprimées ou désactivées. Art. 11 (réponse et récupération) : une relance, un disjoncteur, un basculement, un délai d'attente ou un chemin de récupération qui maintenait une fonction critique active malgré une perturbation est supprimé lors d'un nettoyage. Art. 12 (sauvegarde et restauration) : la portée des sauvegardes, leur fréquence ou les outils de restauration sont réduits, ou un nouveau stockage critique est déployé sans chemin de sauvegarde. Arts. 17 à 19 (gestion des incidents liés aux TIC, classification et signalement) : une modification supprime l'identification, le suivi, la journalisation ou l'enregistrement des incidents liés aux TIC (Art. 17), ou supprime les champs et signaux dont dépend le processus de classification (Art. 18) et le chemin de signalement des incidents majeurs (Art. 19). Art. 28 (principes généraux pour la gestion des risques liés aux tiers TIC), y compris le registre d'informations prévu à l'Art. 28(3) : un nouvel arrangement contractuel pour un service TIC est intégré en production sans être enregistré dans le registre qui doit couvrir tous ces arrangements. Art. 30 (dispositions contractuelles clés) : l'arrangement est traité comme "un simple client SaaS" sans référence au chapitre des dispositions contractuelles pour les services TIC, qui constitue une obligation distincte du registre de l'Art. 28 et des travaux de gouvernance.
Ces explications sont des résumés en langage clair pour les ingénieurs, et non le texte du règlement. L'analyse approfondie du cadre à l'adresse /frameworks/dora passe en revue les articles sur la résilience avec les formes de modifications qui les déclenchent. Les pages "contrôle dans le code" pour l'Art. 9 (protection et prévention) et l'Art. 11 (réponse et récupération) montrent des diffs concrets pour une segmentation aplatie et un disjoncteur supprimé. Ce guide se concentre sur le groupe d'articles qui surprend le plus souvent les ingénieurs produit : les Art. 28 et 30, lorsqu'un appel SaaS pratique devient une dépendance TIC de production.
Exemple concret : un client propre qui devient un tiers TIC non suivi
Une équipe de paiements souhaite des décisions de détection de fraude plus rapides. Un ingénieur ouvre une pull request qui remplace un chemin de règles internes lent par un client HTTP typé vers une nouvelle API externe "FraudScore". Le client dispose de délais d'attente, de relances avec rétrogradation, d'une cartographie des erreurs structurée et d'un feature flag. Les tests couvrent le chemin nominal et les erreurs 5xx. Les commentaires de revue portent tous sur les budgets de latence et sur le fait que le flag est activé ou désactivé par défaut. Rien dans le diff ne semble incorrect en tant que logiciel : il s'agit d'une intégration bien formée.
Ce que la PR ne contient pas, c'est de mise à jour du registre d'informations sur les arrangements contractuels pour les services TIC (Art. 28(3)), ni de référence aux dispositions contractuelles clés de l'Art. 30 qui s'appliquent généralement aux arrangements de services TIC (Art. 30(1) et (2)). Aucune de ces étapes n'attend qu'une personne décide que l'appel est "critique". Par ailleurs, si cette vérification de fraude se situe sur le chemin qui autorise les paiements, l'arrangement peut prendre en charge une fonction critique ou importante, ce qui peut déclencher des obligations supplémentaires, y compris les exigences de stratégie de sortie de l'Art. 28 et l'évaluation des risques de concentration de l'Art. 29, ainsi que les dispositions contractuelles renforcées de l'Art. 30(3). Livrer le client en premier et enregistrer l'entrée dans le registre "plus tard" est la manière dont une dépendance de production devient invisible pour le programme qui est censé suivre chaque arrangement de service TIC.
Voici la forme qu'une revue consciente de la conformité est conçue pour détecter : non pas "le client HTTP est-il correct", mais "cette modification a-t-elle introduit ou remplacé un service tiers TIC dont l'arrangement contractuel doit figurer dans le registre conformément à l'Art. 28(3)". Une observation qui cite l'Art. 28 / Art. 28(3) (et l'Art. 30 lorsque les dispositions contractuelles font défaut) n'approuve pas le fournisseur, ne rédige pas le contrat, ne classe pas le niveau de criticité ni ne décide du risque de concentration. Elle rend simplement la responsabilité liée au tiers visible alors que l'auteur a encore la PR ouverte, afin que les étapes d'enregistrement, de classification et de contrat puissent avancer avec le code, plutôt que des semaines après que le trafic de production dépend du nouveau fournisseur.
Que rechercher lors d'une revue sans devenir juriste DORA
Lorsque une modification ajoute ou remplace une dépendance sortante qui s'exécutera en production pour une fonction financière, posez trois questions d'ingénierie : l'arrangement contractuel pour ce service TIC est-il déjà enregistré dans notre registre d'informations (Art. 28(3)), y compris la classification du service et s'il prend en charge une fonction critique ou importante ; une panne de cet appel dégrade-t-elle suffisamment un service financier pour que des travaux sur la criticité et le plan de sortie soient applicables ; et la même PR (ou une modification liée) met-elle à jour la checklist interne ou le ticket que votre équipe risque utilise lorsqu'un nouvel arrangement TIC est intégré, y compris les travaux sur les dispositions contractuelles de l'Art. 30 si c'est ainsi que votre organisation les suit. Si la réponse concernant le registre est "non" ou "inconnu", la fonctionnalité est incomplète du point de vue des tiers TIC de DORA, même si elle est complète en tant que code. La criticité détermine la quantité de travail supplémentaire à prévoir ; elle ne décide pas si l'arrangement doit figurer dans le registre.
Pour les sauvegardes de résilience que vous possédez déjà, le signe est différent : une PR dont le résumé est "nettoyage", "suppression de code mort" ou "réduction des coûts" qui supprime des relances, des basculements, des sauvegardes, des règles d'isolation ou des hooks de détection sur un chemin critique. Demandez-vous si le système satisfait toujours la propriété de résilience que la sauvegarde fournissait. Les Art. 9, 10, 11, 12 et le groupe de gestion des incidents des Arts. 17 à 19 sont les citations habituelles lorsque la réponse est non. Vous n'avez pas besoin de citer le règlement. Vous devez nommer la propriété et refuser la fusion jusqu'à ce que quelqu'un prenne en charge soit la restauration de la sauvegarde, soit la documentation d'une modification acceptée via votre processus de changement réel.
Rôle de heygrc et limite d'honnêteté
heygrc est conçu pour analyser chaque pull request par rapport aux cadres que vous avez sélectionnés, y compris DORA lorsque vous l'avez activé, et pour identifier l'article qu'une modification semble toucher (par exemple, l'Art. 28(3) pour un nouvel arrangement de service TIC manquant dans le registre, l'Art. 11 pour un chemin de récupération supprimé). L'observation est un commentaire de revue avec l'article joint, afin que l'auteur et le relecteur puissent décider en toute connaissance de cause. Il ne certifie pas la conformité DORA, ne remplace pas votre cadre de risque TIC, n'exécute pas vos tests de résilience, ne dépose pas vos rapports d'incidents, ne maintient pas votre registre des tiers, ni ne rédige les dispositions contractuelles de l'Art. 30. Ces tâches restent des responsabilités humaines et organisationnelles. Une revue heygrc verte n'est pas une approbation supervisée ; c'est un signal précoce, basé sur les articles, indiquant qu'une modification a affecté quelque chose que ces programmes prennent en compte.
Si votre équipe utilise déjà un outil de détection de bugs ou de qualité sur la même pull request, conservez-le. Ces outils vérifient si le code est correct et sûr. Les questions DORA concernent la résilience opérationnelle et les obligations liées aux tiers TIC. Le client FraudScore ci-dessus peut être propre, typé et bien testé, tout en laissant l'Art. 28(3) inachevé. Exécutez les deux couches ; aucune ne remplace l'autre.