Souveraineté des données : faut-il vraiment héberger votre startup en France ?

Un prospect grand compte vous envoie son questionnaire sécurité. Question 14 : « Où sont physiquement stockées les données de vos utilisateurs ? » Vous répondez honnêtement : us-east-1, Virginie. Trois semaines plus tard, le deal est bloqué au juridique. Vous découvrez, un peu tard, que votre choix d’infrastructure vient de devenir un problème commercial.

La souveraineté des données est devenue l’un de ces sujets où l’idéologie, la peur et le marketing se mélangent au point qu’on ne sait plus quoi décider. D’un côté, on vous vend « le cloud souverain » comme une évidence patriotique. De l’autre, changer d’hébergeur quand on a déjà tout construit sur AWS ressemble à un suicide de runway. La vérité, comme souvent, est inconfortable : ça dépend de qui vous vendez, et la plupart des fondateurs tranchent cette question sur des critères émotionnels plutôt que sur leur ICP.

Ce que « souveraineté » veut réellement dire

Le mot est piégeux parce qu’il recouvre trois notions distinctes que l’on confond en permanence.

La première, c’est la localisation : où sont physiquement les serveurs. Un bucket S3 dans la région eu-west-3 (Paris) stocke bien vos données en France. Sur ce plan, AWS, Google Cloud et Azure ont tous des régions européennes et satisfont l’exigence de base du RGPD sur les transferts hors UE.

La deuxième, c’est la juridiction : quelles lois s’appliquent à l’entité qui opère l’infrastructure. Et c’est là que le bât blesse. AWS Europe a beau stocker vos données à Paris, la maison mère reste soumise au droit américain, notamment au Cloud Act, qui permet en théorie à une autorité américaine de réclamer l’accès à des données détenues par une entreprise US, où qu’elles soient hébergées. C’est le cœur du débat, et c’est ce qui distingue un hébergeur « européen » d’un hébergeur réellement « souverain ».

La troisième, c’est la réversibilité : votre capacité à récupérer vos données et à changer de fournisseur. Un point souvent oublié, alors qu’il conditionne tout votre pouvoir de négociation à long terme.

Confondre ces trois notions mène à des décisions absurdes : migrer en catastrophe vers un hébergeur français pour « la conformité RGPD » alors qu’une région européenne AWS suffisait largement, ou au contraire ignorer le sujet juridiction jusqu’au jour où un client de la défense ou de la santé vous demande une certification que vous ne pourrez jamais obtenir sur votre stack actuelle.

La vraie question n’est pas technique, elle est commerciale

Voici le pattern classique : un fondateur technique, sensible au sujet, décide dès le pre-seed d’héberger chez un acteur français « par principe ». Il se prive des services managés matures des hyperscalers, passe plus de temps sur l’infra, et sert un marché early-stage qui, à ce stade, se moque totalement de savoir où sont ses données. Il a résolu un problème qu’il n’avait pas encore.

À l’inverse, la startup B2B qui vise dès le départ des ETI, des banques, des acteurs publics ou de la santé, et qui construit tout sur us-east-1 par réflexe, se crée une dette de conformité qui explosera au pire moment : pendant un cycle de vente à six chiffres, ou pendant une due diligence de levée.

Le bon critère n’est donc pas « est-ce que la souveraineté c’est bien ? » mais « qui sont mes cinquante prochains clients, et qu’exigera leur service achats ou leur RSSI ? »

Si vous vendez à des PME, des indépendants, des scale-ups tech, la localisation UE d’un hyperscaler suffit dans l’immense majorité des cas. Personne ne vous demandera SecNumCloud. Si vous visez le secteur public français, les OIV (opérateurs d’importance vitale), la santé (avec l’obligation d’hébergement de données de santé, l’HDS) ou la défense, alors la juridiction devient un critère d’éligibilité, pas un supplément d’âme. Vous ne perdez pas un point de négociation : vous perdez le droit de participer à l’appel d’offres.

