IA en production : trois voies européennes pour ne pas finir captif d'un stack américain

# IA en production : trois voies européennes pour ne pas finir captif d'un stack américain

En 2026, déployer de l'IA en production sans passer par un acteur américain est devenu techniquement possible. Ce qui manquait encore il y a deux ans — modèles performants, infrastructure souveraine, outillage MLOps mature — existe désormais côté européen. La vraie question n'est plus « peut-on ? » mais « comment choisit-on ? » Et selon l'approche retenue, les implications sur la gouvernance des données, la conformité réglementaire et la résilience opérationnelle sont radicalement différentes.

Il faut être honnête : pendant longtemps, les DSI européens qui voulaient éviter les stacks US n'avaient pas vraiment le choix. Soit ils acceptaient la dépendance à OpenAI, Azure AI ou AWS Bedrock, soit ils bricolaient des solutions expérimentales peu fiables. Ce temps est révolu. Trois approches concrètes s'imposent aujourd'hui dans les projets que je vois monter en production chez les ETI et PME européennes. Je vais les comparer sur quatre critères qui comptent vraiment : architecture de déploiement, intégration dans le SI existant, gouvernance des données, et exposition aux risques d'extraterritorialité.

Les trois approches en présence

Approche A — Modèle open-weight auto-hébergé sur infrastructure européenne certifiée

Déploiement d'un modèle open-weight (type LLaMA ou Falcon dans leurs versions récentes) sur une infrastructure cloud européenne qualifiée SecNumCloud ou équivalente nationale. L'entreprise opère elle-même le modèle via un runtime qu'elle contrôle.

Approche B — API souveraine européenne mutualisée

Consommation d'une API d'inférence proposée par un opérateur européen indépendant (infrastructure et modèle tous deux localisés en Europe, contrat de droit européen, aucune relation de sous-traitance vers un acteur soumis au Cloud Act).

Approche C — Modèle fine-tuné sur infrastructure hybride à ancrage européen

Fine-tuning d'un modèle de base sur des données métier propriétaires, avec stockage des poids et des données d'entraînement exclusivement sur des nœuds européens, mais usage d'un orchestrateur open source auto-hébergé pour le serving.

Comparatif sur quatre critères

1. Architecture de déploiement

| Critère | Approche A | Approche B | Approche C |

|---|---|---|---|

| Localisation du modèle | Votre infra, votre contrôle total | Infra opérateur EU, contrat EU | Infra mixte, poids sur nœuds EU |

| Dépendance réseau externe | Nulle (inférence locale) | Oui (appel API) | Partielle (entraînement distribué possible) |

| Scalabilité | Contrainte par vos capacités | Gérée par l'opérateur | À architector selon usage |

| Résilience opérationnelle | Dépend de votre SRE | Dépend du SLA opérateur | Complexité opérationnelle élevée |

L'approche A est celle qui offre le plus de maîtrise architecturale, mais elle suppose une équipe capable d'opérer un modèle en production — ce qui n'est pas trivial pour une ETI de taille intermédiaire. L'approche B délègue cette complexité mais introduit une dépendance à un tiers, fût-il européen. L'approche C est la plus ambitieuse : elle permet d'embarquer de la spécificité métier profonde, mais elle exige une maturité MLOps que peu d'organisations ont réellement consolidée.

2. Intégration dans le SI existant

C'est souvent le critère qui tue les projets sur le papier les plus solides. Un modèle souverain déployé en silo ne sert à rien.

L'approche A s'intègre via des frameworks d'orchestration open source comme LangChain ou LlamaIndex — deux projets dont il faut noter qu'ils sont d'origine américaine, mais qui s'auto-hébergent sans aucune télémétrie obligatoire vers des serveurs US si la configuration est maîtrisée. Des alternatives européennes émergent, notamment dans l'écosystème germanophone et scandinave, mais restent moins matures sur la documentation.

L'approche B suppose que l'opérateur européen expose une interface API compatible avec les standards ouverts (OpenAI-compatible endpoint, ce qui est paradoxal mais réaliste). La compatibilité avec les connecteurs existants est généralement bonne, mais attention : utiliser un endpoint « OpenAI-compatible » ne signifie pas utiliser OpenAI. Le format est standardisé, les données restent en Europe.

L'**approche C** est celle qui demande le plus de travail d'intégration. Le fine-tuning implique des pipelines de données propres, des processus de validation des outputs, et souvent une refonte partielle des flux métier amont. Scaleway, par exemple, propose des environnements d'entraînement qualifiés qui permettent de garder ce pipeline en Europe sans faire transiter les données d'entraînement vers des plateformes américaines.

3. Gouvernance des données

