Les termes « modèle fermé », « open weight » et « open source » circulent en permanence dans les discussions sur l’IA générative. Ils sont malheureusement régulièrement confondus. Pour un architecte qui doit arbitrer entre personnalisation, souveraineté, maîtrise du coût et dépendance à un fournisseur, ces distinctions ont des conséquences opérationnelles directes.

Cet article clarifie deux points :

• De quoi est fait un modèle d’IA ?
• Que signifient les 3 niveaux d’ouverture d’un modèle d’IA : closed, open weight ou open source ?

De quoi est fait un modèle d’IA ?

Un modèle d’IA générative est un assemblage de plusieurs composants distincts. Chacun peut être publié ou non, indépendamment des autres. Le niveau d’ouverture global du modèle dépend de ce qui est rendu public.

L’architecture

L’architecture désigne la structure du réseau de neurones du modèle. Elle est définie par quelques paramètres structurels :

1. Le nombre de couches (layers) : c’est la profondeur du réseau. Plus un modèle a de couches, plus il peut capturer des relations complexes, au prix d’un coût de calcul et de mémoire plus élevé. À titre d’ordre de grandeur, Llama 7B (un modèle open weight de 7 milliards de paramètres publié par Meta, représentatif de la gamme des « petits modèles ouverts » destinés à l’auto-hébergement) a 32 couches. Les plus grands modèles fermés en ont plusieurs centaines.
2. Le type d’attention : le mécanisme qui permet au modèle, lorsqu’il traite un mot, de regarder tous les autres mots du contexte et de pondérer leur importance relative. Plusieurs variantes du type d’attention existent, chacune avec ses compromis entre vitesse, mémoire et longueur de contexte.
3. La taille du vocabulaire : nombre de tokens différents que le modèle peut manipuler. Un token est l’unité textuelle élémentaire (un mot complet, un morceau de mot, ou un caractère selon le cas). Un vocabulaire typique contient entre 32 000 et 128 000 tokens.
4. Le schéma d’activation : opération mathématique appliquée à la sortie de chaque neurone. Sans elle, le réseau se réduirait à une simple multiplication de matrices et ne pourrait pas apprendre de relations complexes.

L’architecture est généralement décrite dans un article de recherche associé à la publication du modèle. Même pour les modèles fermés, une partie de l’architecture est souvent publique, car elle sert la communication scientifique des éditeurs.

→ Impact de l’ouverture de l’architecture pour l’utilisateur. Une architecture ouverte est un prérequis pour comprendre précisément comment le modèle fonctionne et pour envisager des adaptations profondes (ajout ou retrait de couches, changement du type d’attention). L’exécution effective du modèle et son portage sur une nouvelle plateforme matérielle exigent en plus les poids et le code d’inférence (le programme qui charge les poids en mémoire et exécute les calculs du modèle pour produire une réponse ; distinct du code d’entraînement, qui sert à produire ces poids).

Les poids (paramètres)

Les poids sont les valeurs numériques apprises pendant l’entraînement. Ils représentent ce que le modèle a retenu des données sur lesquelles il a été entraîné.

Ces valeurs sont distribuées sous forme d’un ou plusieurs fichiers binaires, dans des formats standards, téléchargeables sur des plateformes comme Hugging Face. Un modèle de 7 milliards de paramètres représente un fichier de plusieurs gigaoctets.

Charger un modèle, concrètement

« Charger un modèle » signifie placer ces valeurs dans la mémoire d’une machine pour qu’il puisse être exécuté. Deux types de mémoire sont utilisés :

• La RAM système : mémoire vive classique d’un serveur, utilisée pour une exécution sur processeur (CPU). Lente, mais ne nécessite pas de matériel spécialisé.
• La VRAM d’un GPU : mémoire vive dédiée d’une carte graphique. Configuration standard pour l’inférence (l’exécution du modèle pour produire une réponse à partir d’un prompt), car un GPU est bien plus rapide qu’un CPU pour les calculs matriciels massivement parallèles sur lesquels repose un modèle de langage.

Concrètement, charger un modèle consiste à lire le fichier de poids depuis le disque, à l’allouer en mémoire (VRAM dans la majorité des déploiements), et à connecter ces valeurs à une implémentation logicielle de l’architecture.

Deux grandes familles d’outils coexistent :

• une bibliothèque de référence comme PyTorch ou Transformers (Hugging Face) : simple d’usage, adaptée au prototypage et à la recherche, mais pas toujours optimisée pour la performance en production ;
• un moteur d’inférence spécialisé, optimisé pour le service réel. Les deux références open source sont vLLM (orienté production à l’échelle sur GPU datacenter NVIDIA) et llama.cpp (orienté exécution locale et portable sur CPU ou GPU consumer ou mobile).

