IA souveraine : ce que l'AI Act change vraiment pour les DSI européens

# IA souveraine : ce que l'AI Act change vraiment pour les DSI européens

Depuis des mois, la question tourne en boucle dans les comités de direction : faut-il continuer à déployer des outils d'IA américains ou basculer vers des alternatives européennes ? La question n'est plus théorique. L'AI Act de l'Union européenne est entré en application progressive, les premières obligations sont effectives, et les équipes IT se retrouvent au milieu d'un arbitrage qui mêle conformité réglementaire, dépendance technologique et pragmatisme opérationnel. Autant dire que le sujet mérite mieux qu'un webinaire de vendeurs.

Ce que l'AI Act impose concrètement — et ce qu'il ne dit pas

Commençons par dissiper un malentendu fréquent dans les CODIR : l'AI Act n'est pas une loi anti-américaine. Ce n'est pas son objet. C'est un texte de régulation par les risques qui s'applique à tous les systèmes d'IA utilisés sur le territoire européen, quelle que soit l'origine du fournisseur. OpenAI, Anthropic, mais aussi des acteurs européens sont concernés dès lors que leurs modèles tombent dans les catégories à risque élevé ou, pour les grands modèles de langage, dans le cadre des règles spécifiques aux GPAI (General Purpose AI).

Concrètement, pour un DSI d'ETI qui a déployé un assistant RH basé sur GPT-4 pour automatiser des évaluations de candidats, le sujet est immédiat : ce type d'usage entre dans la catégorie à risque élevé selon le texte européen, ce qui implique des obligations de traçabilité, de documentation des données d'entraînement, d'évaluation de conformité et potentiellement d'audit. La question n'est pas de savoir si le modèle est américain ou européen — c'est de savoir si le fournisseur est capable de vous fournir la documentation nécessaire pour vous couvrir, vous, en tant qu'opérateur.

C'est là que la souveraineté commence à entrer dans la danse, mais pas forcément là où on l'attendait.

La vraie question : documentation, auditabilité, et où sont les données

Quand un DSI déploie un modèle d'IA en production, il devient ce que l'AI Act appelle un "opérateur". En clair : une partie de la responsabilité de conformité repose sur ses épaules, pas seulement sur celles du fournisseur. Pour s'acquitter de cette responsabilité, il a besoin d'informations précises sur le modèle utilisé — données d'entraînement, capacités, limites, mesures de sécurité.

Or, les grands modèles américains ne sont pas toujours généreux sur ce point. OpenAI, Google DeepMind ou Anthropic publient des "system cards" et des rapports techniques, mais le niveau de détail reste souvent insuffisant pour une mise en conformité sérieuse. Sur des usages sensibles — décisions RH, scoring de crédit, priorisation médicale — cette opacité devient un problème réglementaire concret, pas une posture idéologique.

Et puis il y a la question des données. Même quand un modèle est utilisé en mode API, les prompts et les données envoyées transitent quelque part. La localisation des serveurs, les sous-traitants de traitement, les conditions dans lesquelles ces données peuvent être utilisées pour du réentraînement : autant de points que le RGPD encadrait déjà, mais que les équipes IT n'avaient pas toujours vérifiés scrupuleusement quand le déploiement s'est fait en mode "shadow IT" pilotage par les métiers.

En 2026, ce flou n'est plus tenable. Les DPO et les RSSI ont rattrapé le sujet.

Pourquoi "souverain" ne veut pas dire "moins performant"

Il y a encore dix-huit mois, la question se tranchait assez vite : les modèles européens n'avaient pas le niveau. C'était vrai. Ce n'est plus entièrement vrai aujourd'hui, et il faut être honnête sur ce que ça signifie — et sur ce que ça ne signifie pas encore.

Mistral AI, la société française, a produit des modèles qui sont devenus des références techniques sérieuses. Leur famille de modèles ouverts (Mistral 7B, Mixtral, et les itérations suivantes) sont déployables on-premise ou en cloud européen, auditables parce qu'une partie est open-weight, et disponibles chez des hébergeurs certifiés SecNumCloud comme OVHcloud ou Scaleway. Ce n'est pas de la propagande industrielle : les benchmarks académiques disponibles publiquement le confirment sur un grand nombre de tâches.

Mais soyons précis : sur des cas d'usage très spécifiques — raisonnement complexe multimodal, certaines tâches de code avancé, traitement de contextes extrêmement longs — les modèles de frontier américains conservent une avance mesurable. La question pour un DSI n'est donc pas "quel modèle est le meilleur en absolu" mais "pour mon cas d'usage précis, quelle est la différence de performance, et est-ce que cette différence justifie le différentiel de risque réglementaire et de dépendance ?".