C'est ici que le prisme souverainiste prend tout son sens, et je ne vais pas édulcorer.

Avec n'importe quel acteur soumis au Cloud Act américain — y compris leurs filiales européennes — vos données d'inférence sont potentiellement accessibles aux autorités fédérales américaines sans notification préalable ni recours effectif en droit européen. Ce n'est pas une hypothèse paranoïaque : c'est la lettre du texte de loi, confirmée par plusieurs avis juridiques commandés par des administrations européennes ces dernières années.

Approche A : gouvernance maximale. Aucune donnée ne sort de votre périmètre. Le log des inférences, les prompts, les contextes métier — tout reste sous votre contrôle. C'est la seule approche qui satisfait pleinement aux exigences de NIS2 pour les entités essentielles sur le volet « maîtrise de la chaîne d'approvisionnement numérique », et qui répond sans ambiguïté aux obligations DORA pour les acteurs du secteur financier concernant la gestion des risques liés aux tiers.

Approche B : gouvernance déléguée, mais contractuellement encadrée en droit européen. C'est un niveau acceptable, à condition de vérifier scrupuleusement la chaîne de sous-traitance de l'opérateur. Un acteur qui se présente comme européen mais qui s'appuie sur des GPUs loués à AWS eu-west ou Azure northeurope reste exposé indirectement au Cloud Act. Il faut exiger la transparence sur l'hébergement physique et la nationalité des entités juridiques qui opèrent l'infrastructure.

Approche C : la gouvernance des données d'entraînement est exemplaire si le pipeline est bien construit, mais la gouvernance des données d'inférence en production dépend de l'architecture de serving finale. C'est un angle mort fréquent dans les projets que j'observe : on sécurise l'entraînement, et on oublie que le modèle en production tourne parfois sur une infra moins bien qualifiée.

4. Exposition aux risques d'extraterritorialité

| Risque | Approche A | Approche B | Approche C |

|---|---|---|---|

| Cloud Act | Nul si infra EU souveraine | Faible si opérateur certifié sans dépendance US | Variable selon le serving infra |

| RGPD (transferts hors UE) | Nul | Nul si contrat DPA conforme | Risque sur pipeline si outils US utilisés |

| NIS2 (chaîne d'appro) | Maîtrisée | À auditer chez l'opérateur | Complexe à cartographier |

| DORA (risque tiers ICT) | Minimal | À évaluer (concentration risque opérateur) | Élevé si dépendances multiples |

Le risque d'extraterritorialité n'est pas qu'un risque juridique abstrait. En 2026, dans un contexte géopolitique où les relations transatlantiques restent sous tension, une ETI européenne qui a externalisé son IA critique sur un stack américain peut se retrouver exposée à des décisions unilatérales — changements de conditions d'utilisation, coupures de service, injonctions de disclosure — sans aucun recours effectif. Il faut appeler ce risque par son nom : c'est un risque de continuité d'activité, pas seulement un risque de conformité.

Ce que je recommande — et pourquoi il n'y a pas de réponse universelle

Il n'existe pas d'approche universellement supérieure, et je me méfie des consultants qui vous vendent une stack clé en main. Ce qui compte, c'est la cohérence entre votre niveau de maturité opérationnelle, la criticité des données traitées par vos cas d'usage IA, et votre appétit pour la complexité.

Pour une ETI avec une DSI de taille modeste et des cas d'usage non-critiques (aide à la rédaction, résumé de documents internes non-sensibles), l'approche B est souvent le meilleur point d'entrée : elle offre un niveau de souveraineté acceptable, une complexité opérationnelle maîtrisée, et elle construit la culture interne sur l'IA sans prise de risque excessive.

Pour une organisation soumise à DORA, opérant dans la santé, l'énergie ou la défense, ou traitant des données à caractère personnel sensibles, l'approche A n'est pas une option premium : c'est une obligation de fait. Le coût opérationnel supplémentaire est le prix réel de la souveraineté.

L'approche C est celle des organisations qui ont déjà de la maturité sur les deux premières et qui veulent créer un avantage compétitif durable via un modèle spécialisé sur leur domaine. C'est le bon problème à avoir — mais il faut l'avoir mérité.

La souveraineté numérique n'est pas un slogan de politique industrielle. Pour un DSI ou un RSSI en 2026, c'est un critère d'architecture comme un autre — avec ses contraintes, ses arbitrages, et ses bénéfices concrets. La bonne nouvelle, c'est que l'écosystème européen a suffisamment mûri pour que ce choix soit réel. Il faut maintenant que les directions techniques le traitent avec la même rigueur qu'un choix de base de données ou d'infrastructure réseau. Pas de romantisme, pas de naïveté — juste de l'ingénierie souveraine.