IA en entreprise : deux architectures, deux destins pour la souveraineté numérique européenne

# IA en entreprise : deux architectures, deux destins pour la souveraineté numérique européenne

En 2026, la fracture IA ne se joue plus entre ceux qui adoptent et ceux qui attendent. Elle se joue entre ceux qui adoptent en comprenant ce qu'ils signent — et les autres. Pour les ETI européennes, le choix de l'architecture IA est devenu un choix stratégique de premier ordre. Pas un choix de confort. Un choix de dépendance, ou d'émancipation.

Ce comparatif ne vous dira pas quelle solution est « la meilleure ». Il vous posera les questions que les commerciaux de vos fournisseurs actuels évitent soigneusement.

Le cadre du problème : une adoption à deux vitesses qui masque une réalité à sens unique

Depuis 2024, les grandes plateformes américaines intègrent des capacités IA directement dans leurs suites applicatives existantes. Le message est simple, rodé, efficace : *vous avez déjà le contrat, vous avez déjà les utilisateurs, l'IA est là, activez-la*. Aucune migration. Aucun appel d'offres. Aucune DSI à convaincre.

En face, les acteurs européens spécialisés — qu'il s'agisse de plateformes d'IA souveraines ou de solutions sectorielles hébergées sur sol européen — demandent un effort d'intégration, une décision consciente, parfois un budget dédié. Et c'est précisément ce déséquilibre d'inertie qui constitue le piège.

Parce que la facilité d'activation d'une IA intégrée à un écosystème américain existant n'est pas de la générosité. C'est de l'approfondissement de dépendance. Et les ETI qui l'activent sans auditer ce qu'elles transfèrent comme données, comme savoir-faire, comme modèles d'usage, prennent un risque que leurs juristes n'ont souvent pas encore mesuré.

Comparons donc trois approches architecturales concrètes, sur quatre critères qui comptent vraiment.

Les trois approches comparées

Approche A — IA intégrée à la suite applicative dominante US

L'IA est activée comme une fonctionnalité native dans un écosystème applicatif américain déjà déployé (messagerie, productivité, CRM). Le modèle sous-jacent est opéré par le fournisseur, sur son infrastructure, selon ses conditions.

Approche B — Modèle ouvert auto-hébergé sur infrastructure européenne

L'ETI déploie un modèle de langage open-weight (poids disponibles publiquement) sur sa propre infrastructure ou sur celle d'un hébergeur certifié européen. Elle contrôle le déploiement, la configuration, les données d'entrée.

Approche C — Plateforme IA souveraine européenne en mode service

L'ETI souscrit à une plateforme IA opérée par un acteur européen, sur infrastructure européenne, avec contractualisation explicite des conditions de traitement, de résidence des données et d'audit.

Critère 1 — Architecture des données : où vont vos prompts, où restent vos données ?

Approche A. C'est ici que le marketing pitch est le plus trompeur. Les fournisseurs américains communiquent abondamment sur leur conformité RGPD. Mais conformité RGPD et souveraineté des données sont deux notions distinctes que l'on confond trop souvent. Un contrat peut être conforme au RGPD et permettre malgré tout au fournisseur d'utiliser vos données d'interaction pour améliorer ses modèles — sauf opt-out explicite, rarement activé par défaut, rarement connu des équipes métier. Par ailleurs, le Cloud Act américain continue de s'appliquer aux entités américaines, quelle que soit la localisation physique des serveurs. En 2026, aucune décision judiciaire européenne n'a définitivement tranché ce conflit de juridictions.

Approche B. L'auto-hébergement règle la question de la résidence des données : elles ne quittent pas l'infrastructure maîtrisée par l'ETI. Mais cette approche a ses propres angles morts. Qui maintient le modèle ? Qui gère les mises à jour de sécurité ? Un modèle open-weight déployé sans équipe MLOps compétente devient rapidement un actif technique orphelin. L'indépendance a un coût opérationnel réel, et le sous-estimer est une erreur fréquente.

Approche C. La plateforme souveraine européenne en SaaS offre un compromis : résidence des données contractuellement garantie, infrastructure auditée, sans la charge opérationnelle de l'auto-hébergement. Le point de vigilance : lire le contrat. Pas le résumé commercial. Le contrat. Les clauses de sous-traitance technique, notamment, méritent une attention particulière — un acteur européen peut très bien opérer sur des composants d'infrastructure américains.

Critère 2 — Intégration SI : l'interopérabilité comme levier de verrouillage

