Quand l’IA open source n’est pas vraiment open

De nombreux modèles d’IA qualifiés d' »open source » ne respectent pas les véritables normes en la matière.

Lorsque les entreprises qualifient leurs modèles d’IA d' »open source », la plupart du temps, elles manquent de transparence. Vous voyez l’étiquette, mais vous n’avez pas une vue d’ensemble. Les données d’entraînement ne sont pas divulguées. Les poids sont verrouillés. Les licences comportent de vagues restrictions. Et pourtant, ces modèles sont publiquement présentés comme « ouverts ». Ce n’est pas ainsi que fonctionne l’open source.

Mike Lieberman, directeur technique de Kusari, l’a dit clairement : de nombreux modèles dits ouverts ne vous disent pas ce que contiennent les données d’apprentissage, qui peuvent inclure des documents protégés par le droit d’auteur ou biaisés. Si vous déployez l’un de ces modèles et que les données s’avèrent problématiques, d’un point de vue légal ou éthique, vous ou votre entreprise pourriez en assumer la responsabilité. Dans les modèles à source fermée, ce risque incombe en grande partie au fournisseur. Avec les modèles ouverts, il est partagé, voire entièrement assumé.

Ce n’est pas une hypothèse. Une étude a examiné plus de 40 modèles de langage de grande taille (LLM) et a constaté que très peu d’entre eux pouvaient être considérés comme véritablement open source, quelle que soit la définition acceptée. La plupart manquaient de transparence en ce qui concerne les données, les méthodes de pondération ou même les droits d’utilisation. C’est un signal d’alarme.

Si vous dirigez une entreprise et envisagez d’intégrer l’IA générative, prenez cette question au sérieux. Ne partez pas du principe que l’open source est synonyme d’innocuité, voire de légalité. Il s’agit de propriété intellectuelle, de risque de réputation et de viabilité à long terme. Avant d’intégrer une IA « ouverte » dans votre pile, vérifiez la transparence du modèle. Effectuez un véritable audit de licence. Sachez sur quoi vous vous appuyez.

La définition de l' »IA open source » reste ambiguë et peu développée

L’IA ne correspond pas au schéma traditionnel de l’open source. Dans un logiciel classique, vous pouvez publier le code source, permettre à d’autres de le modifier, le partager, et c’est à peu près tout. Avec l’IA, la valeur réside également dans ce que vous donnez au modèle, dans les données et dans la manière dont vous l’entraînez. Cela signifie que vous ne pouvez pas juger de l’ouverture sur la seule base du code.

Il n’existe pas encore de norme universelle. L’Open Source Initiative (OSI) s’efforce de définir des normes en matière d IA open source avec la version 0.0.8 de sa spécification évolutive. Son projet actuel souligne que le code source, les paramètres du modèle et la documentation de formation doivent être disponibles pour que le modèle soit considéré comme open source. Mais, et c’est là un point essentiel, les ensembles de données d’entraînement sont laissés en option. C’est un problème.

Marcus Edel, responsable de l’apprentissage automatique chez Collabora, affirme que la véritable source ouverte comprend tout : les données, le code, les poids, tout. Paul Harrison, de Mattermost, ajoute que le contenu doit être légalement propre, open source, sous licence Creative Commons ou explicitement approuvé. Dans le cas contraire, vous vous exposez à des risques juridiques et à une fragmentation de la communauté.

Nathan Lambert, scientifique chez AI2, reconnaît la confusion que cela crée sur le marché. Roman Shaposhnik, cofondateur d’Ainekko, propose une solution : revenir à une véritable collaboration. Pour lui, l’open source n’est pas seulement un accès, c’est une participation. À l’heure actuelle, la plupart des modèles d’IA sont élaborés par des fournisseurs uniques, à l’aide d’une infrastructure interne, avec un accès limité aux contributeurs. Ce n’est pas de l’open source. Il s’agit d’un développement fermé, enveloppé dans un label ouvert.

Pour les dirigeants, voici ce qu’il faut retenir : ne vous fiez pas à l’étiquette. Définissez en interne ce que l’open source signifie pour votre organisation et comment il s’aligne sur votre profil de risque juridique et technique. Si les données ne sont pas ouvertes et que la communauté ne peut pas y contribuer, elles ne sont pas vraiment ouvertes et vous ne devriez pas miser sur des produits de base sans savoir où se trouvent les coutures.

