Capitole du Libre 2026

Tout ce qu'un modèle « sait » vient des textes lus pendant l'entraînement.
Une IA se choisit donc moins à ses performances qu'à ce qu'on a mis dedans : d'où viennent ces textes, et leurs auteurs avaient-ils autorisé cet usage ?

Y répondre sérieusement suppose une contrainte qu'aucun des grands modèles ne s'impose : tracer l'origine de chaque jeu de données, exclure ceux qui ne sont pas ouverts, refuser les faux ouverts (une licence MIT apposée sur un contenu non commercial n'ouvre rien), appliquer rétroactivement les exclusions déclarées dans les robots.txt. À l'inverse, les modèles fermés ne publient même pas leur nombre de paramètres, ce qui rend toute comparaison sérieuse impossible.

Mais cette exigence a un coût direct : elle restreint mécaniquement la quantité de données disponibles. Du texte à la fois libre de droits, documenté et de qualité, il n'y en a pas tant que ça — et encore moins dès qu'on sort de l'anglais. Pour le français courant, c'est déjà tendu. Pour le français régional, les langues peu dotées, les domaines spécialisés, c'est souvent le vide.

C'est là qu'intervient une pratique aujourd'hui banalisée mais rarement assumée : générer soi-même les données manquantes avec un autre modèle. Les données synthétiques permettent de combler ce que le web n'offre pas — de doter une langue ou un domaine d'un corpus qui n'existait pas, à moindre coût de calcul qu'un entraînement massif sur des données brutes.

Le problème, c'est que cette solution porte en elle son propre risque. Un modèle qui réapprend massivement des textes générés par ses prédécesseurs finit par tourner en rond : il perd en diversité, amplifie ses propres biais et erreurs, jusqu'à un phénomène documenté d'effondrement (« model collapse »). Et le web se remplit lui-même de contenus générés, rendant de plus en plus difficile de savoir, au moment de constituer un corpus « ouvert », ce qu'on y intègre réellement.

La question n'est donc pas d'interdire le synthétique — on ne peut pas rester ouvert et multilingue sans lui — mais de le soumettre à la même exigence de traçabilité que le reste : documenter ce qui a été généré, par quel modèle, avec quel prompt, dans quelle proportion du corpus final. Le dire, plutôt que le nier ou le dissimuler comme le font la plupart des modèles fermés. Cette rigueur a aussi une traduction concrète et sobre : mieux vaut distiller un grand modèle vers un petit, ou générer des données ciblées, que racler le web sans fin — un principe qui rejoint les travaux sur l'IA frugale (référentiel AFNOR, quantisation, réutilisation plutôt que ré-entraînement).

La réponse à cette tension, c'est de traiter le modèle lui-même comme un commun numérique.
Pas un produit que l'on consomme, mais un bien partagé : corpus documenté et redistribué tel qu'utilisé — y compris sa part synthétique et sa méthode de génération —, code d'entraînement publié, poids finaux et intermédiaires ouverts, le tout sous licence libre et gouverné collectivement.
C'est exactement la démarche de la famille de modèles Luciole, portée par OpenLLM France.
Sans cela, une langue, une culture, un domaine n'existera dans les modèles de demain qu'à travers le regard d'un autre — humain ou synthétique — et personne ne pourra vérifier lequel.

Ces choix ont un prix : ils pénalisent les scores sur certains classements, et nous expliquerons pourquoi la traçabilité prime sur le « benchmark ».
Mais le mot coût a deux faces. Un modèle propre et sobre, c'est aussi un modèle que l'on peut faire tourner chez soi, auditer, spécialiser, brancher sur ses propres documents, sans dépendre de personne.
Nous terminerons donc sur ce que l'on peut concrètement en faire, avec la famille de modèles Luciole d'OpenLLM France.