Le 23 juillet 2024, Meta a publié un modèle de langage de 405 milliards de paramètres et l'a mis à disposition de quiconque veut le télécharger, l'exécuter et le modifier. Le nom, Llama 3.1 405B, ne dit pas grand-chose à première vue. Le geste, lui, a marqué une bascule. Pour la première fois, un modèle dont les poids étaient publiés en accès ouvert se hissait au niveau des meilleurs systèmes fermés du moment, ceux que l'on n'atteignait jusque-là que derrière une interface payante et une boîte noire. Autrement dit : la cour des géants n'était plus réservée à une poignée d'acteurs qui gardaient tout pour eux. Cet article raconte cette sortie, le chemin qui y menait, ce qu'elle déplace concrètement pour ceux qui font tourner l'IA en conditions réelles, et les perspectives qu'elle pourrait ouvrir.
Je m'occupe ici de ce qui vient après le prototype : l'infrastructure, le déploiement, la mise à l'échelle. C'est précisément par ce prisme que la sortie de Llama 3.1 405B mérite d'être lue. Ce n'est pas seulement une performance de laboratoire. C'est un modèle que des équipes ont pu poser sur leurs propres serveurs, adapter à leurs données et intégrer à leurs chaînes de production sans dépendre d'une seule entreprise. Comprendre ce moment, c'est comprendre comment un pan entier de l'écosystème s'est réorganisé autour d'une brique qu'on peut ouvrir, inspecter et faire sienne.
Un mot de méthode avant d'entrer dans le récit. Les dates, versions, chiffres et citations présentés ici proviennent des annonces officielles de Meta, de la lettre publique de Mark Zuckerberg, de la fiche technique du modèle, de la presse spécialisée et de références documentaires établies. Lorsqu'un détail reste discuté ou non consolidé, il est présenté comme tel. C'est la règle de ce média : on privilégie ce qui se vérifie, et l'on nomme les acteurs pour ce qu'ils font, sans en faire l'apologie.
Ce que c'était : un modèle de 405 milliards de paramètres, ouvert
Le 23 juillet 2024, Meta a annoncé la collection Llama 3.1, une famille de grands modèles de langage multilingues déclinée en trois tailles : 8 milliards de paramètres, 70 milliards, et — pour la première fois dans la lignée Llama — 405 milliards. Les deux premières tailles existaient déjà en version 3, sortie trois mois plus tôt ; elles ont été mises à jour à cette occasion. La nouveauté marquante, celle qui a concentré l'attention, était le 405B. Meta le présentait comme le plus grand et le plus capable des modèles de fondation disponibles en accès ouvert.
Trois caractéristiques techniques définissaient cette version. D'abord, une fenêtre de contexte portée à 128 000 tokens, contre 8 192 pour Llama 3. Concrètement, cela signifie que le modèle peut lire et raisonner sur des documents beaucoup plus longs en une seule passe : un contrat complet, une base de code volumineuse, un dossier de plusieurs dizaines de pages. Ensuite, un ancrage multilingue : la famille 3.1 gérait officiellement huit langues — l'anglais, l'allemand, le français, l'italien, le portugais, le hindi, l'espagnol et le thaï. Enfin, des capacités élargies en usage d'outils et en raisonnement, qui ouvraient la porte à des agents et à des chaînes de traitement automatisées.
Le point le plus frappant tenait dans la comparaison. Meta affirmait que le 405B était le premier modèle ouvert à rivaliser avec les meilleurs systèmes propriétaires sur les connaissances générales, la pilotabilité, les mathématiques, l'usage d'outils et la traduction multilingue. Les acteurs de référence visés étaient explicitement nommés dans les analyses qui ont suivi : GPT-4o d'OpenAI et Claude 3.5 Sonnet d'Anthropic, les deux systèmes fermés qui dominaient l'été 2024.
Llama 3.1 405B est le premier modèle disponible en accès ouvert qui rivalise avec les tout meilleurs modèles d'IA en matière de capacités de pointe en connaissance générale, pilotabilité, mathématiques, usage d'outils et traduction multilingue.
— Meta AI, « Introducing Llama 3.1 », 23 juillet 2024
Ce que disaient les mesures
Une affirmation de ce genre appelle des chiffres. Les benchmarks publiés, repris et recoupés par la presse technique, plaçaient effectivement le 405B au coude à coude avec les modèles fermés de référence. Sur MMLU, la batterie de tests de connaissances multitâches devenue un point de repère de l'industrie, le 405B obtenait 88,6 en configuration zéro-shot avec chaîne de pensée, contre 88,7 pour GPT-4o et 88,3 pour Claude 3.5 Sonnet. Un mouchoir de poche. Sur le raisonnement mathématique (MATH), le 405B obtenait 73,8, devançant Claude 3.5 Sonnet (71,1) mais restant derrière GPT-4o (76,6). Sur d'autres épreuves, l'écart se creusait un peu plus : la génération de code (HumanEval) le voyait à 89,0 %, derrière GPT-4o (90,2 %) et Claude 3.5 Sonnet (92,0 %) ; le raisonnement scientifique de niveau avancé (GPQA Diamond) le situait plus bas encore, à 51,1 %, contre 53,6 % pour GPT-4o et 59,4 % pour Claude 3.5 Sonnet.
Le tableau d'ensemble n'était donc pas celui d'une domination écrasante, mais celui d'une parité crédible. Et c'est là que réside la portée du moment : un modèle qu'on peut télécharger et faire tourner sur son propre matériel se plaçait, mesure après mesure, dans le même intervalle que les systèmes les plus fermés du marché. La distance qui séparait l'ouvert du fermé, longtemps donnée pour structurelle, se réduisait à quelques points de pourcentage.
À retenir. Sur les quatre benchmarks de référence, le 405B se place systématiquement dans l'intervalle des modèles fermés : 88,6 contre 88,7 sur le MMLU, 73,8 contre 76,6 en mathématiques. L'écart entre l'ouvert et le fermé n'est plus structurel — il se mesure en points de pourcentage.
| Benchmark | Llama 3.1 405B | GPT-4o | Claude 3.5 Sonnet |
|---|---|---|---|
| MMLU (0-shot, CoT) | 88,6 | 88,7 | 88,3 |
| MATH (0-shot, CoT) | 73,8 | 76,6 | 71,1 |
| HumanEval (code) | 89,0 % | 90,2 % | 92,0 % |
| GPQA Diamond | 51,1 % | 53,6 % | 59,4 % |
Ce qu'il fallait pour l'entraîner
Derrière ces résultats, un effort d'ingénierie hors norme. Meta indiquait avoir entraîné le 405B sur plus de 15 000 milliards de tokens, avec des campagnes d'entraînement mobilisant plus de 16 000 GPU H100. C'était le premier modèle de la lignée Llama entraîné à cette échelle. Ces chiffres importent moins pour l'exploit que pour ce qu'ils révèlent : produire un tel modèle demandait des moyens que peu d'organisations possèdent. En le publiant en accès ouvert, Meta mettait à disposition de la communauté un artefact que la plupart des acteurs n'auraient jamais pu construire eux-mêmes. C'est une forme de mutualisation : le coût colossal de l'entraînement était consenti une fois, par un acteur qui en avait les moyens, puis le résultat était partagé.
Un détail d'architecture mérite d'être relevé, car il en dit long sur la philosophie de conception. Meta a fait le choix d'une architecture de transformeur dense classique, sans multiplier les mécanismes exotiques. La justification tenait à la stabilité de l'entraînement et à la maîtrise du risque : à l'échelle du 405B, chaque campagne représente un investissement considérable, et les concepteurs ont privilégié une recette éprouvée plutôt qu'une architecture plus aventureuse. Ce parti pris de sobriété n'est pas un aveu de conservatisme ; c'est une décision d'ingénieur, celle de mettre l'effort là où il rapporte — la qualité et le volume des données, le soin apporté à l'ajustement — plutôt que dans la complexité structurelle. On retrouve là une constante des projets qui doivent tenir en production : la robustesse prime sur l'élégance théorique.
Le travail sur les données pesait lourd dans l'équation. Un corpus de 15 000 milliards de tokens ne s'assemble pas au hasard : il suppose un pipeline de filtrage, de dédoublonnage et de contrôle de qualité à très grande échelle. Meta a également recouru, pour l'ajustement, à des données générées par des modèles antérieurs — une boucle où l'IA aide à préparer les données qui entraînent l'IA suivante. Cette pratique, désormais courante, illustre un point que je vois se confirmer sur le terrain : à mesure que les modèles montent en capacité, la frontière entre « produire un modèle » et « produire les données pour l'entraîner » s'estompe. Le 405B, par sa taille et sa qualité, allait précisément devenir un outil privilégié pour cette préparation de données — nous y reviendrons avec la distillation.
Le contexte : d'où venait ce modèle
Rien de tout cela ne surgissait de nulle part. Pour saisir la portée du 23 juillet 2024, il faut remonter le fil des mois qui l'ont précédé.
Llama 3, trois mois plus tôt
Le 18 avril 2024, Meta avait publié Llama 3 en deux tailles, 8B et 70B. Ces modèles avaient déjà été salués comme les meilleurs de leur catégorie parmi les modèles à poids ouverts. Ils souffraient toutefois d'une limite notable : une fenêtre de contexte de 8 192 tokens seulement, modeste face aux fenêtres étendues que proposaient déjà les modèles fermés. Llama 3 posait les fondations — l'architecture, le corpus d'entraînement de plus de 15 000 milliards de tokens, les recettes d'ajustement — mais laissait un manque. La version 3.1 est venue combler ce manque et pousser l'échelle bien plus loin, avec le contexte à 128 000 tokens et l'arrivée du 405B. Trois mois séparaient les deux sorties : le rythme était soutenu, signe d'une équipe qui itérait vite et publiait à mesure.
Le débat sur les poids ouverts
À l'été 2024, une question travaillait le secteur : fallait-il publier les poids des grands modèles ou les garder fermés ? D'un côté, les tenants d'une diffusion large plaidaient pour la transparence, la reproductibilité et l'appropriation par le plus grand nombre. De l'autre, certains estimaient qu'un modèle de fondation aussi capable méritait un accès plus contrôlé. Meta a tranché publiquement en faveur de l'ouverture, et l'a fait de la manière la plus visible possible : en accompagnant la sortie du 405B d'une prise de position argumentée de son dirigeant.
La lettre de Mark Zuckerberg
Le jour même, le 23 juillet 2024, Mark Zuckerberg a publié une lettre intitulée « Open Source AI Is the Path Forward » — « l'IA en source ouverte est la voie à suivre ». Le texte défendait trois idées : pourquoi l'ouverture est le meilleur socle de développement pour les concepteurs, pourquoi ouvrir Llama sert les intérêts de Meta, et pourquoi une IA ouverte profite au monde. L'argument le plus commenté reposait sur une analogie historique avec le logiciel : le trajet de Linux, système ouvert qui s'est imposé face aux Unix fermés dont il descendait.
Linux, en source ouverte, a gagné en popularité — au départ parce qu'il permettait aux concepteurs de modifier son code à leur guise et qu'il était plus abordable.
— Mark Zuckerberg, « Open Source AI Is the Path Forward », 23 juillet 2024
Le raisonnement était limpide : de même que Linux, parti d'une position de challenger, est devenu le standard de l'infrastructure serveur mondiale, l'IA ouverte pourrait devenir le socle par défaut de l'industrie. Zuckerberg avançait aussi un argument de sûreté à contre-courant d'une intuition répandue : selon lui, l'ouverture rend les systèmes plus sûrs, parce qu'ils deviennent plus transparents et peuvent être examinés à grande échelle par un large ensemble de personnes.
L'IA en source ouverte devrait être nettement plus sûre, puisque les systèmes sont plus transparents et peuvent être largement examinés.
— Mark Zuckerberg, « Open Source AI Is the Path Forward », 23 juillet 2024
On peut discuter la thèse — et elle a été discutée. Mais il faut lui reconnaître une cohérence : elle liait la publication du 405B à une vision assumée du développement de l'IA, plutôt qu'à un simple coup de communication produit.
Poids ouverts n'est pas source ouverte : une précision qui compte
Ici, une clarification s'impose, car elle a nourri un vrai débat et elle éclaire ce que Meta a réellement livré. On parle couramment de modèles « en source ouverte » à propos de Llama. C'est un raccourci. Le terme exact est « poids ouverts » (open weights). La nuance n'est pas cosmétique.
- Poids ouverts : les paramètres entraînés du modèle sont publiés et téléchargeables. On peut exécuter le modèle, l'ajuster, le distiller, l'intégrer. Mais le corpus d'entraînement et le code d'entraînement complet ne sont pas nécessairement fournis.
- Source ouverte au sens strict, tel que le mouvement du logiciel libre l'entend : il faudrait en plus fournir une information suffisamment détaillée sur les données pour permettre à un tiers de recréer un système « substantiellement équivalent », ainsi que le code d'entraînement complet, et autoriser tout usage sans restriction. Au moment de la sortie, la question de savoir ce que « source ouverte » devait exactement recouvrir pour un modèle d'IA restait d'ailleurs ouverte, faute de définition partagée et stabilisée par la communauté.
Mesuré à cette aune, Llama 3.1 relève des poids ouverts plutôt que de la source ouverte stricte : ses données d'entraînement ne sont pas publiées, et sa licence communautaire comporte des conditions d'usage. La distinction, discutée dès l'annonce par les tenants du logiciel libre, mérite d'être posée clairement. Elle ne retire rien à la valeur de ce que Meta a mis à disposition — un modèle de premier plan, librement téléchargeable — mais elle invite à nommer les choses avec justesse. Publier les poids d'un modèle de 405 milliards de paramètres reste un acte fort ; ce n'est simplement pas la même chose que publier l'intégralité de la recette.
À retenir. « Poids ouverts » signifie : les paramètres entraînés sont téléchargeables et exécutables chez soi. Ni le corpus d'entraînement, ni le code d'entraînement complet ne sont fournis. On peut faire tourner le modèle et le spécialiser — on ne peut pas le recréer de zéro ni auditer exactement ce qu'il a appris.
Cette précision a son importance pour qui déploie. Disposer des poids suffit à faire tourner le modèle chez soi, à le spécialiser, à le placer dans une chaîne maîtrisée de bout en bout. Ne pas disposer du corpus d'entraînement limite en revanche la capacité à auditer ce que le modèle a exactement appris. Les deux réalités coexistent, et un praticien honnête les tient ensemble.
Ce que ça a changé : l'ouvert entre dans la cour des grands
Passons à ce qui nous occupe le plus ici : les conséquences concrètes pour ceux qui font tourner des modèles.
Un modèle de sommet qu'on héberge soi-même
La première conséquence, la plus directe, est que les équipes ont pu envisager d'exécuter un modèle de tout premier plan sur leur propre infrastructure. Jusque-là, atteindre le niveau de GPT-4o ou de Claude 3.5 Sonnet supposait de passer par une interface distante, avec ce que cela implique : dépendance à un fournisseur unique, données envoyées à l'extérieur, tarification par appel, absence de contrôle sur le modèle lui-même. Avec le 405B, une alternative devenait crédible : télécharger les poids, les servir sur ses propres serveurs, garder les données à l'intérieur du périmètre, et maîtriser la chaîne complète. Pour les secteurs sensibles à la confidentialité — santé, finance, secteur public — cette bascule ouvrait des usages jusque-là compliqués.
Cela dit, héberger un modèle de 405 milliards de paramètres n'est pas anodin. Il faut une infrastructure sérieuse, de la mémoire GPU en quantité, et une équipe capable de dimensionner l'inférence. Beaucoup d'organisations ont préféré passer par des fournisseurs de cloud qui ont rapidement proposé le modèle en service géré. Meta a d'ailleurs annoncé Llama 3.1 en même temps chez plusieurs grands hébergeurs. L'ouverture des poids ne rend pas l'exploitation triviale ; elle rend le choix possible, ce qui est déjà considérable.
Une économie d'inférence rebattue
La deuxième conséquence touche au coût d'exploitation. Meta indiquait que faire tourner l'inférence sur le 405B, sur sa propre infrastructure, revenait à environ la moitié du coût d'un modèle fermé comparable comme GPT-4o. Ce chiffre est à prendre avec les précautions d'usage — il dépend du volume, du matériel, de l'optimisation — mais il pointait une tendance de fond : la parité de capacités s'accompagnait d'une baisse potentielle du coût unitaire pour qui dispose de l'échelle. Pour un service qui traite des millions de requêtes, l'écart n'est pas théorique.
À retenir. Meta avançait que l'inférence du 405B sur infrastructure propre revenait à environ la moitié du coût d'un modèle fermé comparable. Ce chiffre dépend du volume et du matériel, mais pour un service à fort trafic, il s'agit d'un changement d'ordre de grandeur — pas d'une économie marginale.
Servir un modèle de cette taille, en pratique
Puisque nous parlons de production, arrêtons-nous un instant sur ce que représente concrètement le fait d'exécuter un modèle de 405 milliards de paramètres. Dans sa précision native, un tel modèle réclame une mémoire GPU qui se compte en centaines de gigaoctets — au-delà de ce qu'offre une seule carte. Il faut donc répartir le modèle sur plusieurs GPU, orchestrer les échanges entre eux, et accepter une latence qui dépend de cette coordination. Ce n'est pas hors de portée, mais cela suppose une infrastructure pensée pour cet usage et une équipe qui sait la piloter.
C'est ici qu'intervient une technique que tout praticien du déploiement connaît : la quantification. Elle consiste à représenter les poids du modèle avec une précision réduite — passer, par exemple, d'une représentation sur seize bits à une représentation sur huit, voire moins. Le gain est direct : l'empreinte mémoire fond, et le modèle peut tenir sur moins de matériel. Le compromis, c'est une perte de précision généralement modeste quand la technique est bien menée. Meta a d'ailleurs proposé, autour de la sortie, des indications pour servir le modèle en précision réduite. Pour beaucoup d'équipes, c'est cette voie qui a rendu le 405B réellement exploitable sur une infrastructure raisonnable, plutôt que sa version pleine précision.
Combien de mémoire GPU pour servir ce modèle ?
Estimation des poids uniquement. En production, prévoyez 20 à 40 % supplémentaires pour le cache KV et l'overhead système.
La leçon opérationnelle est la suivante : disposer des poids ouvre un espace de décisions techniques qui reste fermé avec un service distant. On choisit la précision, le découpage, le matériel, la stratégie de mise en cache, le compromis entre latence et coût. Cette latitude est précieuse pour qui veut ajuster finement son exploitation. Elle a aussi un revers : elle demande des compétences que tout le monde ne possède pas en interne. C'est pourquoi l'écosystème des fournisseurs qui servent le modèle en service géré a prospéré en parallèle — offrant à ceux qui ne voulaient pas gérer l'infrastructure eux-mêmes un accès au modèle ouvert sans la charge opérationnelle. Ouverture des poids et service géré ne s'opposent pas : ils forment un continuum d'options.
La distillation, explicitement autorisée
C'est peut-être le changement le plus structurant du point de vue de l'ingénierie, et il est passé un peu inaperçu du grand public. La licence de Llama 3.1 autorisait explicitement l'usage des sorties du modèle pour en améliorer d'autres, y compris par génération de données synthétiques et par distillation. En clair : on pouvait se servir du 405B, très capable mais lourd, comme d'un modèle « enseignant » pour produire des données d'entraînement et affiner des modèles plus petits, plus légers à déployer.
Ce point mérite qu'on s'y arrête, parce qu'il change la façon de construire une chaîne d'IA en production. On disposait désormais d'un modèle de référence, ouvert, dont on pouvait légitimement extraire de la connaissance pour spécialiser un modèle compact adapté à une tâche précise. Le lourd sert d'atelier ; le léger part en production. Cette pratique, longtemps freinée par les conditions d'usage des modèles fermés, devenait un droit clair. Les fournisseurs de cloud ont d'ailleurs rapidement publié des guides détaillant comment utiliser le 405B pour générer des données synthétiques et distiller des modèles sur mesure.
La collection Llama 3.1 permet d'exploiter les sorties de ses modèles pour en améliorer d'autres, notamment par génération de données synthétiques et distillation.
— Fiche technique Llama 3.1, licence communautaire Meta
Un écosystème qui s'active
La combinaison de ces facteurs — parité de capacités, poids téléchargeables, distillation autorisée, disponibilité chez les grands hébergeurs — a mis en mouvement un écosystème entier. Des variantes spécialisées, des versions compressées, des adaptations sectorielles ont fleuri. Le modèle est devenu une brique de base sur laquelle d'autres ont construit, plutôt qu'un produit fini à consommer tel quel. C'est exactement la dynamique que Zuckerberg décrivait dans son analogie avec Linux : un socle ouvert autour duquel une communauté large itère et améliore.
Le multilingue, et le cas du français
La gestion officielle de huit langues, dont le français, n'est pas un détail pour un public francophone. Historiquement, les grands modèles ont d'abord brillé en anglais, langue surreprésentée dans les corpus, avant que les autres langues ne rattrapent progressivement le retard. En intégrant le français, l'espagnol, l'allemand, l'italien, le portugais, le hindi et le thaï dans son périmètre officiel, Llama 3.1 offrait aux équipes non anglophones un socle sur lequel bâtir sans repartir de zéro. Pour une organisation française qui veut traiter des documents en français, répondre à des utilisateurs francophones ou spécialiser un modèle sur un domaine métier local, disposer d'un modèle ouvert compétent dans la langue change la donne.
Il faut toutefois nuancer. « Langue officiellement gérée » ne signifie pas performance strictement identique à l'anglais sur toutes les tâches. Les corpus restant déséquilibrés, un léger écart de qualité subsistait souvent au profit de l'anglais. Mais l'ajustement local permettait justement de combler une partie de cet écart : en affinant le modèle sur des données françaises spécifiques à un métier, une équipe pouvait relever son niveau là où elle en avait besoin. C'est un atout considérable de l'accès aux poids : on ne subit pas la performance moyenne du modèle, on peut l'orienter vers son propre usage. Un modèle fermé, servi tel quel derrière une interface, ne laisse pas cette latitude.
Ce point rejoint une préoccupation de souveraineté qui monte nettement en 2024. Pouvoir héberger un modèle compétent en français sur une infrastructure maîtrisée, sans envoyer ses données à un tiers, répond à des exigences réglementaires et stratégiques réelles pour beaucoup d'acteurs européens. Le 405B donne à ces acteurs une option qu'ils n'avaient pas auparavant au même niveau de qualité. Et l'on peut penser que des déclinaisons plus légères de la même lignée, si elles voyaient le jour, prolongeraient cet avantage en abaissant encore la barrière d'entrée matérielle.
Les perspectives : ce que le 405B rend possible
Comment lire ce moment à chaud, sans présumer de la suite ? Comme un point de bascule qui pourrait inaugurer une cadence et installer une norme.
La trajectoire qui se dessine
Meta a montré, entre Llama 3 en avril et Llama 3.1 en juillet, qu'il savait itérer vite et publier à mesure. Rien n'oblige à croire que ce rythme se poursuivra, mais la logique du projet en pose les jalons possibles.
- Vers des modèles plus légers. On peut s'attendre à ce que la même équipe cherche à faire redescendre la capacité vers de plus petites tailles, mieux adaptées aux terminaux et à l'informatique embarquée, là où la contrainte de ressources est forte. La logique de distillation ouverte par la licence 3.1 pointe précisément dans cette direction.
- Vers un resserrement de l'écart. Si le savoir-faire accumulé sur le 405B se reporte sur les tailles intermédiaires, un modèle de l'ordre de 70 milliards de paramètres pourrait, demain, approcher les performances du géant pour une empreinte bien plus légère à servir. Pour un responsable d'infrastructure, ce serait la meilleure des nouvelles : presque autant de capacité, beaucoup moins de matériel.
- Vers des architectures plus économes. Meta a fait, pour le 405B, le choix assumé d'un transformeur dense classique. D'autres approches, comme le mélange d'experts qui n'active qu'une partie du réseau à chaque requête, existent déjà dans le paysage et pourraient inspirer les générations suivantes en quête d'efficacité. Rien n'est acquis, mais le champ des options est ouvert.
Ces pistes dessinent une constante déjà lisible : à chaque étape, Meta publie les poids et laisse la communauté s'en emparer. Le 405B pourrait bien être le moment où cette stratégie cesse d'être une position de challenger pour devenir une force qui pèse sur l'ensemble du secteur.
Une norme concurrentielle qui pourrait s'installer
Au-delà de la seule lignée Llama, la sortie de juillet 2024 pourrait contribuer à installer une norme : l'accès ouvert aux poids comme option sérieuse et non plus comme sous-produit de second rang. D'autres acteurs — chinois, européens, indépendants — publient déjà leurs propres modèles à poids ouverts, et une démonstration de parité à ce niveau pourrait les inciter à accélérer. La conversation est en train de se déplacer. La question n'est plus tout à fait « l'ouvert peut-il rivaliser ? » mais « quel modèle ouvert choisir, pour quel usage, à quel coût d'exploitation ? ». C'est un déplacement discret mais qui s'annonce profond.
Un débat que cette sortie ravive
Le clivage entre poids ouverts et source ouverte stricte, ravivé par cette sortie, appelle à être clarifié. Il faudra sans doute un cadre de discussion partagé pour trancher le vocabulaire ; la communauté du logiciel libre y travaille. On gagnerait déjà à nommer précisément ce que recouvre l'ouverture d'un modèle : les poids seuls, ou aussi les données et le code. Cette clarté serait un acquis. Elle permettrait à un décideur d'évaluer exactement ce qu'il obtient et ce qui lui manque avant de bâtir dessus. Un praticien avisé ne devrait plus demander « est-ce open source ? » mais « qu'est-ce qui, exactement, est ouvert ici ? ».
La question de la sûreté, posée franchement
Publier les poids d'un modèle aussi capable a nourri un débat légitime sur la sûreté. L'argument de Zuckerberg, rappelons-le, était que l'ouverture rend les systèmes plus sûrs par la transparence et l'examen collectif. La position inverse existait aussi : un modèle librement téléchargeable échappe, par construction, au contrôle centralisé que permet un service fermé. Une fois les poids diffusés, on ne peut plus les retirer ni imposer un garde-fou côté serveur. Les deux lectures ont leur cohérence, et il serait malhonnête de trancher d'un mot.
Meta a accompagné la sortie de garde-fous et d'outils dédiés — des dispositifs de filtrage et des recommandations d'usage responsable, publiés en parallèle du modèle. L'idée était de fournir aux équipes qui déploient les moyens d'encadrer les usages sur leur propre infrastructure, puisque le contrôle centralisé n'était plus possible. Cette approche déplace la responsabilité vers celui qui exploite : à lui de poser les vérifications, les limites et la surveillance adaptées à son contexte. Pour un responsable de mise en production, c'est une charge supplémentaire, mais aussi une maîtrise plus fine : on décide soi-même des règles plutôt que de les subir.
Ce débat ne se tranchera pas par un camp contre l'autre ; il gagnerait plutôt à mûrir en distinctions plus fines. Mieux vaudrait raisonner par niveaux de capacité, par types d'usage et par vecteurs d'attaque précis, plutôt qu'en opposant abstraitement ouvert et fermé. La publication des poids appelle une gouvernance adaptée, sans que l'ouverture soit condamnée en bloc. Ce serait là une maturation saine, et le 405B, par sa visibilité, peut y contribuer en posant la question à grande échelle.
Le regard du terrain
Pour qui s'intéresse à la mise en production, la leçon du 405B tient en une phrase : la capacité de pointe devient un point de départ que l'on peut poser chez soi, et non plus seulement un service que l'on loue à distance. Cela ne veut pas dire que l'hébergement autonome convient à tout le monde — il demande des compétences, du matériel et une vigilance opérationnelle réelle. Cela veut dire que le choix existe, et qu'il est désormais un vrai choix d'architecture, pesé au cas par cas selon la confidentialité requise, le volume traité et les ressources disponibles.
Le 405B connaîtra le sort de tout modèle : il sera dépassé, sans doute vite, par des systèmes plus efficaces — peut-être dans sa propre lignée. Mais son rôle restera intact. Il aura été la preuve, à un instant précis et vérifiable, qu'un système ouvert pouvait se tenir au niveau des meilleurs systèmes fermés. Cette démonstration, une fois faite, ne se défait pas. Elle change les attentes de tout un secteur, et c'est peut-être là son legs le plus solide : avoir déplacé la ligne de ce qu'on croyait possible en accès ouvert.
Ce qu'il faut retenir
Le 23 juillet 2024, avec le Llama 3.1 405B, un modèle de 405 milliards de paramètres publié en accès ouvert s'est hissé au niveau des meilleurs modèles fermés du moment. Fenêtre de contexte de 128 000 tokens, huit langues gérées, parité mesurée avec GPT-4o et Claude 3.5 Sonnet sur les principaux benchmarks : les capacités étaient là. La lettre de Mark Zuckerberg, publiée le même jour, a inscrit ce geste dans une vision assumée de l'ouverture, avec l'analogie de Linux en fil conducteur.
Pour les équipes qui déploient, trois changements comptent : la possibilité d'héberger un modèle de sommet chez soi, une économie d'inférence rebattue, et la distillation explicitement autorisée pour spécialiser des modèles plus légers. Si la cadence observée entre Llama 3 et Llama 3.1 se maintient, l'accès ouvert pourrait s'installer comme une norme sérieuse plutôt que comme un pis-aller. Reste une précision de vocabulaire qui ne s'efface pas : ce que Meta livre relève des poids ouverts, pas de la source ouverte au sens le plus strict. Nommer les choses justement, c'est encore la meilleure manière de mesurer ce qu'on gagne.
Sources
- Meta AI — « Introducing Llama 3.1: Our most capable models to date » (23 juillet 2024)
- Mark Zuckerberg — « Open Source AI Is the Path Forward » (About Meta, 23 juillet 2024)
- Meta AI — « Introducing Meta Llama 3 » (18 avril 2024)
- Fiche technique Llama 3.1 (MODEL_CARD, dépôt meta-llama)
- Vellum — Évaluation du Llama 3.1 405B face aux modèles fermés de référence
- IBM Think — « Meta releases new Llama 3.1 models, including the 405B parameter variant »