Quitter Microsoft, 7/7 : garder la liberté de choisir

Une offre qui s’appuie sur la technologie de Google peut-elle remporter un marché européen de cloud souverain ? Le 17 avril 2026, la Commission européenne apporte une réponse concrète. Elle attribue quatre contrats, pour un plafond global de 180 millions d’euros sur six ans. Parmi les offres retenues figure celle de Proximus avec S3NS, Clarence et Mistral, dont la Commission décrit la technologie Google Cloud comme exclusivement exploitée par des entreprises européennes. Cette offre obtient le niveau SEAL 2. Les offres de Post Telecom avec OVHcloud et Clever Cloud, de STACKIT et de Scaleway atteignent SEAL 3. Le montant annoncé représente une capacité contractuelle, dont la consommation effective reste à établir. ^[1]

Ce résultat ouvre une question plus intéressante que la nationalité inscrite sur une facture : quelles dépendances l’acheteur accepte-t-il, pour quel service et avec quelle possibilité de les réduire ? L’origine de la technologie, l’entreprise qui l’exploite et les droits dont dispose le client forment des couches différentes. Le marché européen permet de regarder comment ces couches entrent dans une décision publique.

Ce dernier volet prolonge le travail des équipes après la migration. Il suit la liberté de choix au fil de sa transmission : au marché suivant, au prestataire suivant, puis aux personnes qui hériteront du système. Les textes européens, les clauses françaises et les méthodes britanniques donnent à cette liberté un contenu vérifiable.

Ce que mesure une offre souveraine

Le cadre employé par la Commission examine huit objectifs. Ils couvrent notamment la maîtrise juridique, les opérations, la chaîne de fournisseurs, la technologie, les données et l’intelligence artificielle, ainsi que la sécurité et l’environnement. La souveraineté devient ainsi une évaluation de plusieurs dépendances, appliquée à une offre. Le document d’octobre 2025 décrit une échelle SEAL, pour Sovereignty Effectiveness Assurance Levels, dont les degrés vont de zéro à quatre. ^[2]

La règle de sélection mérite que l’on s’y arrête. Chaque objectif doit franchir le seuil requis. Le guide publié en juin 2026, qui explicite le calcul utilisé dans le marché désormais conclu, précise que le niveau global correspond au plus faible des huit niveaux obtenus. Pour ce marché, le seuil est fixé à SEAL 2. Une faiblesse sous ce seuil entraîne donc le rejet, même si d’autres dimensions sont très bien évaluées. ^{[2] [3]}

Vient ensuite un autre calcul : un score de souveraineté pondéré contribue à la note de qualité des offres admissibles. La chaîne de fournisseurs y pèse 20 %, contre 5 % pour l’environnement ; les autres poids figurent dans le schéma. Cette seconde étape sert à départager la qualité selon les critères du marché. Elle conserve son rôle distinct du seuil minimal. ^[2]

Méthode et périmètre

Cadre de la Commission européenne, version 1.2.1 d’octobre 2025, et guide d’application publié en juin 2026. Le niveau SEAL global est le minimum des niveaux des huit objectifs. Le marché exigeait SEAL 2 au minimum. Les pourcentages sont les poids du score complémentaire, qui contribue à la note de qualité ; ils ne représentent ni des parts de marché ni les notes des fournisseurs. Les niveaux SEAL sont ordinaux. Aucun score individuel absent des documents n’est reconstitué. [2] [3]

La méthode oblige l’acheteur à expliciter le niveau de dépendance qu’il accepte. Elle permet aussi de comprendre la coexistence, dans le même résultat, d’offres classées SEAL 2 et SEAL 3. Ces niveaux renseignent sur leur évaluation dans ce marché, avec ses critères et ses pièces. Le communiqué d’attribution laisse ouverte une autre question : comment chaque service se comporterait lors d’une migration réelle ou d’une interruption de sa chaîne de fournisseurs ? Nous ne disposons ici d’aucun compte rendu de tels essais. ^[1]

Pour une administration qui envisage de quitter Microsoft, la leçon est transposable : décrire les dépendances conservées par la solution d’arrivée. Un opérateur européen peut travailler avec une technologie extérieure ; un logiciel libre peut demander un savoir-faire concentré chez un prestataire. La décision gagne en précision lorsque ces dépendances deviennent des objets de contrat, d’architecture et de formation.

