Résumé

  • La baisse ou la suppression des frais de sortie ne produit pas un droit uniforme à la portabilité. AWS, Microsoft Azure et Google Cloud distinguent désormais plus nettement le départ complet, la sortie d’un service et le multicloud continu. À l’intérieur d’un même hyperscaler, ces trois situations peuvent ouvrir des fenêtres différentes, imposer des préavis différents et faire dépendre le prix du pays du compte, de l’adresse de facturation, de la région source, du réseau utilisé ou de l’appartenance de la destination au même client.

  • Le Royaume-Uni offre le cas le plus visible d’une portabilité devenue géographiquement contractualisée. Après l’enquête de la Competition and Markets Authority, AWS et Microsoft ont inscrit ou annoncé des droits plus larges : fenêtre de 180 jours, possibilité de sortir un service sans quitter entièrement le fournisseur, egress multicloud à prix coûtant et interconnexions plus directes. Ces droits sont concrets. Leur effet concurrentiel, lui, ne l’est pas encore : la CMA juge que leur efficacité pour élargir réellement le choix reste à démontrer et prévoit de réexaminer les progrès.

  • Le Data Act européen renforce cette fragmentation plutôt qu’il ne la fait disparaître. Son article 29 conduit à la suppression des frais de switching à compter du 12 janvier 2027, après une période où ils ne peuvent excéder les coûts directement liés au changement. Mais l’article 34 traite séparément l’usage simultané de plusieurs services et autorise encore la répercussion des coûts d’egress pour ce multicloud parallèle. Le jalon de 2027 ne signifie donc pas que toute circulation intercloud deviendra gratuite.

La frontière est dans la facture

Pendant longtemps, la discussion sur l’egress a été formulée comme une question simple : combien coûte la sortie d’un gigaoctet ? Cette unité reste utile pour lire une grille tarifaire, mais elle décrit de moins en moins correctement le problème économique. Il faut désormais demander : qui sort, d’où, vers quoi, pourquoi, par quel chemin, pendant combien de temps et sous quelle qualification contractuelle ?

Ce changement est important parce qu’il déplace la portabilité du prix affiché vers le droit applicable. Deux entreprises utilisant le même service peuvent disposer de droits différents si leur pays de compte ou leur adresse de facturation diffère. Deux charges de travail appartenant au même groupe peuvent être traitées différemment si l’une réside dans une région éligible et l’autre non. Deux flux vers le même fournisseur concurrent peuvent recevoir un traitement différent selon qu’ils passent par l’Internet public, une infrastructure premium ou une interconnexion dédiée.

La CMA britannique avait déjà établi en 2025 que les obstacles au changement de fournisseur et au multicloud ne se réduisaient pas aux frais de sortie. La différenciation technique, le travail de migration, les services plus abstraits comme le PaaS et le serverless, les engagements de dépense et les difficultés opérationnelles peuvent peser autant ou davantage. Les témoignages clients sur l’egress étaient eux-mêmes hétérogènes : certains en faisaient une contrainte forte, notamment pour des architectures échangeant ou synchronisant de gros volumes de données ; d’autres ne le considéraient pas comme le facteur décisif.

Cette nuance reste essentielle. Réduire l’egress peut rendre une option de sortie crédible sans rendre la migration simple. Une base de données peut être exportable alors que les dépendances applicatives restent coûteuses à reconstruire. Un transfert réseau peut être bon marché alors qu’un engagement de dépense non consommé rend économiquement irrationnel le déplacement immédiat. Inversement, pour une architecture qui synchronise continuellement de grands dépôts entre clouds, le prix du mouvement de données peut influencer directement le dessin technique.

La bonne question de marché n’est donc pas de savoir si l’egress est le verrou. Elle est de savoir si une entreprise peut comprendre son coût total de mobilité avant que son architecture ne se fige.

Trois mouvements, trois économies

Le vocabulaire devient déterminant parce que « partir » recouvre au moins trois opérations.

Le départ complet consiste à quitter le fournisseur pour les services concernés par le compte ou le contrat. C’est le cas le plus intuitif : données et charges de travail sont transférées vers un autre cloud ou une infrastructure sur site, puis l’usage du service source cesse. Les programmes de gratuité de sortie ont historiquement été conçus autour de cette situation.

Le départ par service est différent. L’entreprise peut déplacer intégralement une base de données, un stockage ou un autre service éligible tout en continuant d’acheter d’autres produits au même hyperscaler. Commercialement, ce droit peut être plus important qu’il n’y paraît. La concurrence ne se joue pas seulement lorsqu’un client menace de déplacer la totalité de son parc ; elle se joue aussi lorsque chaque nouvelle charge de travail, chaque base ou chaque couche applicative peut être remise en concurrence séparément.

Enfin vient le multicloud continu. Ici, le client ne part pas. Il exploite simultanément des services appartenant à plusieurs fournisseurs, parfois dans une même application. Les données peuvent circuler de façon répétée entre les plateformes. Le coût correspondant n’est plus un coût ponctuel de séparation, mais une composante du coût d’exploitation.

