Audit documentaire du catalogue de modèles ouverts d'Ai2 : état des preuves sur les licences

Introduction : l'importance de la traçabilité juridique dans les modèles ouverts

Dans le développement de systèmes d'intelligence artificielle, la distinction entre la disponibilité technique d'un modèle et sa viabilité juridique pour un usage en production est critique. Pour les organisations qui évaluent des modèles ouverts, la licence du code source n'est pas le seul facteur déterminant ; les conditions dans lesquelles les poids du modèle sont distribués et, fondamentalement, les données d'entraînement, peuvent imposer des restrictions significatives sur l'usage commercial ou la redistribution.

Le cas d'Ai2 est particulièrement pertinent étant donné son accent déclaré sur l'« ouverture totale », qui inclut la publication du code, des données et des poids. Cependant, la vérification de ces affirmations nécessite un examen détaillé des sources primaires en vigueur. Cette pièce analyse quelles informations sont actuellement vérifiables via la documentation officielle et les dépôts publics, en identifiant les domaines où les preuves sont insuffisantes pour émettre un avis juridique définitif.

La traçabilité juridique ne se réduit donc pas à constater qu’un artefact peut être téléchargé ou qu’un dépôt est public. Elle consiste à relier chaque élément utilisé — le code, les poids et les données — à des conditions identifiables, en vérifiant que la déclaration concerne bien l’élément considéré. Une présentation générale de l’ouverture peut décrire une politique de publication, mais elle ne suffit pas, à elle seule, à établir les permissions attachées à chaque composant. Cette distinction permet de décrire précisément ce qui est établi et ce qui demeure à vérifier, sans transformer une lacune documentaire en conclusion sur les droits applicables.

Pour une organisation, l’enjeu est de conserver cette séparation tout au long de l’évaluation. Une conclusion sur le code ne doit pas être transposée aux poids ou aux données lorsque les sources consultées ne déclarent pas explicitement une telle extension. L’état « non vérifié » signifie ici que les extraits examinés ne permettent pas de confirmer les termes applicables ; il ne signifie ni que l’utilisation est interdite, ni qu’elle est automatiquement autorisée. Cette prudence est particulièrement importante lorsque l’évaluation porte sur un usage en production ou dans un environnement réglementé.

Méthodologie de vérification documentaire

Pour auditer le catalogue de modèles d'une organisation, trois niveaux de vérification sont établis : le code d'entraînement et d'inférence, les poids du modèle (model weights) et les ensembles de données d'entraînement. Chacun de ces artefacts peut être soumis à des licences distinctes. La méthodologie consiste à localiser les dépôts officiels et les portails de documentation, et à extraire les déclarations de licence en vigueur au moment de la consultation.

Dans le cas d'Ai2, la documentation officielle pour les développeurs agit comme la porte d'entrée vers l'écosystème. Cette source confirme l'existence de modèles tels que OLMo, Molmo et Tülu, ainsi que d'ensembles de données tels que Dolma et Pixmo. Le profil de l'organisation sur GitHub permet de localiser les dépôts de code associés. La vérification se concentre sur l'identification de savoir si ces sources primaires contiennent des déclarations explicites sur les permissions d'usage, de distribution et de modification.

Cette méthode gagne à traiter séparément les déclarations portant sur l’existence d’une ressource et celles portant sur ses conditions juridiques. Une page qui répertorie un modèle ou un ensemble de données peut aider à établir qu’il fait partie du catalogue présenté, sans nécessairement préciser les droits de redistribution, de modification ou d’utilisation commerciale. De même, la présence d’un fichier de licence dans un dépôt doit être rapportée au contenu que ce fichier régit : le nom du dépôt, les fichiers concernés et la formulation de la licence doivent être suffisamment clairs pour éviter une extension injustifiée à d’autres artefacts.

