Et maintenant, on signe où ?

Trois articles pour poser le cadre. Les niveaux de garantie ne sont pas interchangeables. Le marché s'organise en trois familles qui ne promettent pas la même chose. Et derrière les plaquettes, les catalogues de services racontent une réalité bien plus contrastée que prévu. Tout cela est désormais documenté. Reste la dernière couche, celle qui fait passer du comparatif à la décision. Elle ne tient pas dans un tableau. Elle dépend de ce que l'on construit, de ce que l'on accepte de ne plus pouvoir quitter, et du prix que l'on met sur le fait de garder la main.

Là où le choix est déjà fait

Pour certains, la question ne se pose pas longtemps. Quand SecNumCloud est dans le cahier des charges, le périmètre se referme de lui-même. OIV, ministères, SI sensibles, données de santé hébergées sous doctrine Cloud au centre. On ne revient pas sur ce que le référentiel exige, on l'a détaillé dans le premier article de cette série.

Ce qui reste ouvert, en revanche, c'est le choix à l'intérieur du périmètre qualifié. Et il n'a rien d'anodin. D'un côté, les natifs qualifiés comme Outscale ou Cloud Temple offrent une cohérence juridique totale. Capital européen, opérations maîtrisées de bout en bout, aucune brique technologique soumise à un éditeur extraterritorial. La souveraineté y est directe, lisible, sans astérisque. De l'autre, S3NS propose depuis décembre 2025 une qualification SecNumCloud 3.2 adossée à la technologie Google Cloud, avec un catalogue nettement plus profond. PREMI3NS compte aujourd'hui une trentaine de services qualifiés (Compute Engine, GKE Autopilot, BigQuery, Cloud SQL Enterprise Plus, Pub/Sub, Cloud Armor, GPU H100) et prévoit d'en ajouter une vingtaine par an. Cloud Run, Dataproc, Cloud Spanner et Filestore sont attendus au premier semestre 2026, Vertex AI Model Garden au second, avec d'abord les modèles open-weight puis, plus tard, les modèles propriétaires comme Gemini. S3NS estime couvrir 60 à 70 % des usages aujourd'hui, avec un objectif de 80 à 90 % à mi-2027. Le tout avec un premium tarifaire de l'ordre de 15 à 20 % par rapport à Google Cloud public, selon Hélène Bringer, présidente de la coentreprise.

La tension est réelle. Choisir un natif, c'est acheter une indépendance technologique forte mais accepter un catalogue plus resserré, y compris sur Kubernetes où OKS chez Outscale n'est disponible que depuis décembre 2025. Choisir S3NS, c'est accéder à une profondeur fonctionnelle rare en environnement qualifié, mais intégrer dans son socle une dépendance à un écosystème américain, même encadré, et accepter que certains services mettent plusieurs mois à passer le sas de quarantaine opéré par Thales. Dans les deux cas, on est conforme. Mais on ne signe pas le même contrat de long terme.

Le ventre mou du marché, là où tout se joue

La réalité, c'est que la majorité des entreprises ne sont pas dans ce périmètre. Elles n'ont pas l'obligation SecNumCloud. Elles veulent un hébergement sérieux, des données en France ou en Europe, un cadre juridique lisible, mais elles ont aussi besoin de profondeur technique, de coûts maîtrisés et d'une capacité à livrer vite. C'est dans cette zone grise que se concentrent les décisions les plus difficiles, parce que plusieurs options se défendent et que le critère de départage n'est jamais le même.

