Open weights : le débat qui façonne l'IA souveraine

Un débat majeur agite la Silicon Valley. Plus d'une centaine d'entreprises, dont Microsoft, NVIDIA, Amazon, Meta et Hugging Face, ont signé une lettre ouverte en faveur des modèles open weights (poids ouverts). Anthropic, de son côté, reste prudent et ne veut publier que des modèles "sans capacités dangereuses". Pour une PME européenne qui vise une IA souveraine, ce débat décide des architectures possibles.

Réponse directe : un modèle open weights est un LLM dont les poids sont publiés librement, téléchargeables et exécutables sur votre propre infrastructure. Pour une entreprise soumise au RGPD, c'est la seule option qui garantit le contrôle des données, à condition d'assumer l'infrastructure, la maintenance et la surveillance.

Qu'est-ce qu'un modèle open weights ?

Un modèle open weights est l'équivalent d'un logiciel open source pour l'IA. L'éditeur rend les poids du modèle entraîné, les milliards de paramètres appris, disponibles en téléchargement. N'importe quelle équipe peut alors exécuter le modèle sur ses serveurs, l'affiner sur ses données ou l'intégrer à son pipeline.

Ce modèle diffère radicalement des API fermées (OpenAI, Anthropic, Google) où le modèle reste derrière une infrastructure centralisée et des conditions d'usage édictées par l'éditeur. La lettre ouverte le dit avec clarté : un modèle à poids ouverts peut réellement être la propriété de l'utilisateur, alors qu'une API fermée n'est que du locatif révocable.

Quatre conséquences pour une entreprise :

• Contrôle des données : les données de vos utilisateurs ne quittent pas votre périmètre.
• Hébergement libre : vous choisissez le pays des serveurs, le matériel et la politique de sécurité.
• Réversibilité : le modèle devient un actif de votre entreprise, pas un service prêté.
• Coût : vous payez la puissance de calcul, pas un montant par token.

Ce contrôle est précisément la valeur que recherchent les PME qui placent la souveraineté des données au cœur de leur stratégie IA.

Qui a signé la lettre en faveur des open weights ?

La lettre a réuni plus de cent entreprises de la Silicon Valley. Les noms les plus connus sont Microsoft, NVIDIA, OpenAI, Intel, Amazon et Hugging Face. Sa thèse est simple : la transparence et la réutilisabilité des poids sont un progrès, et il faut défendre un écosystème où l'IA peut être vérifiée et réutilisée.

Les arguments des signataires convergent :

• L'audit des modèles est un gain de sécurité, car on peut vérifier ce que fait le système.
• La recherche et l'industrie ne doivent pas dépendre de la bonne volonté de trois ou quatre éditeurs.
• La souveraineté passe par la possession des modèles, pas par leur location.
• Les restrictions d'usage excessives freinent l'innovation légitime.

De l'autre côté, Anthropic est le refus le plus visible. L'entreprise soutient "les modèles à poids ouverts qui n'ont pas de capacités dangereuses" : une position nuancée. Un modèle à poids ouverts peut en effet être ré-entraîné et détourné par un acteur malveillant. Le contrôle éditorial d'une API fermée n'existe plus.

Pourquoi une PME française doit suivre ce débat

Ce débat n'est pas théorique pour une PME française. Il porte sur deux enjeux qui se croisent : la souveraineté technologique et la conformité RGPD.

En matière de souveraineté, vos options se résument à deux familles :

1. Traiter via une API : vos données sont envoyées à un opérateur tiers. La localisation réelle, les clauses du contrat et l'hébergement sont ceux de l'éditeur.
2. Héberger un modèle ouvert : vos données restent sous votre maîtrise, sur du matériel que vous définissez, dans l'Union ou dans le pays que vous choisissez.

Dans mon travail de freelance IA, la seconde option est devenue le réflexe dès qu'une donnée personnelle ou sensible entre en jeu. Ce n'est pas un luxe, c'est une réponse directe au RGPD.

Open weights et RGPD : quels articles s'appliquent

Le RGPD ne parle pas des formats de modèle. Il parle du traitement des données. Les articles clés se déclinent ainsi :

