La French Tech ou le malentendu technologique

Résumé exécutif

Thèse. Le label "French Tech" sélectionne des champions de croissance numérique, pas des producteurs de briques technologiques. La majorité des licornes labellisées opèrent sur des infrastructures américaines soumises à des juridictions extra-européennes, sans plan de migration documenté ni cartographie publique de leurs dépendances critiques.

Méthode. Un indice de technicité à six dimensions (dépendances, portabilité, ops/sécurité, différenciation, contribution écosystème, maîtrise juridique), testé sur trois études de cas (Doctolib, ManoMano, Mirakl) et un contre-exemple positif (OVHcloud). Chaque dimension est notée de 0 à 5 sur des critères observables et auditables.

Trois résultats. (1) Les trois licornes étudiées obtiennent un score moyen de 2,3/5, contre 3,8/5 pour un acteur d'infrastructure comme OVHcloud. (2) Le transfert annuel de la France vers les hyperscalers US représente un ordre de grandeur de 8 à 11 milliards d'euros pour le seul IaaS+PaaS (donnée Synergy Research Group, extrapolation proportionnelle). (3) Le coût de migration hors d'un hyperscaler croît exponentiellement avec la durée d'utilisation, passant de ~50 k EUR en année 1 à plusieurs dizaines de millions en année 7.

Cinq recommandations. (1) Cartographie obligatoire des dépendances pour les bénéficiaires de financements publics. (2) Critère de technicité dans la sélection French Tech. (3) Axe "Briques souveraines" de 500 M EUR sur 5 ans dans France 2030. (4) Commande publique : 50 % des dépenses cloud étatiques sur SecNumCloud d'ici 2028. (5) Fonds de maintenance des briques open source critiques (50 M EUR/an). Budget total du plan : ~289 M EUR/an, soit moins de 4 % du CIR.

Ce que cet article ne dit pas (limites à lire avant de poursuivre)

Cet article ne dit pas que les entreprises French Tech sont mal gérées, non innovantes ou sans valeur. Il ne dit pas que la dépendance à des fournisseurs américains constitue une menace imminente et certaine. Il ne dit pas que les alternatives européennes sont aujourd'hui équivalentes en qualité et en coût aux hyperscalers.

Ce qu'il dit : la confusion entre croissance numérique et puissance technologique produit des angles morts dans la politique industrielle française. L'article adopte une perspective souverainiste explicite (biais assumé) et mesure l'autonomie technologique, pas la performance globale. Les scores attribués sont des estimations fondées sur des informations publiques, susceptibles de révision si les entreprises concernées publient leurs propres données.

Convention de marquage des chiffres utilisée dans cet article :

Les données factuelles sont marquées "Donnée (source)" lorsqu'elles proviennent d'une source primaire vérifiable (rapport annuel, communiqué institutionnel, base de données publique). Les calculs dérivés sont marqués "Estimation (hypothèses)" lorsqu'ils reposent sur un raisonnement explicité à partir de données vérifiables. Les extrapolations à forte incertitude sont marquées "Ordre de grandeur (incertitude élevée)" lorsque la marge d'erreur dépasse 30 % ou que la source n'a pas été vérifiée indépendamment.

1) Le malentendu fondamental : "numérique" n'est pas "tech"

Le débat public mélange souvent trois niveaux distincts dont la confusion produit des erreurs de diagnostic et, en aval, des erreurs de politique industrielle.

Le premier niveau est celui de la numérisation (ou digitalisation). Il s'agit de déplacer un processus existant vers un canal numérique : prendre rendez-vous chez un médecin, vendre du bricolage en ligne, gérer un catalogue de produits. L'innovation est réelle, l'impact mesurable, mais la valeur ajoutée réside dans l'optimisation du parcours, pas dans la production de composants techniques réutilisables.

Le deuxième niveau est celui du produit logiciel. Construire une application robuste, ergonomique, conforme, maintenable, sécurisée et opérable exige des compétences d'ingénierie significatives. Les équipes qui y parviennent à grande échelle méritent le respect. Mais le fait de produire un bon logiciel ne signifie pas que l'on maîtrise les briques sur lesquelles il repose.

Le troisième niveau est celui de la technologie au sens "briques". Produire des composants et des capacités réutilisables constitue le socle de la puissance technologique durable : systèmes distribués, bases de données, observabilité, cryptographie, IAM, runtimes, hyperviseurs, orchestration, stacks IA, outils de développement, compilateurs, protocoles. C'est à ce niveau que se situent les actifs qui conditionnent la résilience, l'indépendance et la réindustrialisation logicielle.

Le succès visible (utilisateurs, chiffre d'affaires, levées de fonds, statut "licorne") se situe surtout aux niveaux 1 et 2. La puissance technologique durable, celle qui conditionne l'autonomie stratégique, est largement au niveau 3.

Encadré A : définition opératoire (pédagogique)

Une entreprise peut être excellente sans être "tech" au sens industriel.

Tech (sens fort) désigne une entreprise qui maîtrise, produit et fait évoluer des briques différenciantes : propriété intellectuelle technique, savoir-faire rare, contributions à l'écosystème open source, effets de diffusion vers d'autres acteurs.

Numérique désigne une entreprise qui optimise un marché ou un usage par logiciel en s'appuyant majoritairement sur des briques existantes, souvent externes et souvent extra-européennes.

Ce n'est pas une question de valeur morale. C'est une question de taxonomie et de politique industrielle. Confondre les deux, c'est comme appeler "constructeur automobile" un loueur de voitures performant.

Encadré B : définition opérationnelle de "brique" (critères testables)

L'article utilise le terme "brique" comme concept central. Pour éviter toute ambiguïté, voici la définition opérationnelle retenue, conçue pour être testable par un auditeur externe.

Une brique technologique est un composant logiciel ou matériel qui satisfait cinq critères cumulatifs : (1) il est réutilisable par des tiers extérieurs à l'organisation qui le produit, (2) il est maintenu activement (correctifs de sécurité, mises à jour fonctionnelles), (3) il est documenté publiquement (API, guides d'intégration, spécifications), (4) il est versionné selon un schéma explicite (semver ou équivalent), et (5) il est effectivement consommé en dehors du produit qui l'a engendré.

Indicateurs mesurables pour qualifier une brique : nombre de dépendants externes (packages, services ou organisations qui l'utilisent en production), volume de téléchargements ou d'instanciations, nombre de contributeurs distincts, degré de standardisation (RFC, W3C, IETF, OASIS, ou standard de fait), et ratio mainteneurs actifs / utilisateurs.

Exemples français qui satisfont cette définition : Sōzu (reverse proxy Rust, Clever Cloud), les contributions de Scaleway à l'écosystème Kubernetes, les outils de chiffrement de Tanker (Doctolib). Exemples qui ne la satisfont pas : un algorithme de matching propriétaire utilisé uniquement en interne, une interface utilisateur même sophistiquée, un pipeline de données non réutilisable.

Cette définition exclut délibérément les innovations d'usage (UX, modèle d'affaires, acquisition) qui sont des sources de valeur économique réelles mais ne constituent pas des actifs technologiques au sens de l'autonomie stratégique.

2) Ce que le label sélectionne vraiment : performance économique + croissance

Le programme French Tech Next40/120, lancé en 2019 par la Mission French Tech, met en avant 120 entreprises accompagnées selon des critères principalement lies à la performance économique. La sixième promotion, annoncée le 5 juin 2025, repose sur deux axes : pour le Next40, avoir réalisé au moins 100 millions d'euros de chiffre d'affaires net avec 15% de croissance annuelle sur trois ans, ou figurer parmi les plus importants cumuls de levées de fonds entre janvier 2022 et avril 2025. Pour le French Tech 120, les seuils sont de 20 millions d'euros de chiffre d'affaires avec croissance similaire, ou 30 millions d'euros de levees cumulées.

Source officielle : https://lafrenchtech.gouv.fr/fr/programme/french-tech-next-40-120/

