C'est quoi une usine à modèles, et pourquoi ça vaut 6 milliards ?

Nvidia vient de payer six milliards de dollars pour une machine qu'il ne peut ni toucher, ni photographier, ni charger sur un camion. Mieux : la boîte qui la lui vend continue de s'en servir tous les jours, tranquillement, comme si de rien n'était.

Elle s'appelle la Model Factory. L'usine à modèles. Elle appartient à Poolside, une boîte qui fabrique des modèles d'IA spécialisés dans le code, et la transaction elle-même tient en trois phrases : Nvidia paie six milliards pour avoir le droit de s'en servir, embauche 109 personnes qui savent la faire tourner, et remet un milliard au capital au passage. Poolside garde son modèle, ses clients et ses trois fondateurs. Voilà. C'est plié.

Sauf que la transaction, on s'en fiche un peu. Ce qui vaut le coup de s'asseoir cinq minutes, c'est la machine. Parce qu'on parle de ces modèles à longueur de journée sans jamais se demander comment on en fabrique un, et la réponse est beaucoup plus concrète, beaucoup plus sale et beaucoup plus drôle que ce qu'on imagine.

Cinq postes, un tapis roulant, et tout au bout, un fichier. Toute cette ferraille pour accoucher d'un truc qui tient sur une clé USB.

D'abord, c'est un logiciel ou une vraie machine ?

La question mérite d'être posée tout de suite, parce que le mot usine met tout le monde d'accord sur une image fausse. Non, ce n'est pas une machine à graver les puces comme celles d'ASML, ces engins qu'on livre en pièces détachées dans plusieurs avions cargo et qu'on remonte sur place pendant des mois.

C'est du logiciel. Des dizaines de programmes qui se parlent entre eux.

Mais si tu t'arrêtes là, tu rates complètement le sujet, parce que ce logiciel-là ne fait rien tout seul. Il pilote une salle. Une vraie, avec des dizaines de milliers de cartes graphiques dedans, des kilomètres de câbles, une clim qui hurle et une facture d'électricité qui se compte en mégawatts. L'usine, c'est le logiciel plus la salle plus les gens qui savent ce qu'ils font. Les trois. Enlève-en un et il ne reste rien du tout.

Et pour comprendre pourquoi ça vaut si cher, il faut regarder ce qui se passe vraiment dans la salle pendant qu'un modèle se fabrique.

Une panne toutes les trois heures pendant deux mois

Là j'ai de la chance, parce qu'il existe un document public et précis sur le sujet : quand Meta a sorti son gros modèle Llama 3, ils ont publié un rapport technique où ils racontent honnêtement comment l'entraînement s'est passé. Et c'est édifiant.

Le modèle a été entraîné sur 16 384 cartes graphiques pendant 54 jours d'affilée. Sur cette période, ils ont compté 466 interruptions du travail. Quarante-sept étaient prévues, des maintenances. Les 419 autres, non. Ça fait une panne toutes les trois heures, jour et nuit, pendant deux mois.

La carte graphique est de loin la pièce qui lâche le plus. Ce qui tombe bien, vu qu'il y en a seize mille.

Et le pire n'est pas là. Le pire, c'est qu'un entraînement de ce genre est synchrone : les seize mille cartes avancent au pas cadencé, ensemble, et Meta écrit noir sur blanc qu'une seule carte qui lâche peut obliger à relancer tout le travail. Une carte sur seize mille. Toutes les trois heures.

Celui qui a déjà lancé un traitement de six heures qui plante à la cinquième et demie voit très bien de quoi je parle. Maintenant, multiplie ça par deux mois, et par une salle de seize mille cartes graphiques qui consomme pendant tout ce temps.

Alors voilà le chiffre que je voulais te montrer depuis le début, et c'est lui qui répond à la question « à quoi sert cette machine ». Sur ces 419 pannes, combien de fois un humain a-t-il dû intervenir sérieusement ?

Trois fois.

Trois. Tout le reste a été détecté, diagnostiqué, contourné et rattrapé automatiquement, sans réveiller personne. Voilà ce que c'est, une usine à modèles. C'est ce qui fait qu'un chantier de deux mois sur du matériel qui casse en permanence arrive quand même au bout. Sans elle, tu as juste seize mille cartes graphiques très chères et une équipe qui passe ses nuits à relancer des scripts.

