PIIEC IA : trois approches pour bâtir un stack souverain — et les questions que personne ne pose encore

# PIIEC IA : trois approches pour bâtir un stack souverain — et les questions que personne ne pose encore

Depuis que le PIIEC IA (Projet Important d'Intérêt Européen Commun dédié à l'intelligence artificielle) a commencé à financer concrètement des infrastructures et des acteurs en 2025, un discours s'est installé dans les directions techniques des ETI françaises : *il suffit de choisir un acteur labellisé européen pour être souverain*. Ce raccourci est dangereux. Et en 2026, il commence à coûter cher — pas en euros, mais en dépendances silencieuses.

Car le vrai sujet n'est pas de savoir si l'on *héberge* ses modèles en Europe. C'est de savoir si l'on *contrôle* son stack de bout en bout : les données d'entraînement, les pipelines d'inférence, les API d'orchestration, et surtout la gouvernance des droits d'accès. Sur ces quatre dimensions, les approches disponibles pour une ETI française ne se valent pas. Et certaines promesses de souveraineté méritent d'être interrogées avec rigueur.

Nous comparons ici trois approches distinctes — non des éditeurs en particulier, mais des architectures de déploiement — à travers quatre critères techniques qui comptent réellement pour un DSI ou un RSSI en 2026.

Les trois approches en jeu

Approche A — Cloud IA managé européen : l'ETI délègue l'intégralité de l'inférence et de l'orchestration à un opérateur cloud européen (qualifié SecNumCloud ou en cours), qui expose des API standardisées et héberge les modèles sur sol européen.

Approche B — Déploiement on-premise ou edge souverain : l'ETI déploie des modèles open-weight (Llama, Falcon, ou leurs dérivés européens) sur sa propre infrastructure ou sur des serveurs colocalisés dans un datacenter européen contrôlé contractuellement. L'orchestration reste interne.

Approche C — Modèle hybride piloté par un intégrateur européen : l'ETI s'appuie sur un acteur européen de services (ESN, cabinet de conseil technique) qui assemble un stack à partir de composants open source, de modèles hébergés et d'APIs tierces — en maintenant une couche d'abstraction propriétaire pour la gouvernance.

Critère 1 : Architecture et maîtrise des données

| | Approche A | Approche B | Approche C |

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

| Localisation des données d'inférence | Datacenter européen (contractuel) | Infrastructure interne ou colocalisée | Variable selon assemblage |

| Contrôle sur les logs d'inférence | Partiel (selon SLA) | Total | Partiel à total |

| Portabilité des modèles | Limitée (lock API) | Totale | Moyenne |

| Traçabilité des flux de données | Dépend de l'opérateur | Native | Dépend de l'intégrateur |

L'approche A est souvent vendue comme la plus simple à déployer — et c'est vrai. Mais *simple* ne signifie pas *souverain*. Lorsqu'un opérateur cloud européen expose ses modèles via une API REST standardisée, les données d'inférence transitent bien sur sol européen, mais les logs, les métadonnées de requêtes et les embeddings générés sont souvent stockés dans des systèmes de monitoring dont les contrats n'ont pas été lus ligne à ligne par le service juridique de l'ETI. La question à poser sans détour à l'opérateur : *qui a accès à nos logs d'inférence, et sous quelle juridiction sont-ils hébergés ?*

L'approche B offre la maîtrise architecturale la plus complète — mais elle suppose une équipe ML interne capable de maintenir un modèle en production. En 2026, peu d'ETI françaises de taille intermédiaire ont cette ressource. C'est le paradoxe de la souveraineté maximale : elle exige une autonomie technique que le marché du travail ne permet pas toujours.

L'approche C est la plus répandue dans les faits — et la moins documentée dans les appels d'offres PIIEC. Un intégrateur européen peut très bien assembler un stack souverain en façade tout en s'appuyant sur des composants d'orchestration dont les droits de propriété intellectuelle, les mises à jour et les dépendances transitives pointent vers des entités américaines. La souveraineté d'un stack hybride se mesure à son maillon le plus faible.

Critère 2 : Intégration dans le SI existant

C'est le critère que les DSI d'ETI citent systématiquement en premier — et que les éditeurs minimisent systématiquement dans leurs démonstrations.

L'approche A s'intègre via des connecteurs standardisés (REST, Webhook, parfois des SDK managés). La promesse est séduisante : quelques semaines pour connecter le modèle à un ERP ou à un outil de GED. La réalité opérationnelle est plus complexe. Les modèles exposés par les opérateurs cloud européens sont souvent des modèles génériques, insuffisamment fine-tunés pour les verticaux métiers (industrie, logistique, santé). Le DSI se retrouve alors à choisir entre deux maux : utiliser un modèle sous-optimal, ou envoyer des données métier sensibles pour un fine-tuning que l'opérateur réalise dans ses propres pipelines.