Protéger les données et préparer leur voyage

En France, une fiche de la Direction des affaires juridiques, mise à jour le 21 août 2026, détaille l’application de l’article 31 de la loi SREN, qui vise à sécuriser et réguler l’espace numérique. Le dispositif vise les administrations, opérateurs et groupements d’intérêt public de l’État concernés lorsqu’ils confient certaines données d’une sensibilité particulière à un service cloud fourni par un prestataire privé. Il combine la nature des données et les conséquences possibles de leur violation. Les catégories de données personnelles et de données sensibles au sens de ce texte se recoupent selon les cas : l’acheteur doit apprécier les critères juridiques pour son projet. ^[4]

La fiche explique le décret du 14 avril 2026 et l’arrêté du 12 août qui approuve le référentiel SecNumCloud 3.2. Ce cadre vise notamment la protection contre les accès d’autorités d’États tiers dépourvus de fondement dans le droit de l’Union ou d’un État membre. Son périmètre appelle de la précision : les exigences, les procédures et les dérogations se lisent pour les entités et les données concernées. Une formule générale telle que « tout le cloud public français » effacerait ces conditions. ^[4]

SecNumCloud contient aussi des exigences utiles au départ. Son chapitre contractuel prévoit la récupération des données confiées et de celles générées par l’usage du client. Le prestataire doit proposer des fichiers dans des formats documentés et utilisables hors du service, ou des interfaces techniques suivant un schéma documenté et exploitable. Ces interfaces sont les points d’échange entre logiciels. Les modalités figurent dans la convention de service et donnent une prise technique à la réversibilité : la possibilité de reprendre une prestation ou de la faire reprendre ailleurs. ^[5]

Reste à parcourir la distance entre un fichier récupéré et un service rétabli. Un dossier peut arriver avec son contenu, tandis que les règles qui autorisent sa lecture appartiennent encore à l’ancien environnement. Il faut alors reconstruire les accès dans la destination et les vérifier. Le guide de sortie du cloud de NHS England, destiné aux organisations de santé, décrit précisément ce risque : les droits de lecture et d’écriture associés aux données peuvent se transposer difficilement d’un environnement à l’autre, et les mécanismes d’identité diffèrent entre fournisseurs. ^[9]

La protection pendant l’hébergement et la capacité à reprendre le travail ailleurs se complètent. Pour apprécier la seconde, l’acheteur doit suivre les données jusqu’au geste métier qui les rend utiles. Ce parcours rejoint les dépendances entre procédures et applications examinées dans le quatrième volet.

Le contrat doit transmettre de quoi travailler

Le droit français de la commande publique dispose déjà d’un vocabulaire pour cette transmission. Le CCAG-TIC, le cahier des clauses administratives générales des marchés informatiques, organise un plan de réversibilité ou de transférabilité. Son article 38.4 prévoit, selon le périmètre applicable, des fichiers dans des formats documentés, des éléments de configuration, des scripts, de la documentation et des supports de formation existants. Le code source figure dans la liste lorsqu’il y a lieu. L’article 42 organise l’accès nécessaire à l’acheteur ou au nouveau titulaire, avec le maintien de la sécurité et du service pendant le transfert. Ces clauses s’appliquent aux marchés qui se réfèrent expressément au CCAG, sous réserve des dérogations prévues dans leurs documents particuliers. ^[6]

L’annexe de la fiche DAJ d’août 2026 va plus loin pour certains développements spécifiques. Elle propose que l’acheteur détienne les droits sur le code, les composants et les interfaces réalisés pour ses besoins de cybersécurité ou de souveraineté numérique. Le prestataire remettrait les éléments nécessaires à leur exploitation et à leur évolution, avec une documentation à jour, au fur et à mesure de l’exécution. Ce sont des clauses types à intégrer au contrat. Elles ne transfèrent automatiquement ni la propriété de tous les logiciels utilisés ni les droits sur les briques préexistantes : la fiche distingue les résultats du marché des connaissances antérieures. ^[4]

Imaginons une interface développée pour relier un outil de courrier à un système de dossiers. L’exemple est pédagogique. Le prestataire suivant doit comprendre comment installer cette interface, la configurer et la corriger, puis disposer des droits nécessaires pour le faire. Une livraison progressive permet à l’équipe publique de vérifier ces éléments pendant que le prestataire les entretient encore. Les découvertes tardives risquent, elles, de s’accumuler au moment où les équipes doivent déjà assurer le relais.

