Observabilité et souveraineté numérique

Mode de lecture

IngénieurDécideur

Lecture d’ingénieur, pas avis juridique

Les textes réglementaires cités sont lus du point de vue d’une équipe d’observabilité. Pour une décision d’achat ou de conformité, faites valider l’analyse par votre service juridique. Les statuts juridiques et politiques (FISA, Data Privacy Framework, CADA) évoluent vite : chaque affirmation renvoie à sa source et la page est relue tous les deux mois.

Une plateforme peut être hébergée dans un cloud qualifié, chiffrée avec des clés détenues par le client et exploitée par des équipes européennes, tout en envoyant chaque seconde ses logs, ses traces et ses métriques chez un éditeur soumis à un droit étranger. Dans la plupart des projets souverains, c’est le flux sortant que personne n’a inventorié.

Cet article aborde la souveraineté numérique du point de vue de l’observabilité. Il explique pourquoi les données d’observabilité sont un sujet de souveraineté à part entière, comment les risques classiques s’y appliquent, ce que dit le cadre réglementaire, à quoi ressemble une architecture d’observabilité souveraine et comment évaluer une offre. Il défend l’idée que l’observabilité est à la fois un angle mort de la souveraineté et le meilleur instrument pour la démontrer.

1. La souveraineté en bref

Une définition opérationnelle

Appliquée à une organisation, la souveraineté numérique est la capacité à décider seule de l’accès, de la continuité et de l’évolution de ses actifs numériques et à le démontrer. Transposée à l’observabilité, chaque terme devient une question concrète :

1. Accès : qui peut lire les logs, les traces et les métriques, y compris l’éditeur de l’outil, son support et une autorité étrangère ?
2. Continuité : l’équipe garde-t-elle la visibilité sur ses systèmes si l’outil d’observabilité est coupé, en plein incident ?
3. Évolution : peut-elle changer de backend sans ré-instrumenter toutes ses applications ni perdre ses tableaux de bord et ses alertes ?
4. Démonstration : peut-elle prouver les trois points précédents à un auditeur ou à un client ?

La souveraineté n’est ni l’autarcie, ni un état binaire, ni un label. Il s’agit de maîtriser ses dépendances, dimension par dimension. Le cadre européen la mesure d’ailleurs par niveaux.

Les notions voisines

Deux mots reviennent dans ce tableau et dans la suite. Le backend est l’outil qui stocke les logs, les traces et les métriques et permet de les interroger. Le SaaS désigne un logiciel loué en ligne, exploité par l’éditeur sur ses propres serveurs.

Notion	Question à laquelle elle répond	Exemple côté observabilité
Résidence des données	Dans quel pays les logs et les métriques sont-ils stockés ?	Un backend SaaS hébergé dans une région européenne
Localisation des traitements	Où les données sont-elles indexées, analysées, enrichies ?	Une fonction d’analyse par IA qui s’exécute hors d’Europe malgré un stockage européen
Souveraineté des données	Sous quel droit sont les données et qui peut les lire ?	Le droit applicable à la maison mère de l’éditeur de l’outil
Souveraineté numérique	Qui contrôle l’accès, la continuité et l’évolution de la chaîne d’observabilité ?	La capacité à exploiter et à faire évoluer sa pile sans l’éditeur
Cloud de confiance	L’hébergement est-il qualifié (SecNumCloud, la qualification de sécurité de l’ANSSI, en France) ?	Un backend auto-hébergé sur une infrastructure qualifiée
Autarcie	Tout est-il produit en interne ?	Objectif irréaliste : même une pile auto-hébergée repose sur des projets open source mondiaux

2. Pourquoi l’observabilité est un sujet de souveraineté ?

Les signaux d’observabilité sont une copie du système

Chaque signal reproduit une partie de ce qu’il observe :

• Les logs contiennent des identifiants, des adresses IP, des fragments de requêtes et parfois des données personnelles ou métier qui ont échappé au masquage.
• Les traces distribuées, qui suivent le parcours d’une requête d’un service à l’autre, révèlent les services, leurs dépendances, les points d’entrée et les chemins critiques : c’est une carte de l’architecture.
• Les métriques montrent les volumes, les pics, les horaires et les incidents : c’est un portrait de l’activité.
• Les profils d’exécution, des relevés de ce que fait le code fonction par fonction, de plus en plus collectés en continu, exposent la structure du code et ses points chauds.

Accéder aux logs, aux traces et aux métriques, c’est obtenir une vue détaillée du système sans jamais toucher à la base de production.

Un flux sortant par conception

La plupart des outils d’observabilité du marché fonctionnent en SaaS : des agents installés sur chaque machine poussent en continu leurs données vers un service externe. Ce modèle a trois conséquences que les revues de souveraineté oublient souvent.