Petit bonus dans le même rapport, parce qu'il est délicieux : ils ont observé que le rendement de la salle baissait de 1 à 2 % en milieu de journée, tout simplement parce qu'il fait plus chaud et que les cartes se brident. Et quand les dizaines de milliers de cartes se mettent à attendre en même temps, la consommation du bâtiment fait un bond de plusieurs dizaines de mégawatts d'un coup, ce qui, je cite, met le réseau électrique local à la limite. On est loin du logiciel.

Maintenant, ouvrons le capot

Poolside a fait quelque chose d'assez rare dans ce métier : ils ont raconté publiquement, poste par poste, comment leur usine est faite. Une série d'articles techniques sur leur propre site. Donc ce qui suit n'est pas une reconstitution de ma part, c'est leur plan.

La chaîne fait cinq postes.

Poste 1, la matière première. On récupère du texte et du code partout : jeux de données ouverts, aspiration du web, dépôts de code triés par qualité et par licence, plus du texte fabriqué exprès. Puis on nettoie, et j'y reviens dans deux minutes parce que c'est le poste le plus sous-estimé de toute l'usine. Le tout est servi aux machines par un système maison qu'ils appellent Blender, le mélangeur, qui décide en direct quelle proportion de quoi part dans la moulinette.

Poste 2, la cuisson. Le programme qui répartit le calcul sur toutes les cartes en même temps et qui doit survivre à ce que je t'ai raconté plus haut. Ils l'ont baptisé Titan, et dans le titre de leur propre article ils l'appellent « le four de l'usine ». Je n'invente pas la métaphore, elle est d'eux, et elle est juste.

Poste 3, le banc d'essai. Une plateforme qui exécute pour de vrai le code que le modèle écrit. Celui-là mérite sa propre section, il arrive.

Poste 4, les finitions. Là où un modèle brut devient un modèle utilisable. Pareil, section dédiée, parce que c'est exactement la question que tout le monde se pose sans oser la formuler.

Poste 5, la sortie. Un fichier. Un gros fichier de chiffres, mais un fichier. C'est tout. Toute cette usine pour ça.

Pourquoi une bonne usine donne un meilleur modèle

Voilà la vraie question, et la réponse tient dans une phrase que Poolside écrit sur son site : les expériences qui demandaient des semaines à programmer tournent maintenant en moins d'une heure.

Il faut mesurer ce que ça veut dire.

Personne, aujourd'hui, ne sait calculer à l'avance ce qui fera un bon modèle. Personne. On a des intuitions, des habitudes, des résultats passés, mais la recette exacte, la proportion de code par rapport au texte, la taille du modèle par rapport à la quantité de données, la façon d'organiser l'apprentissage, tout ça se trouve en essayant. Pas en réfléchissant : en essayant, en mesurant, et en recommençant.

Donc celui qui peut tester cent idées pendant que son voisin en teste trois ne va pas gagner parce qu'il est plus malin. Il va gagner parce qu'il a essayé cent choses. C'est une course à la vitesse d'apprentissage, et l'usine, c'est ce qui règle cette vitesse.

C'est d'ailleurs pour ça que la course au plus gros modèle m'a toujours paru un peu bête, et j'écrivais il y a treize jours à propos d'un modèle chinois de dix mille milliards de paramètres que le nombre de paramètres était le chiffre le moins intéressant de l'affaire. Le nombre de paramètres, c'est la cylindrée. La vitesse à laquelle tu peux essayer une nouvelle idée, c'est le pilote.

Le premier nettoyage : les données

Ce poste-là est le plus ingrat et c'est celui qui rapporte le plus.

Quand tu aspires le web pour nourrir un modèle, tu ne récoltes pas une bibliothèque. Tu récoltes un dépotoir. Des pubs, des menus de navigation, des bandeaux de cookies, des insultes, des pages entières générées automatiquement qui ne veulent rien dire, du code cassé, du code copié quinze fois, du code sous licence que tu n'as pas le droit de toucher. Poolside le dit très poliment dans son article : les jeux de données existants contiennent des quantités considérables de contenu qui ne servent tout simplement à rien, comme des publicités.