De nombreux modèles d’IA fondamentaux présentés comme des logiciels libres sont en contradiction avec les pratiques traditionnelles en matière de logiciels libres.

Un grand nombre des modèles d’IA les plus puissants commercialisés aujourd’hui comme étant « ouverts » sont construits derrière des portes closes. Les entreprises développent ces systèmes en interne, souvent en utilisant des ensembles de données propriétaires et des infrastructures de calcul exclusives. Le résultat est un produit qui semble ouvert en surface mais qui ne correspond pas à ce que l’open source signifie réellement dans le développement de logiciels : la transparence, la reproductibilité et une large collaboration avec la communauté.

Nathan Benaich et Alex Chalmers d’Air Street Capital ont été clairs à ce sujet. Ils soulignent que les modèles de base proviennent généralement d’équipes centrales qui exercent un contrôle étroit. Le nombre de contributeurs est limité. La participation externe est souvent bloquée ou fortement verrouillée. Le processus de développement n’est pas transparent et il n’y a que peu ou pas de vérification indépendante de ce qui se trouve sous le capot.

Il est donc difficile de faire confiance à ces modèles dans les environnements critiques. Vous ne pouvez pas facilement vérifier comment ils ont été construits, quelle est la provenance réelle des données ou qui a influencé les résultats. Pour les entreprises qui intègrent l’IA à grande échelle, il s’agit là d’un signal pour prendre du recul et réévaluer la situation. Si votre activité dépend d’un modèle, vous devez savoir exactement comment il fonctionne et à partir de quoi il a été construit.

Si vous occupez un poste de direction et que vous évaluez des modèles en vue d’une intégration, voire d’une utilisation interne, posez des questions sur l’accès. Posez des questions sur les contributeurs. Qui l’a formé ? Avec quelles ressources ? Qui d’autre a validé ces résultats ? Il ne s’agit pas d’un simple contrôle préalable. Il s’agit d’une exigence de base. Vous ne mettriez pas en place des systèmes financiers sans comprendre leur fonctionnement. Faites de même avec l’IA.

Les risques liés à l’utilisation de l’IA prétendument open source reposent sur la transparence et la complexité des licences.

Lorsque la licence d’un modèle n’est pas claire ou restrictive, il ne s’agit pas seulement d’un inconvénient juridique, mais aussi d’un risque commercial. De nombreux modèles « ouverts » comportent des limitations intégrées dans leurs conditions d’utilisation, qui peuvent restreindre le déploiement commercial, limiter l’échelle ou même empêcher certains secteurs de les utiliser. Si vous ne connaissez pas ces conditions, vous risquez d’enfreindre sans le savoir les termes de la licence ou de mettre votre entreprise en péril sur le plan juridique.

Prenez LLaMa 2 de Meta : il n’est pas vraiment ouvert, même s’il est annoncé comme tel. Sa licence interdit spécifiquement son utilisation à toute entreprise comptant plus de 700 millions d’utilisateurs actifs mensuels. Cela signifie que si vous êtes à l’échelle, vous n’y avez pas accès, quelles que soient vos capacités techniques ou votre utilisation commerciale. Ces restrictions sont subtiles, mais elles sont importantes. Stefano Maffulli, de l’OSI, considère ces limitations déguisées comme un problème majeur. Les entreprises supposent qu’elles sont ouvertes, mais se font surprendre par des dispositions restrictives par la suite.

Mike Lieberman, de Kusari, explique que l’ambiguïté de l’ouverture crée un risque en aval. Les fournisseurs peuvent se protéger, mais lorsque vous affinez ce modèle ou que vous l’intégrez dans vos systèmes, l’exposition se déplace vers vous. Vous êtes désormais potentiellement responsable des lacunes de licence non détectées ou de l’utilisation abusive de données restreintes. Roman Shaposhnik prévient que ces responsabilités ne sont pas uniformément réparties. Dès que vous vous lancez dans la mise au point personnalisée, vous êtes seul en termes de protection juridique.