1. Des ouvertures réseau larges. Les règles de pare-feu autorisent fréquemment tout un domaine de l’éditeur, ce qui rend impossible de savoir précisément ce qui sort.
2. Des composants très privilégiés. Un agent d’observabilité lit tous les fichiers de logs, interroge l’interface de l’orchestrateur (le logiciel qui pilote les conteneurs), s’exécute parfois avec des droits étendus sur le noyau du système d’exploitation et accepte souvent des mises à jour et des configurations poussées à distance. C’est un logiciel piloté de l’extérieur, présent sur chaque hôte.
3. Un flux permanent. Contrairement à une sauvegarde ou à un export ponctuel, ces données sortent à chaque seconde, en volume. Elles sont souvent conservées plus longtemps que les données qu’elles décrivent.

Un angle mort organisationnel

L’outil d’observabilité est généralement choisi par les équipes d’exploitation comme un outil, pas comme un hébergement. Il échappe ainsi aux revues d’architecture qui examinent les bases de données et les applications. Le marché accentue le phénomène : la plupart des grands éditeurs d’observabilité en SaaS relèvent du droit américain.

Enfin, l’observabilité est l’outil dont on a le plus besoin quand tout va mal. Une dépendance à un service externe pour voir ses systèmes est une dépendance au moment précis où l’on ne peut pas se permettre de la subir.

3. Ce qui a changé depuis 2018

Trois évolutions ont fait passer la souveraineté du discours à l’opérationnel : des lois étrangères à portée extraterritoriale, des sanctions qui touchent directement des services numériques et des critères européens qui entrent dans les achats. Chacune a une traduction directe pour la chaîne d’observabilité.

Date	Fait	Conséquence pour l’observabilité
Juin 2026	La section 702 du FISA, la loi américaine sur la surveillance du renseignement étranger, expire le 12 juin faute de réautorisation, mais la collecte reste autorisée jusqu’en mars 2027 grâce aux certifications de mars 2026	L’exposition de logs et de traces confiés à un éditeur américain dépend d’un débat politique sur lequel on n’a aucune prise
Juin 2026	La Commission propose le Cloud and AI Development Act, qui couvre aussi les systèmes d’IA hébergés à distance	Les fonctions d’analyse assistée par IA des outils d’observabilité entreront dans le champ des évaluations de risques
Avril 2026	La Commission attribue son appel d’offres cloud souverain avec un niveau SEAL-2 minimum (échelle de souveraineté de 0 à 4, voir section 6)	Un acheteur public peut désormais évaluer un service d’observabilité avec la même grille qu’un service cloud
Janvier 2026	AWS ouvre l’AWS European Sovereign Cloud, séparé des autres régions	Une plateforme hébergée dans un cloud séparé perd ce bénéfice si ses logs et ses traces partent vers un SaaS non séparé
Décembre 2025	S3NS obtient la qualification SecNumCloud 3.2 pour son offre PREMI3NS	Les plateformes qualifiées se multiplient ; leur observabilité doit suivre le même niveau
Octobre 2025	Publication du Cloud Sovereignty Framework	L’évaluation s’étend aux sous-traitants et aux couches techniques : l’outil d’observabilité en fait partie
Septembre 2025	Le Data Act, règlement européen sur les données, s’applique ; le Tribunal de l’UE valide le Data Privacy Framework, qui fait l’objet d’un appel	Le changement d’outil devient un droit, mais les logs contenant des données personnelles restent exposés à la fragilité des transferts
Juin 2025	Devant le Sénat, le directeur juridique de Microsoft France déclare sous serment ne pas pouvoir garantir que des données de citoyens français ne seront jamais transmises aux autorités américaines	Ce qui vaut pour un hyperscaler (un très grand fournisseur de cloud) vaut pour tout éditeur d’observabilité soumis au même droit
Mai 2025	Il est révélé que le procureur de la Cour pénale internationale (CPI), visé par des sanctions américaines depuis février, a perdu l’accès à sa messagerie Microsoft ; Microsoft conteste ensuite avoir coupé le service	Un outil d’observabilité peut lui aussi être coupé : l’équipe devient aveugle
2020	L’arrêt Schrems II de la Cour de justice de l’UE invalide le Privacy Shield, le dispositif qui encadrait alors les transferts de données vers les États-Unis	Les logs exportés vers les États-Unis peuvent devenir non conformes du jour au lendemain
2018	Adoption du CLOUD Act américain	Un éditeur américain peut être contraint de livrer les données d’observabilité de ses clients, quel que soit leur lieu de stockage

4. Les trois mécanismes de dépendance

Derrière le mot souveraineté se cachent trois risques distincts. Chiffrer ses logs ne protège pas d’une coupure de l’outil. Changer de région d’hébergement ne protège pas d’un verrouillage par les agents.