Alors ils filtrent en plusieurs passes. D'abord du grossier, à la machette : les insultes, la haine, les pubs. Ensuite du plus fin, sur les caractéristiques du document. Ensuite, et c'est là que ça devient intéressant, ils regroupent automatiquement les documents par sujet et ils jettent des paquets entiers quand le modèle a visiblement du mal à apprendre quoi que ce soit dessus.

Le résultat annoncé : environ 5 % de mieux en moyenne sur les tests, et jusqu'à 150 % sur certains.

Cent cinquante pour cent. Sans toucher au modèle, sans ajouter une seule carte graphique, sans changer une ligne de l'algorithme. Juste en faisant le ménage dans ce qu'on lui donne à lire.

Ça, c'est le genre de truc que tout développeur connaît par cœur dans un autre domaine. Tu peux optimiser ton code pendant trois jours, si ta base de données est pleine de doublons pourris, tu perds ton temps. Entrée pourrie, sortie pourrie. La règle n'a pas changé depuis les cartes perforées, elle coûte juste beaucoup plus cher à ignorer maintenant.

Le poste que je trouve le plus malin de toute l'usine

Poolside fait des modèles de code. Et pour un modèle de code, il existe un juge que les autres domaines n'ont pas : la machine.

Quand un modèle écrit un poème, personne ne peut dire objectivement si c'est bon. Quand il écrit une fonction, si. Tu la lances. Elle compile ou elle ne compile pas. Les tests passent ou ils ne passent pas. Il n'y a pas de débat, pas d'avis, pas de note subjective : ça marche ou ça ne marche pas.

Alors ils ont construit une plateforme qui fait exactement ça, à très grande échelle. Le modèle propose du code, la machine l'exécute pour de vrai, les tests tranchent, et le résultat remonte au modèle sous forme de note. Bien joué, tu recommences. Raté, tu changes.

La seule note qui ne se discute pas. Le compilateur ne fait pas de politesse, lui.

Et cette boucle tourne en continu, sans jamais s'arrêter. Le modèle n'apprend pas à écrire du code qui a l'air correct, il apprend à écrire du code qui passe. La nuance est énorme, et c'est précisément là que se joue la différence entre un assistant qui te sort quelque chose de plausible et un assistant qui te sort quelque chose qui tourne.

Pour construire ça, il faut savoir exécuter du code inconnu, potentiellement dangereux, en continu et en parallèle, sans que ça mette le feu à ton infrastructure. Ce n'est pas une petite affaire d'ingénierie. C'est même, à mon avis, la pièce qui vaut le plus cher dans le lot.

Le deuxième nettoyage : le modèle lui-même

Deuxième question qu'on se pose rarement : pourquoi faut-il finir un modèle avant de le sortir ? Il est entraîné, il a tout lu, il devrait marcher, non ?

Non. Et l'explication est presque comique.

Ce qui sort du four, ce qu'on appelle le modèle de base, sait une quantité de choses ahurissante et ne sait rien faire. Poolside le formule très bien : les modèles de base sont savants, mais ils ne sont pas bons pour résoudre des problèmes. Parce que ce qu'on lui a appris, ce n'est pas à répondre. C'est à continuer.

Alors tu lui écris « comment trier une liste ? », et lui, très sérieusement, te répond « comment trier un tableau ? comment trier un fichier ? comment trier... ». Il ne se moque pas de toi. Il a vu passer des milliards de pages web, il a compris que dans la vraie vie une question est très souvent suivie d'autres questions, et il fait exactement ce pour quoi il a été entraîné : la suite.

À gauche, il a tout lu. Vraiment tout. Il ne peut juste rien en faire pour toi.

Le poste des finitions sert à ça. On lui montre d'abord des milliers d'exemples de la bonne façon de se comporter : on pose une question, on donne une réponse, on s'arrête. C'est ce qui lui donne un comportement prévisible et, accessoirement, ce que les gens appellent sa personnalité. Puis on lâche la grosse artillerie, la boucle du poste 3, celle qui exécute et qui note, pour lui apprendre à tenir un raisonnement long et à ne pas abandonner au milieu d'un problème compliqué.

