Open Source et IA : les apports du Règlement sur l’Intelligence Artificielle européen

16 avril 2026

Le recours à l’intelligence artificielle (IA) soulève des enjeux juridiques, éthiques et sociétaux majeurs, auxquels les législateurs tentent de répondre par de nouveaux cadres réglementaires. L’Union européenne s’est dotée du Règlement (UE) 2024/1689 sur l’Intelligence Artificielle (RIA) (ci-après « RIA » ou « AI Act »), qui accorde un régime dérogatoire aux systèmes d’IA Open Source, mais avec des formulations qui révèlent une interprétation étroite de ce qu’est l’« Open Source » en matière d’IA.

Autour de la série de trois articles « Open Source et IA », inno3 propose une analyse du RIA, de son impact sur l’écosystème Open Source aboutissant à des pistes d’actions à implémenter.

Dans ce premier article « Open Source et IA : les apports du Règlement sur l’Intelligence Artificielle européen », il s’agit de donner quelques repères clefs sur la place de l’Open Source dans ce Règlement autour des modèles d’IA à usage général (GPAI) et des systèmes d’IA.
Dans le deuxième article « Open Source et IA : trois règlements européens, trois logiques et un écosystème« , l’objectif est de replacer le RIA dans un contexte plus large d’un ensemble de régulations européennes (NPLD, CRA, etc.) et d’analyser leurs impacts sur l’écosystème Open Source européen et dans ses dynamiques internationales.
Dans le dernier article « Open Source et IA : de quoi parle-t-on vraiment ?« , il s’agit d’une part de revenir sur les différentes définitions à l’œuvre sur une IA « open », leurs points de divergence et d’autre part de proposer des pistes d’actions à implémenter.

Ce qu’il faut retenir

Les systèmes d’IA libres et ouverts sont exclus du champ d’application du RIA en droit, mais cette exclusion est largement formelle : les obligations de conformité au droit d’auteur (art. 53(1)(c)) et de publication d’un résumé des données d’entraînement (art. 53(1)(d)) demeurent, créant un régime hybride.

Le RIA définit l’« Open Source » comme l’accès au code, aux paramètres et à l’architecture sous licence libre et ouverte — une définition minimaliste qui ne garantit ni l’accessibilité des données d’entraînement, ni la possibilité concrète de réplication des modèles.

La définition retenue ouvre la porte au phénomène d’« open washing » : publication de modèles prétendument ouverts (LLaMA, Mistral 7B-Instruct) tout en imposant des clauses d’utilisation restrictives qui contredisent la philosophie du libre et ouvert.

L’obligation principale subsiste donc : respecter les droits d’auteur dans la construction des données d’entraînement, et documenter ces données de manière transparente. Les obligations existent depuis août 2025, mais l’exercice du pouvoir de sanction de la Commission ne prendra effet qu’à partir d’août 2026.

L’Union européenne s’est dotée du Règlement (UE) 2024/1689 du Parlement européen et du Conseil du 13 juin 2024 établissant des règles harmonisées concernant l’intelligence artificielle (ci-après « RIA » ou « AI Act »), entré en vigueur le 1er août 2024, et dont les différentes dispositions s’appliquent de manière progressive entre février 2025 et août 2027 (avec notamment un jalon en août 2026). Ce règlement s’inscrit dans un ensemble réglementaire européen plus large touchant au numérique et affectant l’écosystème du logiciel libre et Open Source. Il s’ajoute et complémente ainsi le Règlement (UE) 2024/2847 sur la cyber-résilience (voir le guide CRA) ainsi que la Directive (UE) 2024/2853 relative à la responsabilité du fait des produits défectueux (voir notre analyse NPLD). Le présent billet poursuit cette série en examinant spécifiquement le traitement de l’IA open source par le RIA.

La question de l’ouverture en matière d’IA est devenue un sujet central du débat politique et technique. Le terme « IA Open Source » est utilisé de manière croissante (et souvent imprécise) pour décrire des réalités très différentes, allant de la simple mise à disposition des poids d’un modèle (« open weights » — c’est-à-dire le résultat de l’entraînement) à la publication intégrale du code, des données d’entraînement et de la documentation scientifique (sans quoi aucune démarche de réplicabilité n’est possible). Cette confusion terminologique a été largement documentée. Ainsi, Liesenfeld et Dingemanse (2024), dans leur étude « Rethinking open source generative AI: open-washing and the EU AI Act » portant sur 45 modèles d’IA générative, démontrent que la majorité des modèles se présentant comme « Open Source » ne rendent publics qu’une fraction de leurs composants. Cette tendance est confirmée à l’échelle de la plateforme HuggingFace par Osborne, Ding et Kirk (2024), qui révèlent que 64,67 % des modèles hébergés sont publiés sans licence ou sous licence restrictive.