Mécanisme 1 : l’accès légal extraterritorial

Un État peut contraindre une entreprise qui relève de son droit à lui remettre des données, même stockées à l’étranger. Aux États-Unis, le CLOUD Act permet d’exiger des données détenues ou contrôlées par un fournisseur américain quel que soit leur lieu de stockage. La section 702 du FISA et l’Executive Order 12333, un décret présidentiel américain, encadrent quant à eux la collecte de renseignement visant des personnes non américaines. D’autres pays disposent de mécanismes comparables, comme la loi chinoise sur le renseignement de 2017.

Points d’exposition : le backend SaaS, les diagnostics que les agents remontent à l’éditeur, les accès du support lors d’un ticket, les fonctions d’IA qui transmettent des extraits de logs à un modèle hébergé ailleurs.

Ce qui protège : un backend sous droit européen ou auto-hébergé, le masquage des données sensibles avant tout export, des clés de chiffrement détenues par le client et une passerelle qui contrôle et journalise chaque destination.

Mécanisme 2 : la coupure de service

Un outil d’observabilité peut cesser de fonctionner sans qu’aucune donnée n’ait été lue : panne de l’éditeur, sanctions, suspension de compte, dépassement de quota d’ingestion qui entraîne l’abandon de données, fin de support d’une version auto-hébergée. L’affaire de la messagerie du procureur de la CPI a rendu ce scénario concret.

Conséquence propre à l’observabilité : l’équipe perd la vue sur ses systèmes, souvent au pire moment. Une plateforme dont l’alerting dépend d’un service externe n’alerte plus quand ce service tombe.

Ce qui protège : des collecteurs qui conservent un tampon local, un backend minimal dans le périmètre pour les signaux critiques et l’alerting ; un double export vers un second backend lorsque l’enjeu le justifie.

Mécanisme 3 : le verrouillage économique et technique

C’est le risque le plus fréquent. Agents et SDK propriétaires (les bibliothèques de code fournies par l’éditeur), langages de requête spécifiques, tableaux de bord et alertes dans un format fermé, tarification à l’ingestion qui pousse à réduire la collecte : la sortie finit par coûter plus cher que le maintien.

Le Data Act supprime les frais de changement de fournisseur, y compris les frais de sortie des données, à partir du 12 janvier 2027 (article 29). Pour l’observabilité, ce n’est qu’une partie du problème : le coût réel d’une migration tient moins au transfert des données qu’à la ré-instrumentation des applications et à la réécriture des tableaux de bord et des alertes.

Ce qui protège : une instrumentation OpenTelemetry indépendante de tout éditeur, le transport en OTLP (le protocole standard d’OpenTelemetry), des tableaux de bord et des règles d’alerte gérés en tant que code (décrits dans des fichiers versionnés plutôt que configurés à la main dans l’outil) et des tests réguliers de bascule vers un autre backend.

5. Les dimensions de la souveraineté appliquées à l’observabilité

Il n’existe pas de liste officielle des « types » de souveraineté : les cabinets d’études en retiennent trois, certains fournisseurs quatre, le cadre de la Commission européenne huit objectifs. Plutôt que de chercher le bon nombre, mieux vaut regarder ce que chaque dimension contrôle dans une chaîne d’observabilité. Le tableau se lit dans les deux sens : la chaîne d’observabilité y apparaît comme un risque à maîtriser, mais aussi comme le moyen de prouver la souveraineté de toute la plateforme.

