Personne n’a jamais été licencié pour avoir choisi AWS… mais l’Europe, si

Note méthodologique préliminaire

Ce document adopte une approche analytique du secteur des ESN françaises et de leurs relations avec les hyperscalers américains. Les données présentées proviennent de sources institutionnelles (Numeum, ANSSI, CIGREF), de rapports d'analystes (Synergy Research, Gartner, Markess) et de publications académiques. Lorsque les données précises font défaut, nous recourons à des estimations sectorielles explicitement signalées comme telles, avec indication des fourchettes d'incertitude et des méthodologies sous-jacentes.

Les graphiques et visualisations distinguent :

Hypothèses centrales et critères de falsifiabilité

Une analyse rigoureuse doit expliciter ses hypothèses et identifier les signaux empiriques qui permettraient de les invalider. Cette section présente les conditions de réfutabilité (falsifiabilité au sens de Popper) de la thèse défendue.

Hypothèses structurantes

Signaux qui invalideraient la thèse

Signaux observables qui réfuteraient H1 (biais d'orientation) :

Signaux qui réfuteraient H2 (asymétrie des coûts de changement) :

Signaux qui réfuteraient H3 (effet de concentration des compétences) :

Signaux qui réfuteraient H4 (désintermédiation par l'IA) :

Signaux qui réfuteraient H5 (compétitivité des alternatives) :

Protocole de suivi recommandé

Pour permettre une évaluation continue de ces hypothèses, les indicateurs suivants pourraient être suivis annuellement :

Cette grille permet au lecteur d'évaluer la robustesse de l'analyse et d'identifier les évolutions qui modifieraient ses conclusions.

RÉSUMÉ EXÉCUTIF

Thèse centrale

Les Entreprises de Services du Numérique (ESN) françaises connaissent une évolution structurelle de leur modèle économique. L'analyse des programmes de partenariat, des structures de certification et des mécanismes de rémunération suggère un déplacement progressif de la vente d'expertise technique vers l'intermédiation commerciale au profit des plateformes cloud américaines. Cette transformation soulève des questions relatives à l'alignement des intérêts entre ESN et clients, ainsi qu'aux implications pour l'autonomie technologique française.

Le mécanisme en trois temps

PARTENARIAT → CERTIFICATION → COÛTS DE CHANGEMENT ÉLEVÉS

Les ESN développent des partenariats avec AWS, Microsoft Azure et Google Cloud selon des logiques d'incitation économique documentées (marges commerciales différenciées, crédits cloud, visibilité marketing). Ces partenariats orientent les investissements en formation vers les certifications propriétaires. Les architectures déployées intègrent des services managés spécifiques qui élèvent les coûts de changement ultérieurs pour les clients. Ce mécanisme relève de la théorie économique standard de la dépendance au sentier (path dependency) et des coûts de transfert (switching costs).

Chiffres structurants

Note : Certaines données couramment citées dans la littérature professionnelle (comme le taux de DSI formés sur outils américains ou la part des données européennes chez les hyperscalers US) ne reposent pas sur des méthodologies publiées et vérifiables. Nous les excluons de cette analyse en l'absence de protocole d'audit.

Les mécanismes de coûts de changement

Dimension technique : L'utilisation d'API propriétaires, de formats de données spécifiques et de services managés sans équivalent standardisé (AWS Lambda, Azure Cosmos DB, Google BigQuery) crée une dépendance technique. Une application conçue pour un hyperscaler nécessite généralement une réécriture substantielle pour fonctionner sur une infrastructure alternative. L'ampleur de cette réécriture varie selon les choix architecturaux initiaux.

Dimension économique : Les structures tarifaires des hyperscalers incluent des mécanismes d'incitation (crédits initiaux, committed use discounts, egress fees asymétriques) qui créent des coûts de sortie significatifs. Ces mécanismes sont documentés dans la littérature économique sur les marchés bifaces et les stratégies de verrouillage.

Dimension organisationnelle : La spécialisation des équipes sur les outils propriétaires d'un fournisseur particulier représente un investissement en capital humain qui oriente les décisions ultérieures. Ce phénomène relève de la théorie du capital spécifique (Becker, 1962) et de ses extensions aux compétences technologiques.

Le contexte français

La France dispose d'acteurs cloud nationaux (OVHcloud, Scaleway, Outscale, Cloud Temple) dont les offres sont techniquement compétitives pour une majorité d'usages courants selon les comparatifs indépendants disponibles. L'écart de parts de marché entre ces acteurs et les hyperscalers américains ne s'explique pas uniquement par des différences de performances techniques, mais également par des facteurs structurels : asymétrie des investissements marketing, effet de réseau des compétences, programmes de partenariat plus développés côté américain.

Enjeu de l'automatisation

Les hyperscalers investissent massivement dans les technologies d'intelligence artificielle générative (Amazon Bedrock, Azure OpenAI, Google Vertex AI). Ces technologies présentent un potentiel d'automatisation de certaines fonctions actuellement assurées par les ESN, notamment dans les domaines de l'avant-vente, du conseil en architecture standardisé et du support technique de premier niveau.

L'ampleur et le calendrier de cette transformation restent incertains. Les projections disponibles (McKinsey, Goldman Sachs) présentent des fourchettes larges et reposent sur des hypothèses qui peuvent être contestées. Nous présentons ces éléments comme des scénarios prospectifs, non comme des prédictions.

Implications analytiques

L'analyse suggère que les ESN répondent rationnellement aux incitations économiques créées par l'architecture actuelle du marché. Une modification des comportements supposerait une transformation des structures incitatives : évolution de la commande publique, mécanismes fiscaux, obligations d'information sur les dépendances créées. Ces leviers relèvent de choix de politique publique dont l'opportunité dépasse le cadre de cette analyse descriptive.

Introduction : l'évolution du modèle économique des ESN

De l'expertise à l'intermédiation

Le modèle historique des ESN (ex-SSII) reposait sur la vente d'expertise technique. Les entreprises clientes externalisaient des compétences absentes en interne : développement, intégration, administration de systèmes. La valeur ajoutée résidait dans le capital humain des consultants et leur capacité à résoudre des problèmes techniques complexes.

Ce modèle connaît une évolution progressive avec l'émergence du cloud computing. Les ESN ont identifié une source de revenus complémentaire : l'intermédiation entre leurs clients et les fournisseurs de cloud. Cette intermédiation génère des revenus récurrents (commissions sur consommation cloud, services managés, support) présentant une prévisibilité supérieure aux prestations intellectuelles ponctuelles.

La transformation s'est intensifiée avec le développement des programmes de partenariat des hyperscalers américains. AWS, Microsoft et Google ont structuré des écosystèmes de partenaires offrant des avantages substantiels : formation subventionnée, crédits cloud pour démonstrations, co-marketing, transmission de prospects qualifiés. Ces avantages sont conditionnés à la génération d'un volume d'affaires croissant sur les plateformes concernées.

Une structure incitative asymétrique

Les ESN se trouvent dans une configuration où leurs intérêts économiques à court terme peuvent diverger de l'intérêt de leurs clients à long terme. L'ESN est incitée à orienter son client vers l'écosystème cloud où elle dispose des meilleures conditions commerciales et des partenariats les plus développés. Le client, de son côté, pourrait bénéficier d'une solution plus adaptée à ses besoins spécifiques ou préservant davantage son autonomie future.

Cette divergence potentielle d'intérêts n'est généralement pas explicite ni intentionnelle. Les ESN proposent les solutions qu'elles maîtrisent le mieux, celles sur lesquelles leurs consultants sont certifiés, celles pour lesquelles elles disposent de références. Le biais d'orientation résulte moins d'une stratégie délibérée que de l'alignement structurel des incitations avec les intérêts des hyperscalers.

Note méthodologique : Ce diagramme illustre la structure des flux de valeur, non leur mesure exacte. Les proportions sont des estimations basées sur les marges moyennes du secteur et les parts de marché connues. Les données précises ne sont pas publiquement disponibles.

Partie I : Structure du marché des ESN en France

1.1 Un marché concentré

Le marché français des services numériques représente environ 62 milliards d'euros en 2024 selon Numeum (ex-Syntec Numérique), avec une part croissante liée aux activités cloud. Ce marché est caractérisé par une concentration significative autour de quelques acteurs majeurs.

Capgemini (4,5 milliards d'euros de chiffre d'affaires en France) occupe la première place nationale. Le groupe a fait du cloud un axe stratégique, développant des partenariats avec les trois principaux hyperscalers américains. Sopra Steria (2,8 Mds€) et Atos (en restructuration, environ 2,5 Mds€) complètent le trio de tête. Accenture, bien que d'origine américaine, réalise environ 2,7 milliards d'euros sur le marché français.

Les choix technologiques de ces acteurs majeurs exercent un effet structurant sur l'ensemble du marché. Lorsqu'un acteur comme Capgemini développe une expertise massive sur AWS et forme plusieurs milliers de consultants aux certifications Amazon, cela influence les attentes du marché : les clients demandent des compétences AWS parce que c'est ce que le marché propose, et le marché propose AWS parce que c'est ce que les ESN maîtrisent.

1.2 La dynamique de croissance

Le marché des ESN françaises a connu une croissance modérée en 2024 (+0,3% selon Numeum), après plusieurs années plus dynamiques (+6,6% en 2022). Cette décélération agrégée masque des dynamiques sectorielles différenciées : les activités traditionnelles (TMA, intégration classique) stagnent ou déclinent, tandis que les activités cloud et data progressent plus fortement.

Les priorités d'investissement des entreprises convergent vers trois domaines interconnectés : l'intelligence artificielle, la cybersécurité et le cloud. Ces trois domaines sont techniquement interdépendants et convergent vers les plateformes des hyperscalers qui proposent des offres intégrées.

1.3 Les programmes de partenariat : structure incitative

Les hyperscalers ont développé des programmes de partenariat structurés qui alignent les intérêts économiques des ESN avec les leurs. Ces programmes fonctionnent par niveaux (tiers), chaque niveau supérieur offrant des avantages accrus en échange d'engagements quantifiés.

Le programme AWS Partner Network (APN) illustre cette mécanique incitative. Au niveau "Select", un partenaire doit démontrer un minimum de compétences et générer un certain volume d'affaires. Au niveau "Advanced", les exigences augmentent : plus de certifications, plus de références clients, plus de chiffre d'affaires AWS. Au niveau "Premier", les partenaires accèdent à des ressources privilégiées : équipes AWS dédiées, financements marketing, transmission de prospects qualifiés.

Cette structure crée une dynamique cumulative. Une ESN qui atteint le niveau Premier a consenti des investissements significatifs en certifications, formation et développement de références. Ces investissements constituent un actif spécifique (au sens de Williamson, 1985) qu'elle cherche à rentabiliser en orientant de nouveaux clients vers l'écosystème concerné.

Microsoft (programme Microsoft Cloud Partner) et Google (Google Cloud Partner Advantage) fonctionnent selon des logiques comparables. Les ESN souhaitant maintenir une compétitivité sur l'ensemble du marché doivent généralement maintenir des partenariats de niveau élevé avec plusieurs hyperscalers, ce qui démultiplie les investissements en capital humain spécifique.

1.4 Le mécanisme des certifications individuelles

Les certifications individuelles constituent le vecteur opérationnel de la spécialisation. Un consultant certifié AWS Solutions Architect a investi du temps et des ressources dans une compétence spécifique à l'écosystème AWS. Cette compétence devient un actif professionnel qu'il cherche à valoriser, ce qui l'incite naturellement à recommander des solutions AWS.

Les ESN financent massivement ces certifications. Les communications corporate des grands acteurs mettent en avant des volumes de certifications cloud se comptant en dizaines de milliers. Ces chiffres, présentés comme indicateurs de compétence, révèlent également une orientation stratégique vers les écosystèmes américains. Les certifications sur les alternatives françaises (OVHcloud, Scaleway) restent marginales dans les portefeuilles de compétences des ESN.

Cette asymétrie génère un effet auto-renforçant relevant de la théorie des externalités de réseau. Les clients demandent des consultants certifiés AWS parce que c'est le standard du marché. Les ESN forment sur AWS parce que c'est ce que demandent les clients. Les consultants se certifient AWS parce que c'est ce qui maximise leur employabilité. La boucle se referme, réduisant progressivement l'espace économique des alternatives.

Partie II : Les mécanismes techniques des coûts de changement

2.1 API propriétaires et services managés

Les coûts de changement techniques résultent de l'architecture même des services cloud. Chaque hyperscaler a développé des services propriétaires présentant des interfaces et des comportements spécifiques.

AWS Lambda (fonctions serverless), Amazon DynamoDB (base NoSQL), AWS Step Functions (orchestration) forment un écosystème cohérent mais spécifique. Une application conçue sur ces services nécessite généralement une réécriture pour fonctionner sur Azure ou GCP. Azure Functions, Cosmos DB et Logic Apps offrent des fonctionnalités comparables mais avec des API différentes, des modèles de données différents, des comportements différents.

Les ESN, en intégrant ces services managés dans les architectures de leurs clients, créent des configurations techniquement performantes mais intrinsèquement liées à un fournisseur. Ce choix peut être justifié par des arguments légitimes : réduction de la charge opérationnelle, scalabilité automatique, bénéfice des économies d'échelle du fournisseur. Cependant, ces avantages ont un coût implicite : la réduction de la portabilité future.

2.2 L'intégration native comme facteur de verrouillage

Les hyperscalers ont développé des intégrations natives entre leurs services qui créent des synergies opérationnelles mais renforcent les coûts de sortie. Un data lake sur AWS S3 s'intègre naturellement avec AWS Athena (requêtes), AWS Glue (ETL), Amazon Redshift (data warehouse), Amazon SageMaker (ML). Chaque brique additionnelle augmente la valeur fonctionnelle de l'ensemble et simultanément le coût d'une migration éventuelle.

Les ESN présentent généralement ces intégrations comme des avantages techniques, ce qui est objectivement le cas. L'alternative — utiliser des technologies portables (Apache Spark, Kubernetes vanilla, PostgreSQL) — demande généralement plus d'expertise initiale mais préserve la flexibilité future. Ce compromis entre performance immédiate et autonomie future est rarement explicité dans les recommandations commerciales.

La structure économique de la relation ESN-client n'est pas neutre dans cette équation. Une architecture basée sur des technologies portables génère généralement moins de revenus récurrents qu'une architecture propriétaire. Les services managés génèrent des commissions continues, le support spécialisé se facture, les certifications propriétaires se monnaient. L'intégration native présente donc une convergence entre l'intérêt technique perçu du client et l'intérêt économique de l'ESN.

Partie II-bis : Rationalité des décideurs et contraintes institutionnelles

2.4 Pourquoi les DSI choisissent les hyperscalers : une rationalité sous contrainte

L'analyse des mécanismes de dépendance ne doit pas occulter la rationalité des décideurs côté client. Les Directeurs des Systèmes d'Information (DSI) et acheteurs IT opèrent sous des contraintes institutionnelles qui rendent le choix des hyperscalers américains souvent optimal de leur point de vue individuel, même si ce choix peut être sous-optimal au niveau collectif ou à long terme.

Responsabilité et couverture du risque décisionnel

Un DSI qui recommande AWS ou Azure bénéficie d'une forme d'assurance implicite : "personne n'a jamais été licencié pour avoir choisi AWS". Ce principe, hérité du "Nobody ever got fired for buying IBM" des années 1980, traduit une réalité organisationnelle. En cas d'échec d'un projet sur AWS, la responsabilité est diluée ("la technologie leader n'a pas fonctionné"). En cas d'échec sur une alternative moins établie, la responsabilité est concentrée ("pourquoi avoir choisi ce fournisseur marginal ?").

Auditabilité et conformité

Les hyperscalers disposent de certifications exhaustives (ISO 27001, SOC 2, PCI-DSS, HDS, etc.) et d'équipes compliance dédiées. Pour un DSI devant répondre à des audits internes, des commissaires aux comptes ou des régulateurs sectoriels, cette couverture documentaire constitue un avantage décisif. Les alternatives souveraines, bien que techniquement conformes, présentent parfois une documentation moins extensive ou moins familière aux auditeurs.

Disponibilité des compétences (staffing)

Un projet AWS peut être staffé rapidement via les ESN partenaires ou le marché du freelance. Un projet OVHcloud ou Scaleway nécessite souvent un effort de sourcing plus important et des délais de recrutement allongés. Pour un DSI sous pression de delivery, cette différence de liquidité du marché des compétences pèse lourdement.

Intégration écosystémique

Les hyperscalers proposent des intégrations natives avec les outils déjà déployés (Microsoft 365/Azure, Google Workspace/GCP). Pour une organisation utilisant massivement l'écosystème Microsoft, le choix d'Azure présente une cohérence fonctionnelle réelle, indépendamment des considérations de dépendance.

Benchmark et négociation

Les DSI disposent de références de prix et de benchmarks abondants pour AWS/Azure, permettant des négociations informées. Les alternatives moins répandues offrent moins de transparence tarifaire, rendant la négociation et la justification budgétaire plus complexes.

Cette analyse ne vise pas à exonérer les décideurs de leur responsabilité dans la construction de dépendances. Elle vise à comprendre pourquoi des choix individuellement rationnels produisent des effets collectivement problématiques, ce qui constitue un cas classique de dilemme social en économie institutionnelle.

Encadré A : Comparatif stratégique des architectures

Architecture portable (K8s vanilla, PostgreSQL, S3-compatible)

Profil adapté : Organisations avec vision long terme, équipes techniques matures, données sensibles, volonté d'autonomie stratégique.

Architecture propriétaire intégrée (services managés natifs)

Profil adapté : Startups en phase d'hypercroissance, projets courts (<2 ans), équipes réduites sans expertise infra, cas d'usage où le time-to-market prime sur tout.

Grille de décision : quand le service managé propriétaire est-il rationnel ?

L'utilisation de services managés propriétaires n'est pas intrinsèquement irrationnelle. Elle le devient lorsqu'elle est choisie par défaut, sans évaluation explicite des coûts de changement induits. La grille suivante propose des critères de décision.

Situations où le choix propriétaire est économiquement rationnel

Situations où le choix propriétaire crée une dette de dépendance

Recommandation méthodologique

Tout projet cloud devrait inclure une évaluation explicite du coût de sortie (exit cost assessment) intégrant :

Cette évaluation devrait figurer dans le dossier d'architecture et être validée par la gouvernance IT. Son absence constitue un indicateur de décision sous-informée.

Partie III : Les coûts économiques de la dépendance

3.1 Structure des coûts d'acquisition client

Les hyperscalers ont développé des mécanismes d'acquisition client qui maximisent l'engagement initial tout en créant des coûts de sortie asymétriques.

Les crédits cloud initiaux (généralement 10 000€ à 100 000€ pour les moyennes entreprises, pouvant atteindre plusieurs centaines de milliers d'euros pour les grands comptes) permettent aux clients de tester les services sans investissement immédiat. Ces crédits sont conditionnés à une période d'utilisation et ne sont généralement pas transférables vers des fournisseurs alternatifs.

Les programmes de "committed use discount" offrent des remises significatives (20% à 40% selon les configurations) en échange d'engagements de consommation pluriannuels (1 à 3 ans). Ces engagements créent des coûts d'opportunité à la sortie : un client engagé à consommer 100 000€/an sur 3 ans qui souhaite migrer doit soit honorer son engagement (et payer pour des services inutilisés), soit négocier une rupture anticipée généralement pénalisante.

Les frais de sortie de données (egress fees) constituent un mécanisme de verrouillage économique direct. Chez AWS, le transfert de données hors du cloud coûte entre 0,05€ et 0,09€ par gigaoctet selon les volumes. Pour une entreprise disposant de plusieurs pétaoctets de données, les frais de sortie peuvent atteindre plusieurs millions d'euros. Ces frais sont structurellement asymétriques : l'entrée de données est gratuite, la sortie est payante.

3.2 Estimation du ratio coûts de migration

Les études disponibles (Gartner, analyses sectorielles) suggèrent que le coût d'une migration sortante représente typiquement 2 à 5 fois le coût de la migration entrante initiale. Cette fourchette large reflète la variabilité des situations :

Ce ratio défavorable renforce la réticence des clients à envisager une migration, même lorsque des alternatives plus économiques ou plus adaptées existent. Le phénomène relève de la théorie économique des coûts irrécupérables (sunk costs) et du biais de statu quo.

3.3 Structures de marge et transfert de valeur

La chaîne de valeur cloud présente des structures de marge documentées, bien que les données précises varient selon les sources et les segments :

Cette structure implique qu'une part substantielle de la valeur générée par les dépenses cloud des entreprises françaises transite vers l'économie américaine. L'ampleur exacte de ce transfert dépend de multiples facteurs (part des services cloud vs conseil, localisation des centres de données, optimisation fiscale des groupes) et ne peut être quantifiée précisément avec les données publiques disponibles.

Partie IV : Dimension organisationnelle des coûts de changement

4.1 Capital humain spécifique

La théorie économique du capital humain (Becker, 1962) distingue le capital général (compétences transférables) du capital spécifique (compétences valorisables uniquement dans un contexte particulier). Cette distinction s'applique de manière pertinente aux compétences cloud.

Un consultant certifié AWS Solutions Architect Professional dispose d'un capital humain hautement spécifique à l'écosystème Amazon. Cette compétence est très valorisée dans le marché actuel mais sa transférabilité vers d'autres environnements (Azure, alternatives souveraines) est limitée. À l'inverse, un expert en administration Linux ou en Kubernetes vanilla dispose d'un capital plus général, valorisable sur de multiples plateformes.

Les ESN, en privilégiant les certifications propriétaires au détriment des compétences génériques, orientent le marché du travail vers le capital spécifique. Cette orientation répond à une rationalité de court terme (les certifications propriétaires sont plus demandées et mieux rémunérées) mais peut poser question sur le plan de la résilience collective du secteur.

4.2 Effet de réseau des compétences

Le marché du travail IT français présente des caractéristiques de réseau où la demande de compétences AWS génère une offre de compétences AWS, qui renforce à son tour la demande. Ce mécanisme auto-renforçant crée des équilibres stables mais potentiellement sous-optimaux du point de vue de l'autonomie technologique collective.

Une offre d'emploi requérant une expertise AWS reçoit typiquement un volume de candidatures significativement supérieur à une offre équivalente sur OVHcloud ou Scaleway. Les recruteurs, les cabinets de conseil, les plateformes de freelance amplifient ce déséquilibre en orientant les candidats vers les compétences les plus demandées.

Modifier cet équilibre supposerait un effort de coordination : valorisation des compétences alternatives dans les grilles de rémunération, inclusion dans les cursus de formation, incitations pour les reconversions. En l'absence de cette coordination, l'équilibre actuel se maintient par inertie institutionnelle.

4.3 Érosion des compétences génériques

Un phénomène observé dans le secteur concerne l'érosion progressive des compétences fondamentales au profit des compétences propriétaires. Un administrateur ne travaillant qu'avec des services managés AWS peut perdre progressivement la maîtrise de l'administration d'un cluster Kubernetes vanilla. Un développeur n'utilisant que Lambda peut voir s'atrophier ses compétences en gestion d'infrastructure Linux.

Cette érosion renforce les coûts de changement au niveau organisationnel. Une entreprise souhaitant quitter AWS pour une solution alternative devrait non seulement supporter les coûts techniques et financiers de la migration, mais également reconstruire des compétences que ses équipes ont laissées s'éroder.

Partie V : Implications juridiques et stratégiques

5.1 Le cadre juridique du Cloud Act

Le Clarifying Lawful Overseas Use of Data Act (Cloud Act) de 2018 constitue un cadre juridique dont l'interprétation et les implications font l'objet de débats entre juristes. Les éléments établis sont les suivants :

Les implications pratiques de ce cadre sont plus nuancées que les formulations absolues parfois rencontrées. La question de savoir si "toute donnée chez un fournisseur américain est accessible aux autorités américaines" dépend de multiples facteurs : nature des données, existence de demandes formelles, moyens techniques de protection (chiffrement côté client, contrôle des clés), mécanismes juridiques de contestation.

Ce qui est établi, c'est que l'hébergement chez un fournisseur américain crée une exposition juridique théorique à la juridiction américaine qui n'existe pas avec un fournisseur européen non affilié à une entité américaine. L'évaluation du risque réel associé dépend du contexte spécifique de chaque organisation.

5.2 Les initiatives "Cloud de confiance"

Face à ces enjeux, la France a développé le référentiel SecNumCloud (ANSSI) et la stratégie "Cloud de confiance" visant à garantir la souveraineté des données sensibles.

Les offres "Cloud de confiance" telles que Bleu (Orange/Capgemini avec Microsoft) ou S3NS (Thales avec Google) reposent sur des technologies américaines opérées par des entités juridiques françaises. Cette construction vise à créer une immunité vis-à-vis du Cloud Act par l'interposition d'une entité non soumise à la juridiction américaine.

L'efficacité juridique réelle de ces constructions n'a pas été testée devant les tribunaux compétents. Les avis juridiques divergent sur leur robustesse face à une demande américaine persistante. Par ailleurs, ces offres maintiennent une dépendance technique vis-à-vis des technologies sous-jacentes américaines, même si la dépendance juridique est théoriquement réduite.

5.3 Considérations économiques de souveraineté

Au-delà des questions juridiques, la concentration des dépenses cloud vers les fournisseurs américains soulève des questions de politique économique. Les marges captées par les hyperscalers (estimées entre 25% et 40%) représentent un flux économique orienté vers les États-Unis. Les emplois de R&D associés aux services cloud sont majoritairement créés en Amérique du Nord. Les structures fiscales des groupes américains minimisent généralement l'imposition dans les pays d'utilisation.

Ces considérations relèvent du débat plus large sur la politique industrielle européenne et les arbitrages entre efficacité économique de court terme et autonomie stratégique de long terme. Leur pondération dans les décisions d'investissement IT dépend de choix de valeurs qui dépassent l'analyse économique pure.

Partie V-bis : Études de cas anonymisées

Les mécanismes décrits dans les parties précédentes peuvent être illustrés par des cas concrets, présentés de manière anonymisée pour respecter la confidentialité des organisations concernées. Ces cas sont issus d'observations de terrain et d'entretiens avec des décideurs IT, recoupés avec des données publiques lorsque disponibles.

Cas 1 : PME industrielle (secteur manufacturier, 120 salariés, CA 18 M€)

Contexte initial (2019) Cette PME familiale spécialisée dans l'usinage de précision souhaitait moderniser son SI : ERP vieillissant, absence de suivi de production en temps réel, données dispersées entre Excel et logiciels métiers non intégrés.

Processus de décision Consultation d'une ESN régionale partenaire AWS. Proposition d'architecture "moderne" : migration ERP vers solution SaaS, déploiement IoT pour le suivi machines sur AWS IoT Core, datalake sur S3 avec analytics Athena/QuickSight.

Déroulement du projet (2020-2021)

Investissement total : 340 K€ (dont 180 K€ crédits AWS absorbés la première année)

Situation actuelle (2024)

Éléments d'analyse

Citation (DSI, anonymisée) : "On nous a vendu le futur. Aujourd'hui on se rend compte qu'on a construit une usine à gaz qu'on ne maîtrise plus et qu'on ne peut plus quitter sans tout refaire."

Cas 2 : ETI de services (conseil en ingénierie, 800 salariés, CA 95 M€)

Contexte initial (2018) ETI en croissance externe rapide (3 acquisitions en 2 ans), SI hétérogène hérité des entités fusionnées. Besoin d'unification et de scalabilité pour accompagner la croissance.

Processus de décision Appel d'offres structuré avec cahier des charges détaillé. Trois ESN consultées (deux partenaires AWS, une partenaire Azure). Recommandation unanime : migration vers le cloud public, divergence sur le fournisseur.

Choix Azure motivé par : intégration Microsoft 365 existante, perception de simplicité pour les équipes habituées à l'écosystème Microsoft, offre commerciale agressive (-40% sur 3 ans via Enterprise Agreement).

Architecture déployée (2019-2021)

Investissement : 1,2 M€ sur 3 ans (migration + run première année)

Situation actuelle (2024)

Événement déclencheur de prise de conscience Acquisition d'une filiale allemande (2023) avec contraintes RGPD strictes et exigences du client principal (constructeur automobile) d'hébergement européen garanti. Impossibilité de démontrer l'absence d'exposition Cloud Act. Perte du contrat (valorisé à 2,3 M€/an).

Analyse rétrospective par la DSI

Citation (Directeur Général) : "On a optimisé le court terme. Aujourd'hui on paye le prix de cette optimisation chaque fois qu'un client nous pose la question de la souveraineté."

Cas 3 : Organisation régulée (établissement de santé, 2 500 salariés)

Contexte initial (2020) Centre hospitalier régional confronté à l'obsolescence de son infrastructure (serveurs physiques vieillissants, PRA insuffisant). Contraintes réglementaires fortes : données de santé (HDS obligatoire), RGPD, exigences ANSSI pour les OSE.

Processus de décision Consultation de 4 ESN. Deux propositions :

Choix effectué : Option A (Azure full), motivé par : simplicité apparente, recommandation unanime des ESN consultées, pression du temps (urgence PRA), crédits Microsoft secteur santé.

Déroulement (2021-2023)

Problématique émergente (2023-2024)

Situation de blocage actuelle

Analyse des responsabilités

Citation (RSSI) : "On nous a dit que HDS suffisait. Personne ne nous a expliqué que les règles allaient changer et qu'on construisait sur du sable réglementaire."

Synthèse transversale des cas

Facteurs communs identifiés :

Limites méthodologiques de ces cas :

Ces cas illustrent les mécanismes théoriques mais ne prouvent pas leur généralité. Ils appellent des études quantitatives sur échantillons représentatifs.

Partie V-ter : Conditions de non-validité de l'analyse

Une analyse rigoureuse doit identifier les situations où sa thèse ne s'applique pas. Cette section explicite les conditions dans lesquelles la dépendance aux hyperscalers peut être considérée comme acceptable, voire rationnelle, ainsi que les cas où elle apparaît structurellement inévitable.

Quand la dépendance est acceptable : critères de rationalité

Critère 1 : Horizon temporel court et défini

Pour un projet dont la durée de vie est explicitement limitée (prototype, MVP, projet événementiel), l'optimisation du time-to-market prime légitimement sur la portabilité. Les coûts de changement n'auront pas le temps de s'accumuler.

Seuil indicatif : Durée de vie < 2 ans, sans perspective de pérennisation.

Critère 2 : Criticité faible et réversibilité préservée

Lorsque les données traitées ne sont pas stratégiques et que leur volume reste limité, les coûts de sortie demeurent gérables. La dépendance existe mais n'est pas contraignante.

Seuil indicatif : Volume < 5 To, données non sensibles, pas de contrainte réglementaire spécifique.

Critère 3 : Avantage fonctionnel décisif et documenté

Certains services propriétaires offrent des capacités sans équivalent dans l'écosystème ouvert ou souverain. Lorsque cet avantage est documenté, quantifié et décisif pour le cas d'usage, le choix propriétaire peut être justifié.

Exemples potentiels : Services d'IA générative de pointe (à date), certains services de bases de données spécialisées, intégrations sectorielles spécifiques.

Condition : L'avantage doit être réévalué périodiquement car l'écart fonctionnel évolue.

Critère 4 : Capacité de négociation préservée

Les très grands comptes disposant d'un pouvoir de négociation significatif peuvent obtenir des conditions contractuelles atténuant les effets de la dépendance : plafonnement des hausses tarifaires, réduction des egress fees, clauses de sortie aménagées.

Seuil indicatif : Dépense annuelle > 5 M€, permettant un traitement "stratégique" par l'hyperscaler.

Critère 5 : Externalité de compétences assumée

Une organisation qui fait le choix explicite de ne pas développer de compétences IT internes peut rationnellement accepter une dépendance totale à un écosystème si elle assume que cette fonction est externalisée. Le risque est alors transféré (partiellement) au prestataire.

Condition : Ce choix doit être explicite et documenté, non subi par défaut.

Grille de validation de l'acceptabilité

Si la majorité des réponses est négative, la dépendance crée probablement une dette stratégique non maîtrisée.

Quand la dépendance est structurellement inévitable

Certaines situations rendent la dépendance aux hyperscalers difficilement évitable, indépendamment de la volonté des décideurs.

Situation 1 : Intégration écosystémique préexistante

Une organisation massivement équipée en Microsoft 365 (Exchange, Teams, SharePoint) fait face à des coûts de changement considérables avant même d'aborder la question du cloud infrastructure. L'intégration native Azure/M365 crée une path dependency difficile à rompre.

Réalité : Pour ces organisations, la question n'est pas "AWS ou Azure ou souverain" mais "comment limiter l'extension de la dépendance Azure existante".

Situation 2 : Contraintes sectorielles de fait

Certains secteurs ont développé des standards de fait autour des hyperscalers. Le secteur des startups tech, financé par des fonds qui attendent une scalabilité immédiate, impose de facto le choix AWS/GCP. Le secteur du jeu vidéo est structuré autour des services de gaming cloud américains.

Réalité : Un acteur isolé ne peut pas modifier les normes sectorielles. La non-conformité à ces normes a un coût (difficulté de financement, recrutement, partenariats).

Situation 3 : Pénurie de compétences alternatives

Dans certaines géographies ou spécialités, les compétences sur les alternatives sont simplement indisponibles. Une PME en zone rurale peut n'avoir accès qu'à des prestataires certifiés AWS/Azure.

Réalité : La dépendance aux hyperscalers reflète alors une dépendance au marché des compétences, sur laquelle l'organisation individuelle n'a pas de prise.

Situation 4 : Urgence opérationnelle

Face à une crise (cyberattaque, sinistre, croissance brutale), le temps disponible pour l'analyse stratégique est nul. Les solutions immédiatement déployables sont celles des hyperscalers, disposant de la capacité et des processus pour une mise en oeuvre en jours plutôt qu'en mois.

Réalité : L'urgence légitime des choix sous-optimaux sur le plan stratégique. La question devient celle de la trajectoire post-crise.

Situation 5 : Taille critique insuffisante

Les alternatives souveraines présentent parfois des seuils minimaux d'engagement ou des niveaux de support inadaptés aux très petites structures. Une TPE de 5 personnes peut n'avoir ni les compétences ni le budget pour gérer une infrastructure OVHcloud en autonomie.

Réalité : Le marché des alternatives n'est pas encore structuré pour tous les segments. Cette lacune est un problème d'offre, non de demande.

Implications pour l'analyse

La reconnaissance de ces conditions de non-validité nuance la thèse sans l'invalider :

L'analyse reste valide pour les situations où la dépendance résulte d'un défaut d'information, d'une asymétrie de conseil, ou d'une absence d'évaluation des coûts de changement. Elle ne s'applique pas aux choix explicites et informés dans des contextes où les alternatives sont effectivement inadaptées.

Partie VI : Les alternatives et leurs conditions de développement

6.1 Panorama des acteurs français

La France dispose d'un écosystème d'acteurs cloud nationaux plus développé que la plupart des pays européens.

OVHcloud constitue le principal acteur européen indépendant. Son chiffre d'affaires (850 M€ en 2024) reste modeste face aux hyperscalers, mais sa position sur le marché européen se renforce. L'offre couvre une gamme étendue de services (compute, stockage, réseau, Kubernetes managé).

Scaleway (groupe Iliad) se positionne sur le segment des développeurs et des entreprises technologiques avec une offre moderne et des tarifs compétitifs. Le groupe a développé des services cloud natifs qui rivalisent techniquement avec les offres américaines pour les usages courants.

Outscale (Dassault Systèmes) et Cloud Temple ciblent les marchés réglementés nécessitant des certifications de sécurité (SecNumCloud, HDS).

Numspot (Docaposte, Dassault, Bouygues) a lancé fin 2024 une offre positionnée sur l'open source et l'interopérabilité.

6.2 Compétitivité technique et tarifaire

Les comparatifs indépendants disponibles (Cloud Mercato, Cockpit.io) indiquent que les offres françaises sont techniquement compétitives pour les usages courants. Les performances (compute, réseau, stockage) sont comparables, parfois supérieures, aux offres des hyperscalers pour des charges de travail standards.

Sur le plan tarifaire, les acteurs français affichent généralement des prix inférieurs de 15% à 30% aux hyperscalers américains pour des services équivalents. Cette compétitivité résulte de structures de coûts différentes (investissements R&D et marketing proportionnellement inférieurs).

La limite principale concerne l'étendue du catalogue de services. AWS propose plus de 200 services, OVHcloud une cinquantaine. Pour les architectures nécessitant des services très spécialisés (bases de données exotiques, services d'IA avancés, intégrations complexes), les alternatives françaises peuvent manquer d'équivalents directs.

6.3 Facteurs explicatifs de l'écart de parts de marché

Malgré cette compétitivité technique et tarifaire, les acteurs français ne captent qu'une fraction marginale du marché cloud national. Plusieurs facteurs structurels expliquent cet écart :

Asymétrie des incitations : Les programmes de partenariat des hyperscalers offrent des avantages (marges, crédits, co-marketing) que les acteurs français ne peuvent égaler compte tenu de leur taille. Une ESN maximisant son profit à court terme est économiquement incitée à privilégier les solutions américaines.

Disponibilité des compétences : Proposer une solution OVHcloud ou Scaleway suppose de disposer de consultants formés sur ces plateformes, ce qui est moins fréquent que pour AWS ou Azure. Les ESN tendent à proposer ce qu'elles maîtrisent.

Perception du risque : La théorie de l'agence et les études sur la prise de décision managériale documentent un biais vers les choix conformes aux normes du marché. Un DSI choisissant AWS fait un choix conventionnel difficilement critiquable. Un DSI choisissant une alternative prend un risque de carrière perçu comme supérieur.

Coût de conviction : Recommander une alternative aux hyperscalers nécessite un effort d'argumentation et de pédagogie. Recommander AWS revient à suivre le flux dominant du marché. Les commerciaux, en situation de choix sous contrainte de temps, tendent vers la facilité.

Note : Cette comparaison est qualitative et reflète une synthèse des analyses sectorielles disponibles. Les scores sont des ordres de grandeur, non des mesures précises.

Partie VII : Leviers d'action potentiels

7.1 Réorientation des incitations économiques

Le comportement des ESN résulte de leur réponse rationnelle aux incitations auxquelles elles font face. Une modification des comportements supposerait une transformation de ces incitations.

Conditionnalité de la commande publique : L'État et les collectivités représentent un client significatif des ESN. Conditionner l'accès aux marchés publics IT à l'utilisation de solutions conformes à des critères de souveraineté créerait une incitation structurelle. Les ESN développeraient les compétences correspondantes pour préserver leur accès à ce marché.

Mécanismes fiscaux : Un avantage fiscal sur les dépenses cloud souveraines (comparable aux dispositifs existants pour la R&D) modifierait l'arbitrage économique des clients. Les ESN seraient incitées à proposer les solutions éligibles pour optimiser la situation fiscale de leurs clients.

Obligations d'information : Imposer aux ESN de documenter explicitement les coûts de changement induits par leurs recommandations (nature des dépendances techniques, estimation des coûts de sortie) permettrait aux clients de disposer d'une information plus complète pour leurs décisions.

7.2 Développement du capital humain

Évolution des formations : L'inclusion de modules sur les alternatives souveraines dans les cursus d'enseignement supérieur et les certifications professionnelles créerait un vivier de compétences. La valorisation de ces certifications dans les grilles de rémunération renforcerait leur attractivité.

Programmes de reconversion : Des dispositifs permettant aux consultants certifiés sur les hyperscalers d'acquérir des compétences complémentaires sur les alternatives élargiraient l'offre de compétences disponibles.

7.2-bis Scénarios de formation pour la reprise d'autonomie

La transformation des compétences constitue un levier actionnable à l'échelle individuelle, organisationnelle et sectorielle. Cette section détaille des parcours concrets permettant de réduire la dépendance aux écosystèmes propriétaires.

#### Parcours 1 : Du consultant AWS vers l'architecte cloud-agnostique (6-12 mois)

Investissement estimé : 8 000 à 15 000€ (formation + certifications + temps) ROI attendu : Élargissement du marché adressable, réduction de l'exposition au risque d'automatisation, positionnement différenciant.

#### Parcours 2 : Équipe DevOps vers l'autonomie opérationnelle (12-18 mois)

Investissement estimé : 50 000 à 150 000€ selon taille d'équipe Prérequis : Sponsorship direction, acceptation d'un overhead temporaire de 15-20%.

#### Parcours 3 : DSI vers la maîtrise des dépendances (6-9 mois)

Investissement estimé : 20 000 à 50 000€ (conseil + formation direction) Prérequis : Mandat clair du COMEX, budget pluriannuel.

#### Parcours 4 : Formation initiale "cloud-native souverain" (cursus Master)

Proposition de maquette pédagogique pour les formations supérieures en informatique :

Objectif : Former des professionnels capables d'évaluer objectivement les options, pas uniquement de déployer sur un écosystème donné.

#### Financement et incitations

7.3 Renforcement de l'offre souveraine

Consolidation : Le marché français reste fragmenté entre plusieurs acteurs de taille moyenne. Des alliances ou mutualisations (R&D, infrastructure, commercial) permettraient d'atteindre une masse critique supérieure.

Investissement ciblé : Les domaines où les alternatives françaises présentent des lacunes (services d'IA avancés, bases de données spécialisées) nécessitent des investissements significatifs. Un soutien public (subventions, commandes, participation au capital) pourrait accélérer ce développement.

Standardisation : Les acteurs français pourraient se différencier par l'interopérabilité, en s'appuyant sur des standards ouverts facilitant la portabilité. Cette approche, inverse de celle des hyperscalers, pourrait attirer les clients échaudés par les coûts de changement élevés.

Partie VII-bis : Dimension comparative européenne

L'analyse du cas français gagne en profondeur lorsqu'elle est mise en perspective avec les situations observées dans d'autres pays européens. Cette comparaison permet d'identifier les facteurs structurels partagés, les spécificités nationales et les approches alternatives testées ailleurs.

Panorama des écosystèmes européens de services numériques

#### Allemagne : puissance industrielle, dépendance cloud

Le marché allemand des services numériques est dominé par de grands groupes (SAP, T-Systems, Bechtle, Computacenter) et un tissu dense de Mittelstand IT. La structure du marché présente des similitudes avec la France mais aussi des différences notables.

Spécificité allemande : L'industrie manufacturière (automobile, mécanique, chimie) représente un client majeur des ESN avec des exigences élevées en matière de protection des données industrielles (Industrie 4.0). Malgré ces besoins, la dépendance aux hyperscalers américains reste dominante.

Initiative Gaia-X : Projet franco-allemand lancé en 2019 visant à créer une infrastructure de données fédérée européenne. Après des débuts prometteurs, le projet a été critiqué pour avoir intégré des hyperscalers américains comme membres, diluant l'ambition de souveraineté initiale. Gaia-X fonctionne aujourd'hui davantage comme un cadre d'interopérabilité que comme une alternative aux hyperscalers.

#### Pays-Bas : hub technologique, pragmatisme assumé

Les Pays-Bas constituent un hub technologique européen majeur (présence forte de datacenters, siège européen de nombreux groupes tech américains). Le marché des ESN est internationalisé avec une présence forte d'acteurs globaux (Cognizant, Infosys, Accenture).

Particularité néerlandaise : Approche pragmatique assumée privilégiant l'efficacité économique sur les considérations de souveraineté. Le gouvernement néerlandais utilise Microsoft 365 et Azure pour ses administrations, moyennant des négociations contractuelles spécifiques (DPIA renforcées, clauses de localisation).

Leçon pour l'analyse : L'exemple néerlandais illustre un modèle alternatif où la dépendance aux hyperscalers est acceptée et gérée contractuellement plutôt que combattue. Ce modèle présente des avantages (accès aux meilleures technologies, simplicité) et des risques (exposition juridique, dépendance stratégique).

#### Pays nordiques : maturité numérique, approches différenciées

Les pays nordiques (Suède, Finlande, Danemark, Norvège) présentent des niveaux de maturité numérique élevés avec des approches variées.

Leçon pour l'analyse : Les pays nordiques démontrent qu'un haut niveau de numérisation n'implique pas nécessairement une souveraineté cloud. La corrélation inverse peut même exister : plus un pays est numérisé tôt, plus ses dépendances aux premiers entrants (américains) sont enracinées.

#### Europe du Sud : retard numérique, opportunité de saut technologique ?

L'Espagne, l'Italie et le Portugal présentent des niveaux de maturité cloud inférieurs à l'Europe du Nord, ce qui pourrait théoriquement offrir une opportunité de "leapfrogging" vers des solutions souveraines.

Réalité observée : Les plans de numérisation financés par les fonds européens (Recovery and Resilience Facility) ont majoritairement bénéficié aux hyperscalers américains. L'Espagne a signé des partenariats majeurs avec AWS et Google. L'Italie a lancé le "Polo Strategico Nazionale" avec Tim, CDP et Leonardo, mais basé sur technologies Oracle et Google.

Leçon pour l'analyse : L'opportunité de saut technologique vers le souverain n'a pas été saisie. Les fonds européens ont accéléré l'adoption du cloud mais renforcé la dépendance aux acteurs américains.

Cartographie des approches réglementaires

Analyse comparative des initiatives "cloud de confiance"

Plusieurs pays européens ont développé des stratégies de "cloud de confiance" présentant des architectures variées.

Observation critique : Toutes les initiatives européennes de "cloud de confiance" reposent sur des technologies américaines (Microsoft, Google, Oracle). Aucun pays européen n'a réussi à développer une alternative véritablement souveraine à l'échelle requise pour les besoins gouvernementaux et entreprises critiques.

Facteurs explicatifs des différences nationales

L'analyse comparative permet d'identifier les facteurs structurants des variations nationales :

Facteur 1 : Existence d'un champion national

La France (OVHcloud) et, dans une moindre mesure, l'Allemagne (T-Systems pour les services managés) disposent d'acteurs nationaux d'une certaine taille. Les pays sans champion national présentent des dépendances plus marquées.

Facteur 2 : Tradition de politique industrielle

La France et l'Italie maintiennent une tradition d'intervention publique dans l'économie (participations étatiques, commande publique orientée). Les Pays-Bas et les pays nordiques privilégient une approche de marché.

Facteur 3 : Sensibilité politique au sujet

Le débat sur la souveraineté numérique est plus présent dans l'espace public français et allemand que dans les pays nordiques ou les Pays-Bas. Cette sensibilité influence les arbitrages politiques.

Facteur 4 : Structure du marché des ESN

Un marché d'ESN concentré autour d'acteurs nationaux (France) favorise potentiellement une orientation différente d'un marché dominé par des acteurs globaux (Pays-Bas, pays nordiques).

Le cadre européen : EUCS et ses ambiguïtés

Le projet de schéma européen de certification cloud (EUCS) vise à créer un cadre harmonisé de certification au niveau de l'UE. Les négociations ont révélé des divergences profondes entre États membres.

Position française : Défense d'un niveau "High" excluant les fournisseurs extra-européens pour les usages sensibles (aligné sur SecNumCloud).

Position néerlandaise/nordique : Opposition à l'exclusion des hyperscalers américains, considérée comme protectionniste et contre-productive.

État actuel : Compromis en discussion maintenant un niveau "High+" optionnel avec exigences d'immunité juridique, mais sans exclusion explicite des technologies américaines opérées localement.

Implication pour l'analyse : L'absence de consensus européen sur le niveau d'exigence souveraine limite l'effet de levier que pourrait avoir une politique coordonnée. Les ESN opèrent dans un cadre réglementaire fragmenté où les arbitrages nationaux dominent.

Enseignements pour le cas français

La comparaison européenne apporte plusieurs éclairages sur la situation française :

1. La France n'est pas isolée dans sa dépendance

Tous les pays européens présentent une dépendance structurelle aux hyperscalers américains. La France se distingue par l'existence d'alternatives nationales (OVHcloud, Scaleway) et d'un cadre réglementaire avancé (SecNumCloud), mais pas par un niveau de dépendance fondamentalement différent.

2. Les initiatives de "cloud de confiance" sont un palliatif, non une solution

L'architecture commune à toutes les initiatives européennes (technologie américaine + opérateur local) crée une souveraineté juridique partielle sans autonomie technologique. Cette approche peut réduire l'exposition au Cloud Act mais ne modifie pas la dépendance technique de long terme.

3. La coordination européenne reste faible

L'échec relatif de Gaia-X et les divergences sur EUCS illustrent la difficulté à coordonner une politique européenne de souveraineté cloud. Les ESN françaises opèrent dans un contexte où le marché européen reste fragmenté.

4. Les modèles alternatifs (Pays-Bas, Nordiques) assument leur dépendance

Certains pays ont fait le choix explicite d'optimiser leur relation avec les hyperscalers plutôt que de chercher à s'en affranchir. Ce modèle présente des avantages (simplicité, accès aux innovations) que le modèle français de résistance partielle n'offre pas.

5. L'opportunité de leadership européen reste ouverte

La France dispose des ingrédients (acteurs nationaux, cadre réglementaire, sensibilité politique) pour jouer un rôle de leader dans l'émergence d'une filière européenne. Cette opportunité suppose de dépasser l'échelle nationale et de construire des coalitions avec les pays partageant cette ambition.

Note : Ces estimations sont des ordres de grandeur basés sur les données Synergy Research Group et les rapports sectoriels européens. Les frontières entre catégories sont poreuses (ex: dépenses Azure via licences M365).

Partie VIII : Prospective sur l'automatisation

8.1 Cadre d'analyse

Les hyperscalers investissent massivement dans les technologies d'intelligence artificielle générative. Ces investissements présentent un potentiel de transformation de la chaîne de valeur des services numériques, y compris les fonctions actuellement assurées par les ESN.

Cette section présente une analyse prospective des scénarios possibles. Les projections disponibles (McKinsey, Goldman Sachs, cabinets spécialisés) présentent des fourchettes larges et reposent sur des hypothèses qui peuvent être contestées. Nous présentons ces éléments comme des scénarios à explorer, non comme des prédictions.

8.2 Fonctions potentiellement concernées

L'analyse des tâches composant les métiers ESN permet d'identifier les fonctions présentant un potentiel d'automatisation plus ou moins élevé :

Potentiel d'automatisation élevé (à horizon 5-10 ans selon les projections) :

Potentiel d'automatisation modéré :

Potentiel d'automatisation limité (à horizon visible) :

Note méthodologique : Ces estimations sont des scénarios prospectifs basés sur l'analyse des capacités actuelles et projetées des systèmes d'IA. Elles ne constituent pas des prédictions et présentent une incertitude élevée.

8.3 Dynamique économique

Du point de vue des hyperscalers, les ESN partenaires représentent un canal de distribution efficace mais coûteux. La part de valeur captée par les intermédiaires (estimée à 15-25% des flux) constitue une marge potentiellement récupérable si l'automatisation permet une vente et un déploiement directs.

Cette logique économique suggère un scénario de désintermédiation progressive pour les fonctions standardisables. Les ESN conserveraient une valeur ajoutée sur les projets complexes, sensibles ou nécessitant une proximité géographique et culturelle, mais verraient leur rôle se réduire sur les projets standards.

Le calendrier de cette évolution reste incertain. Les technologies d'IA générative progressent rapidement mais présentent encore des limitations (hallucinations, manque de contextualisation, difficultés sur les cas non standard). Le passage de la démonstration technique au déploiement opérationnel à grande échelle prend généralement plus de temps que les annonces marketing ne le suggèrent.

8.4 Stratégie de désintermédiation des hyperscalers

Les investissements des hyperscalers dans l'IA générative s'inscrivent dans une logique économique identifiable. Le modèle actuel de distribution via les ESN partenaires génère une acquisition de clients efficace mais implique un partage de la valeur. L'analyse des programmes d'IA intégrés aux plateformes cloud suggère une stratégie de réduction progressive de cette dépendance aux intermédiaires.

Séquence observée :

Phase actuelle : Les hyperscalers s'appuient sur les ESN pour l'acquisition et l'accompagnement des clients. Les programmes de partenariat maintiennent des incitations significatives.

Phase émergente (2025-2028, estimation) : Les outils d'IA intégrés (Amazon Bedrock, Azure OpenAI, Google Vertex AI) permettent aux clients d'accéder à des capacités de conseil et d'architecture sans intermédiation humaine pour les cas standards. Les ESN conservent un rôle sur les projets complexes.

Phase projetée (2028+, scénario) : L'extension des capacités IA pourrait permettre une vente et un déploiement directs pour une majorité de projets. Le rôle des ESN se concentrerait sur les projets à haute valeur ajoutée.

Ce scénario comporte une forte incertitude. Les capacités réelles des systèmes IA, leur acceptabilité par les clients, les évolutions réglementaires peuvent modifier significativement cette trajectoire.

8.5 Signaux observables

Plusieurs développements récents constituent des indicateurs de cette tendance :

Amazon Q (lancé fin 2023) : Assistant IA intégré à la console AWS capable de répondre aux questions d'architecture, de suggérer des optimisations, de générer du code d'infrastructure. L'extension vers des fonctions de conseil commercial représente une évolution possible.

Microsoft Copilot : Intégration de l'IA générative dans l'ensemble de la stack Microsoft. Les fonctionnalités Copilot for Sales, Copilot for Service automatisent des fonctions support. L'extension au conseil cloud suit une logique cohérente.

Google Gemini : Intégration aux services Google Cloud avec des capacités documentées de conception d'architecture et de génération de documentation.

Ces outils ne remplacent pas encore les consultants humains pour les cas complexes. Leur trajectoire de développement suggère cependant un élargissement progressif de leur périmètre d'application.

8.6 Analyse économique de la désintermédiation

Le remplacement partiel des fonctions ESN par l'IA répond à une logique économique quantifiable.

Coût d'un commercial ESN : 80 000 à 150 000 euros annuels (salaire, charges, frais). Chiffre d'affaires généré : 500 000 à 2 millions d'euros selon le niveau. Marge contributive positive mais limitée par les coûts salariaux.

Coût marginal d'une interaction IA : tend vers zéro au-delà des investissements initiaux. Scalabilité sans contrainte de recrutement. Disponibilité continue. Cohérence garantie.

Sur un marché européen du cloud estimé à 50 milliards d'euros et une commission ESN moyenne de 15-20%, l'enjeu représente plusieurs milliards d'euros de marge potentiellement réintégrée par les hyperscalers. Cette perspective économique structure les investissements en IA des plateformes.

Note : Ce diagramme illustre un scénario prospectif de répartition des flux, non une mesure de la situation actuelle ou une prédiction certaine.

8.7 Biais cognitifs et institutionnels dans le secteur

L'analyse du comportement des ESN face à cette transformation potentielle révèle plusieurs biais documentés en économie comportementale :

Biais de court terme : Les systèmes de rémunération et d'évaluation privilégient les résultats annuels. Les investissements préparant une transformation à 5-10 ans présentent un retour incertain et lointain, défavorable dans ces structures incitatives.

Dépendance au sentier (path dependency) : Les ESN ont investi massivement dans les compétences cloud américaines. Reconnaître que ces investissements pourraient être dévalorisés implique un coût psychologique et stratégique. Le biais d'engagement favorise la continuation de la trajectoire existante.

Illusion de l'indispensabilité : Les professionnels tendent à surestimer la difficulté d'automatisation de leur propre fonction. Cette perception rassurante peut retarder l'adaptation.

Discours institutionnel : La communication corporate des ESN présente généralement l'IA comme une opportunité (nouveaux services, nouveaux marchés) plutôt que comme une menace potentielle sur le coeur de métier. Ce cadrage positif peut masquer l'urgence de l'adaptation.

Ces biais ne relèvent pas d'une irrationalité individuelle mais de réponses prévisibles aux structures incitatives et informationnelles en place.

8.8 Le paradoxe de l'agent contribuant à son obsolescence

La situation présente un paradoxe structurel que la théorie économique permet d'analyser : les professionnels ESN les plus performants dans les partenariats cloud contribuent, par leur activité même, au développement des systèmes susceptibles de les remplacer.

Chaque certification AWS obtenue renforce le chiffre d'affaires d'Amazon, qui finance le développement de Bedrock.

Chaque projet Azure déployé alimente les revenus de Microsoft, investis dans Copilot.

Chaque migration GCP réussie contribue aux profits de Google, réinjectés dans Gemini.

Ce mécanisme relève de la destruction créatrice schumpétérienne, avec une particularité : contrairement au schéma classique où l'innovation vient d'entrants qui déstabilisent les acteurs établis, ce sont ici les acteurs établis (les ESN) qui alimentent les ressources de ceux qui développent les outils de transformation.

Cette configuration n'implique pas que les professionnels agissent de manière irrationnelle. Au niveau individuel, maximiser sa performance sur les partenariats cloud reste la stratégie optimale à court terme. Le paradoxe résulte de l'agrégation de comportements individuellement rationnels produisant un effet collectif potentiellement défavorable à la profession.

8.9 Options stratégiques pour les professionnels

Face à cette analyse, plusieurs trajectoires d'adaptation s'offrent aux professionnels du secteur :

Montée en gamme : Positionnnement sur les projets complexes, sensibles ou stratégiques où l'automatisation présente des limites plus durables. Cette option suppose l'acquisition de compétences rares (expertise sectorielle approfondie, certifications de sécurité, expérience de transformation organisationnelle).

Intégration chez les hyperscalers : Rejoindre directement les fournisseurs de cloud, qui continueront à employer des équipes commerciales (en effectifs réduits) pour les comptes stratégiques. Alternative : rejoindre les startups développant les outils d'automatisation.

Spécialisation souveraine : Développer une expertise sur les alternatives cloud françaises (OVHcloud, Scaleway) où la concurrence IA sera moindre et où la valeur humaine restera pertinente plus longtemps. Cette option suppose un arbitrage sur la taille du marché adressable.

Reconversion fonctionnelle : Les compétences relationnelles des professionnels commerciaux sont transférables vers d'autres fonctions (gestion de produit, customer success, formation) présentant une exposition différente à l'automatisation.

Entrepreneuriat : Création de structures positionnées sur des créneaux que les hyperscalers servent moins efficacement (souveraineté, secteurs réglementés, proximité TPE/PME).

Note : Ce schéma présente des options analytiques, non des recommandations prescriptives. Le choix optimal dépend du contexte individuel et des préférences de chacun.

Conclusion

Synthèse analytique

L'analyse du secteur des ESN françaises révèle une transformation structurelle du modèle économique. L'intermédiation dans les écosystèmes cloud américains génère des revenus récurrents qui orientent les incitations vers la promotion de solutions créant des coûts de changement élevés pour les clients.

Cette configuration résulte d'une réponse rationnelle aux structures incitatives du marché plutôt que d'une stratégie délibérée de verrouillage. Les programmes de partenariat des hyperscalers, la structure du marché du travail IT, les mécanismes de certification, les biais décisionnels des clients convergent vers un équilibre auto-renforçant.

Les alternatives souveraines françaises présentent une compétitivité technique et tarifaire documentée pour une majorité d'usages. Leur part de marché marginale s'explique par des facteurs structurels (asymétrie des incitations, disponibilité des compétences, perception du risque) plutôt que par un déficit de performance.

Limites de l'analyse

Cette analyse présente plusieurs limites qu'il convient de reconnaître :

Perspectives

La transformation du secteur dépendra de l'évolution des structures incitatives. Les leviers identifiés (commande publique, mécanismes fiscaux, obligations d'information, développement du capital humain souverain) peuvent modifier l'équilibre actuel s'ils sont mis en oeuvre de manière cohérente et soutenue.

L'automatisation par l'IA générative représente une variable structurelle dont l'ampleur et le calendrier restent incertains. Elle pourrait modifier profondément le modèle économique des ESN, indépendamment des questions de souveraineté.

Les professionnels du secteur et les décideurs disposent d'une fenêtre d'action pour anticiper ces évolutions. L'inaction n'est pas neutre : elle revient à accepter la trajectoire actuelle avec ses implications.

Annexe : Données et méthodologie

Sources primaires

Conventions méthodologiques

Protocole de mesure : objectiver les données manquantes

L'analyse du secteur ESN souffre d'un déficit de données publiques sur les dimensions clés (part du CA cloud, répartition des certifications, orientations effectives des recommandations). Cette section propose un protocole méthodologique utilisant des proxies observables pour approcher ces données.

#### Proxy 1 : Analyse des offres d'emploi

Protocole suggéré : Extraction automatisée via API ou scraping des plateformes, avec catégorisation par mots-clés : {AWS, Azure, GCP} vs {OVH, Scaleway, Kubernetes vanilla, cloud-agnostic}.

#### Proxy 2 : Badges et certifications LinkedIn

Protocole suggéré : Constitution d'un panel représentatif (500 profils par grande ESN, 100 par ESN moyenne), suivi annuel des certifications affichées. Distinction AWS/Azure/GCP vs CKA/Terraform/certifications vendor-neutral.

#### Proxy 3 : Pages partenaires officielles

Protocole suggéré : Capture semestrielle des pages partenaires des 20 principales ESN françaises. Codage du niveau de partenariat (Premier/Advanced/Select ou équivalent) et de la visibilité accordée.

#### Proxy 4 : Communications financières

Protocole suggéré : Analyse systématique des documents de référence (URD) et présentations investisseurs des ESN cotées. Extraction des mentions de partenariats et des segmentations d'activité.

#### Proxy 5 : Contenu technique publié

#### Synthèse : construction d'un indice composite

Un indice de dépendance hyperscaler pourrait être construit en combinant ces proxies :

IDH = α(ratio_offres_emploi) + β(ratio_certifications) + γ(score_partenariats) + δ(mentions_financières)

Avec pondérations à calibrer empiriquement (α=0.3, β=0.3, γ=0.2, δ=0.2 comme point de départ).

Limites de l'approche : Ces proxies mesurent des signaux observables, non les comportements réels. Ils sont sujets à des biais de déclaration et de sélection. Ils constituent néanmoins une base plus rigoureuse que les estimations non sourcées circulant dans le secteur.

Proposition : Un observatoire indépendant (académique ou institutionnel) pourrait systématiser cette collecte et publier des données annuelles permettant de suivre l'évolution du secteur sur des bases factuelles.

Annexe B : Méthodologie prospective sur l'automatisation IA des métiers ESN

Cette annexe détaille le cadre méthodologique utilisé pour les projections d'automatisation présentées en Partie VIII. Elle explicite les hypothèses, les sources, les limites et les scénarios alternatifs.

#### Cadre conceptuel : décomposition fonctionnelle des métiers

L'analyse de l'automatisation repose sur une décomposition des métiers ESN en tâches élémentaires, selon la méthodologie O*NET (Occupational Information Network) adaptée au contexte français. Chaque métier est analysé selon :

Les capacités actuelles et projetées de l'IA générative affectent principalement les catégories 1 et partiellement 2.

#### Matrice d'exposition par métier ESN

#### Hypothèses de progression des capacités IA

Les projections reposent sur des hypothèses concernant l'évolution des capacités de l'IA générative. Ces hypothèses sont explicitement spéculatives.

Scénario de base (retenu pour les estimations)

Scénario accéléré (probabilité estimée : 20%)

Percée technologique majeure (type AGI) accélérant les délais de 3 à 5 ans. Implications : restructuration brutale du secteur, disparition rapide des fonctions juniors.

Scénario décéléré (probabilité estimée : 30%)

Stagnation des capacités IA au niveau actuel (hallucinations persistantes, limites de contexte, problèmes de fiabilité). Implications : maintien du modèle actuel, automatisation limitée aux tâches très routinières.

Scénario de base révisé (probabilité estimée : 50%)

Progression régulière mais avec des plateaux. L'automatisation avance par vagues successives avec des périodes de consolidation.

#### Estimation des délais par fonction

Note critique : Ces estimations sont des ordres de grandeur à vocation illustrative. L'incertitude sur les délais est de l'ordre de +/- 50% minimum. Les projections au-delà de 5 ans relèvent davantage de la spéculation que de la prévision.

#### Analyse granulaire par métier

Métier 1 : Consultant support niveau 1

Description : Traitement des tickets incidents, diagnostic de premier niveau, application de procédures, escalade.

Projection : 70-85% des tâches automatisables d'ici 2027. Effectifs potentiellement réduits de 60-80%.

Nuance : La persistance d'une présence humaine peut être requise pour des raisons non techniques (confiance client, SLA contractuels, réglementation).

Métier 2 : Consultant junior (développement/intégration)

Description : Développement selon spécifications, tests, documentation, maintenance corrective.

Projection : 55-70% des tâches automatisables d'ici 2030. Ratio senior/junior évoluant de 1:3 vers 1:1.

Nuance : La génération de code par IA nécessite une supervision experte. Le métier évolue de "producteur" à "réviseur/intégrateur".

Métier 3 : Commercial avant-vente

Description : Qualification prospects, élaboration propositions, soutenance, négociation.

Projection : 50-65% des tâches automatisables d'ici 2028. Réduction des effectifs avant-vente de 40-50%, montée en gamme vers le conseil stratégique.

Nuance : La dimension relationnelle (confiance, réputation, réseau) reste difficile à automatiser mais peut être contournée par des modèles de vente plus directs.

Métier 4 : Chef de projet

Description : Planification, suivi, reporting, coordination équipes, relation client.

Projection : 45-55% des tâches automatisables d'ici 2030. Évolution vers un rôle de "product owner" ou "delivery lead" centré sur les arbitrages et la relation.

Métier 5 : Architecte solution

Description : Conception technique, choix technologiques, validation, conseil.

Projection : 35-45% des tâches automatisables d'ici 2032. Métier préservé mais évoluant vers l'innovation et le conseil stratégique.

Métier 6 : Expert technique / Consultant senior

Description : Expertise de pointe, R&D, résolution problèmes complexes, mentoring.

Projection : 20-30% des tâches automatisables d'ici 2035. Métier le plus résilient, demande potentiellement croissante pour superviser les systèmes IA.

#### Implications sectorielles agrégées

Projection d'évolution des effectifs ESN France (scénario de base)

Avertissement méthodologique : Ces projections sont des scénarios illustratifs, non des prédictions. L'incertitude est majeure. Les effectifs réels dépendront de facteurs non modélisés (croissance du marché, création de nouveaux métiers, régulation, adoption effective de l'IA).

#### Facteurs de modération et accélération

Facteurs de modération (ralentissant l'automatisation) :

Facteurs d'accélération :

#### Limites méthodologiques

Cette analyse présente des limites significatives qui doivent être explicitement reconnues :

Usage recommandé : Ces projections doivent être utilisées comme base de réflexion stratégique, non comme prédictions fiables. Les décisions organisationnelles doivent intégrer plusieurs scénarios et maintenir une flexibilité adaptative.

Références bibliographiques

Sources institutionnelles :

Sources analystes :

Littérature académique :