Indépendance technologique : comment les DSI reprennent le contrôle

Dans un article récemment publié par notre confrère CIO, Henri Verdier, l’ex-DSI de l'État et désormais directeur général de la fondation Inria, s’est alarmé des risques de dépendance numérique qui touchent l'ensemble de la chaîne technologique (du matériel au logiciel) des entreprises et organisations publiques. Lors d’une commission d'enquête dédiée de l'Assemblée nationale, il l'a illustré par un exemple critique : près de 80 % des nouveaux câbles sous-marins transportant les flux mondiaux de données sont aujourd'hui posés par les Gafam. Henri Verdier est même allé jusqu’à comparer la situation de certaines entreprises françaises à celle de « chauffeurs Deliveroo » : elles ne possèdent plus leurs outils et sont devenues des locataires de plateformes étrangères. De ce constat, il ne faut pas non plus tomber dans l’excès inverse en pariant sur une indépendance absolue car, comme le rappelle à juste titre Henri Verdier lors de son audition, celle-ci n’existe pas, même pour les Américains (par exemple très dépendants des terres rares de la Chine). « Tout le monde est en dépendance, la vraie question est d’être dans des équilibres de rapport de force pour que l’on ne puisse pas nous traiter comme des quantités marginales ; mais là, on n’y est pas. Il faut construire une posture, une position stratégique française et/ou européenne pour être d’égal à égal. » Pour Henri Lhomme, sur le terrain, le cœur du débat chez les DSI rencontrés n’est pas axé en soi sur le choix d’une solution américaine par rapport à une alternative européenne ; ce sont d’abord la performance, les coûts, la sécurité, l’indépendance et l’innovation qui vont driver leurs choix.

De manière générale, il reconnaît que les DSI sont un peu perdus aujourd’hui. Leur quotidien est compliqué entre l’augmentation des coûts, les réglementations à respecter, la gestion des risques, les aléas géopolitiques et l’arrivée de l’IA. Cela dit, le porte-parole observe aussi que les décideurs regardent ailleurs : vers l’open source, vers d’autres hébergeurs que les hyperscalers américains, ou vers les nouveaux acteurs de l’IA qui viennent concurrencer des géants comme Microsoft. « Le réflexe naturel d’aller vers le tout SaaS n’est plus systématique, les entreprises se posent même la question de faire par elles-mêmes », ajoute le porte-parole de Deloitte. À ce titre, le baromètre 2025 réalisé par le cabinet auprès d’une soixantaine de décideurs en France souligne que les entreprises se considèrent font face à des à difficultés de maitrise de leurs coûts qui ne cessent de croître notamment sur le Saas et du run. C’est donc dans ce contexte que le cabinet vient de créer une offre souveraine afin d’aider les organisations à reprendre le contrôle de leurs données et de leurs infrastructures stratégiques, tout en garantissant leur indépendance technologique. Cette offre se matérialise surtout par une équipe d’experts métier et technologique (avocats, spécialistes des risques, consultant, etc.) qui savent opérer en France.

Prendre enfin le taureau par les cornes

De leur côté, les pouvoirs publics semblent vouloir agir pour retrouver une certaine indépendance technologique. Dernière initiative en date : le 26 janvier dernier, durant laquelle Anne Le Hénanff, ministre chargée de l’Intelligence artificielle et du Numérique, a officiellement lancé un observatoire de la souveraineté numérique. Celui-ci a pour objectif de mesurer les dépendances numériques de la France afin de mieux les réduire par la suite. Dans le détail, ses missions seront de dresser un diagnostic partagé des dépendances critiques, de fournir des outils d’aide à la décision pour les acheteurs publics et privés et de contribuer à l’orientation des politiques publiques en matière de souveraineté numérique. Les premières analyses et restitutions auront lieu au printemps 2026 ; elles devraient nous donner un état des lieux assez précis.