L’acquisition de droits plus étendus comporte aussi un arbitrage économique. La DAJ avertit que la propriété exclusive peut renchérir une solution : le prestataire dispose de moins de possibilités pour amortir son développement auprès d’autres clients. L’enjeu consiste à choisir les droits adaptés à l’usage futur, avec leur coût et les conditions de maintenance. Cette décision prolonge l’analyse du budget de transition. ^[4]

Les trente jours ont une place précise

Le Data Act européen fournit un autre levier, applicable depuis le 12 septembre 2025. Son chapitre sur le changement de fournisseur vise les services de traitement de données entrant dans sa définition, dont des services cloud. Une application installée sur un ordinateur ne relève donc pas automatiquement de ce régime. Le texte concerne les fournisseurs qui proposent ces services à des clients dans l’Union, quel que soit leur lieu d’établissement. ^[7]

L’article 25 demande que le contrat décrive le changement de fournisseur. Le préavis maximal est de deux mois. Après ce préavis, la période de transition est normalement limitée à trente jours calendaires. Le client dispose ensuite d’au moins trente jours calendaires pour récupérer ses données, à compter de la fin de la période de transition convenue. L’effacement intervient après cette période de récupération, ou à une date ultérieure convenue, sous réserve de la réussite du changement. Chaque durée correspond ainsi à une opération particulière. ^[7]

Le même article prévoit le cas d’une impossibilité technique de tenir la transition normale. Le fournisseur doit la notifier et la justifier dans les quatorze jours ouvrables suivant la demande de changement, en indiquant une période de transition alternative qui ne peut dépasser sept mois. Le client peut également prolonger une fois la transition pour une durée qu’il estime appropriée. Ces dispositions demandent de lire ensemble le régime normal et ses aménagements, sans transformer les trente jours en promesse universelle de migration achevée. ^[7]

Lecture juridique du calendrier

Article 25 du règlement (UE) 2023/2854. Le préavis est plafonné à deux mois ; la transition normale à trente jours calendaires après le préavis ; la période minimale de récupération est de trente jours calendaires à partir de la fin de la transition convenue. L’effacement suppose la réussite du changement et peut être reporté par accord. L’impossibilité technique doit être justifiée dans les quatorze jours ouvrables après la demande ; la transition alternative est plafonnée à sept mois, sans date finale calculée ici. La prolongation unique demandée par le client constitue une disposition distincte. Les longueurs graphiques ne sont pas proportionnelles aux durées. La FAQ précise la portée technique des obligations. [7] [8]

La portée technique compte autant que le calendrier. L’obligation de prendre des mesures raisonnables pour faciliter une équivalence fonctionnelle concerne l’infrastructure à la demande, ou IaaS : capacités de calcul, de stockage et de réseau. Elle ne se transpose pas telle quelle à un logiciel complet fourni comme service, ou SaaS. La FAQ de la Commission précise aussi que le fournisseur de départ n’a pas à reconstruire le service dans l’environnement d’arrivée. Ses obligations d’assistance et d’information sur son propre environnement restent pertinentes. ^{[7] [8]}

Le règlement demande notamment une description des catégories de données et d’actifs exportables, des méthodes et formats, ainsi que des limites techniques connues. Les données exportables comprennent des entrées, des sorties et certaines métadonnées générées par l’usage ; le texte réserve les droits de propriété intellectuelle et les secrets d’affaires du fournisseur ou de tiers. Le travail d’enquête se déplace alors vers une pièce très concrète : la description de ce qui sortira, de ce qui restera et de ce que le destinataire saura utiliser. ^[7]

Répéter le départ pendant que tout fonctionne

Le NHS propose de préparer la sortie dès l’entrée dans le cloud. Son guide prévoit une transition où les environnements peuvent coexister, avec des essais d’acceptation, des contrôles de qualité des données et une possibilité de retour en arrière. Il recommande au moins un premier exercice sur le papier. Il s’agit d’une méthode publiée pour les organisations de santé, dont nous ne déduisons aucun taux de mise en pratique dans les établissements. ^[9]

