Les poids ouverts ne sont pas de l'open source, et l'écart se creuse

Les poids sont les paramètres numériques appris lors de l'entraînement. À eux seuls, ils permettent d'exécuter un modèle, de l'héberger, de l'affiner sur des documents internes et de se passer de l'API d'un fournisseur. C'est un actif réel. Selon l'Open Source Initiative, cela ne représente toutefois que « une fraction des informations nécessaires à une redevabilité complète ».

Le 15 septembre, Steven J. Vaughan-Nichols de The Register a affirmé que l'industrie a discrètement substitué un mot à un autre. Une entreprise publie des fichiers sur Hugging Face, des développeurs les exécutent sur leurs GPU, et la sortie est immédiatement qualifiée de modèle open source. Pas nécessairement, argue-t-il : il peut s'agir uniquement de poids ouverts.

La distinction semble académique. Elle ne l'est pas.

Sans données d'entraînement ni documentation détaillée, les tiers ne peuvent pas établir quelles sources ont alimenté le modèle, quels contenus protégés ou privés y figurent, comment les données ont été filtrées, quelles langues sont sous-représentées, si des données de benchmark ont fui dans l'entraînement, ni quel travail d'alignement a suivi le pré-entraînement. James Landay, directeur du Stanford Institute for Human-Centered AI, a déclaré à The Register que les poids ouverts constituent un progrès car ils permettent de garder le modèle hors du pipeline de données d'autrui. Il ajoute : « Vous ne pouvez toujours pas voir comment la chose a été construite, sur quoi elle a été entraînée, ni pourquoi elle se comporte ainsi. Ce n'est pas un modèle ouvert. C'est de la distribution ouverte. »

L'Open Source Initiative a tenté de trancher avec sa définition de l'IA open source, OSAID 1.0, publiée en octobre 2024. Elle exige que les paramètres du modèle, poids compris, soient disponibles sous des termes approuvés par l'OSI, sans prescrire de mécanisme juridique précis. Cet écart persiste. Luca Antiga, CTO de Lightning AI, a qualifié le traitement des poids de « trou béant qui rendra les licences moins efficaces ». Bruce Perens, auteur de la définition originale de l'open source, a dénoncé l'OSAID en 2024, affirmant ensuite que l'OSI elle-même participait à du blanchiment d'open source. Bradley Kuhn de la Software Freedom Conservancy et Richard Fontana de Red Hat ont demandé l'abrogation de cette définition.

Ce que les poids apportent réellement

Mozilla a publié la version 1.1 de son rapport State of Open Source AI le 15 septembre, avec des données arrêtées au 1er septembre. C'est un retour au réel utile pour les deux camps. Le meilleur modèle ouvert accusait trois points de retard sur le leader fermé à l'Artificial Analysis Intelligence Index, pour 60 % du prix. Il se situait deux points derrière Claude Fable 5 à 30 %. En ajustant les données de l'horizon de tâches de METR, Mozilla a estimé l'écart ouvert-fermé à environ 4,4 mois, proche de l'estimation de quatre mois d'Epoch AI. La capacité ouverte double tous les 3,9 mois, contre 5,5 pour la fermée, selon les calculs de Mozilla.

Mozilla défend les modèles ouverts, et le rapport n'est pas neutre : TIME a rapporté le 14 juillet que le CTO de Mozilla, Raffi Krikorian, le décrivait comme en partie militant. Les chiffres du rapport contredisent d'ailleurs son titre. Il recense 16 sorties notables ouvertes, et aucune ne fournit la recette des données exigée par la définition de l'OSI. L'écart de quatre mois et le chiffre de 30 % pour le prix sont mesurés d'API à API sur des points d'accès hébergés, au prix catalogue.

Reste le matériel. Le graphique de Mozilla place le meilleur modèle ouvert tenant sur un serveur à 52,6 et le meilleur tenant sur un seul GPU à 40, soit des baisses de 10 et 23 points. Le checkpoint natif MXFP4 de Kimi K3 pèse environ 1,56 To répartis en 96 fragments. La configuration de service liste 64 accélérateurs ou plus, et vLLM demande au moins huit GPU GB300 avec plusieurs nœuds pour le trafic de production. Mozilla emploie la formule « ouvert mais non exécutable par la plupart de ceux qui le détiennent ». Une exception : Inkling-Small de Thinking Machines, sous Apache 2.0, tient sur un seul B300 avec un plancher de 180 Go.

Krikorian a déclaré à Ars Technica par courriel que le choix de payer pour des modèles fermés semble dépendre de la charge de travail plutôt que de l'organisation. L'argent confirme. Les fournisseurs fermés ont capté 96 % des revenus de la couche modèle sur OpenRouter de mai à septembre 2025, selon la Linux Foundation. Mozilla comptait pourtant huit des dix premiers modèles en volume de tokens en août comme poids ouverts, dont sept construits en Chine.

Ce dernier détail compte pour la bataille des licences. Les données de Mozilla s'arrêtent au 1er septembre, et Artificial Analysis a depuis fait passer son indice en v4.3 avec un jeu d'évaluation différent. Les chiffres tracés ne sont donc plus directement comparables au tableau en ligne. La légende du graphique de Mozilla dit : « l'écart se réinitialise à chaque cycle de sortie ». Un décalage de 4,4 mois est un instantané, pas une tendance.

L'angle du droit d'auteur est celui où la documentation manquante coûte cher. Un article de A. Feder Cooper, Mark A. Lemley et coauteurs, déposé sur arXiv et révisé le 20 juillet 2026, a mené plus de 3 000 expériences sur 200 livres et 14 LLM à poids ouverts. La plupart des modèles n'ont pas mémorisé la plupart des livres, en tout ou en partie. Mais Llama 3.1 70B a entièrement mémorisé certains titres, dont Harry Potter and the Sorcerer's Stone, au point que le livre entier peut être extrait presque mot pour mot à partir de ses premiers mots. Les auteurs estiment que le résultat ne favorise aucun camp devant un tribunal.

La querelle d'étiquette n'est donc pas sémantique. Si vous ne voyez pas les données, vous ne pouvez pas auditer ce qu'un modèle a mémorisé, ni reproduire le système qui l'a produit. La formulation de Landay est la plus claire. Les poids ouverts répondent à la question de savoir si vous pouvez exécuter ceci. L'open source répond à celle de savoir si vous pouvez lui faire confiance, l'améliorer et construire la suite dessus.