Cloud US ou cloud souverain : où héberger vos données quand vous vendez en Europe

Vous avez démarré sur AWS parce que c’était le choix par défaut, la doc était partout et votre premier dev le maîtrisait. Puis un prospect grand compte — une ETI industrielle, un acteur public, une banque — vous a envoyé un questionnaire de sécurité de quarante lignes. Une question revient : où sont hébergées les données, et qui peut légalement y accéder ? Et là, votre réponse « sur AWS eu-west-1, à Dublin » ne suffit plus.

C’est le moment où l’hébergement des données cesse d’être une case technique cochée à la va-vite pour devenir un arbitrage business. Le débat « cloud US vs cloud souverain » est souvent posé comme une question idéologique — patriotisme technologique contre pragmatisme. C’est une erreur. C’est une décision d’architecture qui engage votre coût, votre vitesse d’exécution, et surtout votre capacité à signer certains clients. Il faut la trancher avec la tête, pas avec le drapeau.

Le vrai problème n’est pas la localisation, c’est le droit applicable

La plupart des fondateurs croient que « héberger en Europe » règle la question RGPD. C’est faux, et cette confusion coûte cher.

Une donnée stockée à Dublin ou à Francfort sur un data center AWS reste soumise à une réalité juridique : Amazon est une entreprise de droit américain. Le CLOUD Act de 2018 permet aux autorités américaines de réclamer l’accès à des données détenues par une société soumise à leur juridiction, peu importe où se trouvent physiquement les serveurs. L’invalidation du Privacy Shield par l’arrêt Schrems II en 2020 a acté que ce risque était réel aux yeux de la justice européenne. Le Data Privacy Framework signé en 2023 a rétabli un cadre de transfert, mais il reste attaqué et fragile.

Traduction concrète pour vous : la localisation physique des serveurs en Europe réduit la latence et rassure sur le papier, mais elle ne vous met pas à l’abri d’une extraterritorialité du droit américain. Pour la majorité des startups B2C ou B2B early-stage, ce risque est théorique et n’aura jamais de conséquence opérationnelle. Pour une startup qui vise la santé, la défense, le secteur public ou les grands comptes régulés, il devient un critère de sélection éliminatoire.

Le bon réflexe n’est donc pas de choisir en fonction d’un principe, mais de vous demander : qui sont mes clients cibles dans les dix-huit mois, et que vont-ils exiger ?

AWS, GCP, Azure : la vitesse à un coût de dépendance

Soyons honnêtes sur ce que les hyperscalers vous apportent. AWS, GCP et Azure offrent une profondeur de services que personne d’autre n’égale : bases managées, files de messages, machine learning, serverless, observabilité, le tout documenté, éprouvé, avec une communauté immense. Pour une startup pre-seed ou seed qui doit sortir un produit vite avec trois développeurs, partir sur AWS n’est pas un aveu de paresse, c’est souvent la décision rationnelle. Vous achetez de la vitesse d’exécution, et à ce stade la vitesse vaut plus que la pureté.

Le piège n’est pas de commencer sur AWS. Le piège est de construire, sans y penser, sur les services propriétaires les plus verrouillants — DynamoDB, Lambda avec des dizaines de fonctions couplées à l’écosystème, Cognito, les workflows Step Functions — au point que migrer devienne un projet de six mois. Vous vous retrouvez alors avec deux problèmes cumulés : une dépendance technique forte et une exposition juridique que vos futurs clients grands comptes refuseront.

La parade n’est pas de fuir AWS. C’est de garder une hygiène d’architecture : bases de données standards (PostgreSQL managé plutôt qu’une base propriétaire), conteneurs plutôt que du serverless ultra-spécifique, et une séparation nette entre votre logique métier et l’infrastructure. Vous restez rapide aujourd’hui sans vous condamner demain.

Le cloud souverain : quand il devient un argument commercial, pas un handicap

OVHcloud, Scaleway, Outscale, Clever Cloud : l’écosystème français et européen a mûri. On n’est plus en 2015 où choisir un acteur local revenait à sacrifier la moitié des fonctionnalités. Ces plateformes proposent aujourd’hui du Kubernetes managé, du PostgreSQL, du stockage objet compatible S3, des GPU pour l’IA. Ce n’est pas au niveau d’AWS en largeur, mais pour 80 % des besoins d’une startup, c’est largement suffisant.