→ Impact de l’ouverture des poids pour l’utilisateur. Sans les poids, on ne peut pas exécuter le modèle soi-même ; on peut seulement appeler une API. Avec les poids, l’architecture et un moteur d’inférence, on peut l’exécuter sur sa propre infrastructure, le personnaliser, et s’affranchir d’un fournisseur d’API.

Le corpus d’entraînement

L’entraînement d’un modèle de langage se déroule en deux grandes phases successives :

1. Le pré-entraînement (pre-training) : le modèle apprend à prédire le mot suivant à partir d’immenses volumes de texte brut (contenus web, livres, code, articles scientifiques). Il n’apprend pas encore à répondre à des questions ou à suivre des instructions, seulement à produire du texte cohérent.
2. Le post-entraînement : il ajuste le comportement du modèle pour qu’il sache répondre et suivre des consignes (détaillé plus loin).

Le corpus dont il est question ici est celui du pré-entraînement. Sa taille se compte en milliers de milliards de tokens (rappel : un token représente environ 0,75 mot en moyenne en français). Sa composition détermine largement ce que le modèle sait, ce qu’il ignore, et les biais qu’il reproduit.

→ Impact de l’ouverture du corpus pour l’utilisateur. Sans le corpus, il est impossible de refaire l’entraînement à partir de zéro pour obtenir un modèle équivalent. Il est également impossible d’auditer les biais avec rigueur, ou de vérifier si des contenus sous droit d’auteur y figurent. La publication du corpus est le critère le plus exigeant de l’ouverture.

Le code et les procédures d’entraînement

Le code d’entraînement désigne les scripts, les frameworks, les hyperparamètres et les procédures de validation. Les hyperparamètres sont les paramètres de configuration de l’entraînement qui ne sont pas appris mais choisis à l’avance.

Ils ont un impact majeur sur le résultat final. C’est l’ensemble « architecture + corpus + code et hyperparamètres » qui, mis en œuvre pendant plusieurs semaines ou mois sur des milliers de GPU, produit les poids.

→ Impact de l’ouverture du code pour l’utilisateur. Sans ce code, on peut disposer des poids mais on ne peut pas reproduire l’entraînement, même avec le corpus. On dépend alors des choix techniques opaques du fournisseur initial.

Les données et procédures de post-entraînement

Après le pré-entraînement, un modèle passe par des phases de post-entraînement (post-training) qui ajustent son comportement. Les principales sont :

• Instruction tuning : entraînement supervisé sur des paires (consigne, réponse idéale) qui apprend au modèle à répondre à des instructions plutôt qu’à simplement continuer un texte.
• Alignement : procédures qui orientent le comportement du modèle vers des réponses jugées préférables par des évaluateurs humains.
• Filtrage des sorties nuisibles : ajustements qui réduisent la production de contenus dangereux, illégaux, ou contraires à la politique de l’éditeur.

Ces phases mobilisent des jeux de données annotés, souvent par des humains, et des procédures propres à chaque éditeur.

→ Impact de l’ouverture des données de post-entraînement pour l’utilisateur. Les données de post-entraînement déterminent le ton, le style, les refus, et le comportement conversationnel du modèle. Sans accès à ces données, il est difficile de reproduire ou de modifier profondément le comportement.

La documentation et la licence

La documentation rassemble l’ensemble des éléments qui permettent à un tiers de comprendre, utiliser et reproduire le modèle. Deux artefacts sont devenus des standards :

• La model card : fiche descriptive du modèle qui documente ses capacités, ses limites, les biais connus, les cas d’usage recommandés et déconseillés. Le format a été proposé par Google en 2019 et s’est imposé comme un standard de facto sur des plateformes comme Hugging Face.
• La datasheet du corpus : équivalent pour les données d’entraînement. Elle documente la provenance, la méthode de collecte, les traitements appliqués, les biais identifiés et les sensibilités juridiques.

La licence précise les droits d’usage, de modification et de redistribution. Une licence restrictive (usage non commercial, seuil d’utilisateurs, interdiction d’usages concurrents) peut rendre un modèle inutilisable dans un contexte d’entreprise, même si les poids sont publics. La licence n’est pas un détail juridique : c’est une contrainte d’architecture.

En résumé

Un modèle est la combinaison d’une architecture, de poids, d’un corpus, d’un code d’entraînement, de données de post-entraînement et d’une licence. Les trois niveaux d’ouverture présentés ci-dessous correspondent à trois combinaisons de ce qui est rendu public.