Approche A. L'intégration est fluide, presque invisible — et c'est exactement le problème. Quand l'IA est native à votre suite applicative, elle exploite des connecteurs propriétaires, des formats de données internes, des API non documentées publiquement. Résultat : plus votre usage de l'IA s'approfondit, plus votre migration future devient techniquement coûteuse. Ce n'est pas un bug. C'est une feature commerciale.

Approche B. Les modèles open-weight exposent généralement des API compatibles avec des standards ouverts (OpenAI API-compatible dans de nombreux cas, ce qui est ironique mais pratique). Cela facilite les intégrations avec des outils tiers, et préserve une certaine portabilité. L'ETI peut changer de modèle sans réécrire ses connecteurs applicatifs. C'est un avantage concret de réversibilité.

Approche C. Dépend fortement de l'acteur choisi. Les meilleures offres souveraines européennes s'appuient sur des standards ouverts et documentent explicitement leurs API. Mais certaines construisent également leurs propres écosystèmes fermés — au nom de la différenciation. La question à poser avant tout engagement : *si je veux partir dans 18 mois, qu'est-ce que j'emporte et qu'est-ce que je perds ?*

Critère 3 — Gouvernance et conformité réglementaire

Approche A. L'AI Act européen, pleinement applicable depuis 2025, impose des obligations de transparence et de traçabilité sur les systèmes IA à risque. Les acteurs américains communiquent sur leur roadmap de conformité — mais la réalité des audits est une autre affaire. La DSI qui déploie une IA américaine dans un processus RH, juridique ou financier assume une responsabilité réglementaire qu'elle transfère sans filet à un tiers hors juridiction européenne.

Approche B. L'auto-hébergement place la gouvernance entièrement dans les mains de l'ETI. C'est une force et une faiblesse simultanées. Force : vous contrôlez la traçabilité, les logs, les politiques d'usage. Faiblesse : vous portez seul la charge de conformité AI Act, sans l'appui d'un éditeur qui absorbe une partie de cette complexité.

Approche C. Une plateforme souveraine européenne sérieuse devrait proposer une documentation de conformité AI Act intégrée, des outils d'audit des décisions automatisées, et une contractualisation claire des responsabilités. C'est théoriquement l'approche la mieux positionnée pour les ETI qui traitent des données sensibles ou opèrent dans des secteurs régulés.

Critère 4 — Réversibilité et capital technique interne

C'est le critère qu'on n'évalue jamais au moment de l'adoption. Et c'est le plus important sur le long terme.

Approche A. Le capital technique construit dans un écosystème IA américain fermé est difficilement transférable. Les prompts optimisés, les workflows construits, les fine-tunings éventuels — tout cela est souvent lié à des APIs propriétaires, à des formats internes, à une logique plateforme. Si le fournisseur change ses conditions (et il le fera), l'ETI repart de zéro.

Approche B et C. À condition de s'appuyer sur des formats ouverts et des modèles documentés, les ETI qui choisissent cette voie construisent un capital technique portable. Les équipes apprennent à travailler avec des modèles qu'elles comprennent, qu'elles peuvent remplacer, qu'elles peuvent faire évoluer. C'est un investissement en autonomie, pas seulement en technologie.

Tableau de synthèse

| Critère | IA intégrée US | Modèle open-weight auto-hébergé | Plateforme souveraine EU |

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

| Résidence des données | Non garantie / ambiguë | Maîtrisée par l'ETI | Contractuellement garantie (à vérifier) |

| Interopérabilité | Faible (écosystème fermé) | Forte (standards ouverts) | Variable selon l'acteur |

| Charge de conformité AI Act | Portée par l'ETI sans visibilité | Portée entièrement par l'ETI | Partagée avec l'éditeur |

| Réversibilité | Faible | Forte | Moyenne à forte |

| Capital technique interne | Nul (dépendance totale) | Fort (si équipe compétente) | Moyen |

Ce que ce comparatif ne dit pas — et pourquoi c'est important

Il ne dit pas que les solutions souveraines européennes sont toutes matures, toutes performantes, toutes prêtes pour des cas d'usage complexes. Ce serait faux, et ce serait le même marketing dont on reproche l'usage aux autres.

Il dit que le choix par défaut — activer l'IA là où elle est déjà, parce que c'est plus simple — est un choix politique autant que technique. Un choix qui transfère de la valeur, de la donnée, du savoir-faire, hors d'Europe. Et que ce transfert ne sera pas réversible facilement.

La vraie question pour une DSI ou un RSSI d'ETI européenne en 2026 n'est pas *quelle IA est la meilleure ?* C'est *dans cinq ans, qui sera propriétaire de l'intelligence que nous avons construite ?*

Si la réponse n'est pas vous, il est temps de reposer le sujet sur la table.