En réaction aux débats qui se tenaient au Parlement européen, au moins deux acteurs réputés de l’Open Source se sont mobilisés dès 2024 pour tenter de clarifier ces notions : l’Open Source Initiative (OSI) au travers de l’Open Source AI Definition (OSAID 1.0) et la Linux Foundation qui a proposé le Model Openness Framework (MOF), un cadre de classification à trois niveaux évaluant l’ouverture selon 17 critères. Ces travaux communautaires sont d’autant plus importants que la genèse du texte du RIA a amené celui-ci à adopter sa propre définition de l’ouverture, qui ne coïncide ni avec l’OSAID ni avec les critères du MOF.

Ce premier article vise à confronter la réglementation actuelle de l’IA et les pratiques (industrielles et communautaires) de l’Open Source, afin d’en comprendre les enjeux et d’apporter des éléments de réponse. Il est décomposé en deux temps : le rappel du cadre de l’IA en Europe et l’analyse du traitement spécifique réservé à l’IA Open Source. Les limites ainsi que l’articulation avec les autres réglementations sont abordés dans d’autres articles complémentaires.

Cadre juridique du RIA : entre encadrement et innovation

Contexte, objectifs et enjeux du Règlement

Publié deux ans après l’ouverture grand public de ChatGPT, le RIA répond à l’essor rapide et l’intégration croissante des nouvelles technologies d’IA et d’IA génératives dans tous les secteurs. Il comprend un certain nombre de mesures destinées à couvrir les besoins urgents : protéger les citoyennes et citoyens européens contre les risques liés aux biais algorithmiques, à l’opacité des systèmes, et aux usages abusifs pouvant porter atteinte aux droits fondamentaux.

Cette architecture se veut « technologiquement neutre » et proportionnée : le législateur européen entend encadrer les usages à risque sans freiner l’innovation. Le considérant 2 du RIA souligne que le règlement vise à promouvoir « le développement et l’adoption de systèmes d’IA sûrs et dignes de confiance » tout en garantissant « un niveau élevé de protection de la santé, de la sécurité et des droits fondamentaux ».

Le texte introduit ainsi une approche fondée sur les risques (risk-based approach), classant les systèmes d’IA en quatre niveaux : risque inacceptable (pratiques interdites, article 5), risque élevé (systèmes à haut risque, Annexe III et produits réglementés), risque limité (obligations de transparence, article 50) et risque minimal (aucune obligation spécifique). Il invite ainsi les acteurs privés à intégrer une culture du risque et de la conformité (logique anglo-saxonne de la conformité que le RGPD a déjà pleinement reprise). À cela se greffe un régime spécifique pour les modèles d’IA à usage général (GPAI), traité au Chapitre V du règlement.

Le RIA régule ainsi deux objets distincts et interconnectés :

Les modèles d’IA à usage général ou GPAI (également désignés modèles de base ou foundation models) sont les modèles sous-jacents, puissants et polyvalents, sur lesquels reposent les différents systèmes d’IA.
Les systèmes d’IA sont des applications construites sur un modèle d’IA dans une finalité spécifique (chatbot médical, système de recrutement, outil de notation de crédit, etc.).

Les modèles d’IA à usage général

Le règlement ne définit pas la notion de modèle d’IA en tant que tel, ainsi faut il déduire de la lecture du RIA qu’un modèle d’IA se compose de l’architecture du modèle, des paramètres du modèle (y compris les poids) et du code d’inférence permettant d’exécuter le modèle.

Se concentrant sur les modèles les plus sujets à dérive, le RIA ne s’intéresse qu’à certains modèles d’IA, dit modèles d’IA à usage général (article 3.63) :