Cette sélection est cohérente pour une politique de croissance. Des critères complémentaires ont été introduits (bilan carbone scopes 1-2-3, index égalité professionnelle Egapro, et depuis 2025 une attention à la capacité d'innovation via le CIR). Mais ces ajouts ne mesurent pas directement la dépendance à des composants critiques, la capacité de repli (exit plan), la maîtrise des couches basses, ou la contribution à l'autonomie stratégique.

Conclusion intermediaire : le dispositif ne "ment" pas. Il fait un arbitrage explicite, assume et documenté. Le probleme nait quand on présente une sélection de champions de croissance comme preuve de puissance technologique. Le glissement sémantique entre "French Tech" (label de politique économique) et "tech française" (capacité d'ingénierie) est la source du malentendu.

Un point d'honnêteté s'impose : la promotion 2025 note que 116 des 120 lauréats déclarent intégrer l'IA dans leurs activités, et que 93% ont une présence significative à l'international. Ces indicateurs montrent que l'écosystème mûrit, mais ils ne suffisent pas à établir une maîtrise technologique au sens des briques. Utiliser un LLM d'OpenAI via API et produire un modèle de fondation sont deux réalités radicalement différentes.

3) Méthode : sortir du débat d'opinion avec un indice de technicité

Pour eviter le "c'est tech / c'est pas tech" au doigt mouille, on peut utiliser un indice simple, falsifiable, applicable à tous. Cette methode n'a pas vocation à être définitive. Elle vise à fournir un outil de diagnostic reproductible, susceptible de critique et d'amélioration, mais préférable à l'absence de grille.

3.1 Indice de technicité (6 dimensions, score 0 à 5)

La première dimension est la maîtrise des dépendances critiques. Il s'agit de compter les services externes indispensables (cloud, CI/CD, observabilité, authentification, paiement, messaging, data pipeline) et d'évaluer le degré de contrôle que l'entreprise exerce sur chacun. Un score de 5 signifie que l'entreprise contrôle ou peut remplacer tous ses composants critiques. Un score de 0 signifie une dépendance totale et non cartographiee.

La deuxième dimension est la portabilité et le plan de sortie. Quel est le temps et le coût d'une migration hors du fournisseur critique (cloud ou SaaS) ? Un exit plan documenté et testé régulièrement vaut 5. L'absence totale de reflexion sur le sujet vaut 0.

La troisième dimension est la maturité Ops et sécurité. Elle couvre les SLO documentés, les post-mortems publiés, les PRA/PCA testés, le SBOM (Software Bill of Materials), le patching, la gestion de la supply-chain logicielle. La certification ISO 27001 ou HDS constitue un minimum, pas un maximum.

La quatrième dimension est la différenciation technique. Il s'agit de la barrière technique réelle : performance, architecture, scalabilité, fiabilité, sécurité, qualité de service. La question est de savoir si un concurrent pourrait reproduire le produit en six mois avec les mêmes briques open source.

La cinquième dimension est la contribution à l'écosystème. Contribuer à l'open source (pas seulement utiliser), proposer des standards, publier de l'outillage partage, diffuser des retours d'expérience techniques substantiels. Consommer du logiciel libre sans jamais contribuer n'est pas neutre : c'est un transfert de valeur non reciproque.

La sixième dimension est la maîtrise juridico-technique. Il s'agit de la capacité à réduire l'exposition aux lois extra-européennes (CLOUD Act, FISA, Patriot Act) et à prouver concretement ce qui est protege. La localisation des données "dans l'UE" ne suffit pas si le fournisseur reste soumis à une juridiction étrangère.

3.2 Le test de réalité en trois questions

Encadré B : test de dépendance (utilisable tel quel)

Question 1 : sans hyperscaler US (AWS, Azure, GCP), l'activite tourne encore ? (oui/non + delai de migration estime)

Question 2 : sans SaaS critiques (Stripe, GitHub, Datadog, Salesforce, Auth0), l'activite tourne encore ? (oui/non + nombre de services concernes)

Question 3 : qui contrôle la brique cle (code, roadmap, exploitation) : vous ou un tiers ? Et ce tiers est-il soumis à une juridiction qui peut vous imposer des conditions unilateralement ?

Si les réponses sont non, non, et tiers soumis à une juridiction extra-européenne, ce n'est pas une injure : c'est un diagnostic. On est face à une entreprise numérique performante, pas à un producteur de briques technologiques souveraines.

3.3 Limites methodologiques

Cet indice présente des limites qu'il faut expliciter. Il ne capture pas la qualité de l'experience utilisateur, l'innovation d'usage, la capacité de distribution, ni la création d'emplois. Il est construit pour mesurer l'autonomie technologique, pas la performance globale. Il favorise structurellement les acteurs d'infrastructure par rapport aux acteurs applicatifs, ce qui est un biais assumé en tant que le but est de mesurer la "technicité" au sens briques.

Par ailleurs, un score faible ne signifie pas que l'entreprise est mal gérée ou non viable. Il signifie que sa valeur stratégique pour l'autonomie technologique nationale est limitée par ses dépendances. Un distributeur efficace et un producteur de composants jouent des rôles différents dans une filière. Les deux sont nécessaires. La confusion entre les deux est préjudiciable.

3.4 Grille de scoring : critères observables et preuves attendues par dimension

Pour chaque dimension, le score repose sur des critères vérifiables. Le tableau suivant fournit les repères pour les niveaux 0, 2 et 4 (les niveaux intermédiaires se déduisent par interpolation), ainsi que les preuves attendues pour qu'un score soit considéré comme auditable.

Exemple comparé : dimension "Portabilité / exit plan"

Une licorne French Tech typique (score 2) : l'équipe infrastructure a documenté un plan de migration théorique vers un second cloud, mais ce plan n'a jamais été testé en conditions réelles. L'architecture utilise 15 à 20 services managés propriétaires (Lambda, DynamoDB, SQS). Le temps de migration estimé est de 12 à 18 mois. La direction considère le sujet comme "important mais non urgent".

Un acteur d'infrastructure comme OVHcloud ou Scaleway (score 4) : l'entreprise opère sa propre infrastructure physique. La portabilité est intrinsèque au modèle (les clients peuvent migrer, l'entreprise ne dépend pas d'un tiers pour ses propres opérations). Les standards ouverts (OpenStack, Kubernetes) garantissent l'interopérabilité. Les tests de résilience sont réguliers.

Exemple comparé : dimension "Maîtrise des dépendances"

Doctolib (score estimé : 2) : l'hébergement AWS est cartographié et documenté publiquement. Le chiffrement via tiers de confiance (Atos/Tanker) constitue une mesure d'atténuation. Mais AWS reste le fournisseur unique d'infrastructure compute et stockage, sans alternative testée ni plan de bascule opérationnel connu.

OVHcloud (score estimé : 4) : l'entreprise fabrique ses propres serveurs, conçoit son système de refroidissement et opère la totalité de sa chaîne technique. Les dépendances critiques résiduelles (composants matériels, connectivité réseau) sont cartographiées et diversifiées.

Encadré D : biais assumés de l'indice

Cet indice comporte trois biais explicites qu'il faut nommer pour éviter les procès d'intention.

Biais 1 : il favorise l'infrastructure par rapport à l'applicatif. C'est assumé. L'indice mesure la contribution à l'autonomie technologique, pas la qualité du produit ni la création de valeur économique. Un éditeur SaaS brillant qui opère entièrement sur AWS obtiendra un score faible. Ce n'est pas une critique de son talent, c'est la mesure d'une dépendance.

Biais 2 : il valorise la souveraineté juridique européenne. La dimension 6 (maîtrise juridico-technique) pénalise structurellement les entreprises qui utilisent des fournisseurs soumis au droit américain. Ce biais reflète la thèse de l'article : la juridiction applicable est un facteur de risque stratégique. Un lecteur libéral considérera ce biais excessif. Un lecteur souverainiste le trouvera légitime.

Biais 3 : il ne mesure pas l'innovation d'usage. Doctolib a transformé l'accès aux soins pour des dizaines de millions de Français. ManoMano a démocratisé l'accès au bricolage. Ces impacts sont réels et considérables. L'indice ne les capture pas, parce que ce n'est pas son objet. Il faut donc lire les scores en complément d'autres indicateurs, pas comme un jugement global.

4) Études de cas : Doctolib, ManoMano, Mirakl

Ces trois cas sont utiles car ils représentent des vitrines fréquentes du succès "French Tech" et illustrent trois mécanismes différents : un produit critique (santé) et la question des dépendances d'infrastructure, une marketplace B2C et la prédominance de l'intermédiation, un SaaS B2B qui industrialise la création de marketplaces.

Important : l'objectif n'est pas de dénigrer des réussites. L'objectif est de clarifier ce que l'on appelle "tech" et d'évaluer ce que ces entreprises apportent à l'autonomie stratégique.

4.1 Doctolib : excellence produit, dépendance structurante

Doctolib est une réussite produit indiscutable : adoption massive, UX de référence, impact mesurable sur l'accès aux soins. Le débat n'est pas "est-ce bien ?" mais "quelles briques critiques, et qui les contrôle ?".

#### 4.1.1 Hébergement et sous-traitance ulterieure

Doctolib indique explicitement recourir à Amazon Web Services pour l'hébergement et precise que les données sont stockées dans l'Union européenne. La page officielle d'aide indique, en date d'avril 2025 : "AWS (Amazon Web Services) hébergé vos données en toute sécurité. [...] En France, AWS est certifié Hébergeur de Données de Sante (HDS), conformement aux exigences de l'Agence du Numérique en Sante et de la CNIL."

Sources :

Point pédagogique essentiel : la localisation ("dans l'UE") n'est pas identique au contrôle technico-juridique. AWS Sarl (filiale luxembourgeoise) reste une filiale d'Amazon Web Services Inc. (société américaine). La juridiction suit l'entreprise, pas la localisation physique des serveurs. C'est exactement le principe tranché par le CLOUD Act de 2018, qui a été adopté pour résoudre l'affaire Microsoft Ireland : la juridiction américaine s'applique aux données détenues par une société américaine, quel que soit le lieu de stockage.

#### 4.1.2 Le point dur : mesure de risque extraterritorial (pas accusation d'accès systématique)

Il est essentiel de poser le cadre avec précision. L'analyse qui suit est une mesure de risque, pas une accusation d'accès effectif. Rien n'indique que les autorités américaines accèdent aujourd'hui aux données de santé de Doctolib. La question porte sur la possibilité juridique d'un tel accès et sur la probabilité opérationnelle dans différents scénarios.

Possibilité juridique. Le CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) autorise les autorités américaines à exiger, par mandat judiciaire ou subpoena, l'accès aux données détenues par des entreprises américaines, y compris sur des serveurs situés hors des États-Unis. Le Department of Justice maintient une page de ressources dédiée : https://www.justice.gov/criminal/cloud-act-resources. Ce cadre s'applique à AWS en tant que filiale d'Amazon Inc. La CNIL à critiqué les approches de certification cloud qui n'intègrent pas cet enjeu, appelant dans son avis EUCS à "l'inclusion, à titre optionnel, de critères d'immunité aux lois extra-européennes". Source : https://www.cnil.fr/fr/cloud-les-risques-dune-certification-européenne-permettant-lacces-des-autorites-étrangères

Probabilité opérationnelle. La probabilité d'un accès effectif varie selon le scénario. En temps normal, entre alliés, la probabilité d'une demande ciblant des données de santé individuelles est faible. En cas de tensions diplomatiques ou de conflit d'intérêts (renseignement économique, compétition industrielle pharmaceutique), la probabilité augmente. En cas de rupture géopolitique, le risque devient systémique (coupure de service, pas seulement accès).

Niveaux d'exposition distincts. L'accès potentiel ne concerne pas les données de la même manière selon leur état :

Les données au repos (fichiers stockés sur S3, bases de données) sont protégées par le chiffrement. Si les clés sont détenues par un tiers européen (Atos/Tanker dans le cas de Doctolib), l'accès au contenu chiffré est techniquement bloqué pour AWS.