Prenons une ETI industrielle qui modernise son SI. Elle a besoin de Kubernetes managé, de bases relationnelles, d'un stockage objet fiable et d'un minimum d'outillage CI/CD. Chez OVHcloud, elle trouve MKS (Managed Kubernetes Service, certifié CNCF, compatible avec les versions upstream jusqu'à Kubernetes 1.33), PostgreSQL et MySQL managés, un Object Storage compatible S3 et une facturation transparente sur l'egress. Le Kubernetes d'OVHcloud tourne sur Ubuntu 22.04 LTS avec containerd et Canal (Calico + Flannel), et supporte nativement les NGINX Ingress Controllers avec provisioning automatique de load balancers. Le socle est solide, souverain, compétitif. Mais si cette ETI a besoin d'un data warehouse managé, d'un message broker serverless ou d'une brique d'IA intégrée à sa chaîne de traitement, elle devra assembler elle-même ce que d'autres fournissent clé en main, typiquement en déployant un Kafka ou un Qdrant via les Managed Databases, puis en orchestrant ses modèles sur vLLM avec des GPU L4 ou L40S. Le choix est tenable si l'équipe plateforme dispose de la maturité nécessaire pour compenser.

À l'inverse, la même ETI peut regarder du côté de l'AWS European Sovereign Cloud, en disponibilité générale depuis janvier 2026. L'offre est techniquement une partition séparée d'AWS, physiquement et logiquement isolée des régions globales, avec sa propre infrastructure IAM, ses propres serveurs DNS (Route 53 sur des TLD européens), et un plan de contrôle entièrement distinct hébergé dans le Brandebourg. Les opérations sont assurées par des résidents européens, dans le cadre d'une entité de droit allemand (AWS European Sovereign Cloud GmbH), avec une transition progressive vers un personnel exclusivement composé de citoyens de l'UE. Le catalogue de lancement compte environ 70 services, incluant EC2, S3, Lambda, EKS, RDS et certaines briques d'IA. Mais cette isolation a un prix concret. Il n'existe pour l'instant qu'une seule région (Brandebourg), sans redondance géographique. Les Local Zones en Belgique, aux Pays-Bas et au Portugal sont annoncées mais pas encore opérationnelles. La migration depuis une région AWS classique ne se résume pas à un changement de région, c'est un changement de partition. Ce qui implique de recréer l'IAM, les configurations réseau et les pipelines de déploiement. Et surtout, Amazon reste la société mère. L'isolation technique et managériale est réelle, mais l'exposition au CLOUD Act demeure un sujet ouvert (même si une démarche SecNumCloud est envisagée). Si un client grand compte ou un régulateur sectoriel pose des questions sur l'exposition juridique, la réponse sera plus compliquée à formuler.

Le cas est différent pour un éditeur SaaS B2B en croissance. Son enjeu n'est pas le même. Il doit rassurer ses clients sur la localisation des données, parfois exhiber une conformité dans un appel d'offres, tout en gardant une agilité technique et un coût unitaire qui reste maîtrisé quand les volumes montent. Scaleway ou OVHcloud répondent bien à ce profil, avec des prix par VM parmi les plus bas du marché européen, du Kubernetes managé, du GPU disponible et aucun frais de sortie en zone EU. Ce que l'on gagne en indépendance et en lisibilité tarifaire, on le paie parfois en maturité d'écosystème ou en étendue du catalogue managé. Mais pour un SaaS qui construit sa propre stack, c'est souvent un compromis parfaitement assumable.

Reste le cas des projets IA sensibles. Ceux où l'on veut entraîner ou fine-tuner un modèle sur des données métier confidentielles. Là, le choix se resserre très vite. Soit on se tourne vers S3NS pour Vertex AI Model Garden en environnement qualifié, avec un accès prévu au second semestre 2026 aux modèles open-weight via une infrastructure H100 déjà opérationnelle dans trois datacenters franciliens. Soit on construit sur OVHcloud avec des GPU (L4 à 24 Go pour l'inférence de modèles jusqu'à 7B paramètres, L40S à 48 Go pour des modèles jusqu'à 20B, H100 pour les charges lourdes), en déployant vLLM ou TensorRT sur MKS avec un autoscaling custom basé sur les métriques Prometheus. La stack fonctionne, OVHcloud publie d'ailleurs des architectures de référence détaillées pour ce type de déploiement, mais il faut assembler soi-même ce que Vertex AI fournit sous forme de plateforme intégrée. Le niveau de contrôle n'est pas le même. La charge de travail non plus.