À cela, le gouvernement a présenté une deuxième initiative, à savoir la création de l’indice de résilience numérique (IRN). Ce "thermomètre" consiste, via un questionnaire, à établir une cartographie précise du niveau de dépendance ou d'autonomie des organisations publiques et privées par rapport à leurs infrastructures. Difficile de dire si ces initiatives auront des impacts positifs par la suite et si elles peuvent fondamentalement changer les choses pour, un jour, corriger ce chiffre du Cigref (que nous avons toujours en mémoire) stipulant que 80 % des dépenses européennes en logiciels et en services cloud professionnels, soit 265 milliards d’euros, bénéficient à des entreprises américaines.  En attendant, le contrat liant le ministère de l’Éducation nationale à Microsoft va finalement se poursuivre jusqu’en 2029. Cette décision est clairement en contradiction avec les consignes passées aux rectorats par la direction du numérique de la rue de Grenelle, qui préconisaient de s’appuyer sur des solutions de confiance qualifiées SecNumCloud. Cela dit, signe que les choses bougent, le 24 avril dernier, la plateforme de données de santé (ex. Health Data Hub qui était hébergée dans le cloud Azure de Microsoft) sera désormais hébergée et opérée par Scaleway.

Pour Sébastien Lesimple, ancien DSI d’Outscale, ex-directeur de production IT chez Econocom et qui officie aujourd’hui en tant que DSI de transition chez Tenexa (ex-groupe Infodis) sur son programme SecNumCloud, l’indépendance technologique débute toujours par se poser la bonne question : « Le niveau zéro est déjà d’exprimer son besoin exact, de se demander ce que l’on veut vraiment à la fin ; dans le cas contraire, inutile de commencer. » Pour illustrer ce point de départ, prenons l’exemple de l’entrepreneur allemand Robert Heide, qui a créé Hank.parts, une plateforme européenne de vente de pièces détachées pour le secteur de l’automobile. Il avait en tête l’idée de bâtir l’infrastructure IT de son site uniquement avec des briques européennes. Tout est expliqué dans un article sur la page d’une SSII nommée Coinerella que notre rédaction a relayé. Il y détaille son projet, les choix technologiques retenus et les difficultés rencontrées. Sur ses motivations, il met en avant la question de la souveraineté des données, la conformité avec le RGPD, la non-dépendance aux trois grands fournisseurs de cloud et une part d’entêtement. Comme le rapporte Robert Heide sur son expérience : « C’est un effort qui en vaut la peine, mais c'est un effort tout de même… »

C’est aussi dans cette perspective que Sébastien Lesimple, à l’époque où il était chez Econocom, avait décidé de migrer plusieurs solutions sous VMware, Hyper-V et Citrix vers Proxmox. « Est-ce que je dois payer tous les ans des licences de solutions propriétaires toujours plus élevées avec des inflations délirantes ? Quand vous disposez d’un budget restreint, il faut trouver des idées intelligentes », nous avait-il expliqué. Cette volonté de changer les choses, de les inverser en mettant en avant l’indépendance technologique dans le choix des solutions, encore trop de décideurs en sont incapables. « La résistance au changement est, selon moi, le problème n°1. Dans de nombreuses entreprises, les collaborateurs sont présents depuis des années et restent bloqués dans leurs habitudes ; il faut de l’envie pour bousculer les choses. Oui, c’est compliqué de convertir des ingénieurs qui ont baigné toute leur vie dans Windows, j’en fais encore l’expérience », reconnaît Sébastien Lesimple. 

Plus généralement, certains décideurs IT ne peuvent tout simplement pas se passer de l’écosystème américain car ils n’ont pas les compétences nécessaires en interne. Certains même ne prennent pas au sérieux les développements de systèmes souverains et/ou alternatifs réalisés par certains de leurs collègues ou employés motivés, en les laissant de côté à l’état de PoC que personne n’utilisera en interne. Enfin, cette indépendance technologique nécessite des relais : des entreprises privées et autres organisations publiques capables d’investir en passant des commandes auprès des fournisseurs français et européens afin que ceux-ci puissent se développer et devenir, à leur tour, des acteurs qui comptent. Il s'agit de ne pas faire comme l’État, qui encourage certains industriels de l’armement à investir et à produire, mais qui ne passe pas commande, faute de budget.