Si vous êtes un cadre qui approuve les déploiements d’IA, mettez en place un processus de validation des licences. N’acceptez pas de garanties générales. Demandez au service juridique de vérifier chaque clause. Assurez-vous que votre équipe de conformité comprend l’impact de la licence sur la mise à l’échelle à long terme. Et assurez-vous que votre équipe d’ingénieurs peut expliquer exactement d’où proviennent les données d’entraînement et les poids. Un examen minutieux aujourd’hui vous permettra d’éviter des dommages juridiques et de réputation à l’avenir.

L’IA open source offre des avantages considérables en termes de transparence, de collaboration et d’amélioration de la sécurité.

Lorsque les modèles d’IA sont réellement ouverts, c’est-à-dire que non seulement le code, mais aussi les données d’entraînement, les paramètres et la documentation sont disponibles, la sécurité s’améliore rapidement. Un plus grand nombre d’yeux formés sur le modèle signifie une identification plus rapide des failles, des biais et des vulnérabilités cachées. Ce type de transparence ne peut pas être reproduit dans des modèles fermés.

Mike Lieberman, directeur technique de Kusari, a expliqué qu’avec le libre accès, les organisations peuvent évaluer et corriger les informations ou les biais dans les données de formation, ce que les modèles propriétaires ne permettent pas. Cela est particulièrement important dans les secteurs réglementés ou dans les régions où les normes éthiques ou juridiques diffèrent de celles des créateurs du modèle.

Au-delà de la correction des erreurs, la collaboration open source raccourcit les cycles d’innovation. Les équipes peuvent éviter la duplication du travail en s’appuyant sur les contributions de la communauté au lieu de réinventer constamment l’architecture et le pipeline. Elle permet également de réduire l’impact sur l’environnement du recyclage de modèles à grande échelle lorsque des points de contrôle ouverts ou des versions adaptées sont déjà disponibles.

Leonard Tang, cofondateur de Haize Labs, a déclaré que la visibilité publique devient elle-même une forme d’assurance qualité. Lorsque davantage de développeurs inspectent la base de code et les processus de formation, la fiabilité augmente naturellement. Les dirigeants qui cherchent à construire des systèmes d’IA fiables devraient donner la priorité aux modèles ouverts, non pas pour réaliser des économies, mais parce que la transparence permet d’obtenir des avantages sur le plan technique et sur celui de la conformité.

L’évaluation de l’IA open source nécessite un examen approfondi des licences, de la provenance des données et du comportement des modèles.

Vous ne pouvez pas simplement déployer un modèle d’IA open source et supposer qu’il est sûr ou légal. Ce n’est pas comme les bibliothèques open source traditionnelles dont l’utilisation est bien documentée depuis des années. Ces LLM sont nouveaux, volumineux et souvent assemblés à partir de multiples composants inconnus. Avant d’en mettre un en production, vous devez vérifier son origine, confirmer son intégrité et tester son comportement.

La licence est le point de départ. Selon Mike Lieberman, les responsables de l’ingénierie doivent examiner non seulement la licence du code, mais aussi toutes les conditions s’appliquant aux poids des modèles et aux paramètres pré-entraînés. Ces licences peuvent inclure des limites à l’utilisation commerciale ou intégrer des obligations incompatibles avec votre produit ou votre clientèle. Stefano Maffulli, directeur exécutif de l’OSI, souligne l’importance de vérifier la provenance des données : d’où elles viennent, comment elles ont été collectées et si elles contiennent des données personnelles ou protégées par des droits d’auteur.

L’évaluation du comportement du modèle est tout aussi importante. Paul Harrison de Mattermost conseille de surveiller de près les résultats du système pour en valider l’exactitude et d’informer les utilisateurs sur l’incertitude des résultats générés par l’IA. Si vous hébergez vous-même le modèle, sécurisez votre pipeline d’entrée. Utilisez des données approuvées. Nettoyez vos journaux. Empêchez les sources mal filtrées d’affaiblir votre modèle.

Nathan Lambert, d’AI2, fait remarquer qu’il est particulièrement important de retracer l’historique des données si le modèle touche à des contenus personnels ou sensibles. La provenance n’est pas facultative, elle est essentielle à tout déploiement responsable ou conforme de l’IA.