Dimension	Question clé	Risque pour la chaîne d’observabilité	Ce que l’observabilité peut prouver
Stratégique	Qui possède et dirige l’éditeur ou le projet ?	Rachat de l’éditeur, changement de licence d’un projet open source	Gouvernance des composants vérifiée : fondation neutre, capacité à maintenir un fork (une copie indépendante du projet)
Juridique	Quel droit s’applique à l’éditeur et à ses sous-traitants ?	Backend SaaS soumis à un droit extra-européen ; agents qui remontent des diagnostics	Liste des destinations réellement contactées, relevée sur une passerelle de collecte unique
Données	Où sont les logs et les traces, qui les lit, combien de temps ?	Logs non classifiés, conservés plus longtemps que les données sources, indexés ailleurs	Masquage à la source dans le collecteur, mesuré : attributs supprimés, emplacement des index
Cryptographique	Qui détient les clés ?	Flux internes en clair, chiffrement au repos avec des clés du fournisseur	Couverture mTLS (chiffrement mutuel des échanges internes), rotations de certificats, accès au KMS ou au HSM du client (ses coffres à clés)
Opérationnelle	Qui exploite et dépanne la chaîne ? Depuis où ?	Lecture des logs et des traces par le support de l’éditeur	Journal de chaque requête de lecture sur le backend, alertes sur les accès hors périmètre
Technologique	Peut-on changer de backend ?	Agents propriétaires, SDK liés à un éditeur, langage de requête fermé	Instrumentation OpenTelemetry, transport OTLP, test de bascule mesuré
Chaîne d’approvisionnement	D’où viennent les binaires des agents et des collecteurs ?	Agent téléchargé sans vérification, composants superflus, mises à jour poussées à distance	Distribution construite avec l’OpenTelemetry Collector Builder, SBOM (inventaire des composants), images signées, registre interne
Calcul et IA	Où s’exécute l’analyse assistée par IA ?	Extraits de logs envoyés à un modèle externe	Traces des appels au modèle selon les conventions GenAI d’OpenTelemetry
Infrastructure et énergie	La capacité suffit-elle à absorber les volumes collectés ?	Volumes qui croissent plus vite que l’activité	Volume par service, échantillonnage, consommation mesurée de la pile (par exemple avec Kepler, un outil open source d’estimation de la consommation électrique)
Compétences	L’équipe sait-elle exploiter sa pile seule ?	Savoir enfermé dans l’outil de l’éditeur	Configuration en tant que code, exercices d’exploitation en mode dégradé
Assurance	Peut-on prouver tout ce qui précède ?	Preuves d’audit stockées chez un tiers	Journaux d’audit immuables dans le périmètre, indicateurs calculés en continu

Deux règles de lecture :

1. Le maillon le plus faible fixe le niveau. Le cadre européen applique ce principe : le niveau global d’une offre est le plus bas obtenu sur ses objectifs. Une chaîne de collecte exemplaire ne compense pas une fonction d’IA qui exporte des extraits de logs.
2. Les dimensions s’empilent. Le tableau ci-dessous montre comment les couches reposent les unes sur les autres et ce que chacune signifie pour l’observabilité.

La souveraineté de l’observabilité s’empile, encadrée par le droit et la preuve. Chaque couche repose sur celle du dessous ; les deux dimensions transverses s’appliquent à toutes.

Couche (du haut vers le bas)	Ce qu’elle signifie pour l’observabilité
Données et cryptographie	Masquage à la source, clés du backend chez le client
Calcul et IA	Où s’exécute l’analyse par IA des logs et des traces
Exploitation et compétences	Qui exploite le backend, qui lit les logs et les traces
Technologie	OpenTelemetry, OTLP, backend interchangeable
Chaîne d’approvisionnement	Provenance des agents et des collecteurs, SBOM, signatures
Infrastructure et énergie	Stockage et énergie pour absorber les volumes collectés
Transverse : juridique et stratégique	Droit de l’éditeur, actionnariat, licences
Transverse : assurance	Journaux d’accès, audit immuable, mesure continue

Une faiblesse dans une couche basse se propage vers le haut : des logs parfaitement masqués ne protègent rien si l’agent qui les collecte accepte des mises à jour poussées par un tiers.

6. Le cadre réglementaire lu par une équipe d’observabilité

Aucun texte ne parle explicitement d’observabilité. Pourtant, presque tous la concernent, soit parce que les logs contiennent des données protégées, soit parce que l’outil d’observabilité est un prestataire, soit parce que les signaux collectés servent de preuve.

RGPD : les logs sont des données personnelles

Adresses IP, identifiants d’utilisateurs, adresses électroniques dans les messages d’erreur : les logs contiennent presque toujours des données personnelles. Leur export vers les États-Unis repose sur le Data Privacy Framework, la décision de la Commission européenne qui encadre ces transferts. C’est le troisième dispositif après le Safe Harbor (annulé en 2015) et le Privacy Shield (annulé en 2020). Il a été validé par le Tribunal de l’UE en septembre 2025, mais un appel est pendant devant la Cour de justice.

À retenir : une chaîne d’observabilité dont la conformité repose sur un mécanisme de transfert peut devenir non conforme du jour au lendemain. Le masquage à la source réduit cette exposition, il ne la supprime pas.

NIS2 et DORA : l’observabilité comme preuve et comme prestataire

NIS2, la directive européenne sur la cybersécurité, impose la détection et la notification rapide des incidents significatifs : sans logs ni traces fiables, pas de détection ni de chronologie défendable. DORA, applicable au secteur financier depuis janvier 2025, exige un registre des prestataires informatiques, une analyse de concentration (la dépendance à un petit nombre de fournisseurs) et des stratégies de sortie. Un éditeur d’observabilité SaaS est un prestataire informatique comme un autre : il entre dans ce registre et doit disposer d’un plan de sortie.

Data Act : le droit de changer d’outil