Confondre ces situations crée de fausses comparaisons. Une offre de 180 jours de transfert gratuit pour sortir un service ne dit rien, à elle seule, sur le prix de la synchronisation quotidienne de ce service avec un autre cloud. Un tarif multicloud « à prix coûtant » ne signifie pas nécessairement qu’un client peut quitter sans formalité. Une interconnexion dépourvue de prix AWS au gigaoctet peut néanmoins comporter un prix horaire, tandis que le fournisseur situé à l’autre extrémité facture sa propre partie du chemin.

La portabilité devient donc une matrice plutôt qu’un chiffre.

Le Royaume-Uni transforme le programme en droit

Le document publié par la CMA le 31 mars 2026 montre ce changement avec une précision inhabituelle. AWS et Microsoft y ont présenté des mesures qui ne se limitent plus à un programme commercial général : le Royaume-Uni bénéficie de fenêtres de migration de 180 jours, d’un traitement du départ d’au moins un service, de conditions réduites pour certains flux multicloud et d’un mouvement vers des droits contractuels plus explicites.

La différence est substantielle. Un geste commercial peut être modifié, interprété ou rendu difficile à découvrir. Un droit contractuel fournit un point d’appui différent aux équipes achats, juridiques et techniques : il peut entrer dans une comparaison d’offres, dans une négociation de renouvellement et dans une politique interne de risque fournisseur.

Cela ne rend pas les règles simples. Chez AWS, l’addendum britannique définit notamment le compte éligible par son Account Country. Il impose une demande au Support au moins deux mois avant la date prévue de début du changement et prévoit une période transitoire de 180 jours. Il reconnaît aussi le Service Switch : un ou plusieurs services éligibles peuvent être entièrement déplacés tandis que le client continue d’utiliser AWS pour les autres.

La géographie n’est donc plus simplement celle du centre de données. Elle peut être celle de la relation de facturation.

AWS : deux cartes du même territoire

AWS illustre particulièrement bien l’écart entre régime mondial et droit local.

Son programme global permet à un client qui quitte AWS de demander au Support des crédits couvrant le transfert de données sortant vers Internet. Depuis la mise à jour de septembre 2025, la fenêtre annoncée est de 90 jours pour les clients éligibles ; une entreprise ayant besoin de davantage de temps doit contacter le Support. Surtout, AWS indique que l’utilisation de ce programme n’oblige pas à fermer le compte ni à mettre fin à toute relation avec AWS.

Le régime britannique est plus structuré. Pour les comptes dont le Account Country est le Royaume-Uni, l’addendum accorde 180 jours, encadre la sortie complète et la sortie de service et transforme certaines conditions en obligations contractuelles. La sortie d’un service suppose bien sa cessation complète : déplacer une partie des données tout en maintenant ce même service n’est pas identique à un Service Switch.

Le même addendum traite séparément le multicloud qui n’est pas un changement de fournisseur. AWS prévoit alors des taux ne dépassant pas ses coûts pour les transferts Internet vers un fournisseur de destination utilisé parallèlement, mais seulement pour l’usage interne des services de ce fournisseur par le même client. La livraison aux utilisateurs finaux, à des clients ou à d’autres tiers est exclue, et une demande préalable au Support reste nécessaire.

Il existe en parallèle une autre économie réseau : AWS Interconnect – multicloud. AWS n’y applique pas de prix de transfert au gigaoctet. La facturation est horaire selon la capacité et le trajet, avec une interconnexion gratuite de 500 Mbit/s par fournisseur cloud et par région AWS. Le fournisseur situé de l’autre côté fixe toutefois son propre prix indépendamment. L’absence de prix AWS au gigaoctet ne signifie donc pas absence de coût de connectivité.

Pour un architecte, ces distinctions sont plus importantes qu’un slogan sur l’egress gratuit. Le coût dépend ici simultanément du statut du compte, de la finalité du mouvement et du produit réseau choisi.

Azure : le chemin réseau devient une clause

Microsoft Azure fait apparaître une géographie différente.

Dans le régime général de sortie, Azure offre un crédit correspondant à un maximum de 60 jours de frais d’egress Internet lorsque le client quitte la plateforme. Une fois les données transférées, les abonnements associés au compte doivent être annulés pour réclamer le crédit. Les transferts via ExpressRoute, VPN, Azure Front Door et CDN, entre autres services spécialisés, restent hors de cette offre.

Le Royaume-Uni bénéficie d’un traitement différent lorsque l’adresse de facturation est britannique et que les données sont transférées depuis des datacentres britanniques. La fenêtre peut atteindre 180 jours ; le départ d’un seul service peut être éligible sans exiger la fermeture de tous les autres ; et le traitement inclut, sous les conditions documentées, le Microsoft Premium Global Network.

Le multicloud continu possède encore une autre règle. Pour les organisations dont l’adresse de facturation se situe dans l’EEE, l’AELE ou au Royaume-Uni, Azure documente un transfert à prix coûtant sous conditions de localisation. Le client doit déposer une demande au Support avec notamment l’identifiant d’abonnement, l’ASN de la destination et une estimation de la part du trafic concerné. Le traitement doit avoir lieu chez la même organisation ; la distribution CDN ou le transfert entre clients différents n’entre pas dans le périmètre.