Les trois niveaux d’ouverture d’un modèle d’IA

Composant publié	Modèle fermé	Open weight	Open source (OSAID)
Architecture	Partiellement, par publication scientifique	Oui, documentée	Oui
Poids	Non	Oui	Oui
Corpus d’entraînement	Non	Non	Oui, ou sa Data Information
Code d’entraînement	Non	Non	Oui
Données de post-entraînement	Non	Non	Oui
Licence autorisant les quatre libertés	Non	Variable selon l’éditeur	Oui, approuvée par l’OSI

Modèle fermé (closed model)

Aucun des composants n’est publié. L’accès se fait exclusivement via une API, sous conditions tarifaires et contractuelles fixées par le fournisseur.

Exemples : GPT (OpenAI), Claude (Anthropic), Gemini (Google DeepMind), Mistral Large (Mistral AI).

✓ Ce que cela apporte

• Simplicité opérationnelle (aucune infrastructure à gérer).
• Accès aux modèles généralement les plus performants du marché.
• Mises à jour automatiques.

✗ Ce que cela limite

• Impossibilité de personnaliser en profondeur.
• Dépendance totale au fournisseur (tarification, disponibilité, conditions d’usage, versions).
• Absence de garantie sur le comportement du modèle en cas d’évolution silencieuse.
• Aucune réversibilité autre qu’une migration complète vers un autre fournisseur.

Modèle à poids ouverts (open weight)

Les poids du modèle sont publiés et téléchargeables, sous une licence qui en autorise l’usage. L’architecture est généralement documentée. En revanche, le corpus, le code d’entraînement complet, et les données de post-entraînement ne sont pas publiés.

Exemples : Llama (Meta, sous Llama Community License), Mistral 7B et Mixtral (Apache 2.0), Qwen (Alibaba, Apache 2.0 pour la plupart), DeepSeek, Gemma (Google), Phi (Microsoft).

✓ Ce que cela apporte

• Exécution sur sa propre infrastructure : maîtrise complète du coût d’inférence (les ressources GPU mobilisées à chaque requête d’utilisation du modèle), de la latence et de la résidence des données utilisateur transitant par le modèle.
• Possibilité de personnalisation via fine-tuning : technique qui consiste à poursuivre l’entraînement du modèle sur un jeu de données plus petit et plus ciblé, pour l’adapter à un domaine, un style ou une tâche spécifique (le corpus d’origine n’est pas nécessaire pour cela).
• Pérennité : un modèle open weight téléchargé reste disponible localement, même si le fournisseur disparaît ou change ses conditions.

✗ Ce que cela limite

• Absence de reproductibilité : impossible de reconstituer le modèle à partir de zéro sans accès au corpus et au code d’entraînement.
• Biais et contenus du corpus non auditables.
• Risque juridique indirect : si le corpus d’entraînement contenait des contenus sous droit utilisés sans autorisation, l’utilisateur du modèle hérite d’un risque de régurgitation (le modèle peut reproduire des passages proches de l’original dans ses sorties).

Modèle open source au sens strict (OSAID)

L’Open Source Initiative (OSI), qui maintient depuis 1998 la définition canonique de l’open source logiciel, a publié en octobre 2024 une définition formelle pour l’IA : l’Open Source AI Definition (OSAID) v1.0. Cette définition a été élaborée pendant deux ans avec plus de 25 organisations partenaires (Mozilla, Linux Foundation, Apache Foundation, Microsoft, Google, Meta, Intel, Samsung, entre autres).

Pour qu’un système d’IA soit qualifié d’open source au sens de l’OSAID, il doit permettre quatre libertés fondamentales :

1. Utiliser le système pour tout usage sans demander la permission ;
2. Étudier son fonctionnement ;
3. Le modifier ;
4. Le partager avec ou sans modifications.

Ces libertés exigent la publication de trois ensembles de composants, tous sous licence approuvée par l’OSI :

• Data Information : une information suffisamment détaillée sur les données d’entraînement pour qu’une personne compétente puisse reconstruire un système substantiellement équivalent. Cette formulation est un compromis : elle ne force pas la publication du corpus complet (parfois impossible pour raisons juridiques ou de protection de données), mais exige au minimum la documentation du pipeline de construction du corpus : provenance des données, critères de sélection appliqués, procédés de nettoyage des données et traitements appliqués avant l’entraînement.
• Code : l’ensemble du code source utilisé pour entraîner et exécuter le système.
• Parameters : les poids et autres paramètres du modèle.