Les données en traitement passent nécessairement en clair dans les instances de calcul (EC2, Lambda). C'est une contrainte architecturale fondamentale : pour traiter une donnée, il faut la déchiffrer. Dans un cloud opéré par un tiers, l'opérateur contrôle l'infrastructure sous-jacente (hyperviseur, réseau, consoles d'administration), ce qui crée une surface d'exposition résiduelle, même si le chiffrement côté client réduit fortement le risque sur les données au repos.

Les données en transit entre composants internes au cloud AWS transitent sur le réseau d'AWS. Le chiffrement TLS protège le contenu, mais l'architecture de terminaison TLS dépend de la configuration applicative et peut, selon les cas, impliquer des composants contrôlés par le fournisseur.

Les métadonnées (qui accède à quoi, quand, depuis quelle adresse IP, volumes de requêtes, patterns d'utilisation) ne sont pas chiffrées par le dispositif Atos/Tanker. Ces métadonnées sont exploitables indépendamment du contenu : savoir qu'un ministre consulte un oncologue à 3 h du matin est une information de renseignement, même sans accéder au dossier médical.

Le débat EUCS illustre la fracture européenne sur ce sujet. La France plaide pour un niveau "High+" incluant des garanties contre les lois extraterritoriales, position soutenue par plusieurs États membres du sud de l'Europe. D'autres, notamment dans le nord, s'y opposent au nom de la compétitivité et de l'accès aux services des hyperscalers. En 2025, le projet reste bloqué faute de consensus, et la Commission européenne a introduit en octobre 2025 un cadre d'évaluation de souveraineté cloud (Cloud Sovereignty Framework) pour ses propres marchés publics, dont les modalités de pondération varient selon les procédures d'achat.

#### 4.1.3 Sécurité, conformité et confusion fréquente

Doctolib détient la certification ISO 27001 et la certification HDS (Hébergeur de Données de Santé), obtenues en novembre 2021. Le chiffrement des données repose sur un dispositif impliquant un tiers de confiance (Atos/Tanker) qui détient les clés, empêchant théoriquement AWS de lire les données au repos.

Ces certifications témoignent d'un effort réel. Mais elles répondent d'abord à la sécurité et à la conformité réglementaire. Elles ne suppriment pas la dépendance industrielle (capacité d'AWS à couper le service, modifier ses conditions, augmenter ses prix) ni l'exposition aux métadonnées et aux données en traitement décrites en 4.1.2.

Source : https://www.usine-digitale.fr/article/doctolib-obtient-deux-certifications-sur-la-securisation-des-données-de-santé.N1162082

Synthèse du risque : le chiffrement côté client protège efficacement les données au repos. Il ne protège ni les données en traitement, ni les métadonnées, ni contre une coupure de service. Le risque n'est pas un accès quotidien et massif : c'est la combinaison d'une possibilité juridique réelle, d'une surface d'exposition technique partielle (traitement + métadonnées), et d'une dépendance opérationnelle totale à un fournisseur unique soumis à une juridiction étrangère. Pour les données de santé de dizaines de millions de Français, cette combinaison mérite une analyse de risque formelle, pas un rejet par argument d'autorité ("les certifications suffisent").

#### 4.1.4 Conclusion Doctolib (sur l'indice)

Produit logiciel : score élevé. Ops et sécurité : élevé (certifications, chiffrement, post-mortems documentés). Souverainete briques : contrainte par le choix de sous-traitance cloud et l'écosystème de dépendances.

Formule : une licorne française peut être excellente tout en étant opérée sur une infrastructure américaine. Ce n'est pas un jugement moral, c'est un fait d'architecture et de dépendances. Le débat porte sur les conséquences stratégiques de ce fait.

4.2 ManoMano : marketplace, intermédiation avant tout

ManoMano illustre une réussite de marché fondée sur l'intermédiation : place de marché entre marchands tiers et clients dans l'univers du bricolage et de l'aménagement. L'entreprise a atteint une valorisation dépassant les 2 milliards d'euros en 2021 après une levée de 355 millions de dollars.

Sources :

#### 4.2.1 Pourquoi c'est central pour la thèse "French Tech != tech"

Une marketplace est une machine d'orchestration sophistiquée. Elle couvre l'acquisition de trafic, le matching et le ranking, la gestion du catalogue, le paiement, la gestion des vendeurs, la logistique et les retours (souvent via partenaires), la lutte anti-fraude, la qualité et le SAV.

Cela demande des ingénieurs solides et une exécution irréprochable. Mais la barrière à l'entrée est mixte : effets de réseau, marque, accès au trafic (dépendant de Google et Meta pour l'acquisition), exécution commerciale, optimisation incrémentale du parcours. Le "moat" technique existe, mais il se traduit surtout en avantage applicatif et en execution. La brique "réutilisable" au sens industriel, celle qui structurerait des milliers d'acteurs en aval, est moins évidente.

La dépendance à Google pour l'acquisition est un point structurel rarement discute. Pour une marketplace, le coût d'acquisition client (CAC) est largement determine par les encheres Google Ads et le referencement naturel. Une modification algorithmique de Google peut faire varier le trafic organique de 30% en quelques semaines. Cette dépendance au canal est une forme de fragilité qui n'apparait pas dans les bilans.

Encadré C : question de vérité

"Si ManoMano disparait demain, quelle brique de base manque au monde (runtime, base de données, système d'observabilité, IAM, standard, protocole) ?" La réponse : probablement aucune. En revanche, si une brique d'infrastructure comme PostgreSQL, Kubernetes ou Let's Encrypt disparait, des milliers d'acteurs sont touches.

Ce test n'est pas une depreciation. Il est un outil de classification.

#### 4.2.2 Conclusion ManoMano (sur l'indice)

Produit : bon. Briques : faibles au sens industriel. Dépendances : probablement importantes (à cartographier publiquement). Valeur principale : intermédiation, exécution commerciale, et effets de réseau.

4.3 Mirakl : logiciel B2B, industrialiser la marketplace

Mirakl vend une plateforme SaaS permettant aux entreprises de lancer et d'opérer des marketplaces, avec des extensions type dropship et retail media. L'entreprise à annonce un ARR de 177 millions de dollars et une croissance de 30% de son GMV en 2023, atteignant la rentabilite sur son activite de plateforme.

Sources :

#### 4.3.1 Pourquoi Mirakl est pédagogique

Mirakl est plus "tech" que la moyenne au sens produit B2B. L'entreprise gère une integration complexe (vendeurs, catalogue, flux, payouts), des enjeux de SLA, de sécurité et de scalabilité, et elle industrialise un produit réutilisable vendu à des dizaines de grands comptes. C'est un editeur de logiciel au sens classique, avec une IP produit réelle.

Mais la these reste valable : la brique centrale est une brique d'intermédiation industrialisée. Mirakl ne produit pas de composant d'infrastructure (base de données, runtime, système d'exploitation, protocole réseau). L'écosystème French Tech valorise fortement l'intermédiation comme horizon technologique, ce qui révèle un biais structurel.

#### 4.3.2 Conclusion Mirakl (sur l'indice)

Produit : élevé. Ops : élevé (selon organisation). Brique "couche basse" : faible. Valeur stratégique : permettre à d'autres de faire de la marketplace. C'est une contribution réelle à l'écosystème économique, mais pas une contribution à l'autonomie technologique au sens infrastructure.

5) Discussion : ce que ces cas révèlent (sans caricature)

5.1 Le biais structurel : l'aval est récompensé, l'amont est invisibilisé

Les entreprises étudiées comptent des ingénieurs de haut niveau et gèrent des systèmes complexes à grande échelle. Le point n'est pas "ils ne savent pas coder". Le point est que la France récompense davantage l'applicatif visible que l'infrastructure, l'outillage et les standards.

Ce biais n'est pas propre à la France. Les États-Unis aussi célèbrent leurs licornes applicatives. Mais ils disposent simultanément d'une base industrielle d'infrastructure massive (AWS, Azure, GCP, GitHub, Docker, Kubernetes, gRPC, TensorFlow, PyTorch) qui rend la dépendance de leurs startups applicatives stratégiquement moins problématique. Quand une startup américaine dépend d'AWS, elle dépend d'une infrastructure nationale. Quand une startup française dépend d'AWS, elle dépend d'une infrastructure étrangère soumise à une juridiction étrangère.

5.3 Le cas Microsoft/CPI et la matérialisation du risque

L'analyse de risque exposée en section 4.1.2 peut sembler théorique. L'incident de mai 2025 la matérialise : Microsoft a bloqué l'accès email du procureur de la Cour pénale internationale Karim Khan, affectant le fonctionnement d'une institution internationale par une décision opérationnelle unilatérale (sources : AP News, mai 2025 ; EU ISS Brief, mai 2025). Ce précédent démontre que le risque n'est pas limité à l'accès aux données : il inclut la restriction ou coupure de service, un levier autrement plus puissant que l'espionnage.

Encadré : les deux risques de la dépendance cloud (ne pas les confondre)

Le débat public confond systématiquement deux risques de nature différente, ce qui permet aux défenseurs du statu quo d'écarter le premier pour ignorer le second.

Risque 1 : accès et exposition des données. Un tiers (gouvernement étranger, acteur malveillant, opérateur lui-même) accède aux données hébergées, aux métadonnées, ou aux flux en transit. Ce risque est juridique (CLOUD Act, FISA 702, subpoena) et technique (accès structurel de l'opérateur au runtime, aux clés de chiffrement en mémoire, aux métadonnées réseau). Le chiffrement côté client atténue partiellement ce risque pour les données au repos, mais ne couvre ni les métadonnées ni les données en cours de traitement.

Risque 2 : restriction, coupure, dégradation ou manipulation tarifaire du service. L'opérateur restreint, suspend ou dégrade le service, ou impose des conditions tarifaires unilatérales exploitant le verrouillage technique. Ce risque relève du pouvoir de marché (lock-in, egress fees, committed use discounts) et du levier géopolitique (sanctions, Entity List, pressions diplomatiques). Le cas Microsoft/CPI (mai 2025) illustre le risque 2 en action. Les précédents russes et iraniens combinent les deux risques simultanément.

Le chiffrement et les contrats peuvent atténuer le risque 1 (partiellement). Ils ne font rien contre le risque 2. C'est pourquoi la portabilité et l'existence d'alternatives sont des conditions nécessaires de souveraineté, indépendamment du niveau de chiffrement.

5.4 Le contre-argument de l'efficience et ses limites

Un contre-argument fréquent mérite d'être traité honnêtement : les hyperscalers américains offrent des services supérieurs en qualité, en disponibilité et en rapport coût-performance. Construire des alternatives européennes coûterait plus cher et produirait des services moins performants. Les startups françaises ont raison de choisir les meilleurs outils disponibles pour maximiser leur compétitivité.

Ce raisonnement est valable à l'échelle microéconomique et à court terme. Une startup individuelle a intérêt à utiliser AWS plutôt qu'un cloud européen moins mature. Mais à l'échelle macroéconomique et à long terme, l'accumulation de ces choix individuels rationnels produit une dépendance collective qui constitue une vulnérabilité stratégique. C'est un cas classique de dilemme entre optimum individuel et optimum collectif, comparable au choix d'un pays d'importer toute son énergie parce que c'est moins cher, jusqu'au jour où le fournisseur coupe le robinet.

La question n'est pas de forcer chaque startup à utiliser un cloud européen. Elle est de s'assurer qu'une alternative crédible existe, qu'un plan de migration est documenté, et que les dépendances critiques sont cartographiées. C'est la différence entre accepter une dépendance les yeux ouverts et la subir par défaut.

5.5 Quantification économique : combien coûte la dépendance ?

Le diagnostic de dépendance reste abstrait sans chiffrage. Cette section tente une estimation, en explicitant le périmètre et la méthode pour permettre la critique.

Périmètre et définitions. Le "marché cloud français" recouvre trois segments distincts : le cloud infrastructure (IaaS : compute, stockage, réseau), le cloud plateforme (PaaS : bases de données managées, containers, fonctions serverless) et le cloud logiciel (SaaS : applications délivrées en ligne). Les sources utilisent des périmètres différents : Markess by Exaegis couvre l'ensemble IaaS+PaaS+SaaS ; Synergy Research Group couvre principalement IaaS+PaaS+cloud privé hébergé. Les chiffres ne sont donc pas directement comparables d'une source à l'autre. Toutes les données ci-dessous portent sur l'année civile 2025, sauf mention contraire.

Données disponibles. Markess by Exaegis estimait en 2022 le marché cloud français (IaaS+PaaS+SaaS) à environ 27 milliards d'euros pour 2025 [Estimation (prévision 2022, périmètre IaaS+PaaS+SaaS)]. Naitways, compilant les données IDC, indique 35,3 milliards d'euros pour 2023 (plateformes 15,6 Mds + services 19,7 Mds) [Donnée (IDC via Naitways, année 2023)], ce qui suggère un marché 2025 de l'ordre de 40 à 45 milliards en incluant le SaaS. À l'échelle européenne, Synergy Research Group estime les revenus cloud infrastructure (IaaS+PaaS, hors SaaS) à 72 milliards d'euros pour 2025 [Donnée (Synergy Research Group)].

Parts de marché. Synergy Research Group (Q3 2025) mesure les parts mondiales d'IaaS+PaaS : AWS 29 %, Azure 20 %, GCP 13 %, soit 63 % pour les trois hyperscalers [Donnée (Synergy Research Group, Q3 2025)]. En Europe, la concentration est plus forte : les trois américains captent environ 70 % du marché IaaS+PaaS européen. En France, la domination d'AWS est encore plus marquée qu'à l'échelle mondiale : selon Markess by Exaegis, AWS détenait 46 % du marché hexagonal IaaS/PaaS en 2021 (contre 31-33 % au niveau mondial), Azure 17 % et GCP 8 %, soit 71 % pour le trio [Donnée (Markess by Exaegis via Distributique, 2021)]. Les fournisseurs européens représentent 15 % de leur propre marché régional, un chiffre stabilisé depuis 2022 après une chute depuis 29 % en 2017 [Donnée (Synergy Research Group)].

Estimation du transfert France vers hyperscalers US. Marché français cloud infrastructure (IaaS+PaaS), estimé entre 12 et 15 milliards d'euros (hypothèse : la France représente environ 15-18 % du marché européen de 72 milliards), multiplié par 70 % de part américaine, donne une fourchette de 8 à 11 milliards d'euros par an pour le seul IaaS+PaaS [Estimation (hypothèse proportionnelle, marge d'erreur ~25 %)]. En ajoutant le SaaS américain (Microsoft 365, Salesforce, Google Workspace, etc.), l'étude Cigref/Astérès, citée par le CNLL en mai 2025, estime le transfert total Europe vers les États-Unis à 264 milliards d'euros par an pour l'ensemble cloud+logiciels. La part française, calculée par extrapolation proportionnelle au PIB (environ 17 % du PIB UE), se situerait dans un ordre de grandeur de 40 à 45 milliards d'euros pour cloud+logiciels combinés [Ordre de grandeur (incertitude élevée, source secondaire non vérifiée indépendamment)].

Sources primaires : Synergy Research Group, Q3 2025 (parts de marché mondiales et européennes) ; Markess by Exaegis, 2022 (prévisions marché FR) ; Naitways/IDC, octobre 2025 (données marché FR 2023). Source secondaire, étiquetée comme telle : Cigref/Astérès via CNLL, mai 2025 (estimation transfert UE vers US, ordre de grandeur non vérifié indépendamment par l'auteur).

5.6 La dynamique temporelle du lock-in : un piège qui se referme

La dépendance technologique n'est pas statique. Elle s'aggrave avec le temps selon un mécanisme de verrouillage progressif que l'économie numérique amplifie par rapport aux secteurs traditionnels.

À l'année 1 d'utilisation d'un hyperscaler, une startup utilise des services génériques (compute, stockage objet, bases de données relationnelles) qui restent relativement portables. Le coût de migration est faible, de l'ordre de quelques semaines-ingénieurs.

À l'année 3, l'entreprise a commencé à utiliser des services managés propriétaires : Lambda (AWS), Cloud Functions (GCP), Azure Functions, des services de messaging (SQS, SNS), des bases de données propriétaires (DynamoDB, Cosmos DB), des pipelines de données intégrés (Glue, Data Factory). Chaque service propriétaire ajoute une couche de dépendance qui n'existait pas au départ. Le coût de migration passe à plusieurs mois-équipe.

À l'année 5-7, la dette de dépendance est massive : les architectures sont construites autour de services specifiques au fournisseur, les pipelines de données utilisent des formats et des API non portables, les équipes ont développé une expertise spécifique à un seul cloud, et les contrats commerciaux comportent des engagements de consommation pluriannuels (committed use discounts) qui pénalisent financièrement la migration. Le coût de migration atteint des dizaines de millions d'euros et des mois d'interruption opérationnelle.

Ce phénomène est aggravé par l'IA : les pipelines de machine learning (SageMaker, Vertex AI, Azure ML) créent des dépendances supplémentaires sur les données d'entraînement, les formats de modèles et les infrastructures GPU spécifiques. Une startup qui a entraîné ses modèles sur SageMaker pendant trois ans fait face à un coût de réimplémentation qui peut excéder le coût de développement initial.

La consequence stratégique est claire : plus on attend pour cartographier les dépendances et planifier la portabilité, plus le coût de l'autonomie augmente. C'est un argument pour agir maintenant, pas apres-demain.

Encadré : les six accélérateurs du verrouillage (ce qui fait exploser le coût)

Le coût de migration ne croît pas linéairement par hasard. Six mécanismes concrets, souvent combinés, transforment une dépendance initiale maîtrisable en piège structurel.

Services managés propriétaires. Lambda, DynamoDB, Cosmos DB, Cloud Spanner, BigQuery : chaque service propriétaire adopté remplace un composant portable par un composant dont l'API, le comportement et les garanties de performance n'existent que chez un seul fournisseur. La migration exige une réécriture, pas une reconfiguration.

IAM natif et politiques d'accès. Les systèmes de gestion d'identités et de droits (IAM roles, policies, service accounts) sont spécifiques à chaque cloud. Une architecture de sécurité construite sur AWS IAM ne se transpose pas vers Azure AD ou GCP IAM sans refonte complète des modèles d'autorisation.

Data egress et formats propriétaires. Les frais de sortie de données (egress fees) pénalisent financièrement toute extraction massive. Les formats de stockage optimisés pour un fournisseur (Parquet sur S3 avec Glue catalog, Delta Lake sur Azure, BigTable) ajoutent un coût de conversion des données qui croît avec le volume.

Observabilité propriétaire. CloudWatch (AWS), Azure Monitor, Cloud Logging (GCP) : les métriques, alertes, dashboards et runbooks opérationnels construits sur ces outils ne sont pas portables. Migrer l'observabilité, c'est reconstruire la visibilité opérationnelle de toute l'infrastructure.

Engagements commerciaux pluriannuels. Les committed use discounts et enterprise agreements lient financièrement l'entreprise sur 1 à 5 ans. Migrer avant l'échéance signifie payer deux fournisseurs simultanément, un surcoût qui dissuade la migration même quand elle est techniquement prête.

Formation interne mono-cloud. Les équipes développent une expertise spécifique à un seul fournisseur (certifications, habitudes, outillage interne). Le coût de reconversion des compétences s'ajoute au coût technique de migration et crée une résistance organisationnelle au changement.

6) Angles morts du débat : ce que l'article doit aussi traiter

6.1 L'emploi et la formation : le vrai goulot

L'écosystème French Tech emploie des dizaines de milliers d'ingénieurs en France. La promotion 2025 du Next40/120 revendique 6 300 emplois créés par les seules entreprises "vertes" de la sélection. Cet impact social est reel et ne doit pas être négligé.

Mais un angle mort persiste : où vont les meilleurs ingénieurs formes en France ? La fuite des talents vers les États-Unis, où les salaires dans la tech sont 2 à 3 fois supérieurs, constitue un drainage systematique des compétences les plus pointues. Les profils capables de travailler sur les couches basses (systèmes distribués, noyaux, compilateurs, cryptographie) sont les plus rares et les plus courtises. Quand ces profils partent, ils ne construisent pas les briques dont l'écosystème français à besoin. Ils les construisent pour des entreprises américaines.

Le CIR (Crédit d'Impôt Recherche), souvent cité comme outil de soutien, finance largement des activités de R&D applicative et non des travaux sur les briques d'infrastructure. La ventilation exacte mériterait un audit indépendant.

6.2 La deep tech et les contre-exemples

L'écosystème français n'est pas uniformement applicatif. Des entreprises comme Alice & Bob (informatique quantique), Mistral AI (modèles de langage), Ledger (sécurité des actifs cryptographiques) ou Ynsect (biotechnologie) représentent des cas différents où la maîtrise technique est au coeur de la valeur.

La promotion 2025 du Next40 inclut d'ailleurs Alice & Bob et Flying Whales, signalant une diversification sectorielle réelle. Le programme French Tech 2030, distinct du Next40/120, sélectionne 80 entreprises sur des critères d'innovation de rupture plus explicitement technologiques.

Ces contre-exemples sont importants. Ils montrent que l'écosystème n'est pas monolithique. Mais ils ne réfutent pas la thèse principale : la majorité des "vitrines" French Tech reste dominée par l'intermédiation et l'applicatif, et les briques d'infrastructure restent le parent pauvre du financement et de la visibilité.

6.3 Contre-exemple : l'applicatif qui produit une brique

Pour montrer que la grille proposée n'est pas "anti-applicatif" par construction, il faut identifier des cas où un éditeur applicatif contribue réellement à l'autonomie technologique. Le cas le plus parlant en France est celui de Clever Cloud.

Clever Cloud est un PaaS (Platform as à Service) français fondé à Nantes. L'entreprise opère une plateforme d'hébergement applicatif, ce qui la place en apparence dans le segment "produit logiciel". Mais elle se distingue par trois caractéristiques : elle opère ses propres datacenters en France, elle à développé son propre orchestrateur de conteneurs (un choix architectural délibéré de ne pas dépendre de Kubernetes), et elle contribue activement à l'écosystème open source (Sōzu, un reverse proxy haute performance en Rust, est open-sourcé). Ce profil hybride obtiendrait un score de technicité de 3,5 à 4 sur l'indice, bien au-dessus d'un éditeur SaaS classique, parce que l'entreprise produit des briques réutilisables en plus de son produit commercial.

À l'échelle européenne, GitLab (fondé en Ukraine, siège aux Pays-Bas puis aux États-Unis, fortement contribué par des développeurs européens) illustre le même schéma : un produit applicatif (CI/CD, gestion de code) qui constitue en soi une brique d'infrastructure utilisée par des milliers d'organisations. GitLab est open core : le code source est auditable, les contributions sont ouvertes, et la plateforme peut être auto-hébergée.

Ces cas prouvent que la frontière entre "applicatif" et "brique" n'est pas étanche. Ce qui fait la différence, c'est la capacité de réutilisation par des tiers, la contribution à l'écosystème, et le contrôle de la chaîne technique. Un éditeur applicatif qui open-source un composant clé ou qui opère sa propre infrastructure sort mécaniquement de la catégorie "consommateur de briques" pour entrer dans celle de "producteur".

6.3 L'angle IA : dépendance accélèree ou opportunite de rattrapage ?

L'explosion de l'IA générative depuis 2022 à crée une nouvelle couche de dépendance potentiellement plus profonde que les précédentes. Les modèles de fondation (GPT, Claude, Gemini, Llama) sont massivement américains. L'infrastructure de calcul (GPU Nvidia, clusters cloud) est américaine. Les frameworks (PyTorch, TensorFlow, JAX) sont américains.

Mistral AI représente une tentative européenne credible de produire des modèles compétitifs. Mais même Mistral opère ses modèles sur des infrastructures cloud américaines et utilise des GPU Nvidia soumis à des restrictions d'exportation américaines (Entity List). La dépendance se deplace vers le hardware et le calcul, couche encore plus difficile à substituer que le logiciel.

Pour les startups French Tech, "intégrer l'IA" (comme le font 116 des 120 lauréats selon la Mission French Tech) signifie le plus souvent consommer des API américaines. C'est une dépendance supplementaire, pas une maîtrise technologique.

6.4 Comparaison internationale : la France est-elle seule dans ce cas ?

La réponse est non. Le Royaume-Uni, l'Allemagne, les pays nordiques connaissent des dynamiques similaires. La startup berlinoise ou londonienne depend autant d'AWS que son homologue parisienne. L'Inde produit massivement du service informatique mais peu de briques d'infrastructure.

La différence se situe dans la réponse politique. Aux Pays-Bas, le sujet a donné lieu à des rapports institutionnels et à des motions parlementaires visant à réduire la dépendance aux éditeurs et clouds américains pour les administrations (Reuters, 2025). La France dispose de la doctrine "Cloud au centre" (2021, mise à jour 2023) qui exige l'hébergement SecNumCloud pour les données "d'une sensibilité particulière" des administrations, mais l'application reste lacunaire. L'Allemagne oscille entre souverainisme rhétorique et pragmatisme opérationnel pro-américain.

6.5 OVHcloud : le cas positif qui prouve que l'alternative existe

La France dispose d'acteurs d'infrastructure réels, même si leur taille reste modeste par rapport aux hyperscalers. Le cas d'OVHcloud mérite un traitement détaillé parce qu'il constitue la preuve concrete que produire des briques d'infrastructure en Europe est possible, et parce qu'il illustre simultanément les limites structurelles auxquelles ces acteurs font face.

OVHcloud a franchi le cap du milliard d'euros de chiffre d'affaires en 2025 (exercice clos août 2025 : 1 084,6 millions d'euros, +9,3% à données comparables). L'entreprise opère plus de 450 000 serveurs dans 43 centres de données sur 4 continents, pour 1,6 million de clients dans plus de 140 pays. L'EBITDA ajusté atteint 437,8 millions d'euros (marge de 40,4%), et le résultat net est devenu positif (0,4 million d'euros, contre une perte de 10,3 millions l'année précédente).

Plusieurs jalons stratégiques méritent attention. Le chiffre d'affaires Cloud Public (IaaS et PaaS) a dépassé les 100 millions d'euros, en croissance de 19,9%. Le segment Corporate dépasse les 200 millions d'euros. OVHcloud est le leader du marché SecNumCloud avec 24 millions d'euros d'ARR en hausse de 63% sur un an. L'entreprise a été admise au SBF 120. Le plan stratégique 2026-2030 "Step Ahead" est en préparation sous la direction réunifiée d'Octave Klaba (PDG).

La différenciation technique d'OVHcloud repose sur plusieurs briques propriétaires : système de watercooling industriel conçu en interne (refroidissement liquide des serveurs, réduisant la consommation énergétique de 30 à 50% par rapport aux datacenter classiques), fabrication de serveurs dans ses propres usines (usine de Croix, près de Roubaix), maîtrise de la chaîne logistique complète du serveur physique au service cloud. Ce modèle industriel verticalement intégré est unique en Europe et représente une propriété intellectuelle réelle.

Les limites sont également instructives. Avec un CA de 1,08 milliard d'euros, OVHcloud représente moins de 1% du marché mondial du cloud infrastructure (environ 400 milliards de dollars en 2025). Le résultat net de 0,4 million d'euros sur un CA d'un milliard illustre la fragilité financière : la dette nette atteint 1 103 millions d'euros (levier de 2,7x). L'entreprise investit massivement (Capex de 361 millions d'euros, soit 33% du CA) mais dispose de marges de manœuvre limitées pour financer la R&D sur les services managés avancés (IA, analytics, serverless) qui constituent les segments à plus forte croissance. Le catalogue de services d'OVHcloud reste modeste (une quarantaine de produits cloud public) face aux 200+ services d'AWS.

D'autres acteurs français d'infrastructure completent le tableau : Scaleway (filiale d'Iliad), 3DS Outscale (filiale de Dassault Systemes, certifie SecNumCloud), Clever Cloud, et des acteurs de niche comme Wallix (PAM/IAM), HarfangLab (EDR) ou Tehtris (XDR). Ces entreprises produisent des briques. Elles contribuent à l'autonomie stratégique. Mais leur financement reste disproportionnément faible par rapport aux acteurs d'intermédiation. Un paradoxe révélateur quand on sait que ces acteurs sont les seuls à réduire effectivement la dépendance technologique.

Sources : OVHcloud, resultats FY2025, communique du 21 octobre 2025 ; OVHcloud, resultats S1 2025, communique du 17 avril 2025.

6.6 Le logiciel libre : vecteur de souveraineté sous-exploite

L'article ne peut pas traiter de souveraineté technologique sans aborder la question du logiciel libre (open source), qui constitue à la fois le levier le plus puissant et le plus paradoxal de l'autonomie numérique.

Le paradoxe est le suivant : les briques open source qui sous-tendent l'ensemble de l'économie numérique (Linux, Kubernetes, PostgreSQL, MariaDB, Git, Python, Rust, etc.) sont massivement développées par des contributeurs européens, mais exploitees commercialement par des entreprises américaines. Linux, noyau développé par le Finlandais Linus Torvalds, fait tourner 96% des serveurs dans le monde et constitue le socle de tous les hyperscalers. Kubernetes, orchestre sous egide de Google mais largement contribue par des ingénieurs européens, est devenu le standard de fait de l'orchestration de conteneurs. PostgreSQL, dont une partie significative des contributeurs sont européens, est la base de données la plus deployee dans les nouvelles applications.

L'Europe contribue massivement à l'open source mais ne capte qu'une fraction de la valeur générée. L'etude "World of Open Source Europe 2025" de la Linux Foundation montre que plus de 90% des organisations européennes tirent de la valeur de l'open source, mais que faute de strategie claire et d'investissements cibles, l'Europe laisse la valeur commerciale migrer vers les GAFAM qui integrent ces briques libres dans leurs services propriétaires (AWS Lambda utilise Linux, AWS Aurora utilise PostgreSQL, Google Cloud SQL utilise PostgreSQL et MySQL).

La France dispose d'un écosystème open source actif : le CNLL (Conseil National du Logiciel Libre) fédère plus de 300 entreprises spécialisées. L'article 16 de la loi République numérique (2016) encourage l'utilisation des logiciels libres dans les administrations. Mais cet "encouragement" n'a jamais été assorti de moyens contraignants. En 2025, le CNLL a dénoncé la migration de l'École Polytechnique vers Microsoft 365 comme un exemple de politique contraire à la souveraineté déclarée.

En janvier 2026, la Commission européenne a lancé une consultation stratégique sur les "European Open Digital Ecosystems", reconnaissant explicitement que "une grande partie de la valeur générée par les projets open source est exploitée en dehors de l'UE, souvent au profit des géants technologiques". La future stratégie, attendue au premier trimestre 2026 dans le cadre du CAIDA (Cloud and AI Development Act), vise à transformer les projets open source européens en alternatives commerciales crédibles. L'initiative EuroStack, lancée en mars 2025 par plus de 200 dirigeants européens et soutenue par le CNLL, propose une feuille de route concrète avec quatre piliers : commande publique ("Acheter Européen"), visibilité ("Vendre Européen"), gouvernance ouverte et financement durable.

La stratégique open source constitue probablement le levier le plus efficient pour réduire la dépendance : les briques existent, les compétences sont la, le cadre juridique le permet. Ce qui manque, c'est la volonte politique de prioriser les solutions libres dans la commande publique et d'investir dans la maintenance des briques critiques. Le rapport Draghi sur la compétitivité européenne (septembre 2024) pointait deja cette opportunite.

6.7 La dimension défense et renseignement : l'angle mort critique

La dépendance cloud dépasse la sphère civile et concerne directement la sécurité nationale. La BITD (Base Industrielle et Technologique de Défense) française, composée de 9 grands groupes et 4 500 PME-ETI représentant 220 000 emplois, ne peut fonctionner indépendamment de la question des infrastructures numériques.

Trois points méritent attention.

Premièrement, les hôpitaux militaires utilisent Doctolib. Le Service de santé des armées (SSA) gère huit hôpitaux d'instruction des armées (HIA), qui accueillent à la fois des militaires et des patients civils. En 2024, le SSA a confirmé l'utilisation de liens directs vers Doctolib pour la prise de rendez-vous dans ses hôpitaux. Doctolib étant hébergé sur AWS, les données de prise de rendez-vous médicaux de militaires en activité transitent potentiellement par une infrastructure soumise au CLOUD Act. Les informations de santé d'un pilote de chasse, d'un officier de renseignement ou d'un ingénieur de la DGA présentent une sensibilité évidente en termes de sécurité nationale.

Deuxièmement, la BITD est confrontée à la question de la dépendance numérique de ses sous-traitants. Les 4 500 PME-ETI de la BITD utilisent dans de nombreux cas, des services cloud et SaaS américains pour leur communication, leur comptabilité, leur gestion de projet et parfois leurs données techniques. Une injonction américaine ciblant un fournisseur SaaS pourrait compromettre des chaînes logistiques de défense sans que le ministère des Armées en soit averti.

Troisièmement, la doctrine Cloud au centre (2021) ne couvre que les administrations civiles. La LPM 2024-2030, qui consacre 413,3 milliards d'euros aux armées sur sept ans, ne contient pas de doctrine cloud specifique pour la BITD. Le fonds Bpifrance Defense (450 millions d'euros, lance en octobre 2025) investit dans des entreprises de défense mais ne conditionne pas cet investissement à l'utilisation d'infrastructures souveraines.

L'enjeu n'est pas théorique. En mars 2025, lors de la conférence sur le financement de la BITD à Bercy, le directeur de la DID (Direction de l'industrie de défense) a souligné que les normes ITAR et la régulation extraterritoriale américaine constituent déjà un risque réputationnel et opérationnel pour les entreprises de défense françaises. Étendre ce risque à l'ensemble de leur infrastructure numérique revient à créer une vulnérabilité systémique dans l'appareil de défense national.

Sources : Ministere des Armées, SSA, "Les hôpitaux militaires à la page du Web confort", juin 2024 ; economie.gouv.fr, dossier BITD, mars 2025 ; Bpifrance, fonds Bpifrance Defense, octobre 2025.

7) Le blocage EUCS : symptôme continental

Le débat EUCS est le miroir européen du diagnostic posé dans cet article. La France, avec SecNumCloud, exige que le niveau le plus élevé de certification inclue des garanties d'immunité aux lois extra-européennes. Le débat a achoppé sur la prise en compte des lois extraterritoriales, plusieurs États membres s'y opposant au nom de la compétitivité et de l'accès aux hyperscalers. Résultat : un EUCS édenté, reporté sine die, et un cadre d'évaluation de souveraineté cloud adopté par la Commission en octobre 2025 comme palliatif pour ses propres marchés publics.

8) Recommandations : redevenir "tech" au sens industriel

Ces recommandations ne pretendent pas être un programme politique complet. Elles visent à identifier les leviers les plus actionnables à court et moyen terme pour corriger le biais structurel identifie dans cet article.

8.1 Cartographier les dépendances (obligation de transparence)

Imposer aux entreprises recevant des financements publics (BPI, CIR, aides French Tech) une cartographie publique de leurs dépendances critiques : fournisseur cloud, SaaS indispensables, composants non substituables, juridictions applicables. Cette cartographie n'a pas vocation punitive. Elle vise la lucidite. On ne peut pas piloter une politique de souveraineté sans savoir où se situent les dépendances.

Mise en œuvre concrète : Créer un format standard de declaration (type SBOM etendu aux services) deposable auprès de la BPI. Coût de mise en place : environ 2 millions d'euros pour le développement de l'outil et la formation. Delai : 12 mois pour la V1. Obligation progressive : entreprises Next40 des 2027, FT120 en 2028, ensemble des beneficiaires de financements publics en 2029. Modele : l'obligation SBOM du decret executif américain 14028 (mai 2021) qui impose aux fournisseurs du gouvernement federal une nomenclature logicielle. Si les États-Unis le font pour leur propre sécurité, la France peut le faire pour la sienne.

8.2 Intégrer un critere de technicité dans la sélection French Tech

Ajouter aux critères existants (CA, levees, ESG) une dimension de technicité mesurant la contribution à l'autonomie stratégique. L'indice propose en section 3 constitue un point de depart perfectible. Meme à titre indicatif et non eliminatoire, ce critere modifierait les incitations et la perception publique.

Mise en œuvre concrète : Intégrer l'indice de technicité à la grille de sélection de la promotion 2027. Pondération initiale suggérée : 10 à 15% du score total, à cote du CA (40%), de la croissance (25%), de l'ESG (15%) et de l'innovation CIR (5-10%). L'indice serait auto-évalué par les entreprises et vérifié par un comité technique indépendant. Coût additionnel marginal (intégration dans le processus existant de la Mission French Tech). Impact attendu : modifier le signal envoyé à l'écosystème, en montrant que la maîtrise technique est valorisée au même titre que la croissance.

8.3 Flecher le financement vers les briques

Orienter une fraction des financements publics (BPI France, France 2030, PIIEC) vers les acteurs qui produisent des briques d'infrastructure : cloud, bases de données, outils de sécurité, systèmes d'exploitation, outillage de développement, composants réseau. Le ratio actuel est massivement déséquilibré en faveur de l'applicatif.

Mise en œuvre concrète : Créer au sein de France 2030 un axe "Briques souveraines" dote de 500 millions d'euros sur 5 ans (100 millions/an), fléchant le financement vers les editeurs d'infrastructure, les contributeurs open source et les acteurs cloud européens. A titre de comparaison, les États-Unis ont consacre 52 milliards de dollars au CHIPS Act pour les seuls semi-conducteurs. Un demi-milliard d'euros pour l'ensemble des briques logicielles est un ordre de grandeur modeste mais significatif.

Criteres d'eligibilite : produire une brique réutilisable par d'autres acteurs, disposer d'un code source auditable (open source ou open core), ne pas être soumis à une juridiction extra-européenne pour les decisions techniques et juridiques. Le Fonds Innovation Defense (FID) de BPI, dote de 220 millions d'euros, offre un modèle de référence.

8.4 Activer la commande publique

L'État est un acheteur massif de services numériques. La doctrine "Cloud au centre" (2021) prévoit le recours à des solutions SecNumCloud pour les données sensibles. L'application de cette doctrine, encore lacunaire, constitue le levier le plus puissant pour créer un marché pour les acteurs souverains. Chaque euro dépensé par l'État sur AWS est un euro qui ne finance pas l'alternative européenne.

Mise en œuvre concrète : Publier un tableau de bord trimestriel de la conformité Cloud au centre par ministère, avec les volumes de dépenses cloud par fournisseur. Fixer un objectif de 50 % de dépenses cloud étatiques sur des solutions qualifiées SecNumCloud d'ici 2028 (contre une estimation de 15-20 % en 2025). S'inspirer du cadre d'évaluation de souveraineté cloud de la Commission européenne (octobre 2025) pour intégrer des critères de souveraineté dans les appels d'offres publics, même en l'absence de consensus EUCS. Budget additionnel : nul (il s'agit de réorienter des dépenses existantes, pas d'en créer de nouvelles). Aux Pays-Bas, le sujet a donné lieu à des motions parlementaires et à des rapports institutionnels visant à réduire la dépendance aux éditeurs et clouds américains pour les administrations, montrant que la démarche est politiquement faisable.

8.5 Investir dans l'open source comme infrastructure critique

La strategie open source doit être elevee au rang de politique industrielle, pas seulement de preference technique. La Commission européenne l'a reconnu en janvier 2026 en lancant sa consultation sur les "European Open Digital Ecosystems".

Mise en œuvre concrète : Créer un "Fonds de maintenance des briques critiques" dote de 50 millions d'euros par an, sur le modèle du Sovereign Tech Fund allemand (financement de projets open source critiques comme curl, OpenSSL, Log4j). La France contribue massivement à l'open source mais ne finance pas la maintenance des briques dont depend son economie. Appliquer l'article 16 de la loi République numérique (2016) avec des objectifs quantifies : 30% des nouveaux projets informatiques de l'État bases sur des solutions open source d'ici 2028. Créer un OSPO (Open Source Program Office) interministeriel dote de moyens réels, comme le recommande le CNLL.

8.6 Valoriser les contributions à l'écosystème

Créer un mécanisme de reconnaissance (crédit d'impôt, label, accès privilégié à la commande publique) pour les entreprises qui contribuent substantiellement à l'open source, aux standards, aux retours d'expérience techniques publics. La contribution à l'écosystème est un bien public qui n'est pas rémunéré par le marché.

Mise en œuvre concrète : Créer un "Crédit d'Impôt Contribution Numérique" (CICN) de 30% sur les depenses de contribution à des projets open source européens (commits, reviews, maintenance, documentation). Plafond : 500 000 euros par entreprise et par an. Coût budgétaire estimé : 50 à 100 millions d'euros par an (moins de 2% du CIR actuel). Rendement attendu : stimuler la contribution française à l'écosystème et créer un avantage competitif pour les acteurs qui investissent dans les briques communes.

8.7 Former et retenir les profils "couches basses"

Créer des parcours de formation spécialisés (systèmes distribués, noyaux, compilateurs, cryptographie) et des conditions de remuneration competitives pour les profils capables de travailler sur les briques d'infrastructure. Le differentiel de salaire avec les États-Unis (facteur 2 à 3) est le principal moteur de la fuite des talents. Des mécanismes fiscaux cibles (exoneration partielle, stock-options defiscalisees pour les profils critiques) pourraient attenuer ce drainage.

Mise en œuvre concrète : Créer 500 bourses doctorales et post-doctorales "Briques Souveraines" par an, dotées de 4 000 euros nets mensuels (contre 1 750 euros pour une bourse doctorale standard), ciblant les domaines systèmes, compilation, cryptographie, bases de données, protocoles réseau. Coût : 24 millions d'euros par an. Défiscaliser les stock-options des entreprises d'infrastructure certifiées SecNumCloud, à hauteur de 50 000 euros par salarié et par an. Coût budgétaire estimé : 30 à 50 millions d'euros par an. Creation de 5 "Chaires d'excellence infrastructure" dans les universités et grandes écoles, avec obligation d'enseignement et de contribution open source.

A titre de comparaison, le coût total de ce plan (environ 290 millions d'euros par an) représente moins de 4% du budget annuel du CIR (7,6 milliards), moins de 2% du transfert annuel estimé vers les hyperscalers US (15-19 milliards), et moins de 0,1% du budget de la LPM 2024-2030 (413 milliards sur 7 ans). La question n'est pas budgétaire. Elle est politique.

9) Tableau récapitulatif : les trois niveaux et ce qu'ils produisent

10) Scénarios prospectifs : la French Tech en 2030

L'analyse ne serait pas complète sans une projection à horizon 2030. Deux scenarios polaires permettent de cadrer le champ des possibles.

Scenario A : Inertie (probabilite estimee : 65%)

Si rien ne change dans les politiques publiques et les incitations, la trajectoire actuelle se prolonge. Les startups françaises continuent de croître sur des infrastructures américaines. L'IA accélère la dépendance (modèles de fondation américains, GPU Nvidia, clusters cloud US). Le marche cloud européen reste à 15% de part locale. Le coût de migration augmente de 20 à 30% par an en raison du lock-in progressif. Les briques critiques de l'économie numérique française restent sous contrôle juridique américain.

En 2030, dans ce scenario, une crise géopolitique majeure (conflit Taiwan, divergence transatlantique, guerre commerciale) pourrait provoquer une perturbation significative de l'accès aux services cloud américains pour les entreprises européennes. Le coût de remédiation d'urgence serait de l'ordre de 50 à 100 milliards d'euros pour l'ensemble de l'UE (estimation basee sur l'extrapolation du coût de la migration forcee des entreprises russes en 2022).

Scenario B : Redressement (probabilite estimee : 35%)

Si les recommandations de cet article (ou équivalentes) sont mises en oeuvre, les effets cumulatifs pourraient être significatifs. La cartographie des dépendances rend visible l'ampleur du problème et crée une pression politique. Le financement fléché vers les briques permet à OVHcloud, Scaleway et aux acteurs d'infrastructure de multiplier leur offre de services managés. La commande publique crée un marché captif de 2 à 3 milliards d'euros par an pour les solutions souveraines. L'investissement dans l'open source européen crée des alternatives crédibles aux services propriétaires des hyperscalers.

En 2030, dans ce scenario, la part des fournisseurs européens dans le marché cloud regional passe de 15% à 25%. Le coût d'assurance contre un choc géopolitique est divise par trois. La France dispose d'au moins deux hyperscalers européens (OVHcloud + un consortium) capables d'opérer des charges de travail critiques. L'écosystème French Tech intégré une vingtaine d'acteurs d'infrastructure dans ses vitrines.

Le choix entre ces deux scenarios n'est pas technique. Il est politique. Les briques existent, les compétences sont la, le financement est disponible. Ce qui manque, c'est la decision.

11) Conclusion : le diagnostic n'est pas une condamnation

L'écosystème French Tech a produit des réussites économiques réelles : emploi, transformation des usages, conquête de marchés internationaux. Mais appeler "tech" un écosystème dont les briques critiques sont dans la majorité des cas observés, extra-européennes, c'est commettre une erreur de diagnostic qui produit des erreurs de politique industrielle. On confond la vitrine et l'usine. On mesure la croissance sans mesurer la dépendance.

Le test est simple : si les trois hyperscalers américains décidaient demain de suspendre leurs services pour les entreprises européennes, combien de licornes French Tech survivraient sans interruption ? Ce scénario n'est pas de la science-fiction : la Russie (2022), Huawei (2019-2025), l'Iran (2019) et Cuba fournissent quatre précédents documentés de coupures ou restrictions technologiques unilatérales américaines (détail en annexe A.8).

L'argument "la France est alliée des États-Unis" est valable en 2026. La question est de savoir s'il le restera dans toutes les configurations géopolitiques sur un horizon de 10 à 20 ans. L'histoire récente montre que les alliances évoluent, que les intérêts divergent (Irak 2003, Iran 2018), et que les États-Unis utilisent le contrôle des infrastructures numériques comme levier de pression, y compris vis-à-vis de leurs alliés (amendes BNP Paribas 8,9 Mds $ en 2014, Alstom 772 M $ en 2014).

La souveraineté technologique n'est pas un luxe souverainiste. C'est une condition d'assurance contre les risques systémiques. Et cette assurance se construit en investissant dans les briques, pas seulement dans les applications qui les consomment.

12) Les cinq meilleurs arguments contre moi, et mes réponses

Cet article défend une thèse. Toute thèse a des objections sérieuses. Les ignorer serait intellectuellement malhonnête et stratégiquement fragile. Voici les cinq critiques les plus solides que l'on peut adresser à cet article, formulées dans leur version la plus forte (steelman), suivies des réponses que les éléments documentés permettent d'apporter.

12.1 "La souveraineté juridique est un faux problème : chiffrement + contrats suffisent"

L'objection au plus fort. Les entreprises sérieuses chiffrent leurs données au repos et en transit. Les contrats avec les hyperscalers incluent des clauses de localisation, des engagements de confidentialité, et des mécanismes d'alerte en cas de demande d'accès gouvernemental. Le RGPD impose des obligations que les hyperscalers respectent sous peine de sanctions massives. Le risque juridique est donc théorique et géré contractuellement.

La réponse. Le chiffrement protège les données au repos, pas les métadonnées (qui accède à quoi, quand, depuis où, avec quels volumes), et pas les données en cours de traitement. Un hyperscaler qui opère le runtime, le réseau et l'orchestration a un accès structurel aux flux qui ne dépend pas du chiffrement côté client. Le CLOUD Act (2018) et le FISA Section 702 permettent aux autorités américaines d'exiger l'accès aux données détenues par des entreprises américaines quelle que soit la localisation physique des serveurs, et ces lois prévalent sur les engagements contractuels de droit privé. La preuve n'est plus théorique : en mai 2025, Microsoft a bloqué l'accès email du procureur Karim Khan de la CPI, démontrant que le risque n'est pas limité à l'espionnage mais inclut la coupure de service (section 5.3, source : AP News). Un contrat de droit commercial ne peut pas neutraliser une obligation de droit public américain.

12.2 "L'Europe n'a pas d'avantage comparatif sur les couches basses"

L'objection au plus fort. Les hyperscalers américains bénéficient d'effets d'échelle massifs, de décennies d'investissement cumulé et d'un écosystème intégré (hardware, logiciel, capital, talents) que l'Europe ne peut pas répliquer. L'Europe devrait se concentrer sur les couches où elle a un avantage (régulation, standards, applicatifs sectoriels) plutôt que de gaspiller des ressources sur des briques d'infrastructure où elle sera toujours seconde.

La réponse. L'argument de l'avantage comparatif suppose un marché ouvert et concurrentiel. Or les briques d'infrastructure sont des actifs stratégiques dont le contrôle confère un pouvoir de levier sur l'ensemble de l'écosystème en aval, comme démontré par les précédents de sanctions technologiques (Russie, Huawei, Iran, Cuba). L'argument "concentrons-nous sur l'aval" revient à accepter structurellement le rôle de consommateur de briques produites par d'autres, ce qui est une décision de politique industrielle, pas une fatalité économique. OVHcloud (1,08 milliard d'euros de CA, marge EBITDA de 40 %, section 6.5) et Clever Cloud (section 6.3) prouvent que produire des briques d'infrastructure en Europe est viable. L'Europe contribue massivement aux briques open source (Linux, PostgreSQL, Kubernetes) sans en capter la valeur commerciale (section 6.6). Le problème n'est pas l'absence de compétences, c'est l'absence de politique industrielle orientée vers l'amont.

12.3 "Forcer des critères souverains tue la compétitivité et l'innovation"

L'objection au plus fort. Imposer des critères de souveraineté aux startups alourdit leurs contraintes, augmente leurs coûts, ralentit leur mise sur le marché et les handicape face à des concurrents étrangers qui n'ont pas ces obligations. Le CIR finance la R&D sans conditions d'hébergement, et c'est ce qui a permis à l'écosystème de se développer. Ajouter des barrières souveraines étouffera l'innovation.

La réponse. L'article ne recommande pas de "forcer" les startups à utiliser des clouds européens. Il recommande trois choses distinctes (section 8) : cartographier les dépendances (transparence, pas contrainte), intégrer un critère de technicité de 10-15 % dans la sélection French Tech (incitation, pas interdiction), et orienter la commande publique vers des solutions certifiées SecNumCloud (levier de demande, pas de restriction d'offre). Le coût total du plan proposé (289 millions d'euros par an) représente moins de 4 % du CIR. Par ailleurs, la compétitivité de long terme suppose la résilience : une startup dont 100 % de l'infrastructure peut être coupée par une décision unilatérale étrangère n'est pas "compétitive", elle est vulnérable. Le coût de migration croît exponentiellement avec le temps (section 5.6) : agir tôt est moins cher qu'agir tard.

12.4 "Les hyperscalers US sont plus sécurisés que les acteurs européens"

L'objection au plus fort. AWS, Azure et GCP investissent chacun des milliards de dollars par an en sécurité, emploient des milliers d'ingénieurs spécialisés, disposent de certifications internationales (SOC 2, ISO 27001, C5, HDS) et affichent des niveaux de disponibilité que les acteurs européens ne peuvent pas égaler. Migrer vers des alternatives moins matures augmente le risque opérationnel réel.

La réponse. La sécurité opérationnelle et la sécurité juridique sont deux dimensions distinctes qu'il ne faut pas confondre. Un hyperscaler peut offrir une excellente sécurité technique (protection contre les intrusions, disponibilité, redondance) tout en étant soumis à des obligations légales qui compromettent la sécurité juridique des données hébergées (CLOUD Act, FISA 702). La qualification SecNumCloud de l'ANSSI intègre précisément cette distinction : elle exige à la fois des garanties techniques et une immunité aux lois extraterritoriales. OVHcloud, qualifié SecNumCloud, offre une marge EBITDA de 40 %, une disponibilité contractuelle de 99,99 % sur ses services critiques et une croissance de 63 % sur son ARR SecNumCloud (section 6.5). La question pertinente n'est pas "qui est le plus sécurisé ?" mais "sécurisé contre qui ?" Un coffre-fort auquel votre concurrent détient une clé légale n'est pas un coffre-fort.

12.5 "Le problème est l'énergie, les salaires, le capital, pas la French Tech"

L'objection au plus fort. Les vraies causes de la dépendance européenne sont structurelles : énergie plus chère qu'aux États-Unis, salaires ingénieurs 2 à 3 fois inférieurs à la Silicon Valley (ce qui draine les talents), marchés de capitaux moins profonds, fragmentation réglementaire entre 27 États membres. Critiquer le label French Tech, c'est tirer sur l'ambulance au lieu de traiter la maladie.

La réponse. Ces facteurs structurels sont réels et documentés dans cet article (section 6.1 pour les salaires, section 8.7 pour la rétention des talents). Mais ils ne sont pas un argument contre le diagnostic. Ils le complètent. La fuite des talents "couches basses" vers les États-Unis est précisément un mécanisme de la dépendance, pas une alternative au constat. Le coût de l'énergie est un facteur pour les datacenters, mais OVHcloud démontre qu'il est possible d'opérer de l'infrastructure compétitive depuis la France. Quant au capital, la France dispose de mécanismes de financement public significatifs (7,6 milliards d'euros de CIR, 54 milliards de France 2030) dont le fléchage vers les briques d'infrastructure reste marginal. L'article ne dit pas que la French Tech est "le" problème. Il dit que la confusion entre croissance numérique et puissance technologique produit un angle mort dans la politique industrielle, et que cet angle mort est corrigeable à un coût modeste. Les facteurs structurels existent ; ils rendent d'autant plus urgent de bien orienter les leviers disponibles.

La dernière objection (facteurs structurels) est celle où la réponse est la plus honnêtement partielle : oui, l'énergie, les salaires et le capital sont des contraintes réelles que cet article ne prétend pas résoudre. Mais reconnaître ces contraintes renforce la thèse centrale plutôt qu'il ne l'affaiblit : puisque les marges de manœuvre structurelles sont limitées, il est d'autant plus important de ne pas gaspiller les leviers disponibles en confondant croissance applicative et puissance technologique.

Annexe A : Sources

A.1 French Tech : programme et critères

A.2 Doctolib : hébergement et dépendances

A.3 ManoMano et Mirakl

A.4 EUCS et souveraineté cloud

A.5 CLOUD Act et extraterritorialité

A.6 Marché cloud mondial et européen

Sources structurantes (vérifiées et primaires) :

Source 1 : Synergy Research Group, Q3 2025. Parts de marché mondiales IaaS+PaaS+cloud privé hébergé : AWS 29 %, Azure 20 %, GCP 13 %, total Big Three 63 %. Revenus mondiaux Q3 : 106,9 milliards de dollars. Trailing twelve-month : 390 milliards de dollars. Méthodologie : analyse trimestrielle des revenus publiés des fournisseurs, recoupée avec les earnings calls. Synergy est cité par The Economist, Wall Street Journal, Financial Times, Federal Reserve Board. URL primaire : https://www.srgresearch.com/articles/cloud-market-share-trends-big-three-together-hold-63-while-oracle-and-the-neoclouds-inch-higher. URL secondaire confirmant les mêmes chiffres : https://www.datacenterdynamics.com/en/news/synergy-research-neoclouds-gradually-increasing-cis-market-share-as-amazon-declines/ (novembre 2025).

Source 2 : Synergy Research Group, part européenne stabilisée à 15 %. Les fournisseurs européens (SAP, Deutsche Telekom, OVHcloud en tête) représentent 15 % du marché cloud IaaS+PaaS européen, stabilisé depuis 2022. URL : https://www.srgresearch.com/articles/european-cloud-providers-local-market-share-now-holds-steady-at-15.

Source 3 : OVHcloud, résultats FY2025 (exercice clos août 2025). Communiqué officiel publié le 21 octobre 2025 : CA 1 084,6 M EUR, EBITDA ajusté 437,8 M EUR, résultat net 0,4 M EUR. URL : https://corporate.ovhcloud.com/fr/newsroom/news/financial-results-fy25/. Données vérifiables dans le document de référence déposé auprès de l'AMF.

Source 4 : Markess by Exaegis, parts de marché IaaS/PaaS en France (2021). AWS 46 %, Azure 17 %, GCP 8 %, trio US 71 % du marché hexagonal. Marché total IaaS/PaaS France : 1,43 milliard d'euros en 2021 (+35 %). La domination d'AWS en France (46 %) est nettement supérieure à sa part mondiale (31-33 % en 2021). URL primaire : https://www.distributique.com/actualites/lire-aws-ultradominant-sur-un-marche-hexagonal-du-iaas-et-du-paas-en-hausse-de-35-32520.html. Note : ces données datent de 2021. Des données France-spécifiques plus récentes ne sont pas disponibles en source ouverte à la date de rédaction. La concentration a pu évoluer, mais l'ordre de grandeur (domination AWS > 40 % en France) est cohérent avec les tendances européennes observées par Synergy.

Source 5 : CLOUD Act, U.S. Department of Justice. Texte intégral et ressources officielles. URL : https://www.justice.gov/criminal/cloud-act-resources. Le CLOUD Act (H.R. 1625, Title II, signé le 23 mars 2018) amende le Stored Communications Act (18 U.S.C. § 2713) pour autoriser les mandats et subpoenas visant des données détenues par des entreprises américaines indépendamment du lieu de stockage.

A.7 OVHcloud

A.8 Précédents de sanctions technologiques

A.9 Open source et souveraineté

A.10 Défense et BITD

Annexe B : Glossaire

Annexe C : Note méthodologique

Transparence sur les limites

Cet article adopte une perspective souverainiste explicite. Cette perspective n'est pas neutre : elle valorise l'autonomie technologique comme objectif de politique industrielle, ce qui n'est pas la seule perspective possible. Un économiste libéral pourrait argumenter que la spécialisation et les avantages comparatifs justifient la dépendance technologique, à condition que les marchés restent ouverts et concurrentiels.

L'indice de technicité proposé est un outil de diagnostic, pas un jugement définitif. Les scores attribués aux entreprises étudiées sont des estimations fondées sur des informations publiques. Des informations internes complémentaires pourraient modifier les évaluations. Les entreprises concernées sont invitées à publier leurs propres cartographies de dépendances, ce qui enrichirait le débat.

Les données de parts de marché proviennent de sources industrielles (Synergy Research Group principalement) dont la méthodologie n'est pas entièrement publique. Les chiffres doivent être considérés comme des ordres de grandeur indicatifs.

L'estimation du transfert de valeur France vers les hyperscalers US (section 5.5) repose sur une extrapolation proportionnelle et des sources secondaires. Elle constitue un ordre de grandeur, pas un chiffre audité.

Certains sujets adjacents mériteraient un traitement séparé : la question des semi-conducteurs et la loi CHIPS, le DNS et la gouvernance d'Internet, et le DMA/DSA dans leur application concrète.