IA « open source » : pourquoi l’ouverture des modèles ne résout pas tous les risques

L’expression « IA open source » est devenue un argument fort dans le débat technologique. Elle évoque un modèle que chacun pourrait examiner, adapter et améliorer, à l’opposé des systèmes entièrement contrôlés par quelques grandes entreprises. Cette ouverture peut effectivement élargir l’accès à l’intelligence artificielle. Elle ne doit toutefois pas faire oublier une réalité essentielle : un modèle disponible n’est pas automatiquement un modèle transparent, vérifiable ou sûr.

À la mi-février 2025, l’essor de modèles proposés par des acteurs comme Mistral ou Meta, ainsi que l’attention portée à DeepSeek, ravive cette discussion. Entre chercheurs, entreprises, administrations et développeurs indépendants, beaucoup voient dans l’ouverture une manière de favoriser l’innovation et de limiter la dépendance à des services distants. Mais les choix qui entourent les données, la licence, la maintenance et le déploiement restent déterminants.

Que signifie vraiment « open source » pour une IA ?

Dans le logiciel traditionnel, l’open source désigne d’abord l’accès au code source, avec une licence qui autorise, selon ses termes, son étude, sa modification et sa redistribution. Pour l’intelligence artificielle, la situation est plus complexe. Un système d’IA moderne repose sur plusieurs briques distinctes : le code, les données, les paramètres du modèle, les méthodes d’entraînement et les outils de mise en production.

Les poids sont les très nombreux paramètres numériques appris pendant l’entraînement. Lorsqu’ils sont publiés, une organisation disposant d’une infrastructure adaptée peut exécuter le modèle, puis éventuellement l’ajuster à son propre cas d’usage. C’est une ouverture importante, mais elle ne donne pas nécessairement accès au jeu de données d’origine, au détail des calculs réalisés pendant l’entraînement ni aux tests internes de sûreté.

Le tableau ci-dessous permet de distinguer les niveaux d’ouverture souvent regroupés, parfois trop rapidement, sous une même étiquette.

Cette distinction compte pour les utilisateurs. Une société qui installe un modèle sur ses propres serveurs peut gagner en maîtrise de ses données opérationnelles. En revanche, elle doit pouvoir assumer l’hébergement, les mises à jour, la surveillance des usages et la correction des failles éventuelles.

Les promesses de l’ouverture : innover, adapter et réduire certaines dépendances

La première force des modèles accessibles est de favoriser l’expérimentation. Une équipe de recherche peut étudier leur fonctionnement. Une PME peut les adapter à son vocabulaire métier. Une administration peut envisager un déploiement sur une infrastructure qu’elle contrôle, plutôt que d’envoyer systématiquement ses requêtes vers un service tiers.

Cette possibilité de personnalisation est particulièrement utile lorsque les données traitées sont sensibles ou lorsque les besoins linguistiques et sectoriels sont spécifiques. L’ouverture peut également encourager l’émergence de services spécialisés : intégration, hébergement, évaluation, outils de sécurité, interfaces de dialogue ou accompagnement des entreprises.

Sur le plan économique, elle contribue à abaisser certaines barrières d’entrée. Il n’est pas indispensable de repartir de zéro pour développer un assistant documentaire ou un outil de classement. Des équipes plus petites peuvent s’appuyer sur des modèles existants, à condition de respecter leur licence et de disposer des compétences nécessaires.

Pour autant, « accessible » ne veut pas dire « gratuit ». Faire fonctionner un modèle demande du matériel, de l’électricité, du stockage, des compétences techniques et du temps. Adapter un modèle à un domaine particulier exige aussi de préparer et de protéger les données utilisées. Le coût se déplace donc souvent de la licence vers l’infrastructure et l’exploitation.

Les communautés de développeurs sont centrales dans ce modèle. Elles contribuent à corriger des erreurs, à produire de la documentation, à partager des méthodes d’évaluation et à créer des outils compatibles. Cette dynamique collaborative peut accélérer les progrès, à condition qu’elle soit organisée et que les responsables du projet répondent aux problèmes signalés.

Pourquoi la transparence reste-t-elle incomplète ?

Le principal malentendu tient à la confusion entre publication d’un modèle et transparence complète. Sans information solide sur les données qui ont servi à l’entraînement, il est difficile de savoir quels contenus le système a appris, quelles langues ou quels contextes sont sous-représentés, et quels biais peuvent se retrouver dans ses réponses.

Un modèle peut ainsi produire des résultats discriminatoires sans qu’une intention discriminatoire ait été inscrite dans son code. Les biais peuvent venir des données disponibles sur internet, de choix de sélection, d’annotations humaines ou de méthodes d’évaluation insuffisantes. Rendre les poids accessibles permet à des tiers de tester le modèle, mais n’efface pas le problème à la source.

La documentation joue ici un rôle décisif. Elle devrait aider les utilisateurs à comprendre :

• les usages pour lesquels le modèle a été conçu ;
• ses limites connues et ses performances mesurées ;
• les langues, domaines ou publics pour lesquels il est moins fiable ;
• les conditions de la licence et les responsabilités de l’utilisateur ;
• les mécanismes prévus pour signaler une vulnérabilité ou une dérive.

La question des données soulève également des enjeux de propriété intellectuelle et de vie privée. Un modèle peut avoir été entraîné sur d’immenses corpus, sans que le public puisse en vérifier exhaustivement la composition. Les utilisateurs qui l’intègrent à un produit ne peuvent donc pas considérer la mention « open source » comme une garantie automatique de conformité juridique.

Les risques de sécurité ne disparaissent pas avec le code ouvert

