428 milliards de paramètres sous licence maison — les 4 vérifications que je fais avant d’écrire « open source »

Panos Petropoulos

Expert développement web · 6 septembre 2026 · 10 min de lecture

Il y a deux façons de lire l’annonce du 4 septembre. La première est géopolitique et elle est fascinante. La seconde est contractuelle, beaucoup plus ennuyeuse, et c’est la seule qui aura un effet sur votre code dans dix-huit mois. C’est celle-ci qui m’intéresse.

Ce qui a été annoncé

Le 4 septembre 2026, HUMAIN, l’entité saoudienne dédiée à l’intelligence artificielle, a présenté un modèle de langue arabe de 428 milliards de paramètres en architecture de mélange d’experts, construit conjointement avec le laboratoire chinois MiniMax et entraîné sur plus de mille milliards de jetons en arabe. La publication des poids est annoncée sous MiniMax Community License.

Trois faits, trois lectures possibles, et il faut résister à l’envie de les fondre en une seule histoire.

Le premier fait est technique : une architecture de mélange d’experts à cette échelle n’active qu’une fraction de ses paramètres à chaque jeton. Les 428 milliards annoncés ne décrivent donc pas le coût d’inférence, seulement la capacité totale. C’est un chiffre de communication autant qu’un chiffre d’ingénierie, et il faut le lire comme tel.

Le deuxième fait est industriel : un acteur souverain du Golfe s’associe à un laboratoire chinois pour produire un modèle destiné à sa propre langue. C’est un signal sur la manière dont se construisent aujourd’hui les capacités nationales — par partenariat, pas par autarcie.

Le troisième fait est juridique, et c’est celui dont personne ne parlera : les poids sortent sous une licence rédigée par le laboratoire, pas sous une licence libre reconnue. C’est devenu la norme, et c’est exactement pour cela qu’il faut s’y arrêter.

Notre avis d’expert #1 — « poids ouverts » n’est pas « open source »

La confusion est devenue si banale qu’on ne la relève même plus. Elle a pourtant des conséquences très concrètes.

Une licence open source, au sens de la définition maintenue par l’Open Source Initiative, garantit un ensemble de libertés dont deux sont ici décisives : l’absence de discrimination envers des personnes, des groupes ou des domaines d’usage, et l’absence de conditions supplémentaires imposées à la redistribution. Une licence dite « communautaire » publiée par un laboratoire ajoute presque toujours au moins l’un des éléments suivants :

• un seuil au-delà duquel l’usage commercial doit être négocié, exprimé en utilisateurs, en chiffre d’affaires ou en volume ;
• des domaines d’usage interdits, énumérés dans une politique d’usage acceptable qui peut être modifiée après coup ;
• une obligation d’attribution visible, parfois jusque dans l’interface du produit final ;
• une clause de résiliation qui met fin à vos droits en cas de contentieux avec l’éditeur.

Aucun de ces éléments n’est scandaleux en soi. Le problème est de traiter le modèle comme une brique libre alors qu’il est une dépendance sous conditions — et de le découvrir au moment où le produit marche, c’est-à-dire au pire moment possible.

Notre avis d’expert #2 — la souveraineté se mesure sur quatre plans, pas un

Cette annonce est présentée, à juste titre, comme une brique de souveraineté technologique. Mais le mot recouvre quatre réalités indépendantes, et une organisation peut être souveraine sur l’une tout en étant complètement captive sur une autre.

Plan 1 — la propriété des poids. Qui peut retirer le modèle, en modifier la licence, ou refuser une version future ? Publier des poids ne signifie pas céder les droits : cela signifie accorder une licence, révocable selon ses propres termes.

Plan 2 — la localisation de l’inférence. Un modèle « ouvert » que vous appelez via l’API du laboratoire ne vous rend souverain sur rien du tout. La possibilité théorique d’héberger le modèle et le fait de l’héberger réellement sont deux situations juridiquement très différentes.

Plan 3 — la chaîne d’entraînement. Quelles données, sous quelle juridiction, sur quel matériel. C’est le plan le plus opaque, et celui sur lequel aucune annonce ne donne de réponse vérifiable.

Plan 4 — la capacité de sortie. Pouvez-vous remplacer ce modèle en une semaine ? C’est le seul plan que vous contrôlez entièrement, et paradoxalement celui que les équipes négligent le plus.

Notre avis d’expert #3 — ce que cette annonce dit vraiment sur les langues sous-dotées

Sous la couche géopolitique, il y a un fait technique qui mérite attention et qui vaut aussi pour le français.

Mille milliards de jetons dans une seule langue, c’est un investissement massif dans la constitution d’un corpus. C’est aussi la reconnaissance implicite d’un problème que toutes les langues non anglophones connaissent : les modèles généralistes sont entraînés sur des proportions qui reflètent la disponibilité des textes sur le web, pas l’importance des langues. L’arabe, comme le français, y est structurellement sous-représenté par rapport à son poids réel.

La conséquence pratique, que nous constatons sur chaque projet, est que les écarts de qualité entre langues ne se voient pas sur les grands classements. Un modèle qui obtient d’excellents résultats en anglais peut se dégrader nettement sur du vocabulaire administratif français, sur des documents comptables ou sur des textes réglementaires — précisément les cas d’usage d’entreprise.

La leçon opérationnelle est simple et elle n’a rien à voir avec l’Arabie saoudite : constituez votre propre jeu d’évaluation, dans votre langue et sur vos documents. Cinquante cas suffisent pour commencer. C’est le seul instrument qui vous permettra de comparer honnêtement deux modèles — y compris celui-ci — et de détecter une régression lors d’une mise à jour.

C’est le même raisonnement que celui appliqué à la maîtrise des coûts d’inférence côté Plug-Tech : sans mesure propre, on subit les annonces du fournisseur au lieu de les arbitrer. Et sur le volet risque, les équipes de WebGuard font le même constat sur les dépendances logicielles : la question n’est jamais « ce composant est-il bon », mais « que se passe-t-il le jour où il devient indisponible ».

Les 4 vérifications, dans l’ordre

Voici la liste que j’applique désormais avant d’introduire un modèle à poids ouverts dans un projet, quelle que soit sa provenance.

• Lire la licence en entier, et archiver le texte utilisé. Pas le résumé de la page de présentation : le fichier de licence, à la version des poids que vous téléchargez. Une licence peut changer entre deux versions ; sans archive, vous ne saurez plus sous quelles conditions vous avez construit.
• Chercher les trois clauses qui coûtent cher : seuil d’usage commercial, domaines interdits, résiliation. Elles tiennent en général en trois paragraphes et se lisent en dix minutes.
• Vérifier la politique d’usage acceptable référencée par la licence. C’est souvent un document séparé, modifiable unilatéralement, et c’est là que se trouvent les vraies restrictions.
• Mesurer le délai de sortie, réellement, en tentant de basculer sur un autre modèle dans un environnement de test. Tant que ce test n’a pas été fait une fois, le délai que vous annoncez est une estimation optimiste.

Aucune de ces quatre vérifications ne demande de compétence juridique particulière, et l’ensemble prend moins d’une journée. C’est très peu comparé au coût d’une migration forcée. Si vous chiffrez un projet qui dépendra d’un modèle de ce type, notre méthode d’estimation appliquée aux plateformes de mise en relation détaille comment intégrer ce risque de dépendance dans un budget, plutôt que de le découvrir en cours de route.

Questions fréquentes