L’exercice doit couvrir le service complet. Les comptes et leurs droits, la gestion des clés de chiffrement, les journaux de sécurité et les sauvegardes peuvent changer d’organisation avec l’hébergeur. Le même guide distingue la sortie d’un fournisseur de la reprise après sinistre, souvent conçue vers un autre centre de données du fournisseur en place. Une sauvegarde restaurable renseigne sur la récupération des données ; une reprise chez un autre opérateur demande de vérifier les autres dépendances. ^[9]

Prenons un scénario d’essai, sans lui attribuer de résultat réel : une équipe transfère un jeu de dossiers représentatif dans un environnement isolé, ouvre les comptes nécessaires avec leurs droits minimaux, fait réaliser un parcours de traitement et vérifie les traces de sécurité. Elle note le temps de travail, les opérations manuelles et les éléments manquants. Ces observations permettent ensuite de corriger le contrat, la documentation ou l’architecture. Les données d’essai et les accès doivent conserver les protections adaptées à leur sensibilité.

Le guide britannique sur la dépendance technique au cloud rapporte que certaines organisations reconstruisent périodiquement des composants critiques chez un autre fournisseur pour réévaluer le coût d’un changement. Il admet aussi l’intérêt des services intégrés : déléguer des tâches d’exploitation peut apporter de la valeur. L’arbitrage consiste à mettre ces bénéfices en regard d’une dépendance connue et réexaminée. La multiplication des hébergeurs laisse cette question ouverte pour chaque composant. ^[10]

Une responsabilité qui reste quand le mandat change

La France dispose d’un diagnostic sur ce point. Dans son rapport d’octobre 2025 consacré aux systèmes d’information civils de l’État, la Cour des comptes demande une stratégie chiffrée couvrant le développement et l’exploitation, avec des audits réguliers de sa mise en œuvre. Le 8 avril 2026, la DINUM annonce une coordination interministérielle et demande à chaque ministère, opérateurs compris, de formaliser un plan de réduction des dépendances extra-européennes d’ici l’automne. Le communiqué fixe une responsabilité et une échéance ; notre corpus ne permet pas d’établir la remise et l’exécution de tous ces plans au 9 octobre. ^{[12] [13]}

Un document de politique interne donne un exemple de traduction organisationnelle. Le ministère britannique du Travail et des Retraites, le DWP, exige pour chaque service cloud critique une stratégie de sortie documentée et testée. Sa politique attribue aussi les responsabilités tout au long du cycle de vie : les propriétaires de services suivent les risques et le partage des tâches, tandis que les équipes d’achat et juridiques doivent faire porter les exigences appropriées dans les contrats. Cette règle appartient au périmètre du ministère et de ses prestataires concernés. Le document établit l’obligation interne ; il ne publie pas les résultats de chaque test. ^[11]

Cette attribution donne une continuité à la décision. Un responsable reprend un service avec ses dépendances connues, ses essais datés et les points qui restent à corriger. À chaque évolution importante, il peut demander si le prochain départ reste praticable. Le choix politique dispose alors d’une mémoire technique et contractuelle.

Au terme de cette enquête, la question initiale appelle donc une réponse à l’échelle des services. Une administration peut organiser son départ de Microsoft par étapes, comme elle peut décider de conserver certains usages dont elle comprend les contraintes. Dans les deux cas, sa marge de décision tient à ce qu’elle sait reprendre, faire maintenir et transmettre. Le premier volet partait des dépendances accumulées. Le dernier aboutit à une tâche durable : maintenir des options assez concrètes pour qu’une nouvelle équipe puisse encore les exercer.

Le prochain contrat peut donner accès aux éléments nécessaires. L’architecture peut rendre leur transfert réalisable. Les exercices peuvent révéler le travail restant. C’est cette capacité entretenue qui permet à un État de choisir à nouveau lorsque ses besoins, ses risques ou ses fournisseurs changent.

Sources et limites de l’enquête

Enquête documentaire arrêtée au 9 octobre 2026. Nous avons rapproché l’attribution du marché européen de son cadre d’évaluation et de son guide de calcul, puis confronté les obligations de sortie aux textes et aux méthodes d’exploitation. Les règles européennes, les clauses françaises à incorporer aux marchés et les politiques internes britanniques ont des champs distincts. Aucun entretien propre, audit de prestataire ou essai de migration n’a été réalisé. Les scénarios pédagogiques sont signalés comme tels. Les deux infographies expliquent des mécanismes documentés ; elles ne reconstituent aucun score d’offre et ne prédisent aucune durée de migration. L’illustration d’ouverture est une composition conceptuelle.

