Le 23 juillet 2026, Atos a annoncé une plateforme cloud conçue et opérée dans l’Union européenne. Le 27 juillet, Orange et Morrison ont présenté un projet de coentreprise française visant 400 MW de capacité et soutenu par un programme d’investissement de 3 milliards d’euros. Ces annonces confirment que la souveraineté numérique devient un argument commercial majeur — mais elles ne dispensent pas les entreprises de définir ce qu’elles veulent réellement contrôler. « Atos launches Atos Sovereign Cloud » et « Orange et Morrison annoncent un projet de création de coentreprise de data centers » détaillent ces deux initiatives.
Pour un dirigeant, le sujet n’est donc pas de choisir entre « souverain » et « non souverain » sur la foi d’une brochure. Il consiste à déterminer quelles dépendances sont acceptables, quelles preuves doivent être exigées et comment sortir du service si les conditions changent.
La promesse qu’on entend partout : reprendre le contrôle grâce au cloud souverain
Le discours dominant est cohérent : en choisissant un cloud hébergé et exploité en Europe, l’entreprise protégerait ses données contre les législations extraterritoriales, renforcerait sa cybersécurité et réduirait sa dépendance aux grands fournisseurs internationaux.
La promesse inclut généralement quatre dimensions :
- les données et leurs sauvegardes restent dans un périmètre géographique défini ;
- les opérations d’administration et de support sont réalisées depuis l’Europe ;
- l’environnement est protégé contre certaines injonctions provenant d’États tiers ;
- les applications peuvent être déplacées vers une autre infrastructure si nécessaire.
Ce discours répond à de vraies préoccupations : dépendance technologique, continuité d’activité, confidentialité des données sensibles et maîtrise des sous-traitants. Il est particulièrement pertinent pour les systèmes financiers, industriels, RH ou de recherche dont l’indisponibilité ou la divulgation aurait un impact direct sur l’entreprise.
Mais l’étiquette « cloud souverain » ne constitue pas, à elle seule, une architecture, une garantie contractuelle ou un plan de continuité.
Ce qui est vrai : certaines offres apportent des garanties solides
Une offre correctement qualifiée peut effectivement réduire plusieurs risques. Le référentiel SecNumCloud de l’ANSSI couvre des exigences techniques, opérationnelles et juridiques destinées notamment à protéger les traitements sensibles contre la cybercriminalité et certaines lois extraterritoriales.
L’ANSSI précise toutefois qu’une qualification concerne une offre déterminée, et non l’ensemble d’un fournisseur ou le bâtiment qui héberge ses serveurs. Elle indique également qu’un service numérique installé sur une infrastructure qualifiée n’hérite pas automatiquement de cette qualification. Ces distinctions sont détaillées dans la FAQ officielle sur la qualification SecNumCloud.
La localisation conserve également une utilité réelle. Elle facilite l’identification du droit applicable, la documentation de la chaîne de sous-traitance et la définition des lieux autorisés pour les données, les sauvegardes et les journaux. La CNIL rappelle néanmoins que le client reste généralement responsable des traitements qu’il met en œuvre et de la configuration du service, comme l’explique sa fiche « Quelles qualifications pour les acteurs de l’informatique en nuage ? ».
Autrement dit, une infrastructure de confiance constitue une base plus robuste. Elle ne sécurise pas automatiquement les droits d’accès, les applications, les comptes administrateurs ou les échanges avec le reste du système d’information.
Ce qui est faux, ou seulement vrai sous conditions
« Les données sont en France, donc nous sommes souverains »
C’est vrai uniquement si l’entreprise sait aussi où se trouvent les sauvegardes, les métadonnées, les journaux techniques, les outils de supervision et les équipes capables d’administrer la plateforme.
Le contrat doit identifier les sous-traitants ultérieurs, les pays depuis lesquels une intervention est possible et les conditions d’accès exceptionnel. Une adresse de data center ne répond pas à ces questions.
« Une offre souveraine supprime la dépendance fournisseur »
Elle peut réduire une dépendance juridique tout en créant une dépendance technique. Une application construite autour d’une base de données propriétaire, d’un système d’identité spécifique ou d’outils d’observabilité impossibles à reproduire restera coûteuse à déplacer.
La portabilité annoncée doit donc être démontrée par un export complet, une documentation exploitable et un test de restauration hors de la plateforme d’origine. Une clause promettant la réversibilité ne prouve pas que l’application redémarrera ailleurs.
« Une qualification sécurise automatiquement nos applications »
L’ANSSI indique explicitement que SecNumCloud ne préjuge pas du niveau de sécurité du service numérique du client hébergé sur l’offre qualifiée. Une mauvaise gestion des identités, un compte administrateur partagé ou une application vulnérable restent dangereux sur une infrastructure qualifiée.
« Il faut tout migrer vers une offre souveraine »
La souveraineté doit être proportionnée à l’impact métier. Déplacer sans distinction le site institutionnel, le CRM, les données industrielles et le système de paie alourdit les coûts sans traiter les risques de manière rationnelle.
Le prolongement utile de notre checklist de migration vers le cloud consiste donc à ajouter un critère de souveraineté à chaque charge de travail, et non à imposer une cible unique à tout le système d’information.
Ce que ça coûte quand on y va sans préparation
Le premier coût est une migration qui déplace la dépendance au lieu de la réduire. L’entreprise change de fournisseur, mais reproduit les mêmes couplages techniques, parfois avec moins de services disponibles et davantage de développements spécifiques à maintenir.
Le deuxième coût est le fonctionnement en double. L’ancien environnement reste actif parce que les interfaces, les sauvegardes ou les procédures de reprise n’ont pas été validées. Les équipes paient alors deux infrastructures et doivent surveiller deux chaînes d’exploitation.
Le troisième coût apparaît lors de la sortie. Le Data Act européen encadre le changement de fournisseur et prévoit la disparition des frais de changement imposés par les prestataires à partir du 12 janvier 2027. Il n’élimine cependant ni les pénalités proportionnées de résiliation anticipée, ni le coût d’un intégrateur chargé de transformer et de réinstaller les applications. Le détail figure dans le règlement européen sur les données.
Prenons un scénario type, à titre d’illustration : un ERP est déplacé vers une nouvelle plateforme sans tester la restauration de sa base sur un environnement secondaire. Au renouvellement du contrat, la direction découvre que l’export est techniquement possible, mais que plusieurs composants applicatifs doivent être remplacés. La réversibilité existe sur le papier ; la sortie opérationnelle, elle, devient un projet de transformation.
Enfin, une décision exclusivement technique peut créer une dette de gouvernance. Personne ne sait alors qui peut accepter un nouveau sous-traitant, autoriser une région supplémentaire ou arbitrer entre continuité, coût et souveraineté. C’est précisément le type d’angle mort qu’une stratégie numérique structurée doit éviter.
La façon raisonnable d’y aller
1. Classer les charges de travail par conséquence métier
Entre le lancement de l’étude et le premier comité d’engagement, le dirigeant sponsor demande au DSI, aux responsables métiers et au juriste de produire un registre des applications. Pour chacune, le livrable indique le propriétaire métier, les données traitées, l’impact d’une interruption, les contraintes juridiques et la solution de sortie envisagée.
L’objectif n’est pas d’étiqueter toutes les données « sensibles », mais de réserver les exigences les plus fortes aux systèmes dont la compromission ou l’arrêt affecterait réellement l’entreprise.
2. Transformer le mot « souverain » en preuves vérifiables
Pendant la consultation fournisseur, les achats et la DSI construisent une matrice de preuves : portée exacte des qualifications, localisation des données et métadonnées, identité des opérateurs, chaîne de sous-traitance, contrôle des clés, modalités d’audit et procédure applicable en cas d’injonction étrangère.
Toute réponse commerciale doit être accompagnée d’un document contractuel, d’un certificat ou d’une description d’architecture. À défaut, il s’agit d’une intention, pas d’un engagement.
3. Tester la sortie avant de signer l’entrée
Avant la signature, puis pendant la recette, l’architecte et le responsable applicatif réalisent un export représentatif et une restauration sur un environnement distinct. Le livrable attendu comprend les fichiers exportés, les dépendances non exportables, les étapes de reconstruction et les personnes responsables de chaque opération.
Ce test doit porter sur l’application et ses données, mais aussi sur les identités, les journaux, les sauvegardes, les secrets et les interfaces avec l’ERP ou le CRM.
4. Contractualiser le contrôle opérationnel
Pendant la négociation, le juriste et les achats annexent au contrat une matrice précisant les délais de restitution, les formats d’export, l’effacement des copies, le traitement des sauvegardes, les changements de sous-traitants, les révisions tarifaires et les conditions d’assistance à la sortie.
Le contrat doit également désigner l’autorité interne qui accepte une évolution importante. Si votre entreprise ne dispose pas d’un pilotage IT permanent, l’article consacré au DSI à temps partagé présente une organisation possible.
5. Migrer par vagues réversibles
De la première vague jusqu’au passage en exploitation, l’équipe projet commence par une application dont les interfaces et la restauration peuvent être vérifiées sans exposer un processus vital. Le passage de la vague suivante dépend d’une recette formelle : sécurité, performance, sauvegarde, reprise, supervision et sortie.
Cette progression évite de confondre signature d’un contrat cloud et maîtrise de la transformation. Elle doit être pilotée avec des décisions documentées, un responsable métier par application et des critères d’arrêt explicites.
Notre position chez D1 Consulting
Nous considérons le cloud souverain comme une réponse pertinente à des risques identifiés, pas comme une destination obligatoire pour l’ensemble du système d’information. Une entreprise conserve le contrôle lorsqu’elle peut prouver qui administre ses données, comprendre ses dépendances et faire fonctionner ses applications ailleurs.
Notre offre de Direction de projet IT permet de cadrer la sélection, organiser la recette, tester la réversibilité et piloter une migration par vagues sans laisser la décision au seul fournisseur. Notre rôle est aussi de signaler les applications qui n’ont pas besoin d’une cible souveraine coûteuse et celles qui, au contraire, exigent des garanties renforcées.
👉 Réservez votre diagnostic gratuit de 30 minutes pour identifier vos charges de travail critiques et définir les preuves à exiger avant votre prochain contrat cloud.