Exemples de modèles qui respectent cette définition : OLMo (Allen AI), Pythia (EleutherAI), BLOOM (BigScience), Baguettotron et la famille Pleias-RAG (Pleias, France), adossés au dataset Common Corpus.

✓ Ce que cela apporte

• Reproductibilité complète du modèle.
• Audit possible des biais à partir du corpus ou de sa description.
• Possibilité d’intervenir sur n’importe quel composant (architecture, corpus, code d’entraînement).
• Sécurité juridique renforcée lorsque le corpus est lui-même sous licence permissive : si les données d’entraînement sont exclusivement issues du domaine public, de licences Creative Commons, ou de contenus explicitement autorisés à l’entraînement, l’utilisateur final n’hérite pas du risque juridique lié aux contenus sous droit présents dans les corpus opaques des modèles open weight.

✗ Ce que cela limite

• Moins de modèles open source strict disponibles aujourd’hui que de modèles fermés ou open weight.
• Performance : les modèles les plus performants du marché (appelés frontier models, c’est-à-dire les modèles qui définissent l’état de l’art à un moment donné, typiquement les derniers GPT, Claude ou Gemini) ne sont pas open source, car les laboratoires qui publient tout ont en général moins de ressources pour rivaliser sur les benchmarks généralistes.

Trois risques pour l’utilisateur d’un modèle opaque

La distinction entre open weight et open source strict n’est pas qu’une nuance théorique. Utiliser un modèle entraîné sur un corpus non auditable expose à trois risques concrets :

• Risque juridique indirect : si le modèle régurgite du contenu sous droit dans une sortie exploitée commercialement.
• Risque de biais non détecté : dont on ne peut pas remonter à la source.
• Risque de réputation : si l’éditeur du modèle est impliqué dans une procédure très médiatisée.

Implications pour l’architecture d’entreprise

Trois niveaux de contrôle coexistent, portant sur des objets différents :

• La donnée : les informations utilisateur et métier qui transitent par le modèle à l’inférence. Question posée : qui voit mes prompts et mes données, où sont-ils stockés ?
• Le modèle : les poids qui produisent les réponses. Question posée : puis-je exécuter ce modèle sur ma propre infrastructure, sans dépendre d’un fournisseur ?
• Le corpus : les données sur lesquelles le modèle a appris. Question posée : avec quoi ce modèle a-t-il été entraîné, et puis-je l’auditer ?

Les leviers qui permettent de répondre à ces questions se cumulent naturellement plutôt que de correspondre une à une aux couches :

• Un service cloud managé (Azure OpenAI, AWS Bedrock) avec clauses contractuelles, résidence européenne et chiffrement adresse la couche donnée uniquement.
• L’auto-hébergement d’un modèle open weight adresse la donnée et le modèle simultanément : les requêtes ne sortent plus de votre infrastructure, et vous n’êtes plus lié à une API.
• Un modèle open source strict (au sens OSAID), auto-hébergé ou entraîné en interne, adresse les trois couches en même temps.

La décision d’architecture consiste à identifier lesquelles de ces couches sont réellement exigées par le cas d’usage :

• Un besoin de conformité RGPD sur des données personnelles peut n’exiger que la couche donnée ; une offre cloud managé européenne suffit.
• Un besoin d’audit scientifique, de contexte très régulé, ou de garantie contre la régurgitation de contenus sous droit exige la couche corpus ; seul un modèle open source strict y répond.

Bibliographie et sources

Définition de l’open source AI

• Open Source Initiative, The Open Source AI Definition v1.0, octobre 2024. https://opensource.org/ai/open-source-ai-definition
• Open Source Initiative, OSAID FAQ. https://opensource.org/ai/faq
• InfoWorld, « OSI unveils Open Source AI Definition 1.0 », 28 octobre 2024. https://www.infoworld.com/article/3593266/osi-unveils-open-source-ai-definition-1-0.html

Références techniques

• Mitchell et al., Model Cards for Model Reporting, Google, 2019. https://arxiv.org/abs/1810.03993

Acteurs et modèles cités

• Pleias (France), laboratoire et start-up d’IA. https://pleias.fr/
• Podcast A la french, épisode « IA : Pourquoi la taille ne compte plus ? », avec Anastasia Stasenko (CEO Pleias), 17 février 2026. https://www.youtube.com/watch?v=wirmd5kCWok
• Hugging Face, page du modèle Baguettotron. https://huggingface.co/PleIAs/Baguettotron
• Allen Institute for AI, famille OLMo. https://allenai.org/olmo
• EleutherAI, famille Pythia. https://github.com/EleutherAI/pythia
• BigScience et Hugging Face, modèle BLOOM. https://huggingface.co/bigscience/bloom