Pour les responsables de haut niveau, l’action à entreprendre est simple : intégrez cet examen minutieux dans votre processus d’évaluation. Établissez une liste de contrôle comprenant un examen juridique, une vérification des données et une évaluation de la sécurité avant de passer à la production. En traitant l’adoption de modèles d’IA avec le même niveau de gouvernance que toute autre infrastructure critique, vous réduisez votre exposition et améliorez votre effet de levier à long terme.

Il est urgent d’améliorer la gouvernance et de clarifier les définitions.

L’IA open source se développe rapidement dans tous les secteurs, mais les cadres réglementaires et de gouvernance n’ont pas suivi. L’Administration nationale des télécommunications et de l’information (NTIA) des États-Unis, dans son rapport de juillet 2024, l’a clairement souligné. Elle a identifié des risques critiques liés à l’accès libre aux poids de modèle de fondation, des risques concernant la sécurité nationale, la vie privée, les droits civils et les abus qui ne peuvent pas être traités avec les structures de surveillance actuelles.

Cela ne signifie pas qu’il faille restreindre l’IA open source. Cela signifie que l’industrie a besoin d’une voie structurée pour garantir la responsabilité, la sécurité et la transparence, que les modèles soient ouverts ou non. Paul Harrison, de Mattermost, est favorable à une gouvernance accrue, mais il est explicite quant à la méthode : il faut éviter d’imposer des charges déraisonnables aux responsables des logiciels libres. Ils n’ont pas les ressources des fournisseurs commerciaux, et leur demander de résoudre la question de la gouvernance à eux seuls est inefficace.

Mike Lieberman, directeur technique de Kusari, propose une solution. Au lieu de rejeter la responsabilité sur les communautés de projet, financez-les et équipez-les d’outils, comme le projet GUAC de l’OpenSSF, pour tracer et gérer les chaînes d’approvisionnement en logiciels. Ces outils donnent aux mainteneurs et aux adoptants la visibilité nécessaire pour comprendre ce que contient un modèle, comment il se comporte et s’il est conforme à la politique interne ou à la législation externe.

L’absence de définition juridique claire entraîne également une répartition inégale des risques entre les développeurs, les vendeurs et les utilisateurs. Roman Shaposhnik, d’Ainekko, souligne que tant que l’industrie n’aura pas établi une norme claire et fiable sur ce qui est considéré comme de l’IA open source, l’ambiguïté juridique persistera, ce qui sapera la confiance dans l’adoption de l’IA.

Pour les dirigeants, cette feuille de route est simple. N’attendez pas que la réglementation vous force la main. Investissez tôt dans la gouvernance, alignez les achats sur des normes transparentes et poussez vos fournisseurs à assurer la traçabilité de toutes les couches de leurs modèles d’IA. La clarté réglementaire arrive. Les entreprises qui prennent aujourd’hui l’initiative en matière de sécurité, de conformité et de transparence seront celles qui façonneront l’évolution future de cette technologie.

En conclusion

Si vous prenez des décisions concernant l’adoption de l’IA, ne vous laissez pas distraire par l’étiquette « open source ». Il ne signifie pas toujours ce qu’il devrait signifier et, dans ce domaine, les définitions floues créent un véritable risque commercial. L’ambiguïté juridique, les données d’entraînement cachées et les licences incohérentes ne sont pas des problèmes théoriques. Il s’agit de responsabilités opérationnelles.

Les avantages sont évidents : la transparence favorise la confiance, améliore la sécurité et stimule l’innovation grâce à l’apport de la communauté. Mais ce potentiel s’accompagne d’une obligation de rendre des comptes. En tant que responsable, vous devez poser des questions difficiles. Les données du modèle sont-elles traçables ? Les conditions de la licence sont-elles acceptables ? Votre équipe peut-elle expliquer comment le modèle a été formé et par qui ?

L’IA open source peut constituer un avantage stratégique, mais seulement si elle est gouvernée de manière intentionnelle. La clarté, la vérification et les normes internes sont ce qui distingue les systèmes performants et conformes de ceux qui accumulent tranquillement les risques. Les modèles que vous choisissez aujourd’hui façonneront votre pile technologique et votre exposition pendant des années. Choisissez avec précision.