Les obligations de changement de fournisseur s’appliquent aux services de traitement de données depuis septembre 2025. Les frais de changement disparaîtront le 12 janvier 2027. Ce droit ne vaut que si l’instrumentation permet effectivement de changer de backend, ce qui renvoie à OpenTelemetry.

Cloud Sovereignty Framework : l’outil d’observabilité est évalué

Le cadre de la Commission évalue un service cloud sur huit objectifs et attribue un niveau SEAL par objectif, de 0 à 4. Il calcule aussi un score de souveraineté pondéré, qui sert à départager les offres. Son évaluation s’étend aux sous-traitants et aux couches techniques, pas seulement à l’entreprise qui répond. Un opérateur qui vise un niveau élevé ne peut donc pas confier ses données d’observabilité à un service qui le ferait redescendre.

Niveau	Signification (source)	Exemple côté observabilité
SEAL-0	Contrôle exclusif d’acteurs non européens	SaaS extra-européen, hébergé hors d’Europe
SEAL-1	Droit européen formellement applicable, application effective limitée	SaaS extra-européen dans une région européenne
SEAL-2	Droit européen applicable et opposable, dépendances non européennes importantes	Service opéré par une entité européenne sur une technologie contrôlée par un éditeur extra-européen
SEAL-3	Influence européenne forte, contrôle extérieur marginal	Pile open source auto-hébergée ou opérée par un acteur européen, sur une infrastructure européenne
SEAL-4	Technologie et exploitation entièrement sous contrôle européen	Rarement atteignable : suppose une chaîne européenne des puces aux logiciels

La colonne d’exemples est une lecture indicative, pas une classification officielle : le niveau SEAL est attribué au cas par cas, sur la base des preuves fournies.

CADA : l’IA de l’observabilité dans le champ

Le Cloud and AI Development Act, proposé le 3 juin 2026, créerait un cadre unique d’évaluation de la souveraineté pour le cloud et l’IA. Il imposerait aux organismes publics une évaluation des risques avant d’utiliser un service. Il inclut les systèmes d’IA hébergés et opérés à distance, ce qui couvre les fonctions d’analyse assistée des outils d’observabilité. Le texte n’en est qu’au début du processus législatif.

SecNumCloud : la plateforme qualifiée et son observabilité

La qualification SecNumCloud 3.2 de l’ANSSI, l’Agence nationale de la sécurité des systèmes d’information, ajoute aux exigences de sécurité une protection contre les lois extraterritoriales. La liste à jour des prestataires qualifiés est publiée par l’ANSSI. Une qualification porte sur un périmètre précis : si l’application tourne sur un service qualifié mais que ses logs et ses traces partent vers un outil qui ne l’est pas, le bénéfice de la qualification s’arrête à la frontière de ce flux.

7. Architecture de référence d’une observabilité souveraine

Une observabilité souveraine ne se résume pas au choix d’un backend. Elle repose sur une architecture dont le principe central est simple : logs, métriques et traces passent tous par un point de contrôle unique, situé dans le périmètre, avant d’aller où que ce soit. Cette architecture s’appuie sur six briques.

1. Une instrumentation neutre. Les applications sont instrumentées avec les SDK et l’auto-instrumentation OpenTelemetry (des mesures ajoutées automatiquement, sans modifier le code), jamais avec le SDK d’un éditeur. C’est ce qui rend le backend interchangeable.
2. Une collecte en deux étages. Des agents au plus près des sources (un collecteur par hôte ou par nœud) transmettent à une passerelle centrale. Les agents restent simples ; l’intelligence est concentrée dans la passerelle.
3. Une passerelle qui sert de point de contrôle. Elle masque les données sensibles avec les processeurs de rédaction (qui effacent ou masquent les champs sensibles) et de transformation du collecteur, échantillonne les traces, enrichit et route les signaux. Surtout, c’est la seule sortie : ses journaux constituent la liste opposable de tout ce qui quitte la chaîne.
4. Un backend dans le périmètre. Stockage, requêtes et alerting restent sous contrôle, sur une infrastructure qualifiée ou auto-hébergée. L’alerting critique ne dépend d’aucun service externe.
5. Un plan de contrôle maîtrisé. La configuration des agents et de la passerelle est gérée en tant que code dans Git et déployée via OpAMP, le protocole de gestion de flotte d’OpenTelemetry. Les binaires proviennent d’une distribution construite en interne avec l’OpenTelemetry Collector Builder, signée et servie depuis un registre interne.
6. Une méta-observabilité et un audit. La chaîne d’observabilité est elle-même observée : données rejetées, files saturées, exports en échec. Chaque lecture sur le backend est journalisée.