« un modèle d’IA, y compris lorsque ce modèle d’IA est entraîné à l’aide d’un grand nombre de données utilisant l’auto-supervision à grande échelle […] » : la précision vise à s’assurer que les grands modèles d’IA soient inclus dans le champ d’application, même s’ils sont entraînés d’une manière différente des modèles d’IA « classiques » (en l’absence de supervision humaine et avec des quantités massives de données et des capacités de calcul colossales) ;
« qui présente une généralité significative et est capable d’exécuter de manière compétente un large éventail de tâches distinctes, »
« indépendamment de la manière dont le modèle est mis sur le marché, et qui peut être intégré dans une variété de systèmes ou d’applications en aval, à l’exception des modèles d’IA utilisés pour des activités de recherche, de développement ou de prototypage avant leur mise sur le marché; »

Les Lignes directrices de la Commission du 18 juillet 2025 sur la portée des obligations des fournisseurs de modèles GPAI précisent cette définition. Pour qu’un modèle soit qualifié de GPAI, il doit réunir deux conditions cumulatives : un caractère général significatif (capacité à exécuter de manière compétente un large éventail de tâches distinctes) et un entraînement à grande échelle. Un modèle limité à des tâches étroites (transcription vocale, amélioration d’image) n’est pas un GPAI, même s’il utilise des techniques d’entraînement à grande échelle.

Le RIA distingue par ailleurs les GPAI « ordinaires » des GPAI à risque systémique (article 51) soumis à des obligations plus importantes. Un modèle GPAI est présumé présenter un risque systémique lorsque la puissance de calcul cumulée utilisée pour son entraînement dépasse 10²⁵ FLOP (opérations en virgule flottante). Cette présomption peut être renversée ou étendue par la Commission. Une dizaine de fournisseurs dans le monde dépassent actuellement ce seuil (OpenAI, Google, Meta, Anthropic, xAI, DeepSeek, entre autres).

Les systèmes d’IA (SIA)

Un système d’IA est défini par le Règlement comme « un système automatisé qui est conçu pour fonctionner à différents niveaux d’autonomie et peut faire preuve d’une capacité d’adaptation après son déploiement, et qui, pour des objectifs explicites ou implicites, déduit, à partir des entrées qu’il reçoit, la manière de générer des sorties telles que des prédictions, du contenu, des recommandations ou des décisions qui peuvent influencer les environnements physiques ou virtuels » (article 3.1) ;
Un système d’IA à usage général est quant à lui défini comme « système d’IA qui est fondé sur un modèle d’IA à usage général et qui a la capacité de répondre à diverses finalités, tant pour une utilisation directe que pour une intégration dans d’autres systèmes d’IA » (article 3.66).

Conformément à la classification par niveaux de risque présentée ci-dessus, les SIA font l’objet d’obligations différenciées. Les systèmes à risque inacceptable (par ex. exploitation de vulnérabilité des personnes) sont interdits, les SIA à haut risque (par ex. dans le médical) font l’objet de la réglementation la plus stricte (domaines sensibles : éducation, emploi, services publics, justice, dispositifs médicaux), les systèmes à risque limité (chatbot) doivent respecter certaines obligations de transparence, et les systèmes à risque minimal (par ex. correcteur orthographique) ne sont pas encadrés par des obligations spécifiques.

Les acteurs concernés par le Règlement

Le RIA prévoit des obligations spécifiques à chaque type d’opérateur intervenant sur la mise à disposition d’un système d’IA ou encore d’un modèle d’IA à usage général.

Acteur	Définition	Obligations principales
Fournisseur	Personne physique ou morale qui développe un SIA ou un modèle GPAI et le met sur le marché ou le met en service sous son propre nom	Conformité technique, documentation, tests de sécurité, système de gestion des risques
Distributeur	Acteur qui commercialise un produit contenant un SIA déjà mis sur le marché par le fournisseur	Vérification de conformité, respect de la documentation fournie
Importateur	Acteur qui importe des produits contenant un SIA de pays tiers sur le marché européen	Vérification de conformité, assurance du respect des obligations du fournisseur
Déployeur	Personne physique ou morale utilisant un SIA (notamment un SIA à haut risque) dans un contexte professionnel ou pour un service	Surveillance du fonctionnement, documentation d’utilisation, conformité aux obligations spécifiques

Par ailleurs, l’article 25 du Règlement consacre la responsabilité (au même titre qu’un fournisseur) de tout opérateur intervenant tout au long de la chaîne de valeur d’un système d’IA à haut risque s’il 1) commercialise en son propre nom un système d’IA à haut risque déjà mis sur le marché, ou qu’il 2) apporte une modification substantielle à un système d’IA à haut risque déjà mis sur le marché ; ou encore 3) modifie la destination d’un système d’IA, y compris à usage général, de telle manière que le système d’IA concerné devient un système d’IA à haut risque.