C'est un calcul de gestion du risque, pas un choix patriotique.

Alors, concrètement, un acteur comme Aleph Alpha — la société allemande qui a connu des turbulences stratégiques mais qui repositionne son offre sur des déploiements souverains en entreprise — propose une approche intéressante : modèles déployables dans des environnements entièrement isolés, avec un niveau de documentation et de traçabilité conçu dès le départ pour la conformité réglementaire européenne. C'est un positionnement différent de Mistral, plus axé sur des grands comptes et des secteurs régulés (défense, santé, administration), mais c'est exactement le type d'offre qui répond à un besoin réel de traçabilité.

Ce que les DSI doivent faire maintenant — sans panique

Première chose : cartographier les usages existants. Avant même de se poser la question des alternatives, il faut savoir ce qui tourne en production. Dans beaucoup d'ETI, des outils comme Microsoft Copilot, des plugins ChatGPT, des intégrations Notion AI ou des outils de code assisté ont été déployés par les métiers sans passage formel par la DSI. Cette cartographie n'est pas optionnelle : c'est le préalable à toute démarche de conformité AI Act, et c'est aussi un prérequis pour une discussion honnête avec le DPO.

Deuxième chose : qualifier le niveau de risque de chaque usage. L'AI Act distingue des niveaux de risque — inacceptable, élevé, limité, minimal. Un outil de résumé de réunion interne, c'est risque minimal. Un outil qui aide à prendre des décisions sur des contrats de travail ou à scorer des fournisseurs dans un processus d'achat sensible, c'est différent. Cette qualification doit être faite usage par usage, pas globalement.

Troisième chose : poser les bonnes questions aux fournisseurs actuels. Avant de migrer quoi que ce soit, il faut d'abord tester la capacité de vos fournisseurs existants à vous fournir la documentation AI Act. Microsoft, par exemple, a investi massivement dans sa posture de conformité européenne pour Azure OpenAI Service, avec des engagements sur la résidence des données et la non-utilisation des prompts pour le réentraînement des modèles. Ce n'est pas parfait, mais c'est documenté. Demandez les preuves. Exigez les contrats data processing. Si le commercial ne peut pas vous fournir ça, c'est un signal.

Quatrième chose : ne pas confondre souveraineté et pureté idéologique. Une architecture hybride — modèles européens pour les usages sensibles et les données confidentielles, modèles américains (avec les garanties contractuelles appropriées) pour des usages à risque minimal et haute valeur de performance — est une réponse pragmatique et défendable. L'objectif n'est pas de sortir de l'écosystème américain pour des raisons symboliques, mais de réduire les risques de dépendance sur les cas où cette dépendance est problématique.

La dimension stratégique que beaucoup de DSI sous-estiment

Il y a un angle que les analyses techniques sur l'AI Act évacuent trop souvent : la question de la dépendance à long terme n'est pas seulement réglementaire, elle est aussi économique et géopolitique.

Les décisions exécutives et les évolutions réglementaires américaines de ces dernières années ont montré qu'une infrastructure critique hébergée exclusivement chez des fournisseurs soumis à des législations extraterritoriales (CLOUD Act, notamment) peut se retrouver exposée à des injonctions ou des changements de politique qui échappent entièrement au contrôle d'une entreprise européenne. Ce n'est pas de la paranoïa : c'est ce que la plupart des services juridiques sérieux des grands groupes ont intégré depuis plusieurs années.

Pour une PME ou une ETI, le risque immédiat est peut-être moins visible. Mais quand votre processus de production, votre service client ou votre R&D sont adossés à une infrastructure sur laquelle vous n'avez aucun levier contractuel solide, vous avez un angle mort dans votre gestion des risques. Un DSI qui explique ça à son COMEX en 2026 sera mieux compris qu'il y a trois ans.

La conclusion qui dérange un peu

La souveraineté numérique est un objectif légitime, mais elle ne se construit pas en une décision de migration. Elle se construit dans la durée, par des choix successifs qui privilégient progressivement des solutions auditables, des données maîtrisées, et des fournisseurs dont la stabilité réglementaire est compatible avec la vôtre.

La vraie question que chaque DSI devrait se poser n'est pas "est-ce que mon IA est européenne ?" mais "est-ce que je suis en mesure de démontrer, en cas d'audit ou d'incident, que j'avais la maîtrise de ce que je déployais ?".

La réponse à cette question détermine à la fois votre conformité AI Act, votre posture souveraine, et votre crédibilité interne. Et elle n'a pas de réponse générique : elle dépend de votre secteur, de vos usages, et de l'appétit au risque de votre organisation.

C'est exactement pour ça que ce sujet ne se délègue pas au prestataire IA du moment.