Le premier passage sert de démarrage à chaud pour le second. On dégrossit à la main, puis on affine à l'exécution. Et à la sortie, tu as quelque chose que tu peux donner à un être humain sans qu'il te regarde bizarrement.

Alors pourquoi Nvidia ? Ils préparent leurs propres modèles ?

C'est la question qui vient naturellement, et la réponse va peut-être te surprendre : ils n'en préparent pas, ils en sortent déjà.

Nvidia publie depuis un moment une famille de modèles ouverts qui s'appelle Nemotron, en trois tailles, et ils ne se contentent pas de donner le fichier final : ils publient aussi les jeux de données et les méthodes qui ont servi à le fabriquer. Ils ont même monté une coalition avec d'autres acteurs pour construire des modèles de haut niveau en public. Donc le débat « est-ce que Nvidia va faire ses modèles » est déjà tranché depuis longtemps. Ce qui leur manquait, ce n'était pas l'envie, c'était la vitesse.

Et puis il y a une raison plus terre à terre. Nvidia vend les cartes. Toutes les cartes, ou presque. Une chaîne d'outils qui sait vraiment tirer parti de ces cartes, qui les fait tourner à plein au lieu de les laisser attendre, qui rattrape les pannes toute seule, ça augmente mécaniquement la valeur de chaque carte vendue. Ils appellent leurs centres de données des usines à IA depuis des années. Ils viennent d'acheter une usine. C'est cohérent, il faut leur reconnaître ça.

Le troisième point est plus discret. Ce n'est ni un rachat ni un débauchage, la lettre aux investisseurs prend soin de l'écrire noir sur blanc, parce qu'une acquisition passe devant les autorités de la concurrence et peut y rester des mois, alors qu'une licence plus des embauches, beaucoup moins. Ce n'est ni nouveau ni illégal, c'est juste devenu la forme habituelle des grosses opérations du secteur.

Et l'autre côté de l'histoire, qui est nettement moins glorieux

Parce qu'on peut se demander pourquoi une boîte qui vient de construire une machine à six milliards accepte de la licencier et de laisser partir l'équipe qui la faisait tourner.

La réponse est brutale, et son cofondateur l'a dite lui-même. Ils avaient une fenêtre de six semaines pour lever deux milliards de dollars destinés à payer un ensemble de 40 000 cartes qui devait démarrer en janvier. Ils n'ont pas bouclé à temps. Ils ont perdu l'ensemble.

Voilà. Ils avaient la recette, l'équipe, l'usine, et plus de four.

Le même cofondateur ajoute que la contrainte du moment n'est pas seulement l'argent, mais l'espace physique dans les centres de données et le calcul déjà réservé. Autrement dit : même avec le chèque, il faut que quelqu'un ait construit le bâtiment. Et il précise que moins de 70 personnes ont construit ce modèle, moins de 115 en comptant toute l'ingénierie et la recherche.

Regarde bien ce chiffre, puis regarde les 109 personnes embauchées par Nvidia. C'est pratiquement toute l'équipe. Ce qui confirme ce que je disais au début : cette usine n'existe pas sans les gens qui savent la faire tourner. On n'achète pas un manuel, on achète une compétence qui vit dans une centaine de têtes.

Bon, et toi là-dedans ?

Il faut être honnête : aujourd'hui, rien. Tu ne verras jamais cette machine, tu ne l'utiliseras jamais, et elle ne changera pas ta journée de demain.

Mais il y a deux conséquences bien réelles, et la première est plutôt une bonne nouvelle.

Les modèles gratuits que tu peux télécharger et faire tourner chez toi sortent exactement de ces usines-là. Le modèle de code de Poolside est à poids ouverts, c'est-à-dire que le fichier final est public et s'installe sur ta machine. Meta a fait la même chose il y a onze jours avec un modèle qui tourne sur une carte graphique de joueur. Chaque progrès de ces chaînes de fabrication finit, avec quelques mois de retard, dans un fichier que tu peux poser sur ton disque dur sans compte, sans abonnement et sans envoyer une ligne de ton travail à qui que ce soit. Pour du code sous contrat ou juste pour du code que tu n'as pas envie de voir partir, ce n'est pas un détail.