Dans tous ces cas, ce qui fait réellement pencher la balance n'est ni le logo ni la famille. C'est la combinaison entre ce que la plateforme fournit nativement, ce que l'on devra construire soi-même, et ce que l'on pourra encore déplacer dans dix-huit mois si le contexte change.

Ce que personne ne met dans le devis

C'est d'ailleurs sur ce dernier point que la plupart des comparatifs s'arrêtent trop tôt. On compare des tarifs de VM, parfois des prix de stockage, rarement le coût réel de ce qui se passe quand on veut partir.

Les egress fees ne sont que la partie émergée. Chez AWS, le trafic sortant se facture autour de 0,09 $/Go, auxquels s'ajoutent 0,045 $/Go de traitement NAT Gateway si le trafic sort d'un sous-réseau privé, soit un coût réel de 0,135 $ par Go dans ce cas de figure. Chez Azure, le tarif est de 0,087 $/Go après les 100 premiers Go gratuits mensuels, avec toutefois une politique de gratuité pour les migrations définitives vers un autre fournisseur. Chez OVHcloud et Scaleway, le trafic sortant est gratuit en zone européenne, tout comme les appels API et le réseau privé (vRack). Un SaaS qui sert 50 To par mois depuis AWS paie environ 4 300 $ d'egress pur, soit plus de 51 000 $ par an, uniquement pour délivrer des données à ses propres utilisateurs. Sur trois ans, l'écart avec un hébergement européen à egress gratuit se chiffre en centaines de milliers d'euros. Mais le vrai sujet est ailleurs.

Le vrai coût de sortie est architectural. Une application qui tourne sur Cloud Run ou Azure Functions n'a pas d'équivalent direct chez un acteur natif qui ne propose pas de serverless. La migrer, c'est la réécrire. Une base Cloud SQL avec des extensions spécifiques ne se transpose pas en un clic vers un PostgreSQL managé dont le périmètre d'extensions n'est pas le même. Le stockage objet « S3-compatible » est un bon exemple de cette portabilité en trompe-l'œil : les opérations standard fonctionnent, mais les lifecycle policies avancées, les event notifications ou certains modes de versioning diffèrent d'un fournisseur à l'autre. Un retour d'expérience publié par Zenika sur un déploiement multi-cloud AWS/OVHcloud le confirme : le Kubernetes managé se comporte de manière très similaire entre les deux plateformes, mais les intégrations périphériques (registre Docker, stockage S3, gestion des certificats TLS) demandent chacune des adaptations spécifiques. Les modules Terraform, les pipelines de déploiement, les intégrations de monitoring, tout cela est construit autour d'un fournisseur précis. Le jour où l'on change, on ne déménage pas une application. On la reconstruit en partie.

Il y a aussi un coût que personne ne chiffre dans un appel d'offres. Le temps qu'il faut à une équipe pour apprendre un nouvel écosystème. Les certifications à repasser. La double compétence à maintenir pendant la transition. Pour une équipe de dix personnes, basculer d'AWS vers OVHcloud ou l'inverse représente plusieurs mois de montée en compétence, pas en théorie, mais dans la réalité du delivery quotidien.

Intégrer le coût de sortie dans le coût d'entrée ne change pas forcément la décision finale. Mais cela change la manière dont on la prend. On ne compare plus des grilles tarifaires. On compare des trajectoires à trois ans.

Le bail compte autant que le loyer

Le marché du cloud souverain a suffisamment mûri pour que le choix d'un fournisseur ne relève plus de la conviction idéologique ou de l'habitude technique. Les garanties sont documentées, les catalogues sont ouverts, les écarts de prix sont connus.

Ce qui manque encore trop souvent, c'est la lucidité sur les clauses de sortie. On choisit un cloud comme on signe un bail. Le loyer compte, la surface aussi, mais c'est la durée d'engagement et les conditions de départ qui disent si le choix est réellement libre. Le meilleur fournisseur n'est pas celui qui promet le plus. C'est celui dont les limites restent compatibles avec les vôtres, y compris le jour où vous déciderez de ne plus en avoir besoin.