Dans son projet d’utiliser des technologies européennes pour construire le SI de son site e-commerce Hank.parts, l’entrepreneur allemand Robert Heide a trouvé pratiquement toutes les briques. Déjà, pour la partie hébergement, il s’est tourné vers l’allemand Hetzner ; ce dernier prend en charge l'infrastructure de calcul principale (répartition de charge, machines virtuelles et stockage d'objets compatible S3). « Les tarifs de Hetzner sont incroyablement avantageux par rapport à AWS, et ses performances sont excellentes », rapporte-t-il. Ensuite, il a, en complément, sélectionné Scaleway. « J'utilise leur service de messagerie transactionnelle (TEM), le container registry, un second compartiment S3 pour des charges de travail spécifiques, leur suite d'observabilité et même leur bureau d'enregistrement de noms de domaine. Un seul fournisseur pour de multiples services : au moins, cela simplifie la facturation », explique-t-il.

Côté CDN (Content Delivery Network), il est parti sur Bunny.net, une société slovène qui propose diverses fonctionnalités (stockage distribué, DNS, optimisation d'images, WAF et protection DDoS). Il a aussi sélectionné l’allemand Hanko, qui gère l'authentification et l'identité, et Nebius, qui alimente son inférence IA (à savoir une capacité à fournir de la puissance GPU en Europe sans envoyer de requêtes à un serveur américain). Sébastien Lesimple est catégorique sur ce point : hormis la partie matérielle, au niveau du logiciel, des alternatives existent en France et en Europe. Quelques exemples : sur la virtualisation avec des offres comme Proxmox ou XCP-ng de Vates ; sur le firewall avec le français Stormshield, le suédois Clavister ou l’allemand Lancom Systems ; sur le reverse proxy en s'appuyant sur BunkerWeb ; au niveau du bastion avec l’offre The Bastion d’OVHcloud ; sur l’IAM avec Zitadel ; idem pour la partie ITSM où des solutions comme Easy Redmine sont abouties… « Il faut être prêt à basculer vers des offres open source comme Cumulus ou Sonic (ndlr : système d'exploitation réseau open source) – les codes sont auditables, nous pouvons aller voir ce qu’il y a à l’intérieur. Parfois, c’est compliqué de trouver chaussure à son pied, il faut faire des PoC, mais globalement on trouve tout ce dont on a besoin en logiciel, y compris les BIOS/UEFI avec Canoeboot », rapporte le DSI.

Open source, une option incontournable

Pugnace et déterminé comme Robert Heide, Sébastien Lesimple travaille actuellement sur un projet de PKI as a service et s’impose, dans sa feuille de route, une hiérarchie dans ses choix technologiques pour construire l'architecture. Cela commence par l’open source français : le code des logiciels est ouvert, auditable et maintenu par des acteurs sous juridiction française. « Ensuite, je me tourne vers l’open source européen : des projets — dont le code est également ouvert — doivent être développés et maintenus par des contributeurs ou des entreprises de l'Union européenne », ajoute-t-il. Puis, toujours dans le domaine de l’open source, si les deux premières étapes n’ont pas abouti, il regarde au niveau international : « des solutions communautaires globales sélectionnées sur la base de critères définis : taille critique de la communauté, ancienneté du projet et rattachement à des structures de gouvernance établies telles que la Linux Foundation. L'intégration de ces solutions implique un audit de sécurité. »

Parfois, l’open source ne se justifie pas : une technologie peut aussi être sélectionnée car elle est innovante et prometteuse pour l’avenir. Il existe aussi sur le marché, comme le rappelle le DSI, des solutions propriétaires françaises et européennes. « Pour les solutions françaises, je m’oriente d’abord vers des offres développées et hébergées en France, et conditionnées à l'obtention de certifications de sécurité par l’Anssi. Et pour les applications européennes, leur modèle doit au moins garantir l'absence de soumission à des lois extraterritoriales », précise-t-il. Enfin, pour la partie matérielle, l'usage de hardware exclusivement européen s'applique essentiellement aux modules de sécurité (HSM) et aux pare-feu. Les serveurs et les équipements réseaux standards font plutôt l'objet d'adaptations, comme l’ajout d'un BIOS/UEFI libre si disponible ou encore le remplacement du système d'exploitation des commutateurs réseaux par un OS libre, là aussi, si disponible.

Si nous revenons au projet de l’entrepreneur allemand Robert Heide dans la création de son site avec des technologies souveraines, le dirigeant admet quelques difficultés, notamment le fait de quitter l’environnement GitHub, propriété de Microsoft. « Si vous êtes un adepte de l'écosystème GitHub (actions, issues, workflows de revue de code, réseau social…), le quitter, c'est comme partir d’une ville où l'on a vécu pendant dix ans. On connaît tout par cœur », avait témoigné le dirigeant. Il ne faut pas oublier qu’une plateforme comme GitHub bénéficie d'un effet réseau, dont il est donc très difficile de se passer. Des alternatives existent bel et bien comme Bitbucket, GitLab, Framagit, Gitea, etc., mais, là aussi, de nombreux utilisateurs reconnaissent que GitHub est en avance sur de nombreux projets, sur le design aussi, sur la simplicité ainsi que sur de nombreuses fonctionnalités. Par exemple, pour Robert Heide, si Gitea est excellent, il a dû reconstruire les pipelines CI/CD ; quant aux intégrations considérées comme acquises, elles n'existent plus.

Des plateformes Apple et Google difficilement évitables 

L’entrepreneur a aussi constaté que certaines technologies américaines sont incontournables et n’ont pas d’équivalences en Europe. C’est le cas de Google Ads pour acquérir des clients ou du programme développeur d’Apple pour distribuer une application mobile. « Si vous souhaitez acquérir des utilisateurs et distribuer une application mobile, vous devez payer le prix fort à Mountain View et Cupertino. Il n'existe pas d'alternative européenne à l'App Store ou au Play Store. C'est le prix à payer pour faire des affaires », précise-t-il. Ces deux sociétés sont également une porte d’entrée pour les réseaux sociaux indispensables pour avoir de la visibilité.

Enfin, l’usage de l’IA est clairement dominé par des acteurs américains comme OpenAI, Google et Anthropic. « L'écosystème d'IA de l'UE se développe, mais pour les modèles de pointe, les options sont principalement américaines. Vous pouvez exécuter des modèles à pondération ouverte chez des fournisseurs d'inférence européens, mais si vous voulez Claude, vous devez faire un appel API transatlantique », précise Robert Heide qui voulait absolument Claude. Un dernier point que partage aussi Sébastien Lesimple : « Sur ce volet IA, les LLM propriétaires sont beaucoup plus performants que ceux en open source et vous bénéficiez aussi de toute cette partie ressources de calcul. Nous avons Mistral en France, même si son capital est très dilué. »

« La résilience, c’est la maîtrise de son avenir numérique pour surmonter des perturbations de toute nature (dépendance, pannes, aléas climatiques, défaillances tiers, compétences critiques, tensions géopolitiques ...). Pour une part importante de la gestion de nos risques, la résilience revient donc à être indépendant d’un point de vue économique, technique et commercial vis-à-vis des fournisseurs, lesquels ont justement rendu leurs offres très dépendantes grâce au SaaS et à la bundleisation. La souveraineté, plutôt associée à l’État, consiste par exemple à veiller à ce que les données relatives à ses services et prérogatives régaliennes ne soient pas dépendantes de législations extra-européennes. La distinction est claire : une entreprise peut très bien choisir une solution européenne, que l'on pourrait dire "souveraine", comme SAP tout en étant très dépendante de ce même éditeur. Par ailleurs, une entreprise internationale doit composer avec une pluralité d'exigences de souveraineté, en s'alignant sur les cadres réglementaires et les exigences spécifiques de chaque pays où elle opère », explique Laurent Tréluyer, DSI de la Cnaf. Ce constat posé, le dirigeant s’engage au sein de la Cnaf à être moins dépendant et plus souverain, la souveraineté comptant désormais pour 15 % dans le choix de ses solutions. Un exemple l’illustrant est celui de la migration de l’actuel moteur de règles (élément central du SI de la Cnaf) sous Oracle depuis 2019 vers l’offre open source Catala de l’Inria, l’une des premières briques du programme Apollo de construction de systèmes d'information pour les administrations. À ce titre, les développeurs de la Cnaf et de l’Inria travaillent en étroite collaboration pour enrichir la solution, notamment sur la partie gouvernance. Autre exemple : la migration de 3 500 postes en libre-service à destination des allocataires de Windows vers Linux Ubuntu. Ce projet, opéré par l’allemand Igel, a entraîné quelques difficultés à résoudre, dont la gestion des imprimantes. À cela, d’autres orientations vers des solutions souveraines ont été prises, comme celle d’Oodrive pour la signature électronique, de Troov pour la prise de rendez-vous simplifiée ou encore de Polaria pour son chatbot boosté à l’IA de Mistral et hébergé chez OVHcloud.

Souveraineté mais pragmatisme 

L’un des autres projets de Laurent Tréluyer est de sortir à terme de Broadcom VMware, ou du moins en partie. Toutefois, pour une structure comme la Cnaf, c’est un processus long, « de l’ordre de 5 à 6 ans » estime le dirigeant. Ses équipes mènent actuellement des tests sur diverses alternatives comme XCP-ng, Proxmox, etc. Toutes ces initiatives ne font, bien sûr, pas de Laurent Tréluyer une personne arc-boutée et retranchée derrière une indépendance et une souveraineté absolues. Pragmatique, il recherche les meilleures solutions du marché pour répondre aux besoins de la branche Famille et aux enjeux du service public. Sur le volet décisionnel, il se félicite notamment du fonctionnement de Databricks sous Azure, bien qu'il ait interrogé l'éditeur sur la possibilité d'un autre hébergement. « Il faut trouver le bon compromis entre les composants du marché et le fait d’avoir une certaine indépendance », précise-t-il. 

En interne, le DSI admet qu’il faut expliquer tous ces changements et arbitrages : « Pourquoi je ne prends pas la "meilleure" solution ? C'est ce critère qui fait que nous sommes amenés à en choisir d’autres. De même, sur le projet Catala, nous avons créé des équipes de développeurs intéressées malgré les difficultés ; tous ne connaissent pas le langage OCaml (NDLR : anciennement connu sous le nom d'Objective Caml). Même chose pour Linux sur nos postes de travail pour les allocataires : cela demande une certaine adaptation, mais cela nous permet de monter en compétences et de continuer, pourquoi pas, sur d’autres sujets », conclut Laurent Tréluyer.

 *Cnaf, la Caisse nationale des Allocations familiales qui gère diverses prestations sociales (des allocations familiales au RSA en passant par l'aide aux personnes handicapées). La Cnaf et les Caf /CSS ou caisses de sécurité sociale, emploient 35 000 collaborateurs dont 884 au sein de la DSI.

Une démarche de gouvernance

La donnée peut aujourd’hui être considérée comme un actif industriel à part entière. La produire, la transformer et l’exploiter suppose des infrastructures, des outils et des chaînes de traitement — en d’autres termes, de véritables “usines de données”. Or, toute entreprise industrielle sait à quel point le choix d’implantation d’une usine est stratégique. On ne l’arbitre jamais uniquement sur des critères de coût, mais aussi en fonction de la stabilité politique, des cadres réglementaires, des accords commerciaux ou des risques géopolitiques. Il en va désormais de même pour la donnée.

Ainsi, l’enjeu n’est plus seulement où se situe la data, mais quels risques son hébergement et son traitement impliquent — et s’ils sont acceptables au regard de leur criticité. C’est en cela que la souveraineté doit être perçue comme une véritable démarche de gouvernance.

La souveraineté ne se décrète pas : elle s’évalue

Parler de souveraineté implique de dépasser les slogans pour revenir à des critères concrets. Si la localisation des données reste un repère, elle ne constitue qu’un élément parmi d’autres. Il faut nécessairement y associer la dimension juridique : à quel cadre réglementaire et à quelle juridiction sont soumis les acteurs avec lesquels je travaille ? La question est centrale, comme l’illustre le Cloud Act américain, une loi à portée extraterritoriale qui peut contraindre des fournisseurs soumis au droit américain à transmettre des données, même stockées en Europe.

A cela s’ajoute la dimension technologique : suis-je dépendant d’un fournisseur dont je ne maîtrise ni les évolutions ni les contraintes ? Suis-je en situation de vendor lock-in ? Enfin, les aspects opérationnels ne doivent pas être sous-estimés : ai-je les compétences, les ressources et les moyens de piloter ces systèmes moi-même ?

Au fond, la souveraineté se joue dans la capacité réelle à garder la maîtrise dans des situations concrètes, notamment lorsqu’un incident survient ou qu’un arbitrage critique s’impose. Qui peut intervenir, décider, prioriser, rétablir ? Lorsque cette latitude est limitée, on ne parle pas nécessairement d’un problème, mais d’un risque. Un risque qui peut être acceptable, à condition d’être clairement identifié, évalué et assumé au regard des enjeux métiers — comme toute autre catégorie de risque dans l’entreprise.

Sortir du “tout ou rien” 

L’un des principaux écueils est la tentation du “tout ou rien”. Soit une souveraineté totale, soit aucune. Cette approche est clairement irréaliste. Aucune grande entreprise internationale ne pourra fonctionner uniquement avec des solutions locales, parfaitement souveraines, sur l’ensemble de son système d’information. La complexité, les coûts et les enjeux d’innovation rendent cette option impraticable.

À l’inverse, reléguer les enjeux de souveraineté au second plan revient à accepter des dépendances non maîtrisées, avec des conséquences potentiellement majeures. La seule voie viable est donc celle de la classification et de l’adaptabilité.

Cela suppose d’être capable de cartographier ses usages, ses flux et ses données, puis de les classer en fonction de leur criticité. Certaines données peuvent être traitées dans des environnements moins souverains, parce qu’elles ne présentent pas de risque majeur. D’autres, en revanche, nécessitent un niveau de maîtrise beaucoup plus élevé.

Dans certains cas, il sera pertinent de conserver des solutions existantes, notamment lorsqu’elles apportent un avantage technologique significatif. Dans d’autres, une approche hybride permettra de concilier performance et maîtrise, en développant particulièrement les questions de portabilité et de réversibilité. Enfin, pour les usages les plus critiques, des architectures plus souveraines s’imposeront.
Loin d’être un principe abstrait, la souveraineté apparaît ainsi comme une série de choix concrets, alignés sur la stratégie de l’entreprise.

La donnée : un décalage de maturité ?

La question mérite en effet d’être posée. Car si la souveraineté suppose une maîtrise fine des actifs critiques, toutes les composantes du système d’information n’ont pas atteint le même niveau de maturité.

Sur les systèmes ERP, les entreprises disposent aujourd’hui d’un réel savoir-faire. Elles ont appris à gérer la complexité, à composer avec des contraintes locales. A l’inverse, la donnée reste souvent moins structurée et moins gouvernée. Ces dernières années, la tendance a été de centraliser les données dans des plateformes unifiées, souvent hébergées dans le cloud, afin de faciliter les analyses et le développement des usages.

Les gains en efficacité ont été indéniables. Mais cette centralisation s’est parfois opérée au prix d’une perte de maîtrise et de l’apparition de nouvelles formes de dépendance — précisément là où les enjeux de souveraineté deviennent les plus sensibles.

Les entreprises doivent désormais faire évoluer cette approche. Toutes les données n’ont pas vocation à être centralisées au même endroit. Certaines doivent rester localisées, protégées, voire “décriticisées” avant d’être partagées. Cela suppose de repenser les architectures de données en s’inspirant des pratiques éprouvées sur les ERP : une distribution maîtrisée, adaptée aux contraintes locales, avec des mécanismes d’agrégation permettant de conserver une vision globale sans exposer les données sensibles.

Cette évolution va inévitablement complexifier les systèmes d’information. Mais c’est le prix à payer pour retrouver un véritable niveau de maîtrise.

Une démarche pragmatique, pas idéologique

En définitive, il faut sortir des postures idéologiques. La souveraineté numérique relève avant tout d’une démarche pragmatique : comprendre son écosystème, évaluer ses risques et prendre des décisions en conséquence. Elle suppose une véritable gouvernance, portée au plus haut niveau de l’entreprise. Mais également des outils, des méthodes et une capacité à accompagner les transformations nécessaires.

Elle implique enfin un changement de regard : accepter que nous évoluions dans un environnement plus complexe, plus fragmenté et plus incertain. Dans ce contexte, la capacité à faire des choix – en connaissance de cause – devient un avantage stratégique.

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.

1/ Assessment & diagnostic : établir une vision claire de son exposition

L’accompagnement d’APGAR débute par une phase d’assessment qui constitue le socle de la démarche. Cette analyse croise contraintes métier, réglementaires et géopolitiques : organisation, empreinte géographique, nature des activités et des données. « Un groupe fortement centralisé ne sera pas confronté aux mêmes enjeux qu’une organisation composée d’entités locales autonomes », rappelle Frédéric Robert. Les entreprises présentes sur plusieurs zones doivent ainsi composer avec des cadres juridiques parfois incompatibles, imposant une approche différenciée selon les régions et la nature des données.

Cette phase vise aussi à reprendre la maîtrise d’un existant souvent partiellement connu. Entre architectures historiques, empilement d’outils et shadow IT, la visibilité sur les contours réels du SI est parfois défaillante. « Nous sommes de plus en plus confrontés à des usages non maîtrisés de l’IA », observe Frédéric Robert.
Pour redonner de la visibilité, APGAR s’appuie notamment sur un vendors registry, un référentiel des fournisseurs et services utilisés, qui permet une première lecture structurée de l’existant et des dépendances.

Cette cartographie — données, métadonnées, outils, implantations — constitue un préalable pour qualifier les risques. Elle permet également d’identifier, très en amont, les brèches de souveraineté nécessitant une attention immédiate.

Enfin, l’assessment pose un principe clé : la souveraineté se raisonne par niveaux d’exigence. L’objectif n’est pas de tout “souverainiser”, mais de concentrer les efforts là où les enjeux sont critiques. « Si la démarche fait exploser le TCO, elle devient irréaliste. Il faut arbitrer », rappelle Frédéric Robert. Ces arbitrages s’appuient sur la nature et la criticité des données, mais aussi sur les contraintes réglementaires et les réalités opérationnelles.

2/ Stratégie & roadmap : structurer une trajectoire réaliste

Une fois l’exposition cartographiée, l’enjeu est de traduire les arbitrages issus du diagnostic en un cadre opérationnel : entités concernées, métiers, typologies de données. « Comme dans les référentiels ISO, il faut définir très précisément le périmètre », souligne Frédéric Robert.

Sur cette base, APGAR construit une roadmap priorisée, structurée par zones géographiques, types de données et niveaux de criticité. Cette trajectoire peut se décliner en plusieurs scénarios — d’une cible ambitieuse, visant un haut niveau d’exigence et une réduction maximale des dépendances, à une approche plus pragmatique, centrée sur les actifs critiques et les contraintes les plus fortes, en passant par des trajectoires intermédiaires.

Au-delà des choix techniques, cette phase engage l’organisation. Répartition des responsabilités, évolution des rôles, adaptation des processus : les impacts doivent être anticipés dès le cadrage. « On doit pouvoir visualiser très tôt la charge que cela va représenter pour l’organisation », précise l’expert.

Enfin, la transformation s’inscrit dans le temps long. « Nous ne sommes pas sur un projet de quelques mois, mais sur une trajectoire multi-annuelle. » Elle se construit par étapes, avec des phases intermédiaires et des ajustements progressifs.

3/ Architecture cible & sélection des vendors : raisonner en écosystème

Une fois la stratégie définie, l’enjeu n’est pas de choisir immédiatement des solutions, mais de structurer une architecture cible. « La souveraineté se joue rarement à l’échelle d’une solution isolée, mais d’un ensemble de briques interconnectées », rappelle Frédéric Robert.

Cette architecture cible s’atteint progressivement, étape par étape. La première consiste à formaliser des patterns d’architecture, en fonction des cas d’usage, des métiers ou des régions. Il s’agit de définir les capacités attendues, les niveaux de souveraineté requis et les conditions dans lesquelles ces exigences peuvent être tenues. Ce travail permet de poser un cadre structurant, et surtout de poser les bonnes questions avant même de parler de fournisseurs.

C’est à partir de cette architecture que se construisent les critères de décision. Juridiction, modalités de traitement des données, dépendances technologiques ou conditions d’accès deviennent des variables d’évaluation, permettant de comparer les fournisseurs de manière objective, au regard des besoins réels.

Dernier point clé : confronter cette cible à la réalité du marché. Toutes les solutions ne sont pas disponibles dans toutes les zones, notamment sur des sujets comme l’IA. « Si aucune alternative n’existe sur une région, il faut adapter l’approche », poursuit Frédéric Robert. L’architecture cible reste ainsi un cadre évolutif, ajusté en continu aux contraintes d’offre comme aux priorités de l’organisation.

4/ Mise en œuvre et migration : confronter la stratégie au réel

C’est dans cette phase que la stratégie se heurte à la réalité opérationnelle. La souveraineté ne se déploie pas sur un terrain vierge : elle s’inscrit dans un existant hétérogène, souvent plus complexe qu’anticipé.

La mise en œuvre consiste à traduire l’architecture cible en trajectoire concrète, en définissant les étapes de transition : migration des données, transformation des usages, coexistence entre environnements. « On passe souvent par des phases hybrides avant d’atteindre la cible », souligne Frédéric Robert. C’est aussi à ce stade que les écarts apparaissent entre la vision définie sur le papier et la réalité des dépendances : environnements mal maîtrisés, actifs non identifiés, interconnexions sous-estimées.

La question de la portabilité devient alors centrale. Il ne s’agit pas seulement de déplacer des données, mais de reproduire des usages, des configurations et des dépendances dans un nouvel environnement. Cela suppose une connaissance fine de l’existant, qui fait parfois défaut… Définir des niveaux de portabilité, anticiper les scénarios de réversibilité et avoir la capacité de revenir en arrière font partie intégrante de la démarche. Cette phase impose ainsi un travail de fond pour reprendre le contrôle sur le système d’information : comprendre les dépendances réelles, documenter les configurations, sécuriser les transitions.

Enfin, le décommissionnement des anciens environnements constitue un point critique. Au-delà de la migration, il s’agit de s’assurer que les données ont bien été supprimées chez les anciens fournisseurs, que les usages résiduels ont été identifiés et que rien ne subsiste dans l’ombre.

5/ Gouvernance, compliance & acculturation : inscrire la souveraineté dans la durée

Dernière étape, et condition de réussite : structurer une gouvernance capable de faire vivre la souveraineté dans le temps. « Le cadre est global, mais l’exécution est locale », rappelle Frédéric Robert.

L’enjeu consiste à articuler un cadre commun avec des déclinaisons locales adaptées aux contraintes réglementaires, aux organisations et aux usages. Cela suppose de clarifier les responsabilités entre IT, data, métiers et entités locales, et de mettre en place des instances d’arbitrage capables de trancher sur des sujets souvent transverses.

Cette démarche devient pilotable à travers des indicateurs. Niveaux de service, conformité, réduction de l’exposition au risque sont autant de métriques qui permettent de suivre les progrès et d’inscrire la souveraineté dans une logique d’amélioration continue.

Autre levier structurant : les processus d’achat. La souveraineté s’intègre désormais en amont des décisions, aux côtés du coût et de la performance. Chaque acquisition doit être évaluée au regard de son niveau de criticité, de son alignement avec le cadre global et des risques qu’elle introduit. « Il faut intégrer ces critères sans bloquer la capacité d’innovation. » L’objectif est double : éviter les contournements et limiter l’émergence de nouveaux Shadow IT.

Enfin, ne perdons pas de vue que la souveraineté repose aussi sur la capacité de l’organisation à faire évoluer ses pratiques. Elle implique un véritable travail de conduite du changement, pour aligner les usages avec les principes définis et garantir leur appropriation dans la durée.

Formation, sensibilisation et accompagnement des équipes sont essentiels pour intégrer ces exigences dans les pratiques quotidiennes. L’enjeu est d’assurer une cohérence d’ensemble et d’éviter les écarts entre le cadre défini et la réalité opérationnelle, au sein des équipes comme chez les partenaires amenés à manipuler les données.

Commencez votre assessment ici >>

[1] Lien vers Tribune

[2] Lien vers article n°2