1. Commission européenne, Commission advances cloud sovereignty through strategic procurement, 17 avril 2026. Quatre contrats, plafond global de 180 millions d’euros sur six ans, titulaires et partenaires, niveaux SEAL attribués aux offres. Communication de l’acheteur ; aucune consommation budgétaire ou réussite de migration n’en est déduite.
2. Commission européenne, Cloud Sovereignty Framework, version 1.2.1, octobre 2025, pages 2–3 et 6. Seuil pour chaque objectif, niveaux SEAL et score complémentaire contribuant à la note de qualité ; pondérations des huit objectifs.
3. Commission européenne, Cloud Sovereignty Framework: Implementation guidance, juin 2026, introduction et pages 9–11. Explication du calcul utilisé dans le marché conclu : minimum des niveaux par objectif, seuil SEAL 2, puis score pondéré.
4. Direction des affaires juridiques, Mise en œuvre de l’article 31 de la loi SREN et clauses pour renforcer la souveraineté des achats numériques, mise à jour du 21 août 2026, pages 1–8 et annexe, notamment page 13. Champ des données sensibles et des entités, décret du 14 avril 2026 et arrêté du 12 août 2026, clauses types de réversibilité et de droits sur les développements spécifiques. Distinguer obligations réglementaires, recommandations et clauses contractuelles à retenir.
5. ANSSI, SecNumCloud, référentiel d’exigences, version 3.2, 8 mars 2022, page 48, exigences contractuelles 19.1 h et i. Modalités de récupération des données confiées et générées, formats exploitables hors du service et interfaces documentées.
6. Arrêté du 30 mars 2021 approuvant le CCAG-TIC, annexe, articles 1.1–1.2, 38.4 et 42, texte consulté le 9 octobre 2026. Référence expresse au CCAG, dérogations, plan et éléments de transfert, accès et sécurité pendant la reprise.
7. Règlement (UE) 2023/2854, Data Act, 13 décembre 2023, articles 1–2, 25–26, 30–31 et 50. Champ, définitions, délais, informations de sortie et distinction entre infrastructure et autres services cloud. L’article 25 est la référence normative du calendrier ; les exceptions techniques et la prolongation à la demande du client sont conservées.
8. Commission européenne, Data Act: Frequently Asked Questions, version 1.4 du 22 janvier 2026, pages 37–40, questions 56, 58a et 58b. Portée des obligations de changement, SaaS et IaaS, responsabilités respectives du fournisseur de départ et de la destination. Explications non substitutives au règlement.
9. NHS England, NHS cloud exit strategy, dernière modification affichée le 3 novembre 2025. Préparation de la sortie, essais, droits d’accès, identité, sécurité, continuité et distinction avec la reprise après sinistre. Guide méthodologique, sans mesure de sa mise en œuvre par les établissements.
10. Government Digital Service, Managing technical lock-in in the cloud, publié le 17 décembre 2019, révision de fond signalée le 1er avril 2025, consulté le 9 octobre 2026. Bénéfices et coûts de la dépendance, suivi continu, essais chez un autre fournisseur et compétences. La modification du 3 septembre 2026 porte sur le nom de l’organisme d’achat public.
11. Department for Work and Pensions, Cloud computing security policy, version consultée le 9 octobre 2026, sections 1, 6.3 et responsabilités. Stratégie de sortie documentée et testée pour chaque service critique, responsabilités et exigences contractuelles. Politique interne dont le champ est défini dans le document.
12. Cour des comptes, Les enjeux de souveraineté des systèmes d’information civils de l’État, 31 octobre 2025, pages imprimées 9, 28–31 et 55. Gouvernance interministérielle, stratégie chiffrée couvrant développement et exploitation, audits de mise en œuvre ; recommandations, sans présumer leur exécution ultérieure.
13. DINUM, Réduction des dépendances numériques extra-européennes, communiqué du 8 avril 2026. Coordination interministérielle et plans demandés à l’automne, ministères et opérateurs compris. L’annonce ne constitue pas un bilan de réalisation.