Un export vers un service externe reste possible, mais il devient une décision explicite : filtré, agrégé si possible, limité à des destinations autorisées et tracé par la passerelle. Les fonctions d’analyse assistée par IA suivent la même règle : modèle hébergé dans le périmètre de préférence, chaque appel tracé selon les conventions GenAI d’OpenTelemetry.

Cette architecture fonctionne aussi dans les environnements les plus contraints, isolés du réseau ou à sortie restreinte. L’export externe disparaît, les collecteurs stockent localement et transmettent dès qu’une fenêtre de sortie s’ouvre.

La passerelle de collecte est le point de contrôle de la souveraineté. Tout ce qui quitte le périmètre passe par elle et y laisse une trace.

flowchart LR
    subgraph P["Périmètre souverain"]
        CP["Plan de contrôle : OpAMP et Git<br/>Configuration en tant que code,<br/>distribution signée, registre interne"]
        APP["Applications<br/>SDK OpenTelemetry<br/>agents par hôte"]
        GW["Passerelle<br/>Masquage à la source<br/>Échantillonnage<br/>Journal des sorties"]
        BE["Backend<br/>Stockage<br/>Requêtes<br/>Alerting local"]
        META["Méta-observabilité<br/>Accès au backend journalisés<br/>Pertes de données mesurées"]
        CP -- configuration --> APP
        CP -- configuration --> GW
        APP --> GW
        GW --> BE
        BE --> META
    end
    EXT["Export<br/>optionnel, filtré<br/>et agrégé"]
    GW -. sortie filtrée .-> EXT

Le trait pointillé qui franchit le périmètre est la seule sortie possible : elle part de la passerelle, jamais directement d’un agent ou d’une application.

8. Les modèles de déploiement de l’observabilité

Il n’y a pas de bon modèle dans l’absolu : chacun déplace le curseur sur certaines dimensions. Le choix dépend de la sensibilité des données collectées et du niveau visé pour la plateforme observée.

Modèle	Ce qu’il apporte	Ce qu’il ne règle pas
SaaS d’un éditeur extra-européen	Mise en route rapide, fonctionnalités riches	Droit applicable, accès du support, coupure, verrouillage par les agents
Même SaaS dans une région européenne	Stockage des données en Europe	Droit applicable à la maison mère, traitements annexes (support, IA)
Service managé par un acteur européen	Droit et exploitation européens	Dépendance éventuelle à une technologie extra-européenne sous-jacente
Logiciel d’un éditeur, auto-hébergé	Données d’observabilité dans le périmètre	Licence, mises à jour et feuille de route décidées par l’éditeur
Pile open source auto-hébergée sur une infrastructure qualifiée ou sur site	Contrôle maximal, réversibilité, compatibilité avec un SEAL élevé	Compétences et capacité à prévoir ; gouvernance et licence de chaque composant à vérifier
Hybride : backend critique dans le périmètre, export filtré vers un SaaS	Alerting et données sensibles sous contrôle, outils avancés pour le reste	Discipline sur ce qui sort ; deux chaînes à exploiter
Environnement isolé ou à sortie restreinte	Aucune sortie, souveraineté maximale	Exploitation plus lourde, mises à jour à organiser hors ligne

Deux remarques complètent ce tableau :

• Le logiciel libre n’est pas souverain par nature. Plusieurs projets d’observabilité ont changé de licence ces dernières années. Un composant dont les mainteneurs, la feuille de route et la distribution binaire dépendent d’une seule entreprise peut évoluer contre l’intérêt de ses utilisateurs. La gouvernance d’une fondation neutre (la CNCF, Cloud Native Computing Foundation, pour OpenTelemetry et Prometheus) et la capacité à maintenir un fork comptent autant que la licence.
• Les modèles se combinent. Grâce à OpenTelemetry, une même instrumentation peut alimenter un backend souverain pour les signaux sensibles et un service externe pour des métriques agrégées. Le choix n’est plus figé au moment de l’instrumentation : il se fait dans la passerelle et peut évoluer.

Les acteurs et les offres disponibles pour chacun de ces modèles sont détaillés dans l’article État du marché de l’observabilité souveraine.

9. Les questions à poser à un éditeur d’observabilité

Le mot souverain est devenu un argument commercial. Les éditeurs d’observabilité n’y échappent pas. Les étiquettes se multiplient sans toujours reposer sur les prérequis techniques et juridiques, comme le montre l’analyse du livre blanc du ZenDiS allemand sur le sovereign washing, qui consiste à présenter une offre comme souveraine sans les garanties correspondantes. Les questions suivantes permettent de faire le tri.

