SAP Sovereign Cloud via Bleu : souveraineté opérationnelle, dépendance technologique
Date de publication : 20 mars 2026 Thématique : Souveraineté numérique, cloud, politique industrielle Format : Analyse politique et technique
Résumé exécutif
Le 19 mars 2026, SAP a annoncé le lancement de "SAP Sovereign Cloud" en France, opéré via Bleu, la coentreprise formée par Orange et Capgemini pour distribuer les services Microsoft Azure dans un cadre de confiance. L'annonce, faite à Roland-Garros lors du SAP Connect Day, mobilise un vocabulaire de souveraineté qui mérite un examen rigoureux. La souveraineté opérationnelle revendiquée est juridiquement défendable dans les limites du référentiel SecNumCloud 3.2 : Bleu est une entité de droit français, son personnel est européen, et l'ANSSI a validé la trajectoire de qualification. Deux tensions analytiques méritent cependant d'être examinées. La première tient à la portabilité de S/4HANA : l'éditeur déploie son ERP sur AWS, GCP ou des infrastructures OVHcloud déjà qualifiées SecNumCloud, ce qui fait du choix d'Azure une décision stratégique, non une contrainte technique. La seconde tient à la nature de la dépendance résiduelle : souveraineté opérationnelle et souveraineté technologique ne se confondent pas, et la stack Azure reste la propriété intellectuelle d'une entreprise de droit américain. Cette analyse examine les facteurs qui expliquent le choix et ses implications pour la politique française de souveraineté numérique.
Introduction : une annonce qui tranche une ambiguïté tout en en créant une autre
Pendant plusieurs mois, les clients français de SAP ont nourri une inquiétude légitime. L'éditeur allemand, qui occupe une position centrale dans les systèmes d'information de la plupart des grandes entreprises et administrations françaises, tardait à préciser sa feuille de route souveraine dans un contexte marqué par deux évolutions simultanées : l'abandon du niveau "high+" dans l'European Union Cybersecurity Scheme on Cloud Services (EUCS) sous l'effet d'un lobbying transatlantique bien documenté, et la montée en puissance des exigences réglementaires françaises pour les secteurs sensibles.
Ce 19 mars 2026, SAP a levé l'ambiguïté. L'éditeur s'adossera à Bleu pour ses charges critiques françaises. Le choix est cohérent sur le plan réglementaire : Bleu est l'acteur le plus avancé sur le segment du cloud de confiance adossé à une technologie Microsoft, avec deux jalons SecNumCloud franchis (J0 en avril 2025, J1 en novembre 2025) et une qualification J2 visée pour le second semestre 2026. SAP dispose d'un précédent allemand, Delos, bâti sur le même modèle Azure opéré par une entité nationale indépendante de Microsoft, ce qui accélère la transposition française.
Ce que l'annonce ne dit pas, c'est qu'une infrastructure qualifiée SecNumCloud opérée sur stack open source, avec des serveurs certifiés SAP HANA, existait déjà chez OVHcloud. L'éditeur a préféré Azure via Bleu. Comprendre pourquoi, et ce que cela implique pour la politique de souveraineté numérique, est l'objet de cette analyse.
I. L'architecture du montage : ce que Bleu est, et ce qu'il n'est pas
1.1 La structure juridique et capitalistique
[Fait établi] Bleu est une coentreprise créée en janvier 2024 par Orange et Capgemini, deux entreprises de droit français. Microsoft n'en détient aucune part au capital. La société est donc bien, au sens strict du droit des sociétés, une entité française indépendante.
[Fait établi] Cette structure repose sur un accord technologique avec Microsoft : Bleu distribue et opère les services Microsoft Azure et Microsoft 365 dans un environnement physiquement localisé en France, au sein de datacenters exploités depuis des centres opérationnels à Paris et Rennes, avec un personnel exclusivement européen.
[Lecture analytique] La séparation entre propriété du capital (française) et propriété de la technologie (américaine) est la clé de voûte intellectuelle du dispositif. Elle permet à Bleu de solliciter la qualification SecNumCloud 3.2, dont les critères portent sur le prestataire (sa nationalité, son autonomie opérationnelle, l'absence d'accès des sous-traitants non européens aux données clients) et non sur l'origine du code source. L'ANSSI, par la voix de son directeur général Vincent Strubel, a clairement indiqué que rien dans l'analyse de l'agence ne s'oppose à cette qualification.
[Fait établi] Orange est détenue à hauteur d'environ 23 % par l'État français (via Bpifrance et l'APE). Cette participation étatique donne à l'accord Bleu une dimension de politique industrielle implicite : l'État est indirectement actionnaire d'un opérateur qui distribue des services Microsoft Azure aux administrations et aux OIV français. Cette configuration n'a suscité aucun débat public notable.
1.2 Ce que la qualification SecNumCloud couvre effectivement
[Fait établi] Le référentiel SecNumCloud 3.2, actualisé en mars 2022, impose notamment : le stockage et le traitement des données sur le territoire de l'Union européenne ; un prestataire dont le siège social et la capitalisation sont européens ; l'absence d'accès aux données par les sous-traitants non européens ; et la démonstration de l'autonomie opérationnelle, c'est-à-dire la capacité à exploiter la solution sans intervention extérieure.
[Fait établi] S3NS, la coentreprise entre Thales et Google Cloud, a obtenu la qualification SecNumCloud 3.2 en janvier 2026 pour son offre PREMI3NS. Ce précédent confirme la compatibilité du modèle "cloud hybride" (technologie GAFAM opérée par une entité européenne indépendante) avec le référentiel de l'ANSSI. Bleu vise la même qualification pour le second semestre 2026.
[Lecture analytique] La qualification SecNumCloud offre deux protections concrètes. La première est la protection contre la captation directe des données par une autorité extraterritoriale : un juge américain ne peut pas ordonner à Bleu de lui remettre des données, Bleu n'étant pas soumis à la juridiction américaine. La seconde est la protection contre le "kill switch" : si Microsoft décidait de couper l'accès à Azure, Bleu ne serait pas juridiquement tenu de suivre cette injonction. Ces protections sont réelles pour les scénarios courants.
[Inférence] Ces protections sont néanmoins bornées. L'ANSSI elle-même a reconnu en janvier 2026 que S3NS et Bleu ne pourraient maintenir en condition opérationnelle leur solution que six à douze mois en l'absence de mises à jour. Ce chiffre constitue la mesure la plus précise disponible de l'autonomie technologique réelle de ces offres.
II. La portabilité multi-cloud de S/4HANA : un fait que le choix d'Azure ne documente pas
2.1 Une portabilité multi-cloud que SAP documente lui-même
[Fait établi] SAP S/4HANA Cloud est déployable, dans le cadre de l'initiative RISE with SAP lancée en 2021, sur plusieurs hyperscalers : Amazon Web Services, Google Cloud Platform, Microsoft Azure, Alibaba Cloud et IBM Cloud. AWS est le premier fournisseur cloud à avoir été certifié pour supporter le portefeuille SAP, et des milliers d'entreprises mondiales exécutent des solutions SAP sur AWS. GCP dispose d'une architecture de référence officielle certifiée SAP pour S/4HANA, avec des instances Compute Engine certifiées SAP HANA couvrant les déploiements centralisés et distribués en haute disponibilité.
[Fait établi] SAP S/4HANA repose sur la base de données in-memory SAP HANA. Cette base de données est déployable sur tout matériel respectant la certification SAP HANA TDI (Tailored Datacenter Integration), qui définit les exigences de performance (nombre de SAPS), de mémoire et de connectivité réseau, indépendamment du système d'exploitation ou de l'hyperviseur sous-jacent. SUSE Linux Enterprise Server for SAP Applications, distribué en mode BYOL (Bring Your Own License), constitue la couche OS standard sur les infrastructures souveraines françaises.
[Lecture analytique] Ces faits, publics et documentés par SAP lui-même, établissent que S/4HANA est agnostique sur la couche d'infrastructure, à condition que celle-ci respecte les certifications SAP HANA TDI. L'infrastructure Azure n'est donc pas un prérequis technique pour l'offre souveraine de SAP en France. Cette neutralité multi-cloud de S/4HANA est le point de départ nécessaire pour évaluer les facteurs qui expliquent néanmoins le choix d'Azure via Bleu.
2.2 OVHcloud : une alternative SecNumCloud existante et opérationnellement démontrée
[Fait établi] OVHcloud propose une offre "SAP HANA on Private Cloud" reposant sur des serveurs HCI certifiés SAP HANA, déployés au sein de l'infrastructure VMware on OVHcloud qualifiée SecNumCloud par l'ANSSI depuis décembre 2020. Cette offre est qualifiée SecNumCloud, opérée exclusivement par du personnel européen, hébergée dans des datacenters français (Roubaix, Gravelines, Strasbourg), et immunisée vis-à-vis des réglementations non-européennes. OVHcloud a également obtenu la certification "Cloud and Infrastructure Operations" de SAP, qui lui octroie le droit d'héberger des solutions SAP sur son IaaS managé.
[Fait établi] En octobre 2022, OVHcloud et Sopra Steria ont annoncé une collaboration pour déployer SAP S/4HANA sur infrastructure SecNumCloud OVHcloud, visant spécifiquement le secteur public français, les OIV et les OSE. Un démonstrateur fonctionnel couvrant les processus financiers et comptables a été présenté à la convention des Utilisateurs Francophones de SAP (USF). D'autres partenaires intégrateurs SAP certifiés opèrent sur l'infrastructure OVHcloud : CGI, Atos, Capgemini (avant son engagement dans Bleu), Deloitte, Oxya.
[Fait établi] La stack d'OVHcloud repose sur OpenStack (orchestration IaaS), KVM/VMware (virtualisation), et SUSE Linux Enterprise Server pour les applications SAP. Ces composants sont open source ou distribués sous licence standard, sans dépendance à une propriété intellectuelle d'un unique fournisseur américain. OVHcloud maîtrise sa chaîne de valeur matérielle de bout en bout : conception des serveurs, construction des datacenters, orchestration réseau. Scaleway, filiale d'Iliad (Xavier Niel), propose une architecture similaire sur base KVM avec sa propre pile logicielle, et est engagé dans le processus de qualification SecNumCloud avec une cible de fin 2026.
[Lecture analytique] Au 19 mars 2026, l'argument selon lequel il n'existerait pas d'alternative souveraine et fonctionnelle pour les charges SAP critiques ne résiste pas à l'examen des sources disponibles. Une infrastructure qualifiée SecNumCloud, avec des serveurs certifiés SAP HANA, opérée par une entreprise de droit français sans dépendance à une technologie américaine propriétaire, est disponible chez OVHcloud depuis au moins 2023. Elle n'a pas été retenue comme véhicule principal de l'offre souveraine française de SAP. La section suivante examine les facteurs qui l'expliquent.
2.3 Les facteurs qui expliquent le choix d'Azure
[Lecture analytique] Plusieurs facteurs permettent d'expliquer le choix de SAP pour Bleu-Azure plutôt que OVHcloud.
Le premier facteur est la continuité de l'écosystème. SAP propose RISE with SAP, son offre cloud managée, prioritairement sur les hyperscalers américains (AWS, Azure, GCP). L'essentiel de son infrastructure mondiale de production et de ses accords commerciaux globaux repose sur ces acteurs. Passer par un acteur souverain européen pour la France impliquerait une fragmentation de l'architecture globale des offres SAP Cloud, et une négociation tarifaire et technique distincte avec un acteur de moindre envergure mondiale.
Le second facteur est l'intégration fonctionnelle des services AI. Martin Merz, président de SAP Sovereign Cloud, a explicitement placé l'IA au même niveau stratégique que la souveraineté. Les services d'IA générative de SAP (Business AI) sont profondément intégrés à Azure OpenAI Service. Reproduire ces intégrations sur une infrastructure OVHcloud supposerait un effort de portage significatif ou le recours à des modèles alternatifs (Mistral, Llama) dont la parité fonctionnelle avec les offres Microsoft n'est pas acquise pour tous les cas d'usage ERP.
Le troisième facteur est commercial et capitalistique. Capgemini est actionnaire à 50 % de Bleu. Capgemini est également l'un des plus grands intégrateurs SAP en France. En poussant ses clients SAP vers Bleu, Capgemini cumule les revenus d'intégration SAP et les revenus d'opération cloud Bleu. La convergence d'intérêts est structurelle, non accidentelle.
[Inférence] Ces trois facteurs, pris ensemble, suggèrent que la "souveraineté pragmatique" défendue par SAP repose sur une logique de continuité d'écosystème autant que sur une logique de protection des données. Cela ne disqualifie pas le choix : les contraintes commerciales et les intégrations existantes sont des réalités opérationnelles légitimes. Cela implique en revanche de ne pas confondre la rationalité commerciale du choix avec une démonstration que ce choix est le seul souverainement défendable.
III. Les limites structurelles du modèle Bleu : ce que la qualification ne couvre pas
3.1 La dépendance permanente aux mises à jour Microsoft
[Fait établi] L'ANSSI a reconnu publiquement en janvier 2026 que S3NS et Bleu ne pourraient maintenir en condition opérationnelle leur solution que six à douze mois en l'absence de mises à jour de leurs fournisseurs technologiques. La qualification SecNumCloud impose à Bleu de démontrer son autonomie opérationnelle au sens de la capacité à opérer sans intervention extérieure, non au sens de la capacité à se passer de la technologie elle-même.
[Lecture analytique] Cette distinction entre autonomie opérationnelle et autonomie technologique est centrale. Un opérateur de centrale nucléaire peut opérer son installation sans intervention du constructeur au quotidien, tout en étant structurellement dépendant du constructeur pour les maintenances lourdes, les pièces de rechange et les mises à niveau de sûreté. Le modèle Bleu est analogue : autonomie quotidienne réelle, dépendance structurelle sur le cycle long. Pour une infrastructure d'information d'État ou d'OIV, l'horizon de continuité pertinent n'est pas de six à douze mois mais de décennies.
[Inférence] L'argument symétrique de l'ANSSI mérite d'être discuté sérieusement : OVHcloud dépend également de composants open source maintenus par des communautés où l'influence américaine est présente. Toutefois, cette symétrie est incomplète. La dépendance à des composants open source présente une structure de risque différente de la dépendance à une technologie propriétaire d'un fournisseur unique. L'open source offre une capacité de fork : un État ou un consortium européen pourrait prendre en charge la maintenance d'une version dérivée de Linux, d'OpenStack ou de PostgreSQL. Cette capacité n'existe pas pour la stack Azure, dont les conditions de licence interdisent toute dérivation autonome. La dépendance à Azure est plus concentrée, plus opaque et moins réversible que la dépendance à l'open source.
3.2 La déconnexion par injonction extraterritoriale : un risque borné mais non nul
[Fait établi] La mise en oeuvre de l'Entity List américaine contre Huawei en 2019, les sanctions technologiques contre des entités russes après 2022, et la restriction d'accès aux services Microsoft imposée à des magistrats de la Cour pénale internationale ont documenté que les États-Unis sont prêts à utiliser leur contrôle sur la technologie comme levier de politique étrangère dans des contextes spécifiques.
[Inférence] Dans ce cadre, le modèle Bleu offre une protection juridique réelle contre la captation des données dans les scénarios ordinaires. Sa robustesse dans un scénario de pression extraterritoriale grave impliquant l'interruption des mises à jour Microsoft est plus incertaine : la résistance juridique de Bleu à une telle injonction ne suffirait pas, par elle-même, à maintenir la sécurité opérationnelle au-delà de la fenêtre d'autonomie documentée par l'ANSSI. La probabilité d'un tel scénario est difficile à évaluer, mais les précédents cités suggèrent qu'il ne peut pas être exclu par hypothèse. Sur cette dimension précise, l'architecture OVHcloud présente une différence de nature : en l'absence de dépendance contractuelle à un fournisseur américain de technologie propriétaire, le vecteur d'injonction extraterritoriale sur la continuité du service est structurellement différent. OVHcloud reste exposé aux dépendances open source évoquées par l'ANSSI, mais ces dépendances ne sont pas concentrées sur un interlocuteur unique soumis au droit américain.
3.3 L'absence de la qualification au moment de l'annonce
[Fait établi] À la date du 19 mars 2026, Bleu n'a pas obtenu la qualification SecNumCloud J2. SAP annonce donc une offre qualifiée de "souveraine" en s'adossant à un opérateur dont le label justificatif n'est pas encore obtenu, avec une cible de fin 2026. OVHcloud dispose, lui, d'une qualification SecNumCloud effective depuis décembre 2020 pour son offre VMware on OVHcloud, incluant les serveurs certifiés SAP HANA.
[Lecture analytique] Ce décalage temporel est une nuance factuelle que les clients des secteurs les plus réglementés doivent intégrer dans leurs arbitrages : en choisissant SAP via Bleu aujourd'hui, ils s'engagent contractuellement avec un opérateur dont le label souverain revendiqué n'est pas encore acquis. En choisissant OVHcloud avec un intégrateur SAP certifié, ils s'appuient sur une qualification effective et sur une stack technologique dont la souveraineté est plus profonde.
3.4 Les limitations fonctionnelles initiales non annoncées en titre
[Fait établi] L'offre SAP Sovereign Cloud via Bleu sera disponible à mi-2026 avec environ 80 % du périmètre de services Azure et Microsoft 365. Copilot ne sera pas disponible au lancement. Microsoft Fabric est attendu plus tard. Les 20 % restants arriveront dans les 18 mois suivants. Ces limitations ne figurent pas dans les intitulés de l'annonce mais dans les détails techniques de la conférence de presse.
[Lecture analytique] Pour les DSI des administrations et des OIV qui ont attendu cette offre comme solution à leur enjeu de mise en conformité réglementaire, la fenêtre d'incertitude est donc au moins de 12 à 18 mois après la date de qualification officielle avant d'avoir accès à un périmètre fonctionnel complet. Cette temporalité, combinée à l'absence de qualification J2 au jour de l'annonce, signifie que la promesse commerciale du 19 mars 2026 est une promesse à horizon 2027-2028 pour sa pleine réalisation.
IV. Le contexte politico-industriel : pourquoi ce modèle s'impose néanmoins
4.1 L'EUCS, un niveau "high+" sacrifié sous pression
[Fait établi] Le schéma de certification européen pour les services cloud (EUCS) ne comprend plus le niveau "high+" qui aurait imposé aux fournisseurs cloud des exigences d'immunité vis-à-vis des lois extraterritoriales non européennes. Ce niveau, soutenu par la France et quelques États membres, a été retiré du processus sous l'influence combinée d'un lobbying américain documenté et d'oppositions allemandes au nom de la continuité des relations industrielles transatlantiques. La disparition de ce niveau a mécaniquement renforcé la position du SecNumCloud comme référentiel de facto pour les charges les plus sensibles, et contraint les acteurs comme SAP à s'y conformer sans équivalent européen harmonisé.
[Fait établi] SAP mentionne explicitement ce contexte : "faute d'un EUCS capable de porter une souveraineté renforcée à l'échelle européenne, SAP choisit de passer par le cadre français le plus lisible : SecNumCloud." La France subit donc, sur son propre marché réglementé, les conséquences d'un échec de régulation européenne auquel elle avait tenté de résister.
4.2 L'argument de continuité fonctionnelle : valide mais surestimé
[Lecture analytique] Le modèle Bleu-Azure offre à SAP et à ses clients un avantage opérationnel réel : la continuité avec l'écosystème existant. Un client SAP qui migre de S/4HANA Cloud sur Azure commercial vers SAP Sovereign Cloud via Bleu reste sur une architecture Azure compatible. Les intégrations, outils de développement, et compétences internes ne sont pas remis en cause. Une migration vers OVHcloud exige une refonte architecturale et une adaptation des outils de déploiement. Ce coût de transition est réel et non négligeable.
[Inférence] L'argument de la continuité mérite cependant d'être qualifié : il est d'autant plus fort que l'organisation est déjà sur Azure, et d'autant plus faible qu'elle migre pour la première fois depuis un on-premise. Pour les organisations en migration initiale ECC-to-S/4HANA, la "continuité Azure" n'est pas une contrainte héritée mais un choix prospectif.
4.3 Les bénéficiaires industriels du montage
[Lecture analytique] L'accord SAP-Bleu génère des flux de valeur clairement identifiables pour chacun des acteurs parties prenantes. Microsoft maintient et étend sa présence sur le segment français le plus réglementé, qu'il n'aurait pas pu atteindre directement. Capgemini cumule les revenus d'intégration SAP (qu'il capturait déjà) et les revenus opérateurs de Bleu. Orange valorise son infrastructure et ses équipes techniques dans un segment à forte visibilité politique, avec une prime "cloud de confiance" de 10 à 15 % sur les tarifs Azure commerciaux. SAP préserve ses intégrations AI avec Azure OpenAI, ses accords commerciaux globaux et sa position de partenaire privilégié de Microsoft en Europe. L'État français, actionnaire indirect via Orange, est à la fois prescripteur et bénéficiaire induit du montage. Aucun de ces acteurs n'a d'intérêt à pousser vers une architecture purement souveraine qui fragmente ces flux.
[Inférence] La convergence de ces intérêts constitue un facteur explicatif significatif du choix de l'architecture Bleu-Azure. Ce n'est pas une défaillance de marché : c'est son fonctionnement ordinaire. La question pertinente est de savoir si la politique publique a les instruments et la volonté pour peser sur ces arbitrages lorsqu'ils entrent en tension avec les objectifs de long terme de souveraineté technologique.
V. L'alternative souveraine : avantages, limites et conditions d'arbitrage
5.1 Bénéfices et limites comparés de l'architecture OVHcloud
[Lecture analytique] L'architecture OVHcloud SecNumCloud présente trois avantages propres par rapport au modèle Bleu-Azure, symétriques aux trois facteurs qui expliquent le choix de SAP pour Azure. Sur la continuité technologique d'abord : la stack open source (OpenStack, KVM, SLES) est forçable, maintenable sans dépendance contractuelle à un fournisseur unique, et réversible. Sur la protection extraterritoriale ensuite : OVHcloud est une entreprise de droit français dont aucun actionnaire ni dirigeant n'est soumis à la juridiction américaine, et la stack open source ne crée pas de dépendance contractuelle à un fournisseur américain unique. L'ANSSI rappelle néanmoins qu'aucun acteur n'est totalement immunisé, les composants open source eux-mêmes étant maintenus partiellement par des acteurs exposés à ce droit. La différence avec Bleu est de nature du risque, pas d'immunité absolue. Sur la maturité de qualification enfin : la qualification SecNumCloud est effective depuis décembre 2020 pour l'offre VMware on OVHcloud incluant les serveurs certifiés SAP HANA, sans délai résiduel.
[Lecture analytique] Cette même architecture présente deux limitations documentées par rapport au modèle Bleu-Azure. La première est l'intégration AI : SAP Business AI s'appuie profondément sur Azure OpenAI Service, et les alternatives disponibles sur OVHcloud (Mistral AI, modèles open source) ne couvrent pas l'ensemble du périmètre fonctionnel de façon établie. La seconde est la richesse de l'écosystème de services managés : Event Hub, Service Bus, Cosmos DB et les outils de développement Azure n'ont pas d'équivalents open source intégralement comparables sur OVHcloud, ce qui génère un effort d'adaptation pour les architectures qui en dépendent. À ces deux limitations s'ajoute un facteur de maturité commerciale : l'offre OVHcloud pour SAP repose sur des partenariats d'intégration (Sopra Steria, CGI, Oxya) là où RISE with SAP via Bleu constitue une offre packagée directe de l'éditeur, avec un interlocuteur unique et des SLA intégrés.
[Inférence] L'arbitrage entre les deux architectures dépend donc du profil de l'organisation et de la nature de ses charges. Pour une organisation déjà fortement intégrée dans l'écosystème Azure, avec des cas d'usage AI actifs sur SAP Business AI, le surcoût d'adaptation vers OVHcloud est réel et doit être évalué concrètement. Pour une administration publique en migration initiale depuis un on-premise, dont les charges critiques sont financières, comptables ou de gestion RH, les limitations d'OVHcloud sur l'AI et les services natifs Azure sont moins déterminantes que les avantages en termes de souveraineté technologique et d'absence totale d'exposition extraterritoriale. L'argument générique selon lequel Bleu serait la seule option viable ne résiste pas à cet examen cas par cas.
5.2 Scaleway et la perspective d'un deuxième acteur souverain qualifié
[Fait établi] Scaleway (filiale Iliad / Xavier Niel) a engagé le processus de qualification SecNumCloud pour l'ensemble de son offre, avec une cible de fin 2026. Scaleway utilise une pile logicielle entièrement construite en interne sur base KVM, sans dépendance à VMware (racheté par Broadcom en 2023, ce qui a introduit un risque de coûts et de discontinuité pour les utilisateurs VMware). Scaleway dispose d'un cluster GPU H100 (projet Nabuchodonosor) pour les workloads AI, positionnant l'acteur sur l'argument de la richesse fonctionnelle IA en infrastructure souveraine.
[Lecture analytique] Si Scaleway obtient sa qualification SecNumCloud en 2026, le marché français des données sensibles disposera de deux acteurs souverains au sens technologique qualifiés (OVHcloud, Scaleway) face à deux acteurs hybrides qualifiés (S3NS, Bleu). La dynamique concurrentielle en serait modifiée. L'argument de l'absence d'alternative souveraine fonctionnelle, déjà fragile aujourd'hui, deviendrait intenable dans ce scénario.
5.3 Le coût de la migration vers un acteur souverain : une évaluation à nuancer
[Lecture analytique] L'argument du coût prohibitif d'une migration vers une infrastructure souveraine mérite d'être déconstruit. Pour un client qui migre depuis un on-premise SAP ECC vers S/4HANA (migration imposée par SAP avec une date limite de fin 2027 pour les instances ECC), la question n'est pas de migrer depuis Azure vers OVHcloud mais de choisir, lors de la migration initiale vers S/4HANA, la destination cible. La "migration supplémentaire" n'existe pas pour un client qui n'est pas encore sur Azure. Pour les clients déjà sur Azure, les coûts de réarchitecture sont réels mais doivent être mis en regard du risque géopolitique et du coût à long terme d'une dépendance consolidée.
[Inférence] La fenêtre de la migration ECC-to-S/4HANA représente le moment où le coût marginal d'un choix souverain est le plus faible : une organisation qui n'est pas encore sur Azure n'a pas à supporter de coût de réarchitecture supplémentaire. Cette fenêtre se ferme une fois la migration effectuée. Une politique publique orientée vers la réduction de la dépendance technologique trouverait ici un levier d'action à faible coût : incitations à la migration vers des acteurs qualifiés technologiquement souverains, doctrine d'achat public différenciée, accompagnement technique des DSI du secteur public. Aucun de ces instruments n'est visible de façon structurée dans le paysage actuel.
VI. L'ANSSI face au paradoxe de sa propre doctrine
6.1 Une doctrine défensive mais cohérente
[Lecture analytique] La position de l'ANSSI, défendue par Vincent Strubel avec constance et une réelle rigueur argumentative, est que SecNumCloud vise un niveau de protection "raisonnable et atteignable" plutôt qu'une souveraineté technologique absolue jugée inaccessible. Cette position est techniquement défendable et pragmatiquement cohérente : exiger que 100 % du code soit d'origine européenne serait, dans l'état actuel de l'écosystème technologique mondial, une condition impossible à remplir.
[Fait établi] Vincent Strubel a lui-même reconnu que SecNumCloud "ne signifie pas l'absence de dépendance" et que les offres hybrides qualifiées restent exposées au risque de dégradation de la sécurité en l'absence de mises à jour du fournisseur technologique américain. Il a également rappelé que même les clouds purement français dépendent de composants open source maintenus partiellement par des acteurs américains.
[Inférence] Cette position pragmatique produit un effet structurel qui mérite d'être noté sans lui prêter d'intention : en validant le modèle hybride comme conforme à SecNumCloud, le référentiel ouvre aux hyperscalers américains un accès aux marchés les plus réglementés de France qu'ils n'auraient pas pu atteindre directement. Pour Microsoft, l'accord Bleu résout un problème d'accès au marché que la doctrine cloud au centre de l'État lui fermait. La qualification de Bleu est donc, simultanément, un progrès réel en matière de protection des données et un vecteur de maintien de la présence Azure dans les segments les plus sensibles du marché français.
6.2 Le paradoxe du label comme vecteur de lock-in
[Inférence] Si le modèle hybride devenait dominant sur le segment des données sensibles françaises, les acteurs purement souverains (OVHcloud, Scaleway, NumSpot, 3DS Outscale) se retrouveraient en compétition avec des offres portant le même label réglementaire qu'eux, mais adossées aux capacités fonctionnelles et aux budgets commerciaux des hyperscalers américains. Ce scénario n'est pas certain, mais sa trajectoire mérite d'être anticipée dans les choix de politique industrielle.
VII. Contre-arguments et leur évaluation
Premier argument : la souveraineté absolue est une illusion, le pragmatisme est une nécessité. C'est l'argument central de l'ANSSI et des promoteurs du modèle hybride. Il repose sur une réalité : la dépendance à des composants technologiques non européens est structurelle dans l'écosystème numérique actuel. Évaluation : L'argument est recevable dans sa dimension immédiate. Il ne l'est que partiellement dans sa dimension stratégique : le pragmatisme est un point de départ acceptable, il ne devrait pas être un point d'arrivée. Le problème n'est pas que le modèle Bleu existe : c'est qu'il est promu comme la réponse principale sans que des politiques actives d'investissement dans les acteurs purement souverains l'accompagnent.
Deuxième argument : les alternatives souveraines ne sont pas fonctionnellement équivalentes, notamment sur l'IA. Cet argument est partiellement fondé : les intégrations SAP Business AI avec Azure OpenAI Service n'ont pas d'équivalent immédiat sur OVHcloud. Évaluation : La parité fonctionnelle est incomplète pour les cas d'usage AI les plus avancés. Elle est en revanche suffisante pour la grande majorité des charges critiques du secteur public français, qui n'ont pas besoin de la dernière génération de services AI génératifs pour leurs fonctions régaliennes de base. L'argument AI est valable pour les innovateurs ; il est surestimé comme justification pour les administrations.
Troisième argument : nommer cette offre "souveraine" est un choix marketing légitime, le marché comprend les nuances. Évaluation : Partiellement valide dans les milieux DSI avertis. Moins valide pour les prescripteurs politiques et administratifs pour qui le terme a une portée réglementaire forte. Bleu emploie lui-même la terminologie "cloud de confiance" dans ses propres communications, formulation plus précise que le terme "souverain" retenu par SAP dans ses annonces commerciales. La distinction entre les deux régimes de souveraineté, établie en sections I et III, en mesure les effets concrets sur les arbitrages d'achat public.
Quatrième argument : sans Bleu, les clients SAP n'auraient tout simplement pas migré vers un cloud souverain. C'est l'argument de l'effet d'entraînement : un cloud de confiance "imparfait" est préférable à pas de cloud de confiance du tout. Évaluation : L'argument a une validité sur le court terme et pour des organisations dont les systèmes sont déjà fortement intégrés dans l'écosystème Azure. Il perd de sa force pour les organisations en migration initiale depuis un on-premise, pour lesquelles le choix entre Bleu et OVHcloud ne constitue pas un surcoût de réarchitecture mais un choix prospectif d'architecture.
Conclusion : des protections réelles, des dépendances non résolues
L'annonce du 19 mars 2026 apporte aux clients SAP des secteurs réglementés français un cadre réglementaire défendable, une protection juridique contre l'extraterritorialité dans les scénarios ordinaires, et une continuité fonctionnelle avec l'écosystème existant. Ces apports sont réels et répondent à une attente de marché légitime.
Deux points méritent néanmoins d'être tenus distincts dans l'évaluation. Le premier est la portabilité de S/4HANA : le choix d'Azure résulte de facteurs stratégiques identifiables, non d'une contrainte technique, et une alternative qualifiée SecNumCloud sur stack souveraine existait au moment de l'annonce. Le second est la nature de la dépendance résiduelle : la souveraineté opérationnelle que vise Bleu est réelle et mesurable, la souveraineté technologique ne l'est pas, et l'ANSSI chiffre elle-même à six à douze mois l'autonomie de Bleu en cas de rupture avec Microsoft.
Ces deux points ne condamnent pas le modèle Bleu. Ils délimitent ce qu'il accomplit réellement. La confusion entre cloud de confiance et souveraineté technologique a des effets pratiques sur les décisions d'achat public et d'architecture des DSI. La clarifier n'est pas une posture idéologique : c'est une condition d'arbitrage éclairé.
La fenêtre de la migration ECC-to-S/4HANA, qui concerne l'essentiel du parc SAP français d'ici fin 2027, est le moment où ces arbitrages ont le coût marginal le plus bas. Une politique de souveraineté numérique cohérente trouverait là un point d'entrée pertinent.
Note méthodologique
Cet article distingue systématiquement trois niveaux épistémiques :
[Fait établi] : informations vérifiables sur la base de sources primaires accessibles (communications officielles de SAP, Bleu, Microsoft, ANSSI, OVHcloud, auditions parlementaires, communiqués de presse datés, documentation technique officielle).
[Lecture analytique] : interprétations de ces faits mobilisant un raisonnement explicite, non directement vérifiables comme des faits.
[Inférence] : projections ou conclusions dépassant les éléments directement disponibles, présentées avec leur degré d'incertitude.
Les estimations de parts de marché dans le graphique de positionnement sont des estimations analytiques sans source primaire unique, présentées comme telles.