La vérification doit aussi être rattachée à la version effectivement examinée. Les déclarations peuvent varier selon le dépôt, la documentation propre à un modèle ou l’emplacement où les fichiers sont distribués ; il convient donc de noter la source précise et la date de consultation au lieu de généraliser à l’ensemble du catalogue. Si une information manque dans les éléments consultés, la consignation de cette lacune préserve une distinction utile entre absence de preuve dans l’extrait et preuve d’absence de droits. Cette discipline rend l’audit réexaminable et aide les équipes à déterminer quelles pièces doivent encore être obtenues avant toute décision d’adoption.

État des preuves dans les sources primaires

La révision de la documentation officielle d'Ai2 confirme la politique institutionnelle d'« ouverture totale », qui promet la libération du code, des données, des poids et des recettes d'entraînement. Cette déclaration est un fait vérifiable sur le portail développeurs. Cependant, le texte de la documentation générale ne spécifie pas les licences juridiques exactes qui régissent chacun de ces composants.

Dans le profil GitHub de l'organisation, on observe que plusieurs dépôts de code, tels que 'Olmo-core', 'open-instruct' et 'olmo-eval', sont sous la licence Apache-2.0. Cela permet de vérifier la licence du code d'entraînement et d'inférence pour ces outils. Toutefois, la licence du code ne s'étend pas automatiquement aux poids du modèle ni aux données d'entraînement, qui sont généralement distribués via des plateformes externes ou dans des dépôts spécifiques avec leurs propres termes.

Les éléments vérifiés autorisent ainsi une conclusion circonscrite : les sources décrivent une politique institutionnelle d’ouverture et permettent d’identifier certains dépôts de code assortis de la licence Apache-2.0. Ces constats portent sur des objets et des déclarations distincts. La politique générale indique ce qu’Ai2 affirme vouloir publier ; les fichiers de licence des dépôts identifiés renseignent sur le code concerné. Aucun de ces constats ne fournit, dans les extraits examinés, la licence exacte des poids ou des ensembles de données cités.

Il est donc préférable de conserver des états de preuve séparés plutôt que de qualifier indistinctement tout le catalogue d’« ouvert » au sens juridique. La licence du code peut être vérifiée pour les outils nommés, tandis que le statut des poids d’OLMo, Molmo et Tülu, ainsi que celui de Dolma et Pixmo, reste non vérifié dans les éléments disponibles. Cette formulation n’infère pas de restriction et ne présume pas non plus que les ressources sont libres de conditions : elle décrit uniquement les limites de la documentation effectivement examinée.

Cette séparation aide également à éviter une confusion entre ouverture de publication et permissions d’usage. La publication de code, de données, de poids et de recettes constitue une déclaration sur les ressources rendues disponibles, mais les termes juridiques doivent être établis au niveau des artefacts concernés. Pour les dépôts où Apache-2.0 est indiqué, la conclusion doit rester attachée aux outils correspondants. Pour les autres éléments, une confirmation exige une déclaration applicable à leurs fichiers ou à leur documentation spécifique, qui n’apparaît pas dans les extraits présentés.

Analyse des lacunes dans la documentation

L'une des principales limites à l'audit du catalogue d'Ai2 avec les sources actuelles est le manque d'une déclaration centralisée et explicite sur les licences des poids et des données. La documentation décrit la nature « ouverte » des ressources, mais ne détaille pas les termes juridiques spécifiques, tels que si l'usage commercial est permis sans restrictions supplémentaires ou s'il existe des clauses d'attribution obligatoires.

Cette lacune est critique pour les équipes de conformité juridique. La licence Apache-2.0 du code garantit la liberté d'usage du logiciel d'entraînement, mais ne résout pas la question des données de Dolma (3 billions de tokens) ni des poids d'OLMo. Sans une déclaration claire dans la documentation primaire, il n'est pas possible d'affirmer avec certitude que l'usage commercial est libre de restrictions dérivées de la provenance des données ou des termes de la plateforme de distribution.