Enfin, les fournisseurs et déployeurs de systèmes à haut risques ou à risques limités sont soumis à des obligations de transparence (article 50) importantes :

Les utilisateurs doivent être informés lorsqu’ils interagissent directement avec un système d’IA ;
Les utilisateurs doivent être informés qu’ils sont exposés à un système de reconnaissance des émotions ou d’un système de catégorisation biométrique ;
Tous les contenus créés ou modifiés par l’IA (images, vidéos, textes ou sons) doivent l’indiquer ;
Les articles d’actualité rédigés par IA doivent le mentionner, à moins qu’un journaliste humain n’ait relu et validé le contenu.

Le RIA organise ainsi les SIA selon le niveau de risque qu’ils présentent, et prévoit des responsabilités spécifiques pour les opérateurs intervenant dans la mise à disposition du public de ces SIA. Cette structure juridique crée un cadre où l’Open Source occupe une place particulière.

L’Intelligence Artificielle Open Source au sein du RIA

La proposition initiale de la Commission européenne d’avril 2021 ne contenait aucune disposition sur les modèles d’IA à usage général (GPAI), le texte originel se concentrant exclusivement sur les systèmes d’IA. L’irruption des grands modèles de langage (pour rappel ChatGPT en novembre 2022) et la prise de conscience de leur impact ont conduit le Parlement européen et le Conseil à greffer le Chapitre V sur les modèles GPAI lors des trilogues de fin 2023 (y compris l’ajout d’un bureau de l’IA chargé de la supervision de ce chapitre). Ainsi, si l’exclusion des systèmes d’IA Open Source figurait dans le texte dès les premières versions, le régime d’allègement pour les modèles GPAI (article 53(2)) a été conçu dans l’urgence en s’appuyant sur les concepts des licences logicielles existantes pour définir l’ouverture en matière d’IA. Cette intégration n’est pas des plus fluides, l’IA interrogeant et réinventant la notion même d’Open Source.

Le RIA prévoit donc deux mécanismes distincts pour l’IA Open Source, qui s’appliquent à des objets différents (systèmes d’IA vs. modèles GPAI) et produisent des effets juridiques différents (exclusion vs. allègement). Cette dualité est une source fréquente de confusion.

L’exclusion des systèmes d’IA Open Source du champ d’application du Règlement

L’article 2, paragraphe 12 du RIA dispose :

« Le présent règlement ne s’applique pas aux composants d’IA fournis au titre de licences libres et open source, à moins qu’ils ne soient mis sur le marché ou mis en service en tant que systèmes d’IA à haut risque ou en tant que système d’IA relevant de l’article 5 ou de l’article 50. »

Les systèmes d’IA publiés dans le cadre de licences libres et ouvertes ne sont pas inclus dans le champ d’application du Règlement sauf dans 3 cas (article 2.12) :

Les SIA à haut risque (Titre III, Chapitres 2 et 3) : un système d’IA classé à haut risque selon l’Annexe III (biométrie, infrastructures critiques, éducation, emploi, forces de l’ordre, justice, etc.) reste pleinement soumis au RIA, même distribué sous licence open source.
Les pratiques interdites (article 5) : un SIA relevant des interdictions absolues (manipulation subliminale, notation sociale, etc.) ne peut bénéficier d’aucune exemption.
Les obligations de transparence (article 50) : les SIA conçus pour interagir avec des personnes physiques, générer du contenu synthétique (texte, image, audio, vidéo — « deepfakes ») ou détecter des émotions restent soumis aux obligations de transparence, même sous licence Open Source.

Les SIA Open Source ne sont pas définis, mais mentionnés au considérant 102 du RIA comme les systèmes dont « les logiciels et les données, y compris les modèles, sont publiés dans le cadre d’une licence libre et ouverte grâce à laquelle ils peuvent être partagés librement et qui permet aux utilisateurs de librement consulter, utiliser, modifier et redistribuer ces logiciels et données ou leurs versions modifiées ». Ce même considérant précise que cette exception est justifiée par le fait que les systèmes diffusés sous licence libre et ouverte sont considérés comme « garantissant des niveaux élevés de transparence et d’ouverture » dès lors que « leurs paramètres, y compris les poids, les informations sur l’architecture du modèle et les informations sur l’utilisation du modèle, sont rendus publics », ainsi les SIA Open Source contribuent « de manière substantielle à la recherche et à l’innovation sur le marché ».