Affirmation de l’éditeur	Question à poser	Ce qu’une réponse sérieuse contient
« Vos données restent en Europe »	Quelle entité exploite le service et à quel droit sa maison mère est-elle soumise ?	Le nom de l’entité, sa chaîne de contrôle capitalistique, le droit applicable
« Le support n’accède pas à vos données »	Comment un ingénieur du support lit-il les logs et les traces lors d’un ticket ? Depuis quel pays ?	Un mécanisme d’approbation par le client, des accès journalisés et consultables par lui
« Chiffrement de bout en bout »	Qui génère, stocke et peut utiliser les clés du stockage ?	Des clés dans le KMS ou le HSM du client, révocables par lui
« Fonctions d’IA respectueuses de vos données »	Où s’exécute le modèle et quels extraits de logs ou de traces lui sont transmis ?	La localisation de l’inférence (l’exécution du modèle), la liste des données envoyées, une désactivation possible
« Agent léger et sécurisé »	Quelles destinations l’agent contacte-t-il ? Les mises à jour sont-elles poussées à distance ?	La liste exhaustive des domaines, un mode sans mise à jour automatique, des binaires signés
« Compatible OpenTelemetry »	Peut-on n’utiliser que des SDK et collecteurs OpenTelemetry standards, sans agent propriétaire ?	Une ingestion OTLP native, sans perte de fonctionnalités essentielles
« Migration facile »	Les tableaux de bord et les alertes s’exportent-ils dans un format exploitable ailleurs ?	Un export documenté, un langage de requête répandu, un exemple de migration réelle
« Qualifié » ou « certifié »	Sur quel périmètre exact de services ? Jusqu’à quelle date ?	La référence de la qualification et son périmètre précis

Une règle simple aide à arbitrer : une promesse que le client ne peut pas vérifier lui-même ne compte pas comme une garantie. C’est précisément ce que permet la passerelle de collecte : vérifier par la mesure ce qui sort réellement, au lieu de croire ce qui est annoncé.

10. Méthode en six étapes

La démarche suivante s’applique à une plateforme existante comme à un nouveau projet. Elle commence par l’inventaire, parce qu’on ne maîtrise pas un flux qu’on n’a pas vu.

1. Inventorier les flux d’observabilité. Lister tous les agents installés, toutes les destinations configurées et tous les domaines autorisés en sortie. Croiser avec les journaux du pare-feu : les flux oubliés (agents d’un éditeur de sécurité, SDK de monitoring applicatif côté navigateur, plugins) apparaissent presque toujours à cette étape.
2. Classifier les données collectées. Leur appliquer le même niveau de classification que les données qu’elles contiennent. Des logs applicatifs d’un système de santé sont des données de santé ; des métriques agrégées d’infrastructure le sont rarement.
3. Fixer un niveau cible par classe et évaluer l’écart. Pour chaque classe, choisir un niveau visé (l’échelle SEAL peut servir de référence), puis évaluer la chaîne actuelle dimension par dimension avec le tableau de la section 5. Le niveau réel est celui du maillon le plus faible.
4. Installer le point de contrôle. Déployer la passerelle de collecte, y faire converger tous les flux, y mettre en place le masquage, puis fermer en sortie tout ce qui ne passe pas par elle. C’est l’étape qui apporte le plus de maîtrise pour le moindre effort.
5. Rendre le backend réversible. Migrer l’instrumentation vers OpenTelemetry, gérer tableaux de bord et alertes en tant que code, choisir le modèle de déploiement adapté à chaque classe (section 8), puis tester une bascule vers un second backend et mesurer sa durée.
6. Mesurer et démontrer en continu. Suivre les destinations réellement contactées, les accès au backend, le taux de masquage et les pertes de données. Revoir l’évaluation au moins une fois par an : le statut de la section 702 du FISA ou du Data Privacy Framework peut changer en quelques mois.

L’étape 6 transforme le travail des cinq précédentes en preuve. C’est aussi celle qui permet à l’équipe d’observabilité de devenir le fournisseur de preuves de souveraineté pour toute la plateforme.

Pour choisir le modèle de déploiement de l’étape 5, la carte des acteurs donne une première liste d’outils open source auto-hébergeables, avec le siège et le groupe de chaque éditeur.

Glossaire

