Data, opérations et technologies : trois niveaux à maîtriser

En pratique, la souveraineté est encore souvent abordée au moment du choix d’une solution ou d’une plateforme cloud. Or, ce point d’entrée reste insuffisant pour appréhender le sujet dans sa globalité. « La souveraineté concerne à la fois la data, les opérations qui lui sont appliquées et les technologies qui les supportent » souligne Alaa Hoblos. Trois dimensions indissociables, qui n’impliquent ni les mêmes enjeux, ni les mêmes niveaux de risque.

Dans ce contexte, la souveraineté ne peut être abordée comme une question générique. Elle suppose d’entrer dans une logique d’analyse et d’arbitrage, en fonction du contexte propre à chaque organisation.

Poser le cadre : juridictions, données et criticité

La première étape consiste à qualifier concrètement ce que recouvre la souveraineté pour l’organisation. Car derrière cette notion, les réalités varient fortement d’une entreprise à l’autre. Juridictions, secteurs d’activité, criticité des données, contraintes internes sont autant d’éléments à prendre en compte. La démarche consiste alors à structurer l’analyse, en commençant par identifier le cadre juridictionnel applicable, auquel vient s’ajouter les politiques internes en matière de souveraineté.

Ce cadre posé, on peut identifier les données concernées, puis les processus qui les mobilisent. À partir de là, l’entreprise peut remonter vers les applications impliquées, les métiers impactés, et in fine qualifier le niveau de criticité pour le business. Ce cheminement permet de relier la souveraineté à la réalité opérationnelle de l’entreprise — et d’introduire une notion clé : toutes les données et tous les usages ne se valent pas.
Il conduit également à élargir l’analyse du risque. Au-delà de la visibilité ou du contrôle des accès, c’est toute la question de la dépendance opérationnelle qui est posée : qui contrôle réellement le service ? Sous quelle juridiction opère le fournisseur ? Et quelles seraient les conséquences en cas de contrainte légale ou technique imposée de l’extérieur ?

Cette dimension juridique est d’ailleurs structurante dans l’analyse. « Chez Apgar, nous travaillons avec des équipes de juristes pour qualifier précisément les juridictions applicables et sécuriser cette première étape » précise Alaa Hoblos.

Identifier ses dépendances et qualifier son niveau d’exposition

A ce stade, on quitte le terrain des intentions pour entrer dans celui de l’analyse. « À partir du moment où je sais ce qui s’applique à moi, je peux identifier mes dépendances. Et donc mes points d’exposition. »

C’est ici que l’approche d’Apgar prend tout son sens : raisonner en termes d’exposition plutôt qu’en termes de conformité. Concrètement, cela revient à cartographier l’ensemble des dépendances qui structurent le système d’information : fournisseurs cloud, applications SaaS, plateformes data, briques d’IA… mais aussi les accès, les flux, les lieux de traitement.

Ce travail révèle une réalité plus complexe qu’il n’y paraît. Derrière une solution unique se cache bien souvent un empilement de dépendances — techniques, juridiques, opérationnelles — qui échappent en partie au contrôle de l’entreprise.

« Il s’agit d’identifier où il y a de l’influence extérieure, à travers l’infrastructure, les plateformes, les applications ou les modèles d’IA. C’est ce qui permet ensuite de prioriser et d’établir une architecture cible adaptée aux enjeux de souveraineté de l’entreprise » résume Alaa Hoblos.

Un référentiel pour éclairer les choix

Pour accélérer cette phase d’analyse, Apgar s’appuie sur un référentiel de solutions structuré par région. Concrètement, il s’agit d’une base de connaissance qui recense les principaux acteurs technologiques et permet d’évaluer le niveau d’exposition associé à leur utilisation — c’est-à-dire les risques auxquels l’entreprise s’expose en termes d’accès aux données, de dépendance opérationnelle ou encore de contraintes juridiques.

L’objectif est ensuite d’identifier les dépendances, comparer les alternatives et anticiper les risques. Car une même solution peut impliquer des niveaux d’exposition très différents selon les régions. “Une solution n’est pas souveraine ou non en soi. Tout dépend du contexte dans lequel elle est utilisée.” Dans certaines zones, des contraintes locales — réglementaires ou politiques — peuvent imposer des choix spécifiques, ce qui en fait un enjeu structurant pour les entreprises internationales. “Nous n’avons pas pour ambition de proposer un catalogue de conformité, mais plutôt un outil d’aide à la décision”, précise Alaa Hoblos.

Maîtriser ses dépendances par l’architecture

Une fois cette analyse établie, l’enjeu devient de la traduire en choix concrets — et donc en architecture. Dans les faits, cette dernière repose rarement sur un choix exclusif. Elle se construit plutôt comme un assemblage de solutions et de mécanismes de contrôle : segmentation des environnements, chiffrement maîtrisé, gestion fine des accès, anonymisation des données…

L’objectif n’est pas de supprimer toute dépendance — ce qui serait illusoire — mais de reprendre la maîtrise des points critiques. Il s’agit avant tout de comprendre où se situent les risques, et de mettre en place les mécanismes adaptés pour les encadrer. « Par exemple, on peut accepter qu’une donnée soit hébergée chez un tiers, tout en conservant la maîtrise des clés de chiffrement » illustre Alaa Hoblos.

Ce type de choix reflète bien le changement de posture à l’œuvre : la souveraineté ne repose plus sur des décisions absolues, mais sur une série d’arbitrages techniques et organisationnels. Et plus les contextes varient, plus ces arbitrages deviennent complexes.

« Global design, local execution »

La complexité devient particulièrement visible dans les environnements internationaux, où les entreprises doivent composer avec des cadres juridiques et réglementaires parfois divergents, voire incompatibles.

Dans ces situations, l’enjeu n’est plus seulement de définir une architecture cible, mais de l’organiser pour qu’elle puisse s’adapter aux contraintes locales sans perdre en cohérence globale. C’est dans cette logique que s’inscrit le modèle défendu par Apgar : « global design, local execution ».

Concrètement, il s’agit de concevoir et d’implémenter au niveau central un socle commun — en termes d’architecture data, de gouvernance, de standards de sécurité et de qualité — qui définit les grands principes applicables à l’ensemble du groupe. Ce socle est ensuite instancié localement dans chaque région ou pays. Il intègre les contraintes spécifiques : exigences réglementaires, obligations d’hébergement, restrictions d’accès ou encore particularités métier. Les plateformes ne sont donc pas dupliquées à l’identique, mais adaptées dans un cadre maîtrisé.

Cette approche permet de gouverner la cohérence au sein du groupe et de s’adapter aux contraintes d’héberger et traiter les données localement. Ceci impose naturellement des choix technologiques plus stricts. Elle évite également deux écueils fréquents : une centralisation excessive, incompatible avec certaines contraintes locales, ou, à l’inverse, une fragmentation du SI, difficile à piloter et coûteuse à maintenir.

Mettre en place un socle de pilotage dans la durée

Reste une dernière réalité : la souveraineté ne se traite pas en une seule fois. Les contraintes évoluent, les technologies aussi, et les arbitrages doivent être régulièrement réévalués. “C’est un programme dans le temps, qui nécessite un pilotage » rappelle le CEO.

Ce pilotage se matérialise par des indicateurs, la mise en place de tableaux de bord et la capacité à documenter les arbitrages : quels risques ont été traités, à quel coût, avec quel impact sur les opérations ?
L’enjeu est de rendre la souveraineté lisible et pilotable, au même titre que la performance ou la sécurité, en impliquant à la fois les directions IT, les métiers et les instances de gouvernance.