Cette exception est néanmoins limitée à l’absence d’activité commerciale : les systèmes d’IA libres et ouverts commercialisés, monétisés, fournis dans le cadre d’une activité commerciale ou encore intégrés dans des produits et des usages commerciaux « ne devraient pas bénéficier des exceptions prévues pour les composants d’IA libres et ouverts » (considérant 103). Dans les faits, la limitation de cette exemption des SIA Open Source la rend purement formelle, puisque seuls sont concernés les SIA Open Source ne présentant pas ou peu de risques. Or, aucune obligation ne s’impose aux SIA relevant de cette catégorie (Open Source ou non) : l’exclusion art. 2(12) n’allège dans la réalité aucune obligation concrète et doit plus être vu comme une déclaration politique. Une lecture comparative du considérant 102 du RIA et du considérant 14 de la NPLD laisse penser que ces considérants ont pour finalité première de rappeler le soutien de l’Union européenne au développement de logiciels et systèmes d’IA libres, justification politique des régimes d’exclusion ou d’exemption prévus par les deux textes.

Le régime dérogatoire des modèles d’IA à usage général Open Source

L’article 53, paragraphe 2 prévoit que les obligations relatives à la documentation technique (paragraphe 1, point a) et à l’information des fournisseurs de SIA en aval (paragraphe 1, point b) « ne s’appliquent pas aux fournisseurs de modèles d’IA qui sont mis à disposition au titre d’une licence libre et « open source » qui permet l’accès, l’utilisation, la modification et la diffusion du modèle, et dont les paramètres, y compris les pondérations, les informations relatives à l’architecture du modèle et les informations relatives à l’utilisation du modèle, sont rendus accessibles au public ». Cette obligation vise la relation entre le fournisseur du modèle (upstream) et les fournisseurs de SIA qui l’intègrent dans leurs produits (downstream), le respect des obligations du premier étant nécessaire au respect des obligations du second (l’exemption se justifiant ainsi par le caractère public des informations dans un modèle ouvert).

Un régime dérogatoire est prévu à l’article 53.2, appuyé par les considérants 102 et 104, pour les modèles d’IA à usage général publiés sous une licence libre et ouverte, à condition que ledit modèle ne présente pas un risque systémique. Il ne s’agit pas d’une exclusion du champ d’application du Règlement, mais d’un régime préférentiel qui prend en compte le mécanisme de l’Open Source et qui se traduit concrètement par :

L’exemption des obligations de documentation technique détaillée ;
L’allègement des exigences de transparence ;
La suppression de l’obligation de nommer un représentant autorisé.

Le considérant 103 précise que « les composants d’IA fournis contre un prix ou autrement monétisés ne devraient pas bénéficier des exceptions prévues pour les composants d’IA libres et « open source » ». Les Lignes directrices de la Commission du 18 juillet 2025 ont apporté une clarification importante : le simple fait de rendre un modèle disponible sur un dépôt ouvert (HuggingFace, GitHub) ne constitue pas en soi une monétisation. En revanche, les stratégies commerciales construites autour du modèle (services d’hébergement, de fine-tuning, d’API payante) peuvent faire perdre le bénéfice de l’exemption. Cette distinction est essentielle pour les acteurs de l’écosystème Open Source qui adoptent des modèles économiques mixtes (open core, services professionnels, dual licensing). La ligne de démarcation reste toutefois floue et sera sans doute précisée par la pratique du Bureau de l’IA. Ce critère de monétisation fait écho au mécanisme du CRA (considérant 18), qui exclut les logiciels open source « développés ou fournis en dehors du cadre d’une activité commerciale ». Les analyses du guide CRA x Open Source semblent pouvoir s’appliquer au RIA dans leur ensemble. En pratique, l’article 2(12) exclut du champ d’application du RIA les composants d’IA Open Source destinés à des usages à risque minimal ou limité (c.-à-d. la grande majorité des projets communautaires). Ainsi, un développeur qui publie un modèle de classification d’images sous licence Apache-2.0 pour des usages généraux n’est pas soumis au RIA. En revanche, si ce même modèle est intégré dans un dispositif médical de diagnostic (SIA à haut risque au titre de l’Annexe I), les obligations du RIA s’appliquent pleinement au fournisseur du SIA intégré. Dans la chaîne de valeur Open Source, ce sera typiquement le déployeur qui intègre le composant qui sera responsable, et non le développeur communautaire initial.