L’absence d’une déclaration centralisée rend nécessaire une vérification au niveau de chaque ressource plutôt qu’une déduction à partir d’une page générale. Pour les poids, cela implique de consulter les métadonnées et les conditions associées à la distribution du modèle, puis de vérifier que ces informations concernent bien la version envisagée. Pour les données, il faut examiner la documentation propre à l’ensemble concerné et rechercher les termes applicables aux éléments distribués. Les extraits disponibles ne permettent pas de conclure à l’avance quel sera le résultat de ces vérifications.

La mention de Dolma comme corpus de 3 billions de tokens ne répond pas à la question de sa licence : une caractéristique descriptive de l’ensemble de données ne constitue pas une déclaration de droits. De la même manière, la présence de poids dans un catalogue ne suffit pas à établir les conditions de leur redistribution ou de leur usage. Garder ces questions distinctes évite qu’une description technique, une promesse de publication ou une licence de code soit interprétée comme une autorisation juridique non documentée.

Dans l’exemple d’évaluation commerciale, la démarche ne consiste donc pas à présumer qu’une lacune bloque nécessairement le projet, mais à suspendre la conclusion juridique jusqu’à ce que les informations pertinentes soient vérifiées. L’équipe peut constater la licence du code concerné, relever que les termes des poids et des données ne sont pas établis dans les extraits consultés, puis consulter les informations propres aux ressources et à leur distribution. Si ces vérifications ne fournissent pas de réponse explicite, l’incertitude doit rester documentée au lieu d’être remplacée par une affirmation d’autorisation ou d’interdiction.

Limites des preuves et questions ouvertes

La vérification réalisée avec les sources fournies permet de confirmer l'existence des modèles et la licence du code d'entraînement, mais ne résout pas les questions sur les licences des poids et des données. La documentation officielle agit comme un index de ressources, mais pas comme un contrat juridique détaillé pour chaque artefact.

Les questions suivantes restent ouvertes : Quelle est la licence exacte des poids d'OLMo et Molmo ? Sous quels termes sont distribuées les données de Dolma et Pixmo ? Existe-t-il une documentation officielle qui clarifie la relation juridique entre la licence du code et celle des données ? Jusqu'à ce que ces questions soient répondues par des sources primaires spécifiques (comme des fichiers LICENSE dans les dépôts de poids ou de documentation des données), la traçabilité juridique du catalogue d'Ai2 reste incomplète.

Les questions ouvertes sont liées, mais elles appellent des vérifications distinctes. La licence des poids doit être recherchée dans les informations propres aux modèles et à leurs dépôts de distribution ; les termes de Dolma et Pixmo doivent être établis à partir de la documentation des ensembles de données concernés. La relation entre ces conditions et la licence du code ne peut être affirmée que si une source applicable la précise. En l’absence de telles déclarations dans les extraits fournis, les réponses demeurent inconnues, et cette limite doit être conservée dans toute synthèse destinée à guider une décision.

Une vérification complémentaire devrait enregistrer, pour chaque artefact, l’emplacement de la déclaration, son champ d’application et la version à laquelle elle se rapporte. Ce relevé permettrait de distinguer une licence explicitement attribuée à un modèle ou à un ensemble de données d’une mention générale portant sur le catalogue. Il permettrait aussi d’indiquer clairement si la documentation consultée répond aux questions d’usage, de distribution et de modification, ou si certains de ces points restent sans réponse. Il s’agit d’une manière de rendre les conclusions traçables, non d’un motif pour supposer des termes qui ne figurent pas dans les sources.

Jusqu’à l’obtention de documents spécifiques, le constat prudent demeure que certains dépôts de code sont identifiés sous Apache-2.0, alors que les conditions des poids et des données ne sont pas établies par les extraits examinés. Cette réserve ne constitue ni un avis sur la validité juridique des licences, ni une conclusion définitive sur la possibilité d’un usage commercial. Elle indique simplement que la documentation examinée ne suffit pas à trancher ces points et que la décision doit tenir compte de cette incertitude.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.