L’ouverture a une vertu : elle donne à davantage d’experts la possibilité d’examiner un système et d’y repérer des défauts. Dans le monde du logiciel, ce principe a souvent permis de renforcer la sécurité grâce aux audits et aux correctifs collectifs. Mais ce bénéfice n’est pas automatique. Un code public qui n’est ni audité ni entretenu peut rester vulnérable longtemps.

Les modèles d’IA posent une difficulté supplémentaire : ils peuvent être détournés pour produire des contenus trompeurs, automatiser des opérations malveillantes ou faciliter des fraudes. Une diffusion large augmente le nombre de personnes capables d’expérimenter le modèle, y compris à des fins nuisibles. À l’inverse, fermer entièrement un modèle ne supprime pas les abus possibles. Le sujet est donc celui d’un équilibre entre diffusion des connaissances et mesures de prévention.

Pour les entreprises, le risque le plus immédiat est souvent moins spectaculaire : il concerne les données saisies dans l’outil. Héberger un modèle en interne peut limiter l’exposition à un prestataire extérieur, mais seulement si l’environnement est correctement sécurisé. Les droits d’accès, les journaux d’activité, le cloisonnement des données et les mises à jour restent indispensables.

Réglementer sans décourager la recherche

L’idée selon laquelle les modèles ouverts évolueraient hors de tout cadre légal est trompeuse. En Europe, le règlement sur l’intelligence artificielle, connu sous le nom d’AI Act, est entré en vigueur le 1er août 2024. Certaines de ses dispositions, notamment des interdictions de pratiques jugées inacceptables, s’appliquent depuis le 2 février 2025. Les obligations relatives aux modèles d’IA à usage général doivent, elles, s’appliquer à partir du 2 août 2025.

Le texte européen reconnaît la spécificité de certains modèles distribués sous licence libre et open source. Il prévoit des aménagements, mais ceux-ci ne constituent pas une exemption générale. La diffusion ouverte ne dispense pas automatiquement de prendre en compte les droits d’auteur, la sécurité, la protection des données ou les risques graves associés à un modèle puissant.

La réglementation doit répondre à plusieurs questions concrètes : qui répond d’un dommage quand un modèle est adapté et redistribué par de multiples acteurs ? Quelles informations doivent accompagner un modèle afin que ses utilisateurs puissent en mesurer les limites ? Comment rendre les évaluations comparables ? Et comment éviter que des contraintes disproportionnées empêchent les chercheurs, les petites structures et les communautés de contribuer ?

Les pouvoirs publics ne sont pas les seuls concernés. Les entreprises qui mettent un outil sur le marché, même lorsqu’il repose sur un modèle accessible, gardent une responsabilité dans son paramétrage et dans la protection de leurs clients. Elles doivent notamment définir les usages autorisés, tester l’outil dans son contexte réel et prévoir une supervision humaine lorsque les conséquences d’une erreur peuvent être importantes.

La durabilité, angle mort des projets d’IA ouverts

Publier un modèle n’est que le début de son existence. Les modèles vieillissent : de nouvelles vulnérabilités apparaissent, les bibliothèques logicielles évoluent, les besoins des utilisateurs changent et de meilleurs systèmes peuvent les rendre moins compétitifs. Sans maintenance, documentation et gouvernance, un projet initialement prometteur peut devenir difficile à utiliser ou risqué à déployer.

Cette question est aussi environnementale et matérielle. L’entraînement et l’exécution des grands modèles nécessitent des ressources de calcul considérables. Des projets tels que DeepSeek illustrent l’intérêt porté à des modèles cherchant à rester économes en ressources tout en étant accessibles. L’efficacité ne se résume pas à un seul indicateur : il faut considérer la taille du modèle, la qualité du matériel requis, l’usage réel et la fréquence des requêtes.

La pérennité suppose également un modèle de financement. Certaines entreprises peuvent proposer des modèles accessibles tout en vendant de l’hébergement, du support, des services d’intégration ou des offres professionnelles. Cela peut soutenir la maintenance, mais rappelle que l’écosystème de l’IA ouverte n’est pas uniquement bénévole.

L’initiative Current AI, qui entend soutenir des infrastructures et des projets d’intérêt général liés à l’IA, s’inscrit dans cette recherche de coopération entre développeurs, chercheurs, entreprises et pouvoirs publics. De tels dispositifs peuvent aider à structurer des ressources partagées, à condition que leurs règles de gouvernance soient claires et que les contributions soient réellement accessibles.

Ce qu’il faut surveiller pour faire de l’IA ouverte un choix responsable

La compétition entre acteurs propriétaires et acteurs qui diffusent leurs modèles devrait continuer à diversifier l’offre. Pour les utilisateurs, le bon choix ne se résumera pas à comparer une taille de modèle ou la gratuité apparente d’un téléchargement. Il faudra examiner le niveau réel d’ouverture, la licence, le coût d’exploitation, la qualité de la documentation et la capacité à gérer les incidents.

L’hébergement sur des infrastructures maîtrisées, y compris des infrastructures souveraines, est également appelé à prendre de l’importance. Il peut renforcer le contrôle sur les données et réduire la dépendance à certains services tiers. Il ne dispense cependant ni de sécuriser les systèmes ni de former les personnes qui les utilisent.

Le débat sur l’IA « open source » ne se joue donc pas entre ouverture totale et fermeture totale. Son enjeu est de créer les conditions d’une ouverture utile : des modèles auditables autant que possible, des limites clairement expliquées, des communautés actives, des mécanismes de correction et des règles proportionnées aux risques. C’est à ce prix que l’accessibilité technologique pourra renforcer la confiance plutôt que déplacer les problèmes vers les utilisateurs finaux.