Le hangar coûte deux milliards. Ce qui en sort finit sur ton bureau, et c'est gratuit. Cherchez l'erreur.

La seconde conséquence est moins réjouissante. Si la valeur est désormais dans l'usine, et qu'une usine se paie six milliards, alors le nombre de maisons capables d'en tenir une se compte bientôt sur les doigts d'une main. Poolside avait la meilleure équipe possible et s'est fait sortir par un problème de calendrier bancaire. Ça donne la mesure du ticket d'entrée.

Quant à savoir quand tout ça se voit dans ta vie de tous les jours : c'est déjà le cas, en fait. L'assistant qui complète tes phrases, celui qui trie tes photos, celui qui te répond quand tu appelles un service client, ils sont tous sortis d'une chaîne comme celle-là. Tu n'as juste jamais vu l'atelier.

Ce qu'il faut prendre avec des pincettes

Les montants viennent d'une lettre aux investisseurs révélée par la newsletter Newcomer, pas d'un document déposé auprès d'un régulateur. Bloomberg, The Next Web et The Decoder confirment tous les trois les six milliards, mais une reprise de flux annonçait six cents millions : je retiens le chiffre des trois sources concordantes et je te dis d'où il vient.

Ensuite, personne n'a publié l'inventaire exact de ce que couvre la licence. Poolside a décrit son usine publiquement, ce qui est déjà remarquable, mais entre un article de blog technique et une liste contractuelle il y a de la marge. On sait ce que Nvidia paie. On ne sait pas exactement ce qu'il reçoit.

Enfin, les chiffres de pannes que je t'ai montrés viennent de Meta et concernent l'entraînement de Llama 3, pas celui de Poolside. Ce sont des ordres de grandeur du métier, pas les mesures de cette usine-ci. Poolside n'a pas publié les siennes.

Ce que j'en pense

Ce qui me plaît dans cette histoire, c'est qu'elle remet les choses à l'endroit. Pendant trois ans on nous a vendu des modèles comme on vend des voitures, avec des classements, des noms qui claquent et des courbes qui montent. Et il se trouve que la vraie valeur était derrière, dans l'atelier, dans les scripts qui redémarrent un travail à trois heures du matin parce qu'une carte a lâché, dans les filtres qui jettent les pubs, dans la plateforme qui exécute le code au lieu de le croire sur parole.

C'est le genre de leçon que tout développeur finit par apprendre à ses dépens. La valeur d'un projet n'a jamais été dans le livrable, elle est dans la capacité à le refaire. Perds ta chaîne de compilation et tu n'as plus rien, même avec le binaire dans les mains.

Et puis il y a un truc que je trouve assez beau, quand même. Toute cette débauche de moyens, cette salle grande comme un hangar, ces seize mille cartes qui tombent en panne toutes les trois heures, ces filtres, ces tests, ces millions d'exécutions, tout ça pour aboutir à un fichier que quelqu'un va télécharger gratuitement et faire tourner sur la tour qu'il a montée lui-même dans son salon.

Alors si tu fais partie de ceux qui téléchargent ces modèles pour les faire tourner chez eux, sache que tu es le bout d'une chaîne à deux milliards de dollars. Profites-en bien, et pense de temps en temps aux trois gars qui se sont levés la nuit !

Sources

• Poolside : The Model Factory, la description de la plateforme par ses auteurs
• Poolside : Gathering and processing raw materials for the Model Factory, le nettoyage des données et les gains mesurés
• Poolside : The finishing touches, ce que fait le post-entraînement
• Meta : The Llama 3 Herd of Models, section 3.3.4 et tableau 5, les 466 interruptions et les 3 interventions humaines
• Newcomer : Poolside Strikes 6 Billion Licensing Deal with Nvidia, la lettre aux investisseurs, 21 août 2026
• The Decoder : Nvidia is acquiring Poolside's Model Factory and 109 employees
• Latent Space, les propos d'Eiso Kant sur le cluster perdu et la taille de l'équipe
• Nvidia : Nemotron Labs, How Open Models Give Enterprises and Nations AI They Can Trust