Même le chemin réseau compte. Le régime européen général vise l’egress Internet supporté sur le chemin ISP ; le MGN n’est normalement pas couvert lorsque le service peut utiliser ce chemin, tandis que le régime britannique autorise le traitement à prix coûtant via le MGN pour les données provenant de datacentres britanniques.

Deux paquets identiques peuvent ainsi relever de droits différents parce que leur routage n’est pas le même.

Google : l’éligibilité descend jusqu’au service et à l’ASN

Google Cloud apporte une troisième forme de granularité.

Exit Cloud organise le départ comme une procédure : notification de sortie, initiation, période de migration puis notification d’achèvement. Pour les produits éligibles, le transfert Internet associé à la sortie du service concerné peut être crédité. Le client doit toutefois réellement quitter le service en question ; le dispositif de sortie n’est pas conçu comme une réduction permanente du prix d’un multicloud continu.

Pour les usages européens et britanniques de services exploités en parallèle, Google renvoie à Data Transfer Essentials. Cette séparation est conceptuellement utile : l’entreprise qui cesse un service n’effectue pas la même opération que celle qui maintient deux services simultanément.

Data Transfer Essentials est initialement proposé sans frais pour le trafic répondant à ses conditions. Mais l’éligibilité ne repose pas seulement sur la localisation du client. Le produit est réservé aux transferts entre services de la même organisation, sur des services, niveaux réseau et régions supportés, au moyen d’une connectivité IP externe. Les destinations doivent être configurées et utiliser des ASN reconnus.

Le contrôle est actif. Une destination dont le préfixe IP ne respecte plus les critères peut être invalidée ; si les points de terminaison deviennent non valides, le trafic revient à la tarification Internet normale. Le service n’est pas conçu pour desservir des clients tiers et n’offre pas de SLA propre. En outre, un service déjà inscrit au programme de sortie gratuite ne peut pas être simultanément éligible à Data Transfer Essentials.

Ici, la portabilité a moins l’allure d’une exemption tarifaire que d’un état de configuration vérifiable.

2027 ne rendra pas tout multicloud gratuit

Le Data Act européen fournit le cadre qui permet de comprendre pourquoi ces distinctions vont probablement durer.

Le règlement s’applique depuis le 12 septembre 2025. Son article 25 impose que les droits et obligations liés au changement de fournisseur soient clairement inscrits dans un contrat écrit et encadre le processus de switching. L’article 29 organise ensuite la disparition progressive des frais de changement : jusqu’au 12 janvier 2027, les frais réduits ne peuvent dépasser les coûts directement liés au processus ; à compter de cette date, les frais de switching ne peuvent plus être imposés au client.

Mais le multicloud permanent possède son propre article. L’article 34 autorise, lorsque deux services de traitement sont utilisés en parallèle, des frais d’egress destinés à répercuter les coûts effectivement supportés, sans les dépasser.

La distinction est structurante. En 2027, une entreprise pourra bénéficier d’un régime sans frais de switching et continuer à payer un coût de circulation entre deux clouds qu’elle conserve. Le législateur ne traite pas une séparation ponctuelle et un flux opérationnel permanent comme la même activité économique.

Le marché devrait donc cesser de mesurer la portabilité avec une seule question — « l’egress est-il gratuit ? » — et passer à une autre : « quel type de mouvement est reconnu, avec quelle preuve et selon quelle géographie contractuelle ? »

Ce que les nouveaux droits ne prouvent pas encore

La séquence britannique fournit un test grandeur nature, mais pas encore son résultat.

La CMA considère que les mesures annoncées par AWS et Microsoft réduisent certains coûts de mouvement de données et améliorent l’interopérabilité. Elle estime néanmoins que leur capacité à élargir effectivement le choix des entreprises britanniques reste à établir et qu’il faut encore faciliter la gestion des applications entre clouds. Elle a prévu un suivi avec les clients et les concurrents et un bilan des progrès à six mois.

Cette prudence évite une erreur fréquente : mesurer une réforme de portabilité au nombre de migrations qu’elle provoque immédiatement. Un droit de sortie peut être concurrentiellement utile sans déclencher un exode. Il peut renforcer le pouvoir de négociation lors d’un renouvellement, rendre un nouveau fournisseur crédible pour une charge de travail supplémentaire ou empêcher qu’un engagement technique futur soit conclu uniquement parce que la sortie paraît impossible.

L’inverse est également vrai. Un droit généreux sur le papier peut avoir peu de valeur si l’entreprise découvre trop tard qu’il exige une adresse de facturation particulière, un compte principal correctement enregistré, une région source éligible, une demande préalable au Support ou un chemin réseau qui n’est pas celui de l’architecture déjà déployée.

C’est là que la portabilité prend véritablement une adresse. Non parce qu’un code postal commanderait mécaniquement le prix, mais parce que la localisation contractuelle, la topologie et la procédure deviennent ensemble une condition d’accès au droit.

Sources