Et surtout, ces acteurs transforment un contrainte en argument de vente. Quand vous répondez à un appel d’offres public, une qualification SecNumCloud (le référentiel de l’ANSSI) ou un hébergement chez un acteur non soumis au CLOUD Act peut faire la différence entre être présélectionné ou éliminé au premier tour. Pour une startup HealthTech, l’hébergement HDS (Hébergeur de Données de Santé) n’est pas optionnel — c’est la condition légale d’exercice. Dans ces cas, le cloud souverain n’est pas un compromis : c’est votre permis de jouer.

Le pattern à éviter : la startup qui, par militantisme ou par peur, choisit un cloud souverain dès le pre-seed pour un produit B2C grand public sans aucune contrainte réglementaire, et se retrouve à réinventer des briques que AWS aurait fournies en une ligne. Vous payez alors la souveraineté en vélocité, sans aucun retour business. C’est le symétrique exact de l’erreur inverse.

L’option qui monte : l’architecture multi-cloud portable

Entre le tout-AWS et le tout-souverain, il existe une voie médiane devenue crédible : construire votre produit sur des briques ouvertes et portables, de façon à pouvoir déployer chez l’un ou l’autre selon le client.

Concrètement, cela veut dire s’appuyer sur des standards : conteneurs Docker orchestrés par Kubernetes, base PostgreSQL, stockage compatible S3, une couche d’abstraction (Terraform) pour décrire votre infrastructure. Avec cette discipline, héberger un client sensible sur Scaleway pendant que votre offre standard tourne sur GCP devient une question de configuration, pas de réécriture.

Attention, ce n’est pas gratuit. Le multi-cloud ajoute de la complexité opérationnelle, et il ne faut pas s’y engager en pre-seed « au cas où ». Mais dès que vous avez un ou deux prospects sérieux avec des exigences de souveraineté, cette portabilité vaut de l’or : elle vous permet de dire oui à un deal grand compte sans forker tout votre produit. C’est typiquement le genre de décision qui se prépare en seed pour être activée à la série A.

Ce qu’il faut vraiment faire, selon votre stade

En pre-seed et seed early, si vos clients cibles n’ont pas de contrainte réglementaire forte, partez sur un hyperscaler pour la vitesse — mais imposez-vous l’hygiène de portabilité : PostgreSQL, conteneurs, infrastructure décrite en code, pas d’enfermement dans les services propriétaires les plus exotiques. Vous vous gardez toutes les portes ouvertes pour un coût quasi nul.

Si votre marché est régulé dès le départ — santé, secteur public, défense, données sensibles — ne perdez pas de temps : l’hébergement souverain (HDS, SecNumCloud selon le cas) est une condition d’existence, pas un luxe. Intégrez-le dès l’architecture initiale, car le rétrofitter coûtera dix fois plus cher.

En seed avancé ou en approche de série A, quand vous ouvrez le B2B grand compte, faites l’inventaire des questionnaires de sécurité que vous recevez. S’ils exigent régulièrement une localisation européenne stricte ou une garantie contre l’extraterritorialité, préparez une capacité de déploiement souverain pour ces clients-là — sans forcément migrer tout votre socle. C’est là que la portabilité travaillée en amont paie.

Dans tous les cas, documentez vos choix. Un investisseur en due diligence technique, comme un acheteur grand compte, ne vous reprochera pas d’être sur AWS. Il vous reprochera de ne pas savoir répondre à la question pourquoi, et que se passe-t-il si un client exige autre chose ?

Une décision réversible si vous la préparez

L’hébergement des données n’est pas une croyance à défendre, c’est une contrainte à arbitrer entre la vitesse dont vous avez besoin maintenant et les clients que vous voulez signer plus tard. Le cloud US vous fait avancer vite ; le cloud souverain vous ouvre des marchés fermés ; la portabilité vous permet de ne pas choisir trop tôt.

La vraie erreur n’est ni AWS ni Scaleway. C’est de prendre cette décision par défaut, sans l’avoir reliée à votre stratégie commerciale — puis de la découvrir dans le questionnaire de sécurité d’un prospect que vous n’avez pas les moyens de perdre.

La question à vous poser ce trimestre n’est donc pas « suis-je souverain ? », mais : quel est le premier client que mon hébergement actuel m’empêche de signer — et à quel horizon ai-je besoin de lui dire oui ?