Ainsi, même les modèles GPAI Open Source bénéficiant de l’allègement de l’article 53(2) restent soumis à deux obligations :

a) La politique de conformité au droit d’auteur (article 53(1)(c)) :
- Le fournisseur d’un modèle GPAI (ouvert ou fermé) doit mettre en place une politique visant à respecter le droit de l’Union en matière de droit d’auteur et de droits voisins, et notamment à identifier et respecter les réservations de droits exprimées au titre de l’article 4 de la Directive (UE) 2019/790 (exception de fouille de textes et de données, dite text and data mining).
- Pour les acteurs de l’IA Open Source, ces évolutions ouvrent un terrain stratégique à ne pas négliger. Les opt-out TDM en hausse rapide réduisent d’autant le corpus de données librement exploitables et donc la capacité même de développer des modèles compétitifs en Europe.
b )La documentation et le partage d’un résumé des données d’entraînement (article 53(1)(d)). Le fournisseur doit rédiger et rendre publiquement disponible un résumé suffisamment détaillé du contenu utilisé pour l’entraînement du modèle, conformément au modèle (template) fourni par le Bureau de l’IA. Ce modèle, publié en juillet 2025, exige de documenter :
- Les types de contenus utilisés ;
- Les sources de données ;
- Les méthodes de collecte ;
- Et (pour les données issues du web scraping) une description narrative incluant le crawler utilisé et les principaux domaines consultés.

On peut y voir un parallèle direct avec les SBOM (Software Bill of Materials) rendus obligatoires par le CRA pour les produits comportant des éléments numériques : de la même manière que le SBOM documente les composants logiciels et leurs vulnérabilités connues, le résumé des données d’entraînement vise à documenter les « ingrédients » du modèle d’IA. Cette convergence traduit une logique réglementaire commune de traçabilité de la chaîne d’approvisionnement numérique.

Le respect du droit d’auteur risque d’être un point de friction croissant compte tenu des évolutions réglementaires à ce sujet. Ainsi, l’European Copyright Society a souligné, dans son avis de janvier 2025 sur le droit d’auteur et l’IA générative, les difficultés pratiques de la mise en œuvre de l’exception TDM dans le contexte de l’entraînement de modèles à grande échelle, notamment s’agissant de la détection et du respect des opt-out formulés par les ayants droit. Ces questions font écho aux travaux sur l’articulation entre text and data mining et droit d’auteur dans le contexte de l’IA.

Plus récemment, le Parlement européen a adopté le 10 mars 2026 le rapport de la commission des affaires juridiques (Copyright and generative artificial intelligence opportunities and challenges), qui recommande l’instauration d’une présomption réfragable : dès lors qu’un fournisseur d’IA ne fait pas preuve d’une transparence complète sur ses données d’entraînement, toute œuvre protégée pertinente serait présumée avoir été utilisée. Un mécanisme similaire en France est en voie d’être étendu (imposant au fournisseur de démontrer qu’il n’a pas utilisé une œuvre dès lors qu’il existe un indice qui rend vraisemblable cette exploitation), le Conseil d’État ayant validé la constitutionnalité de la proposition de Loi Darcos le 19 mars 2026. La PPL Darcos a été adoptée par le Sénat le 8 avril 2026 en première lecture.

Synthèse : le double régime open source du RIA

Type d’objet	Mécanisme	Condition	Effet juridique
Système d’IA (SIA)	Exclusion (art. 2.12) si usage non commercial	Licence libre et ouverte + publication du code et des données	Exonération complète du RIA (sauf si haut risque, interdit, ou transparence requise)
Modèle GPAI	Allègement (art. 53.2)	Licence libre et ouverte + publication des poids, architecture et infos d’utilisation	Exemption de documentation technique et d’informations aux fournisseurs en aval ; obligation maintenue sur droit d’auteur et résumé des données

Crédit de l’illustration : @2006, Señor Codo, blotter_explosion. This file is licensed under the Creative Commons Attribution-Share Alike 2.0 Generic license.