Terme	Définition
Agent	Logiciel installé sur un hôte qui collecte les logs, métriques et traces locaux et les transmet
CADA	Cloud and AI Development Act, proposition de règlement européen de juin 2026
CLOUD Act	Loi américaine de 2018 permettant aux autorités d’exiger des données d’un fournisseur américain quel que soit leur lieu de stockage
Cloud Sovereignty Framework	Cadre d’évaluation de la souveraineté des services cloud publié par la Commission européenne en octobre 2025
Collecteur OpenTelemetry	Composant qui reçoit, transforme et exporte logs, métriques et traces ; utilisé comme agent ou comme passerelle
Data Act	Règlement européen qui impose notamment le changement de fournisseur cloud et supprime les frais de changement au 12 janvier 2027
Data Privacy Framework	Décision d’adéquation de juillet 2023 encadrant les transferts de données personnelles vers les États-Unis
DORA	Règlement européen sur la résilience opérationnelle numérique du secteur financier, applicable depuis janvier 2025
Échantillonnage	Sélection d’une partie des traces à conserver, en tête (à la création) ou en queue (une fois la trace complète)
FISA section 702	Disposition américaine autorisant la surveillance de personnes non américaines à l’étranger avec le concours des fournisseurs
HSM / KMS	Module matériel de sécurité / service de gestion des clés : là où les clés de chiffrement sont conservées
Méta-observabilité	Observation de la chaîne d’observabilité elle-même : pertes, files, exports en échec, accès
NIS2	Directive européenne sur la cybersécurité des entités essentielles et importantes
OpAMP	Open Agent Management Protocol : protocole OpenTelemetry de gestion à distance d’une flotte d’agents et de collecteurs
OpenTelemetry	Standard ouvert de la CNCF pour produire et transporter logs, métriques et traces
OTLP	OpenTelemetry Protocol : protocole standard de transport des logs, métriques et traces
Passerelle	Collecteur central par lequel transitent tous les signaux avant stockage ou export
SBOM	Software Bill of Materials : inventaire des composants d’un logiciel
SEAL	Sovereignty Effectiveness Assurance Level : niveau de souveraineté de 0 à 4 attribué par objectif dans le cadre européen
SecNumCloud	Qualification de l’ANSSI pour les services cloud, qui inclut depuis sa version 3.2 une protection contre les lois extraterritoriales
Sovereign washing	Présentation d’une offre comme souveraine sans les garanties juridiques et techniques correspondantes

Conclusion

Logs, traces et métriques forment une copie du système, produite en continu et envoyée par défaut vers l’extérieur. Tant qu’ils restent hors du champ des projets souverains, ces projets s’arrêtent à mi-chemin : la base de données est protégée, mais sa description détaillée part chez un tiers à chaque seconde.

Il n’est pas nécessaire de tout rapatrier. Il s’agit de reprendre la main sur le flux : une instrumentation neutre avec OpenTelemetry, une passerelle qui contrôle et journalise tout ce qui sort, un backend dont on peut changer et une mesure continue. Ainsi construite, l’observabilité cesse d’être un angle mort pour devenir l’instrument qui démontre la souveraineté de toute la plateforme.

Sources

• Cloud Sovereignty Framework, guide d’application (Commission européenne)
• Commission advances cloud sovereignty through strategic procurement (Commission européenne, avril 2026)
• EU CSF: Assessing Cloud Sovereignty (arc42)
• Cloud Sovereignty Framework et achats publics (cosinex)
• European Commission Publishes Proposal for Act to Reduce Reliance on Foreign Cloud and AI (Wilson Sonsini, juin 2026)
• Section 702 of the Foreign Intelligence Surveillance Act, Explained (Brennan Center)
• Microsoft backs EU Commission in EU court case on transatlantic data flows (Insight EU, juin 2026)
• European Court of Justice to Review Challenge to EU-U.S. Data Privacy Framework (WilmerHale)
• Règlement (UE) 2023/2854, Data Act, article 29 (EUR-Lex)
• Compte rendu de l’audition de Microsoft France (Sénat, 10 juin 2025)
• Microsoft confirms potential access to EU data by US authorities (it-daily)
• Microsoft’s email block a wake-up call for digital sovereignty et le démenti de Microsoft (heise, mai et juin 2025)
• AWS Launches AWS European Sovereign Cloud (Amazon, janvier 2026)
• Section 702 expiration (Axios, juin 2026)
• Bleu vs S3NS vs Scaleway (Qovery, octobre 2026)
• Sovereign Washing (ayedo, sur le livre blanc du ZenDiS)

PasserellesCe que cette page change au-delà de l'équipe technique.

BusinessValeur, coût, risque

Le coût réel d'une sortie tient moins au transfert des données qu'à la ré-instrumentation et à la réécriture des tableaux de bord et des alertes. Voir OpenTelemetry et réversibilité.

OrganisationQui décide, qui possède

L'outil d'observabilité est choisi comme un outil, pas comme un hébergement : il doit entrer dans les revues d'architecture, le registre des prestataires DORA et la classification des données.

HumainÉquipes, astreinte, compétences

Une équipe qui ne sait exploiter sa pile qu'à travers l'outil d'un éditeur perd la main le jour où l'outil est coupé. Les exercices en mode dégradé entretiennent cette compétence.

MétiersProduit, finance, risque, relation client

Des logs d'un système de santé sont des données de santé : les métiers propriétaires des données doivent valider ce qui est collecté et où cela part.

Pourquoi des passerelles →