Mistral AI piraté : ce que ça dit de la souveraineté IA européenne

Mistral, c'est l'argument souveraineté de tous les pitchs IA européens depuis 2023. Modèle français, équipe française, hébergement européen possible, alternative crédible à OpenAI et Anthropic. Le 12 mai 2026, le groupe TeamPCP annonce avoir exfiltré 450 dépôts privés et 5 Go de code interne via une dépendance JS compromise — la chaîne TanStack, maintenue principalement aux États-Unis. Mistral a confirmé.

Ce n'est pas un échec de Mistral, ni un échec du modèle souverain. C'est un rappel utile : la souveraineté d'un produit IA, c'est la souveraineté de toute sa chaîne de production. Le modèle, les poids, le dataset, l'infra d'entraînement, l'infra de service, l'infra de build, les outils du dev qui code l'auth. Le maillon faible définit le niveau réel.

La souveraineté en quatre couches

Quand un acheteur me parle de souveraineté IA, je distingue toujours :

1. Souveraineté du modèle : poids ouverts ou poids contrôlés par une entité EU, entraînement sur dataset traçable.
2. Souveraineté de l'inférence : où tournent les GPU au moment où vous appelez l'API.
3. Souveraineté de l'infra produit : où vit le code qui gère votre compte, vos clés, vos prompts, vos logs.
4. Souveraineté de la chaîne de développement : qui code, avec quels outils, sur quelle CI, avec quelles dépendances.

Mistral cochait clairement (1) et (2). L'incident montre que (3) et (4) sont l'angle mort de l'écosystème — et pas seulement chez Mistral.

Pourquoi la couche 4 est presque toujours hors souveraineté

Le développement logiciel moderne repose sur des registres de packages dominés par des acteurs US : npm (GitHub/Microsoft), PyPI (Python Software Foundation, US), Docker Hub (Docker Inc., US), GitHub lui-même. Les bibliothèques les plus utilisées — React, Tailwind, TanStack, Express, FastAPI, NumPy, PyTorch — sont maintenues majoritairement par des contributeurs hors UE, souvent salariés de big tech US.

Ce n'est pas un jugement de valeur. C'est la réalité industrielle. Un éditeur EU qui veut livrer un produit moderne en 2026 utilise ces briques. La question n'est pas "comment s'en passer ?" — souvent impossible à coût raisonnable. C'est "comment réduire l'exposition résiduelle ?".

Trois leviers réalistes, pas de fantasme

1. Inventaire et mirroring interne

• SBOM systématique (cf. SBOM en pratique 2026) sur tous les artefacts.
• Registres internes mirrorés : Verdaccio, JFrog, Sonatype Nexus. Vos builds tirent depuis votre miroir, jamais directement du registre public. Quarantaine de 48-72h avant qu'une nouvelle version soit servie.
• Sur les dépendances critiques et stables, considérer le vendoring (copie locale du code, mise à jour manuelle). C'est old school, c'est efficace.

2. Audit ciblé des dépendances à risque concentré

Toutes les libs ne se valent pas. Pour chaque produit, une dizaine de dépendances portent 90% du risque réel :

• Celles avec accès au runtime serveur.
• Celles avec scripts postinstall ou équivalent.
• Celles maintenues par un seul contributeur.
• Celles ajoutées dans les 30 derniers jours.

Un audit annuel de ces 10-20 packages, par un humain, c'est plus efficace que dix outils de scan automatique.

3. Plan de bascule, pas de plan de remplacement

Personne ne va remplacer React par un fork européen demain. Mais avoir documenté comment vous basculeriez une dépendance critique en cas de compromis grave (qui décide, en combien de temps, vers quoi) — c'est ce qui sépare une équipe qui survit d'une équipe qui prend trois mois pour réagir.

Le mot "souveraineté" mérite une définition claire

Le marketing souveraineté est devenu paresseux. Beaucoup d'éditeurs revendiquent "hébergement souverain" parce que leur app tourne sur OVH ou Scaleway, alors que leur stack remonte vers GitHub, npm, Datadog, Sentry, et trois SaaS US sans même que l'équipe le voie. La souveraineté n'est ni binaire ni gratuite : c'est un curseur, et il faut savoir où vous êtes.

Trois questions honnêtes à se poser avant d'écrire "souverain" dans un commercial :

• En cas de coupure d'accès à GitHub demain matin, combien de temps pour reprendre vos builds ?
• Si npm publie une politique qui vous exclut, vos dépendances continuent-elles à se mettre à jour ?
• Si AWS / Azure / GCP vous lâche, combien de jours avant que votre produit redevienne disponible ?

Si la réponse est "je ne sais pas" — la posture honnête est de reconnaître que vous êtes hybride, pas souverain. Et de cibler les briques où ça compte vraiment pour vos clients.

Ce que je retiens de l'incident Mistral

Mistral a réagi vite, communiqué proprement, identifié le vecteur. C'est ce qu'on attend d'une équipe sérieuse. Le sujet n'est pas "Mistral est-il moins solide qu'OpenAI ?" — la réponse est non, l'écart de surface d'attaque vient de la maturité de l'opération, pas du pays.

Le sujet, c'est que la souveraineté IA en Europe ne peut pas se penser sans une politique de chaîne d'outils. Et que cette politique manque encore largement dans les éditeurs européens, y compris les plus visibles.

Pour le détail technique du vecteur d'entrée, voir La compromission TanStack en détail. Pour les clients de Mistral qui s'interrogent sur leur propre exposition, Vendor risk : que faire si vous avez signé avec Mistral.