Nvidia confirme le rachat de Hugging Face à 12,93 Md$ — les 5 dépendances que j’ai relues le soir même

Panos Petropoulos

Expert développement web · 7 septembre 2026 · 11 min de lecture

L’information est tombée le 3 septembre 2026 : Nvidia achète Hugging Face pour 12,93 milliards de dollars. L’accord définitif a été signé la veille, le closing est attendu au premier semestre 2027 sous réserve des approbations réglementaires. La réaction immédiate de la plupart des équipes a été de commenter le montant. La nôtre a été d’ouvrir les fichiers de dépendances, parce qu’une acquisition ne change presque jamais ce que les gens redoutent, et change presque toujours quelque chose que personne n’avait regardé.

Ce qui a exactement été annoncé

Le montant se décompose. 11,9 milliards de dollars vont aux actionnaires de Hugging Face, et 1 milliard supplémentaire est alloué en actions destinées à retenir les salariés. Cette ventilation est l’information la plus dense du communiqué : on ne met pas un milliard de rétention sur la table pour acquérir des dépôts Git publics. On le met pour acquérir les personnes qui maintiennent ces dépôts, et ce détail dit tout de ce qui a de la valeur dans un projet open source : pas le code, les mainteneurs.

Le reste des éléments publics est sobre. L’annonce a été relayée le jour même par TechCrunch et confirmée sur le blog officiel de Nvidia. Le dirigeant de Hugging Face a indiqué à CNBC avoir approché Nvidia plusieurs semaines avant l’accord, ce qui écarte le scénario de l’offre hostile et raconte plutôt une entreprise qui cherchait un adossement.

Ce qui ne change pas — et il faut le dire clairement

Les bibliotèques restent sous licence Apache 2.0. Une licence libre concédée sur une version donnée est irrévocable pour cette version : personne ne peut vous retirer le droit d’utiliser la version que vous avez déjà récupérée. Les modèles à poids ouverts déjà publiés le restent, aux conditions de leur licence d’origine. Et le closing n’interviendra pas avant 2027.

Il faut le dire nettement parce que la moitié des réactions lues cette semaine annonçaient la fermeture imminente de l’écosystème. Ce n’est pas ce qui se passe, et confondre une inquiétude légitime avec une urgence technique conduit à des migrations précipitées qui coûtent plus cher que le risque qu’elles prétendent couvrir.

Ce qui peut changer, en revanche, ne relève pas du droit mais de l’attention. Les projets suivent l’intérêt de ceux qui les financent : un chemin qui mène aux accélérateurs du propriétaire sera mieux testé, mieux documenté et plus rapidement corrigé qu’un chemin alternatif. Ce n’est pas de la malveillance, c’est de l’allocation de ressources. Nous avons déjà décrit ce mécanisme à propos du départ de Chris Mason et du bus factor sur btrfs : la santé d’une dépendance se lit dans l’attention qu’elle reçoit, pas dans son fichier de licence.

Les 5 dépendances à relire ce mois-ci

Voici l’exercice que nous avons fait le soir de l’annonce, sur une base de code de production française de taille moyenne. Il a pris deux heures et il a remonté trois problèmes qui n’avaient rien à voir avec Nvidia.

1. Le téléchargement de modèle au démarrage. Cherchez dans vos images Docker et vos scripts d’initialisation tout appel qui récupère un artefact depuis internet au lancement du conteneur. Chez nous, deux services le faisaient. Une indisponibilité du Hub, pour n’importe quelle raison, aurait empêché le redémarrage. Ce n’est pas un risque d’acquisition, c’est un risque d’exploitation, et il était là depuis un an.

2. Les révisions épinglées par nom, pas par empreinte. Référencer un modèle par son nom de branche revient à accepter que son contenu change sans que votre code change. Épinglez par empreinte de commit. C’est une modification d’une ligne par appel et cela transforme un artefact mouvant en artefact reproductible.

3. L’absence de miroir local des poids. Les modèles que vous servez en production doivent exister sur un stockage que vous contrôlez, avec le fichier de licence de la version exacte et sa date de récupération. C’est votre protection contre un changement de licence sur les versions futures, et accessoirement contre la panne d’un tiers.

4. Les dépendances transitives sur l’écosystème. Beaucoup de bibliothèques tirent transformers ou huggingface_hub sans que ce soit visible dans votre fichier de premier niveau. Un simple arbre de dépendances vous dira si vous en dépendez indirectement dans un service où vous ne l’imaginiez pas.

5. Le chemin matériel par défaut. Vérifiez que votre code fonctionne, même plus lentement, sur un backend autre que celui du propriétaire. Non pas parce qu’une rupture est probable, mais parce que la capacité à changer de matériel est ce qui vous donne une position de négociation le jour où les prix bougent.

Ce que ça veut dire pour une équipe française

Trois points concrets. Le premier est réglementaire : pour les organisations qui documentent leur chaîne d’approvisionnement logicielle, le changement d’actionnaire d’un fournisseur critique est un événement à consigner dans le registre, même si rien ne change techniquement. Nos confrères de WebGuard Agency traitent régulièrement ce sujet sous l’angle NIS2, où la maîtrise des fournisseurs est une exigence explicite.

Le deuxième est budgétaire. Une plateforme adossée à un actionnaire industriel finit généralement par mieux monnayer ses services gérés. Si vous utilisez des points d’accès d’inférence hébergés, inscrivez dès maintenant une ligne d’incertitude dans votre budget 2027, et gardez sous la main l’alternative auto-hébergée correspondante. Les équipes qui déploient de l’IA en entreprise trouveront chez Plug-Tech plusieurs analyses détaillées sur l’arbitrage entre inférence hébergée et inférence auto-gérée.

Le troisième est stratégique et il dépasse le cas d’espèce. La distribution des modèles ouverts est en train de se concentrer, exactement comme s’est concentrée la distribution des paquets il y a quinze ans. Les équipes qui s’en sortiront le mieux ne sont pas celles qui auront fui le plus vite, ce sont celles qui auront gardé la capacité de partir : artefacts miroirés, révisions épinglées, licences archivées. Trois pratiques, une journée de travail, et le sujet redevient une actualité qu’on lit sans stress.

Questions fréquentes