Entre les deux, il y a une zone grise B2B — les grands comptes privés — où le sujet apparaît de plus en plus dans les questionnaires sécurité sans être toujours bloquant. Un client peut préférer un hébergement européen sans l’imposer. Là, savoir répondre proprement (localisation, sous-traitants, mesures de chiffrement) vaut souvent plus que le choix d’hébergeur lui-même.

Le paysage réel des options en France

Concrètement, vous avez trois familles d’options, avec des arbitrages très différents.

Les hyperscalers en région européenne. AWS Paris, GCP, Azure. Maturité maximale, écosystème de services managés imbattable, vitesse de développement optimale. Vous cochez la localisation UE, mais pas la juridiction. C’est le défaut raisonnable pour 80 % des startups early-stage, et il n’y a aucune honte à commencer là.

Les acteurs européens et français « cloud ». OVHcloud, Scaleway, Clever Cloud, Outscale. Vous gagnez sur la juridiction (droit français, capital européen), souvent sur le prix, et pour certains sur des certifications comme SecNumCloud. Vous perdez en revanche sur la profondeur du catalogue managé : vous devrez parfois opérer vous-même ce qu’AWS vous offre en un clic. Pour une startup avec une petite équipe tech, ce surcoût opérationnel est réel et doit entrer dans l’équation runway.

Les offres « cloud de confiance ». Bleu (Orange/Capgemini) et S3ns (Thales/Google) proposent les technologies des hyperscalers américains opérées par des entités françaises, avec l’objectif SecNumCloud. Séduisant sur le papier pour combiner maturité et souveraineté, mais l’offre est encore jeune, chère, et calibrée pour des grands comptes plus que pour une startup seed.

Une architecture qui garde vos options ouvertes

Le vrai levier, quel que soit votre choix initial, c’est de ne pas vous enfermer. La souveraineté et la réversibilité se préparent dès l’architecture, pas le jour où un client l’exige.

Chiffrez vos données au repos et en transit, et gardez la maîtrise de vos clés — un chiffrement dont vous détenez les clés répond déjà à une bonne partie des inquiétudes du Cloud Act, indépendamment de l’hébergeur. Isolez ce qui est vraiment sensible : rien ne vous oblige à tout héberger au même endroit. Une architecture où les données personnelles ou réglementées vivent sur une infrastructure conforme, tandis que le reste tourne sur un hyperscaler, est parfaitement viable et souvent le meilleur compromis.

Enfin, limitez votre dépendance aux services propriétaires les plus difficiles à migrer. Une base PostgreSQL managée se déplace ; une architecture entièrement câblée autour de services maison très spécifiques d’un fournisseur vous enferme. Ce n’est pas un plaidoyer pour tout réinventer vous-même — ce serait absurde en seed — mais pour faire ces choix les yeux ouverts, en sachant lesquels seront coûteux à défaire.

Ce qu’il faut vraiment faire, selon votre stade

En pre-seed et seed, ne sur-optimisez pas. Choisissez une région européenne chez l’hébergeur qui vous fait avancer le plus vite, chiffrez proprement, documentez où sont vos données et vos sous-traitants dans un registre RGPD basique. Vous serez prêt à répondre à 90 % des questionnaires sécurité sans avoir sacrifié votre vélocité. La seule exception : si votre marché cible dès le jour un est la santé, le public ou la défense — là, la conformité est un prérequis produit, pas une optimisation.

Au moment d’attaquer le grand compte ou de préparer une série A, faites l’audit honnête : listez vos flux de données, vos sous-traitants, vos zones d’hébergement, et confrontez-les aux exigences de vos prospects les plus stratégiques. C’est souvent à ce moment qu’une migration partielle — pas totale — devient un investissement rentable, financé par les deals qu’elle débloque.

La souveraineté n’est ni un dogme à embrasser ni un gadget marketing à ignorer. C’est un curseur, et le bon réglage se lit dans votre pipeline commercial, pas dans l’actualité. Avant votre prochain arbitrage d’infrastructure, posez-vous la seule question qui tranche vraiment : parmi les clients que je veux gagner dans les dix-huit prochains mois, combien refuseront de signer à cause de l’endroit où vivent mes données ?