Hyperscalers : positionnement, dépendance fournisseur et alternatives européennes

Un hyperscaler est un fournisseur d’infrastructure cloud capable de faire croître ses capacités de calcul, de stockage et de réseau à une échelle mondiale, avec un catalogue de services managés dont la profondeur constitue le véritable avantage concurrentiel. Trois acteurs dominent : Amazon Web Services, Microsoft Azure et Google Cloud Platform. Pour une direction informatique, la question n’est pas de désigner le meilleur, mais de mesurer ce que l’on abandonne en s’engageant. Cette page traite le sujet sous l’angle de la dépendance et du coût de sortie, dans le prolongement de notre couverture cloud et infrastructure.

Ce qui différencie réellement les trois acteurs

Définition. Un hyperscaler désigne un opérateur de centres de données à très grande échelle, proposant en libre-service des ressources de calcul, de stockage et de réseau, complétées par un catalogue étendu de services managés facturés à l’usage.

Les comparatifs de puissance brute ou de tarif à l’heure de calcul n’ont plus grand sens : les écarts sont marginaux et les grilles évoluent. Ce qui différencie tient à trois choses.

Le catalogue de services managés. C’est le vrai terrain de concurrence. Bases de données, files de messages, services d’authentification, plateformes de données, outils d’apprentissage automatique. Plus ce catalogue est utilisé, plus le développement s’accélère, et plus la sortie devient coûteuse.

L’ancrage historique. Les organisations déjà équipées d’une suite bureautique et d’un annuaire Microsoft trouvent chez Azure une continuité qui pèse davantage dans la décision que n’importe quelle caractéristique technique. C’est un fait commercial, pas un jugement de valeur.

Les engagements contractuels. Remises pluriannuelles, crédits de migration, conditions négociées. Ils influencent le coût réel bien plus que le tarif catalogue, et ils sont le principal levier de négociation d’une direction achats.

La mécanique de la dépendance fournisseur

C’est le point que les argumentaires de migration escamotent, et le seul qui compte à cinq ans.

Une machine virtuelle se déplace. Une base de données relationnelle standard se déplace, avec un effort mesurable. En revanche, une application construite sur une base de données propriétaire, un service d’authentification maison, une chaîne d’événements spécifique et des fonctions serverless du fournisseur ne se déplace pas : elle se réécrit.

La question à poser en comité d’architecture n’est donc pas quel fournisseur choisir, mais quel niveau de service managé accepter, et pour quelles applications. Une organisation peut décider en connaissance de cause d’accepter une dépendance forte sur des applications non critiques et de la limiter sur celles qui portent l’activité. Ce qui n’est pas tenable, c’est de subir la dépendance sans l’avoir arbitrée.

Trois mécanismes concrets à instruire :

• Les frais de transfert sortant, qui pénalisent économiquement la sortie et les architectures faisant dialoguer deux fournisseurs. Le cadre réglementaire européen a évolué sur ce point, avec une trajectoire de suppression des frais de changement de fournisseur. Vérifier l’état d’application avant de s’appuyer dessus dans une négociation.
• Les formats propriétaires de stockage, de journalisation et de configuration, qui imposent une conversion.
• Les compétences des équipes, spécialisées par fournisseur, dont la reconversion représente un coût rarement chiffré.

État d’application des frais de changement de fournisseur cloud (UE)

Depuis le 12 septembre 2025, le Data Act européen impose aux fournisseurs de cloud de faciliter la portabilité des données et limite les frais de changement aux coûts réels supportés. Microsoft a déjà supprimé les frais de sortie pour ses clients sous conditions, tandis qu’OVHcloud propose des sorties gratuites.

À partir du 12 janvier 2027, ces frais seront totalement interdits dans l’UE pour éviter l’effet de verrouillage (lock-in). Pour aller plus loin : https://eudeadlines.eu/deadline/data-act-cloud-switching-fees-end

Les acteurs européens

OVHcloud, Scaleway, Orange Business et quelques autres occupent un segment plus étroit sur les services managés. Sur l’infrastructure de base, calcul, stockage, réseau, l’écart s’est largement résorbé. Sur les services applicatifs avancés, il reste réel et ne se comblera pas à court terme.

Ils répondent en revanche à une contrainte que les trois grands ne peuvent pas traiter par construction : l’immunité juridique. Une offre dont la maison mère relève d’un droit tiers reste exposée aux demandes d’accès extraterritoriales, quelle que soit la localisation des serveurs. Depuis l’arrêté du 12 août 2026, cette question est devenue une obligation opposable pour une partie du secteur public. Le sujet est développé dans notre section cloud souverain.

La configuration la plus répandue en pratique n’est ni l’un ni l’autre mais une répartition : les charges soumises à contrainte réglementaire chez un acteur qualifié, les charges d’innovation là où le catalogue est le plus riche. Cette approche a un coût de gouvernance, traité dans notre section architectures hybrides et multicloud.

Ce qu’il faut instruire avant de s’engager

1. La réversibilité, service par service. Pour chaque service managé envisagé, estimer l’effort de sortie. L’exercice se fait avant la souscription, pas au moment du renouvellement.

2. Le coût réel sur trois ans, engagements compris, et pas le tarif catalogue. Voir notre section FinOps et pilotage de la dépense.

3. Les conditions de sortie contractuelles : durée de conservation des données après résiliation, format d’export, assistance à la reprise.

4. La localisation de l’exploitation, distincte de la localisation des données.

5. La trajectoire de compétences de l’équipe d’exploitation, qui conditionne autant la réussite que le choix technique.

Explorer le cluster

Cette page fait partie de notre couverture des architectures cloud et infrastructures d’entreprise : souveraineté, coûts, migration, virtualisation et datacenters.

iTPro+ : recevez chaque semaine les analyses d’architecture et les arbitrages de coût qui concernent les directions informatiques.