• Article 28 : tout sous-traitant qui traite des données pour votre compte doit être encadré par un contrat. Avec un modèle open hébergé par vous, le traitement reste sous votre responsabilité.
• Article 44 : encadre les transferts de données hors de l'Union européenne. Un modèle hébergé en France ou en Europe de l'Union supprime la question du transfert, contrairement à une API américaine exposée au CLOUD Act (loi de 2018).
• Article 30 : vous devez tenir un registre des traitements. Un modèle local rend la traçabilité simple : on sait où il tourne, quelle version, quels journaux.

La contrainte principale porte donc sur la localisation de l'infrastructure. La CNIL le rappelle dans ses fiches : la protection des données se construit au niveau du traitement dans l'architecture, pas seulement au niveau de l'application.

Héberger un modèle open weights en Europe : le dimensionnement

Passons à l'architecture. Un modèle open se déploie selon sa taille :

Gamme	Cas d'usage	Infrastructure de base
1 à 8 milliards	classification, résumé, extraction	VM 8-16 Go
8 à 32 milliards	RAG, assistance, analyse de documents	GPU 24-48 Go ou 1 serveur
70 milliards et plus	génération de pointe, agent complexe	cluster de GPU

La première étape est le dimensionnement. Avant d'acheter une carte, le simulateur de VRAM estime l'empreinte mémoire d'un modèle choisi. Un calcul fait en amont évite les mauvaises surprises d'exploitation.

Mon conseil : commencer petit et par un cas identifié. Évaluer un modèle 8 milliards sur un référentiel de tests métier, puis monter en gamme seulement si les résultats le justifient. Dans le ML, ce qui manque n'est pas le modèle, mais un jeu de tests représentatif. Pour la mise en œuvre, complétez avec le guide sur le codage agentique avec LLM local ou la méthode pour intégrer un LLM sans violer le RGPD.

Quels risques faut-il anticiper quand on héberge soi-même ?

Un open weights change la répartition des risques. En passant au déploiement local, plusieurs responsabilités habituellement portées par l'éditeur reviennent à votre équipe :

• Mise à jour : vous devez suivre les versions publiées et repasser les tests de qualité.
• Sécurité : un modèle accessible sur le réseau peut servir à de l'exfiltration de données, par exemple via du prompt injection.
• Traçabilité : il faut journaliser les requêtes et pouvoir expliquer les traitements.
• Licences : les poids ouverts ont des licences multiples, certaines commerciales, d'autres restrictives. À vérifier en amont.

Aucun de ces risques n'est bloquant. Ils doivent simplement être anticipés comme n'importe quel composant logiciel critique.

Open weights ou API propriétaire : le bon périmètre

Critère	Open weights	API propriétaire
Coût	dépend de l'infrastructure	abonnement ou à la consommation
Déploiement	à charge	simple
Données hors périmètre	non si hébergé en Europe	selon l'éditeur
Contrat RGPD	interne	fournisseur
Mise en production	sous votre contrôle	éditeur
Mise à jour	vous	éditeur

La décision n'est donc pas binaire. Pour les données sensibles, je privilégie l'open : le coût de l'infrastructure se compare à celui d'une licence. Pour une fonction ponctuelle peu sensible, l'API reste raisonnable. Ce type de compromis est typiquement réalisé lors d'un projet d'intégration d'un LLM conforme.

Conclusion

La lettre de la Silicon Valley ouvre une page nouvelle : la possession des poids devient le support de l'IA souveraine, et elle croise directement les obligations RGPD de la réglementation européenne. Pour une PME française, le choix d'architecture est un choix de souveraineté : le modèle doit être sous contrôle et la localisation certaine.

En pratique, le chemin est progressif : un atelier d'évaluation, un prototype, un déploiement maîtrisé. C'est exactement le type d'intégration d'IA qui peut être engagé sur un périmètre réduit avant d'élargir. Ce choix d'architecture et la conformité qu'il implique se discutent avec un expert RGPD : n'hésitez pas à me poser vos questions.

Parlons-en.