La souveraineté numérique est souvent abordée par le haut : choix d'un hébergeur, d'un cloud, d'un éditeur. C'est important, mais cela laisse dans l'ombre une couche que nous voyons rarement cartographiée en entier : les flux d'intégration. Passerelles API, plateformes d'intégration, bus de messages, connecteurs SaaS, outils d'observabilité : c'est par là que circulent les données, et c'est souvent là que se cachent les dépendances que personne n'a choisies explicitement.

Cet article propose une démarche pratique pour savoir où passent vos données. Il ne constitue pas un avis juridique : les questions de conformité doivent être validées avec vos équipes juridiques et conformité.

Pourquoi la couche d'intégration est un angle mort

Plusieurs raisons expliquent que cette couche soit mal connue :

  • elle s'est construite par strates : une passerelle d'éditeur ici, une plateforme d'intégration managée là, des connecteurs ajoutés projet par projet ;
  • elle transporte sans stocker, en apparence : on oublie qu'elle journalise, met en cache, trace, et parfois réplique ;
  • ses dépendances sont indirectes : une passerelle hébergée en Europe peut envoyer ses métriques, ses journaux ou ses traces vers un service tiers situé ailleurs ;
  • les plans de contrôle sont souvent distincts des plans de données : le trafic peut rester local alors que la configuration, les statistiques ou les licences transitent par un service distant.

Ce que recouvre la question « où passent mes données ? »

Pour chaque flux, nous cherchons à répondre à quatre questions :

  1. Où les données sont-elles traitées ? Localisation physique des composants qui voient passer les données en clair.
  2. Qui opère ces composants ? L'entreprise elle-même, un prestataire, un éditeur en mode SaaS.
  3. Sous quelle juridiction est placé l'opérateur ? Un opérateur soumis à une législation extraterritoriale, comme le Cloud Act américain, peut être contraint de communiquer des données même hébergées en Europe. L'analyse précise de ce risque relève de vos juristes.
  4. Que reste-t-il après le passage ? Journaux, caches, traces, sauvegardes, données d'analyse : où sont-ils, combien de temps, et qui y accède ?

Étape 1 : cartographier les flux

On part des points d'entrée et de sortie : APIs exposées, APIs consommées, échanges de fichiers, flux événementiels. Pour chaque flux, on note :

  • l'émetteur et le destinataire ;
  • les composants traversés (passerelle, plateforme d'intégration, bus, proxy) ;
  • la nature des données (personnelles, financières, sensibles, techniques) ;
  • les services annexes alimentés (journaux, métriques, traces, alertes).

Les sources utiles : configuration des passerelles, catalogue d'APIs, schémas d'architecture (à confronter à la réalité), journaux réseau. Les schémas d'architecture sont souvent en retard sur la réalité ; la configuration réelle fait foi.

Étape 2 : identifier les dépendances non choisies

C'est l'étape qui produit le plus de surprises. Les dépendances typiques que nous cherchons :

  • un plan de contrôle SaaS pour une passerelle déployée localement ;
  • une plateforme d'observabilité externe recevant journaux et traces, parfois avec des extraits de requêtes ;
  • des connecteurs d'intégration qui transitent par l'infrastructure de l'éditeur ;
  • des vérifications de licence ou de télémétrie qui contactent un service distant ;
  • des sauvegardes ou des réplications configurées par défaut.

Aucune de ces dépendances n'est forcément un problème. Le problème, c'est qu'elle ne soit pas connue, et donc pas décidée.

Étape 3 : classer et décider

Pour chaque dépendance identifiée, on décide :

  • accepter : le risque est connu, jugé acceptable, et documenté ;
  • réduire : filtrer ce qui est envoyé (par exemple masquer les données personnelles dans les journaux), changer de région, chiffrer avec des clés maîtrisées ;
  • remplacer : par un composant opéré en interne ou par un opérateur placé sous une juridiction compatible avec vos exigences.

La décision appartient à l'entreprise ; le rôle de la cartographie est de la rendre possible.

Le lien avec DORA

Pour les entités financières concernées, le règlement DORA, applicable depuis janvier 2025, demande notamment de maîtriser les risques liés aux prestataires de services TIC : tenue d'un registre d'informations sur les accords contractuels, analyse des dépendances, stratégies de sortie pour les services qui soutiennent des fonctions critiques ou importantes. La cartographie des flux d'intégration alimente directement ces travaux, sans les remplacer. Le périmètre exact des obligations dépend de votre situation : à valider avec vos équipes conformité.

Étape 4 : préparer la réversibilité

Savoir où passent les données ne suffit pas si l'on ne peut pas changer de composant. Pour chaque brique critique de la couche d'intégration, nous vérifions :

  • que la configuration est exportable dans un format exploitable, idéalement versionnée dans Git sous une forme indépendante du produit ;
  • que les contrats d'API sont documentés indépendamment de la passerelle ;
  • qu'un scénario de remplacement a été au moins esquissé, avec ses délais.

Le délai réaliste de remplacement d'une passerelle se définit avec les équipes, selon le contexte.

Les erreurs fréquentes

  • Confondre hébergement et souveraineté. Un composant hébergé en Europe peut être opéré par un acteur soumis à une autre juridiction, ou dépendre d'un service distant pour sa configuration, ses licences ou sa télémétrie.
  • Oublier les données annexes. Les journaux, les traces et les caches contiennent souvent plus d'informations qu'on ne le pense, parfois des extraits de requêtes ou des identifiants.
  • Faire la cartographie une seule fois. Chaque nouveau connecteur, chaque nouvelle option d'observabilité peut ajouter une dépendance. La cartographie doit vivre avec le patrimoine, idéalement à partir de la configuration versionnée.
  • Traiter le sujet comme purement juridique. Les juristes qualifient le risque, mais seule l'équipe technique sait où passent réellement les données.

Ce qu'il faut retenir

La souveraineté des flux d'intégration commence par une question simple, « où passent mes données, et qui peut y accéder ? », à laquelle peu d'organisations savent répondre complètement. Cartographier, identifier les dépendances non choisies, décider explicitement et préparer la réversibilité : ces étapes ne dépendent d'aucun produit. Elles donnent une base solide aux décisions d'architecture, et aux échanges avec la conformité.

À côté du conseil, CAB Ingénierie édite STOA, iPaaS souverain, plateforme d'API et d'intégration.

Parlons de votre projet

Vous voulez savoir où passent réellement vos flux d'API et d'intégration, ou préparer la réversibilité d'une brique critique ? Décrivez-nous votre contexte en quelques lignes : cab-ingenierie.com · contact@cab-ingenierie.com