L'approche B impose une intégration sur mesure, coûteuse en temps-ingénieur, mais elle permet une connexion native aux systèmes internes sans exposition externe. Pour des ETI qui gèrent des données à forte sensibilité (données industrielles, propriété intellectuelle, données de santé), c'est souvent le seul modèle acceptable du point de vue du RSSI.

L'approche C est la plus agile en apparence, mais elle crée une dépendance vis-à-vis de l'intégrateur qui peut s'avérer aussi structurante que la dépendance à un éditeur américain. La question à poser : *si cet intégrateur disparaît ou est racheté dans dix-huit mois, combien de temps faut-il pour reprendre la main sur le stack ?*

Critère 3 : Gouvernance et conformité RGPD/AI Act

Depuis l'entrée en vigueur progressive de l'AI Act en 2025-2026, les ETI qui déploient des systèmes d'IA à usage interne ou en interaction avec des tiers sont soumises à des obligations de documentation, de traçabilité et de gestion des biais. Ce cadre réglementaire modifie profondément les arbitrages techniques.

| | Approche A | Approche B | Approche C |

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

| Documentation du modèle (model card) | Fournie par l'opérateur | À produire en interne | Responsabilité partagée |

| Registre des traitements IA | Partiellement couvert | Sous contrôle total | Dépend du contrat |

| Droit à l'explication (AI Act) | Variable selon opérateur | Implémentable nativement | Variable |

| Audit tiers possible | Selon SLA | Oui | Selon accord contractuel |

L'approche B est, sur ce critère, structurellement supérieure : la maîtrise technique totale permet de documenter, auditer et modifier le comportement du modèle à tout moment. Mais cette supériorité théorique ne vaut que si l'ETI dispose effectivement d'une politique de gouvernance IA formalisée — ce qui reste rare en 2026 hors des grandes entreprises.

L'approche A transfère une partie de la charge de conformité à l'opérateur, ce qui peut sembler avantageux. Attention : *transférer la charge* ne signifie pas *transférer la responsabilité juridique*. En cas d'incident ou de contrôle, c'est l'ETI qui répond devant la CNIL ou devant un client lésé — pas l'opérateur cloud.

L'approche C concentre les risques de gouvernance dans les zones grises contractuelles. Qui est responsable de la mise à jour du modèle si un biais est détecté ? Qui documente le changement de version ? Ces questions doivent figurer noir sur blanc dans le contrat avec l'intégrateur — et elles n'y figurent presque jamais par défaut.

Critère 4 : Résilience et absence de dépendance critique

C'est le critère le plus négligé dans les phases de sélection, et le plus douloureux à découvrir a posteriori.

L'approche A expose l'ETI à un risque de dépendance opérationnelle vis-à-vis d'un opérateur unique. Si cet opérateur est lui-même dépendant de fournisseurs de GPU américains pour ses capacités d'inférence — ce qui est le cas de la quasi-totalité des acteurs en 2026 — la chaîne de souveraineté présente un maillon hors juridiction européenne. Ce n'est pas rédhibitoire, mais c'est une réalité qu'il faut intégrer dans l'analyse de risque.

L'approche B offre la meilleure résilience opérationnelle, au prix d'une dépendance aux compétences internes. Une ETI qui déploie un modèle on-premise sans plan de continuité (rotation des équipes, documentation, procédures de reprise) peut se retrouver plus vulnérable qu'une ETI sur cloud managé.

L'approche C est, sur ce critère, la plus risquée si le contrat n'inclut pas d'escrow du code, de clauses de réversibilité et de transfert de compétences documenté.

Ce que le PIIEC ne dit pas encore

Le PIIEC IA a le mérite d'exister et de financer une infrastructure qui n'aurait pas émergé sans impulsion publique. Mais les ETI qui lisent les appels à projets avec l'espoir d'y trouver un guide d'architecture souverain seront déçues : le programme finance des capacités, pas des pratiques.

La souveraineté d'un stack IA ne se décrète pas par la localisation géographique des serveurs. Elle se construit par des choix d'architecture réversibles, des contrats qui posent les bonnes questions, et une gouvernance interne qui donne au RSSI un droit de regard réel sur les flux de données — pas seulement un tableau de bord fourni par l'opérateur.

En 2026, les ETI françaises qui s'en sortent sur ce terrain sont celles qui ont refusé la facilité du *plug-and-play souverain* et qui ont accepté d'investir dans la compréhension technique de leur propre stack. Ce n'est pas la majorité. Mais c'est la direction.