La banque cloud-natif en 2026 est en phase d'audit DORA. Le Règlement (UE) 2022/2554 ⧉ est en vigueur depuis le 17 janvier 2025. Le régime de désignation des prestataires tiers critiques (CTPP) au titre des Articles 28-44 s'ouvre tout au long de 2025-2026, AWS, Microsoft (Azure), Google (GCP) et Salesforce se trouvant à l'intérieur ou à proximité du périmètre de désignation. Les Autorités européennes de surveillance (EBA, EIOPA, ESMA) ont publié les RTS et ITS définitifs sur le Registre d'informations ⧉ en 2024. L'équipe Supervision bancaire de la BCE inscrit des programmes explicites sur la préparation aux ruptures cloud et les tests d'intrusion pilotés par la menace dans les priorités prudentielles 2026-28 ⧉. La question institutionnelle n'est plus de savoir s'il faut aligner la stratégie cloud sur DORA — c'est tranché — mais de savoir si les primitives d'ingénierie de plateforme de l'institution produisent la preuve à la vitesse du pipeline de déploiement plutôt que dans des PDF assemblés la semaine précédant l'examen.
Résumé exécutif / Points clés
- Résilience cloud DORA en application active depuis le 17 janvier 2025. Articles 6, 8, 18, 26 et 28-44 tous en vigueur. Les constats prudentiels de la première vague d'examens sont tombés au T4 2025. La rhétorique de la « préparation » accuse deux cycles de retard.
- Régime de désignation CTPP en ouverture. AWS, Microsoft, Google, Salesforce — à l'intérieur ou à proximité. La désignation confère aux AES des pouvoirs de surveillance directe : demandes d'informations, inspections sur site, recommandations prudentielles.
- L'ingénierie de plateforme est le livrable. Voies pavées Kubernetes (EKS / AKS / GKE / OpenShift), portail développeur de type Backstage, GitOps (ArgoCD ou Flux), Open Policy Agent à l'admission, OpenTelemetry de bout en bout. Cinq primitives nommées ; toute absence devient un constat.
- Le cloud souverain est de l'ingénierie, pas du branding. AWS European Sovereign Cloud, Microsoft EU Data Boundary, Bleu (Capgemini + Orange + Microsoft), Thales / S3NS, Oracle EU Sovereign Cloud — chacun répond à une dimension spécifique Schrems II + DORA Article 28 ; aucun n'est une réponse clé en main.
- Preuve de sortie testée requise. Paragraphes 81 et 113-117 d'EBA/GL/2019/02. Le tabletop trimestriel ne suffit pas ; les superviseurs attendent un test annuel d'exécution de sortie de bout en bout pour chaque fonction critique ou importante.
- RTO / RPO depuis l'inventaire FCI. Palier 1 : 2 h / 15 min. Palier 2 : 4 h / 1 h. Palier 3 : 24 h / 4 h. Dérivés de l'analyse d'impact métier, pas de la capacité de l'équipe plateforme.
Pourquoi la résilience cloud DORA est en phase d'audit #
Trois raisons pour lesquelles la rhétorique de la « préparation » est fausse en 2026.
Premièrement, le calendrier. DORA a été publié en décembre 2022. La période d'application de 24 mois s'est close le 17 janvier 2025. Les RTS et ITS définitifs des AES — y compris l'ITS sur le Registre d'informations utilisé pour la désignation CTPP — ont été publiés tout au long de 2024. La première vague d'examens prudentiels s'est déroulée pendant 2025 ; les constats sur l'exhaustivité du cadre de gestion des risques TIC (Article 6) et la réconciliation du registre Article 8 sont tombés au T4 2025 dans plusieurs institutions de premier rang.
Deuxièmement, le régime de désignation CTPP. L'Article 31 fixe les critères de désignation comme prestataire tiers critique : impact systémique en cas de défaillance, criticité des services fournis, échelle et complexité des services, substituabilité. Les AES tiennent le registre et publient les décisions de désignation. AWS, Microsoft (Azure), Google (GCP) et Salesforce se trouvent à l'intérieur ou à proximité du périmètre de désignation, selon la part de marché des services financiers par État membre. La désignation confère au superviseur principal (l'une des AES, attribuée par prestataire) un pouvoir de surveillance directe : demandes d'informations au titre de l'Article 37, inspections sur site au titre de l'Article 38, recommandations au titre de l'Article 35 et régime de publicité au titre de l'Article 41. Les banques supervisées sur ces CTPP sont soumises aux attentes prudentielles correspondantes sur la façon dont elles gèrent cette dépendance désignée.
Troisièmement, les priorités prudentielles 2026-28 de la BCE. Le document des priorités nomme deux programmes explicites qui affectent directement la banque cloud-natif : la préparation aux ruptures majeures de service cloud (les scénarios prudentiels modélisés testent la capacité de l'institution à absorber une panne prolongée d'un CTPP désigné) et le TLPT aligné TIBER-EU (chaque exercice TIBER-EU couvre les fonctions critiques et importantes de l'institution, ce qui inclut désormais les services hébergés sur cloud public). La vague d'examens 2026 produira des constats sur les deux.
Le cadre de pensée pour 2026 n'est pas « DORA arrive » ; c'est « les constats d'examen DORA arrivent dans la boîte mail de votre institution, et les décisions d'ingénierie de plateforme que vous avez prises en 2024-2025 sont ce que le superviseur scrute dans ces constats ».
L'architecture de l'index 2026 #
| Couche d'index | À quoi ressemble la « préparation » | Indicateur de préparation | Mode de défaillance |
|---|---|---|---|
| Maturité de plateforme | >80 % des charges de travail sur une plateforme Kubernetes en voie pavée (EKS / AKS / GKE / OpenShift) avec admission politique en tant que code, déploiement GitOps, tests de PRA automatisés | % de FCI sur plateforme voie pavée ; nombre de déploiements fantômes ; délai moyen d'onboarding d'un nouveau service sur la plateforme | Plateformes fantômes aux contrôles incohérents ; FCI tournant sur des infrastructures non pavées, invisibles à la réconciliation du registre Article 8 |
| Intégrité du registre Article 8 | Le Registre d'informations se réconcilie automatiquement à la consommation d'API tierces de la plateforme + la nomenclature des composants cloud ; classification de criticité cohérente avec l'inventaire FCI de l'institution | % d'entrées de registre réconciliées à la télémétrie de la plateforme ; nombre d'entrées orphelines ; contrôle d'intégrité du périmètre CTPP | Les AES identifient une dépendance CTPP désignée que l'institution n'a pas déclarée au titre de l'Article 8 ; constat individuel et conséquence sur le périmètre CTPP |
| Concentration cloud | Fonctions critiques cartographiées par fournisseur cloud ET sous-régions ET services ET évaluation de substituabilité ; exposition corrélée inter-FCI quantifiée | Score de concentration par FCI ; exposition corrélée entre FCI partageant une région CTPP désignée | Une seule panne IAM AWS us-east-1 fait tomber quatre FCI que l'institution croyait approvisionnées indépendamment |
| Capacité de sortie testée | Test annuel d'exécution de sortie de bout en bout pour chaque FCI dépendante d'un CTPP désigné ; RTO / RPO documenté conforme aux cibles issues de la BIA ; chemin de portabilité des données testé | Taux de réussite des tests par FCI ; temps moyen d'exécution de sortie face à la cible RTO ; latence du chemin de portabilité des données | Plan de sortie qui n'existe qu'en PDF ; le tabletop annonce un RTO de 4 h, le test réel en révèle 48 h au premier essai |
| Observabilité + notification d'incident | Traces OpenTelemetry de bout en bout entre services ; assistant automatisé de classification 4 heures Article 18 câblé dans la plateforme de gestion des incidents | % de trafic FCI couvert par les traces OTel ; temps moyen entre détection de l'incident et décision de classification Article 18 | Incident majeur classé en dehors de la fenêtre de 4 heures parce que la qualification de criticité a exigé une réunion d'arbitrage ; constat Article 18 |
| Intégration TLPT | Périmètre TLPT dérivé de l'inventaire FCI et rafraîchi en continu ; les constats remontent dans la politique en tant que code de la plateforme ; les constats clos produisent des paquets de preuves prêts pour le superviseur | Taux de clôture des constats TLPT ; durée du cycle constat-vers-mise à jour de politique | Le TLPT découvre une vulnérabilité que l'équipe d'ingénierie de plateforme ne peut pas corriger en moins de deux cycles de release |
Signaux à suivre #
| Signal | Ce que cela signifie pour les banques | Source |
|---|---|---|
| DORA en application active depuis le 17 janv. 2025 | Constats prudentiels de la première vague tombés au T4 2025 ; deuxième vague attendue pour le S2 2026 | EUR-Lex ⧉ |
| Désignation CTPP en ouverture sur 2025-2026 | AWS, Microsoft, Google, Salesforce à l'intérieur ou à proximité du périmètre ; la désignation confère aux AES des pouvoirs de surveillance directe | EBA ⧉ |
| Les priorités prudentielles 2026-28 de la BCE nomment explicitement la rupture cloud | Les scénarios prudentiels modélisés testent la capacité à absorber une panne CTPP désignée prolongée | Supervision bancaire BCE ⧉ |
| TIBER-EU aligné sur l'Article 26 DORA | Le périmètre TLPT couvre les fonctions critiques / importantes, y compris les services hébergés sur cloud | BCE TIBER-EU ⧉ |
| Les orientations d'externalisation EBA (EBA/GL/2019/02) s'imbriquent avec l'Article 28 DORA | Présence substantielle (¶64), évaluation de substituabilité (¶81), stratégie de sortie (¶113-117) — les paragraphes que les superviseurs testent réellement | EBA ⧉ |
| Avancement du projet de schéma européen des services cloud (EUCS) | Futur schéma de certification cloud souverain au titre de l'Acte européen sur la cybersécurité ; projet publié par l'ENISA | ENISA EUCS ⧉ |
Ingénierie de plateforme : les cinq primitives nommées #
La maturité cloud-natif en 2026 se ramène à cinq primitives d'ingénierie qui s'imbriquent pour produire la preuve prudentielle à la vitesse du pipeline de déploiement. Toute absence est un constat en sursis.
1. Voies pavées sur Kubernetes #
Chaque FCI tourne sur une plateforme Kubernetes managée — EKS, AKS, GKE ou OpenShift sur un CTPP désigné, ou une alternative managée par l'éditeur. L'équipe plateforme exploite un patron unique de cluster doré avec déviation contrôlée : nœuds depuis une image de base documentée ; isolation namespace par équipe ; profil pod-security-standards-restricted ; politiques réseau ; injection de service mesh (Istio ou Linkerd) pour l'authentification inter-services et l'observabilité. Les nouveaux services rejoignent la voie pavée via un flux de travail d'onboarding modèle qui produit l'entrée du registre Article 8 comme artefact de déploiement.
2. Portail développeur de type Backstage #
Un portail développeur central — l'open source Backstage ⧉ de Spotify est l'implémentation de référence, avec diverses alternatives entreprise — fournit le système d'enregistrement de ce qui tourne où. Le catalogue liste chaque service, propriétaire, dépendance, classification de criticité, runbook, rotation d'astreinte. Le portail s'imbrique avec le registre Article 8 : chaque entrée du catalogue se mappe à une entrée de registre ; les entrées sans référence de registre déclenchent une rupture CI ; les entrées de registre sans présence dans le catalogue déclenchent des alertes anticipant le superviseur.
3. Déploiement GitOps via ArgoCD ou Flux #
Le déploiement en production passe par un contrôleur GitOps — ArgoCD ou Flux est le standard de production en 2026 — qui réconcilie un état déclaratif versionné sous Git au cluster en exécution. Le kubectl apply manuel est désactivé ; la seule voie vers la production est une pull request fusionnée. Le dépôt Git est la piste d'audit ; aux superviseurs demandant « montrez-moi la configuration du service X à la date Y », on présente un tag Git, pas une capture d'écran.
4. Open Policy Agent à l'admission #
Open Policy Agent (OPA) se place dans la chaîne d'admission du cluster pour faire respecter la politique de plateforme : conformité au profil pod-security, provenance des images, limites de ressources, présence de politique réseau, réplication adaptée au palier de criticité, placement sous-régional sous contraintes de cloud souverain. Les politiques sont versionnées Git et gérées en change management aux côtés des configurations de service. Les déploiements rejetés produisent des justifications revues qui alimentent le paquet de preuves de change management.
5. OpenTelemetry de bout en bout #
Chaque service émet des traces, métriques et logs OpenTelemetry. L'équipe plateforme exploite un pipeline d'observabilité centralisé — typiquement Tempo ou Jaeger pour les traces, Prometheus pour les métriques, Loki ou OpenSearch pour les logs — qui fait remonter la santé FCI de bout en bout, la cartographie des dépendances et les intrants de classification d'incident. La fenêtre de classification de 4 heures Article 18 démarre à la détection ; le pipeline OTel raccourcit le chemin de la détection à la classification jusqu'à une consultation interrogeable, pas une réunion d'arbitrage.
Cloud souverain comme ingénierie, pas branding #
La stratégie cloud souverain en 2026 doit répondre à quatre questions spécifiques Schrems II + DORA + externalisation EBA :
- Où la donnée est-elle traitée et stockée ? Localisation dans un État membre de l'UE ; sous-région pour les flux à haute criticité ; engagements écrits de résidence des données.
- Qui a un accès légal à la donnée ? Exploitation par des employés locaux uniquement ; demandes d'accès gouvernementales étrangères soumises à une procédure judiciaire locale ; réponse testée aux demandes d'accès légal.
- Quel est le profil de substituabilité ? Évaluation de substituabilité au titre du ¶81 d'EBA/GL/2019/02 ; exécution de sortie testée ; prestataire alternatif identifié et contractualisé (ou documentation justifiant l'infaisabilité).
- Quel est le modèle de souveraineté technique ? Clés contrôlées par le client ; séparation cryptographique ; plan de gestion souverain ; chaîne d'approvisionnement auditable.
Les options fournisseurs 2026 qui répondent à ces questions :
- AWS European Sovereign Cloud (annoncé en 2023, GA attendu au S2 2026) : région physique exploitée par une filiale AWS résidente UE ; exploitation et support assurés par du personnel résident UE ; clés contrôlées par le client via le patron KMS-XKS. Alignement du contenu contractuel DORA Article 28 attendu en 2026.
- Microsoft EU Data Boundary (GA 2024) + Bleu (Capgemini + Orange + Microsoft, France uniquement) : le Data Boundary maintient les données clients UE dans les régions UE ; Bleu est le cloud souverain français aligné SecNumCloud qui fait tourner la pile Microsoft Azure sous contrôle opérationnel français.
- Partenariats souverains Google Cloud : Thales / S3NS en France (équivalent de Bleu) ; T-Systems en Allemagne.
- Oracle EU Sovereign Cloud (GA 2023) : patron à double région (Francfort + Madrid) avec exploitation résidente UE ; conformité Schrems II nette.
- Fournisseurs alignés Gaia-X (OVHcloud, Scaleway, Stackit, Aruba Cloud, IONOS) : prestataires natifs UE avec labellisation Gaia-X ; échelle et écosystème plus modestes que les hyperscalers mais aucune exposition au Foreign Intelligence Surveillance Act.
La décision stratégique est rarement binaire. Les banques de premier rang exploitent typiquement une configuration hyperscaler-avec-Data-Boundary pour le gros des charges de travail, une option de cloud souverain pour les flux désignés à haute sensibilité (p. ex. les systèmes de gestion des dossiers LCB-FT / sanctions traitant des données personnelles de résidents UE) et un chemin de substituabilité de contingence testé chaque année au titre de l'Article 28 DORA.
Exécution de sortie testée #
Les paragraphes 113-117 d'EBA/GL/2019/02 ⧉ portent les dispositions sur la stratégie de sortie. Le texte est explicite sur les attendus : « Les établissements et les établissements de paiement devraient s'assurer qu'ils sont en mesure de mettre fin aux accords d'externalisation sans perturbation indue de leurs activités commerciales… Les stratégies de sortie devraient également être documentées et testées dans le cadre des revues régulières des accords d'externalisation. »
L'attente prudentielle en 2026 est un test annuel d'exécution de sortie de bout en bout pour chaque FCI dépendante d'un CTPP désigné. Les exercices tabletop et les revues documentaires ne suffisent pas. Le test doit produire :
- Mesure du temps de restauration : temps réel écoulé entre la déclaration de sortie et la restauration de la charge de travail sur le prestataire alternatif, face à la cible RTO issue de la BIA.
- Preuve de portabilité des données : export de données testé depuis le prestataire principal, validé contre le chemin d'import du prestataire de destination, avec preuve de réconciliation.
- Équivalence fonctionnelle : charge de travail testée sur le prestataire alternatif avec des SLO équivalents.
- Preuve de coût : coût d'exécution de sortie documenté face à l'hypothèse de coût de restauration dans la planification de contingence de l'institution.
La première tentative de test de sortie de bout en bout pour une FCI révèle typiquement un écart de 5 à 10× entre le RTO documenté et le RTO réel. Combler cet écart est un travail d'ingénierie qui prend des mois. Les banques qui le découvrent lors d'une inspection prudentielle plutôt que pendant leur propre cycle de test annuel font face à un cycle de constats au T3 qu'elles auraient pu éviter.
Cibles RTO / RPO depuis l'inventaire FCI #
Chaque fonction critique ou importante se mappe à une classification de palier dérivée de l'analyse d'impact métier de l'institution. Le palier conditionne les cibles RTO et RPO que l'équipe d'ingénierie de plateforme s'engage à livrer.
| Palier | Exemples | RTO | RPO |
|---|---|---|---|
| Palier 1 (mission-critique) | Connectivité RTGS (CHAPS / T2 / Fedwire), autorisation des paiements de détail, authentification client pour les canaux digitaux | 2 heures | 15 minutes |
| Palier 2 (critique) | Filtrage LCB-FT / sanctions, pipelines de détection de fraude, autorisation DAB, traitement par lots des paiements | 4 heures | 1 heure |
| Palier 3 (important) | Reporting et soumission réglementaire, bases de connaissances client, plateformes de collaboration interne | 24 heures | 4 heures |
| Palier 4 (non critique) | Systèmes RH internes, outillage marketing, reporting interne non client | 72 heures | 24 heures |
Ces chiffres sont indicatifs — la BIA de l'institution produit les siens. Le livrable d'ingénierie de plateforme est une capacité testée en non-régression à respecter les cibles issues de la BIA, étayée par des tests de PRA automatisés par service et validée par le test annuel d'exécution de sortie pour les FCI dépendantes d'un CTPP.
Ce que cela signifie selon le type de banque #
Banques d'importance systémique mondiale #
Le problème difficile est l'échelle entre lignes de métier : milliers de services, centaines de FCI, multiples expositions à des CTPP désignés à travers produits, juridictions et profils de résilience. L'investissement, c'est la capacité centrale d'ingénierie de plateforme — voies pavées Kubernetes, portail Backstage, GitOps, OPA, OTel — qui produit la réconciliation du registre Article 8, la cartographie de concentration CTPP et la capacité d'exécution de sortie FCI par FCI sans construction sur mesure par ligne de métier.
Banques universelles et de taille intermédiaire #
L'investissement d'ingénierie de plateforme se justifie à ce palier mais le périmètre est contraint : ciblez les deux ou trois FCI les plus critiques, bâtissez le patron de voie pavée autour d'elles, acceptez que le parc historique reste sous les contrôles existants à moyen terme. Le positionnement prudentiel compte plus que la largeur de la plateforme — être capable d'étayer l'intégrité du registre Article 8 DORA et la sortie testée pour les trois principales FCI couvre les préoccupations primaires du superviseur.
Banques régionales et plus petites #
Sélection fournisseur plutôt que construction interne. Choisissez un éditeur de plateforme bancaire dont l'architecture Kubernetes-native est documentée, dont l'intégration au registre Article 8 est intégrée et dont les engagements de contenu contractuel DORA Article 28 sont clairs. La capacité d'ingénierie interne porte sur la configuration, la supervision et la réponse à incident — pas sur la construction de plateforme.
Fintechs, PSP et fournisseurs SaaS au service des banques #
La question produit pour les éditeurs qui vendent aux banques UE en 2026 est de savoir si la plateforme produit les entrées de registre Article 8 et le contenu contractuel DORA Article 28 dont la fonction conformité de la banque a besoin. Les éditeurs aux sorties structurées remportent les deals entreprise ; ceux qui n'ont que des modèles PDF perdent face à des concurrents au JSON structuré.
Conclusion #
La résilience cloud DORA est en phase d'audit. Les décisions d'ingénierie de plateforme prises en 2024-2025 sont ce que le cycle de supervision 2026 scrute. Les institutions qui paraîtront crédibles devant la BCE et l'EBA en 2026-2028 sont celles qui exploitent des voies pavées Kubernetes avec des portails de type Backstage et un déploiement GitOps sous admission Open Policy Agent avec OpenTelemetry de bout en bout — produisant la preuve du registre Article 8 comme artefact de déploiement et la preuve d'exécution de sortie testée comme cycle annuel, pas comme réponse à une demande prudentielle.
Les institutions qui n'ont pas fait ces investissements découvriront si leur équipe conformité de deuxième ligne peut absorber la première salve de constats prudentiels avant l'arrivée de la deuxième.
Mesurez la plateforme comme tout programme opérationnel : couverture voie pavée, taux de réconciliation du registre, score de concentration CTPP, temps de sortie testé face à la cible RTO, temps moyen de classification Article 18, taux de clôture TLPT. Preuve à la vitesse du pipeline ; dossiers documentaires uniquement quand le superviseur en demande un.
Questions fréquentes #
La résilience cloud DORA est-elle encore en phase de préparation en 2026 ?
Non. DORA est en application active depuis le 17 janvier 2025. Le régime de désignation CTPP au titre des Articles 28-44 s'ouvre tout au long de 2025-2026. Les constats d'examen de la BCE sur la gestion des risques TIC (Article 6) et l'intégrité du registre Article 8 sont tombés dans plusieurs institutions de premier rang au T4 2025. La question prudentielle 2026 porte sur la preuve d'examen propre à chaque institution, pas sur la préparation réglementaire.
Quels fournisseurs cloud sont désignés CTPP ?
Les AES publient les décisions de désignation sur leurs sites. Les institutions à l'intérieur ou à proximité du périmètre en 2026 incluent AWS, Microsoft (Azure), Google (GCP), Salesforce et un petit nombre d'autres selon la part de marché des services financiers par État membre. Les banques supervisées sur ces prestataires font face aux attentes prudentielles correspondantes sur la façon dont elles gèrent cette dépendance.
Le cloud souverain élimine-t-il le besoin de contenu contractuel DORA Article 28 ?
Non. Le cloud souverain répond à la dimension Schrems II + résidence des données ; le contenu contractuel DORA Article 28 est une obligation distincte qui s'applique quel que soit le lieu de la donnée. Le contrat du prestataire de cloud souverain doit toujours couvrir l'accessibilité des données, la sécurité, la résidence, les droits d'audit, les stratégies de sortie et la continuité au titre de l'Article 28.
Quel est le livrable d'ingénierie qui démontre la résilience cloud DORA ?
Cinq primitives d'ingénierie de plateforme qui s'imbriquent : voies pavées Kubernetes (cluster managé avec déviation contrôlée par politique), portail développeur de type Backstage (catalogue se réconciliant au registre Article 8), déploiement GitOps (ArgoCD ou Flux), Open Policy Agent à l'admission, OpenTelemetry de bout en bout. Preuve à la vitesse du pipeline plutôt qu'au moment de l'examen.
À quelle fréquence l'exécution de sortie doit-elle être testée ?
Un test annuel d'exécution de sortie de bout en bout par FCI dépendante d'un CTPP désigné. Les exercices tabletop et les revues documentaires ne suffisent pas. Le test doit produire le temps de restauration, la preuve de portabilité des données, l'équivalence fonctionnelle et la preuve de coût — mesurés face aux cibles RTO et RPO issues de la BIA.
Références #
- Union européenne, (2022). Règlement (UE) 2022/2554 — Digital Operational Resilience Act (DORA) ⧉.
- Autorité bancaire européenne, (2019). EBA/GL/2019/02 — Orientations sur les accords d'externalisation ⧉.
- Autorité bancaire européenne, (2026). Digital Operational Resilience Act ⧉.
- Autorités européennes de surveillance, (2024). Rapport final sur l'ITS relatif au Registre d'informations au titre de DORA ⧉.
- Supervision bancaire BCE, (2025). Priorités prudentielles 2026-28 ⧉.
- Banque centrale européenne, (2024). Cadre TIBER-EU ⧉.
- ENISA, (2024). Schéma européen de cybersécurité pour les services cloud (EUCS) ⧉.
- Spotify, (2020-2024). Portail développeur Backstage ⧉.
- Cloud Native Computing Foundation, (2018). Open Policy Agent (OPA) ⧉.
- Cloud Native Computing Foundation, (2019). OpenTelemetry ⧉.
Dernière revue .
Dernière révision .