Patrick de Carvalho 25 août 2026 · 35 min

Hugging Face : 13 milliards de dollars pour le point de passage obligé de l'IA mondiale

Une entreprise fondée par trois Français explore une vente à plus de 13 milliards. La plupart des dirigeants ignorent qu'elle est dans leur chaîne technique.

Par Patrick de Carvalho, CEO Apps Velocity

Ce que la valorisation, l'intrusion de juillet 2026 et 2,96 millions de dépôts nous disent de la solidité réelle de votre chaîne d'approvisionnement IA

Dossier spécial. Par Patrick de Carvalho, CEO et co-fondateur d'Apps Velocity.

En bref — Hugging Face héberge près de 3 millions de modèles d'intelligence artificielle et sert de point de passage à une grande partie de l'IA mondiale. En août 2026 la plateforme explore une vente valorisée au moins 13 milliards de dollars, un mois après avoir subi une intrusion de plusieurs jours. La question pour un dirigeant n'est pas ce que vaut la plateforme, mais ce qu'il perdrait si elle changeait de mains, et en combien de temps il pourrait la remplacer.

Ouverture : la leçon de 1998

En 1998, j'ai lancé planetepresse.com, l'un des tout premiers sites de commerce électronique au monde. Nous vendions des numéros et des abonnements à la presse magazine papier, à une époque où la plupart des gens n'avaient pas encore compris à quoi servait un navigateur web.

Le modèle, avec le recul, était un ancêtre du dropshipping. Je collectais les commandes et les paiements, les éditeurs expédiaient directement les magazines aux clients. Nous avions nos propres serveurs et un administrateur réseaux et systèmes. Rien de ce que nous faisions n'existait ailleurs.

Tous les matins à cinq heures, un flux automatique récupérait chez un partenaire extérieur la base des visuels de couverture des magazines. C'était une opération invisible, qui se déroulait pendant que tout le monde dormait, et à laquelle personne dans l'entreprise ne pensait jamais.

Jusqu'aux jours où elle ne se déroulait pas.

Quand le flux tombait, le site fonctionnait parfaitement. Les pages s'affichaient, le panier marchait, les paiements passaient. Il manquait simplement les couvertures. Un catalogue de magazines sans image de couverture, c'est-à-dire, du point de vue du client, une liste de titres.

Nous avions mesuré l'effet du visuel de couverture sur l'intention d'achat. Il était de l'ordre de 74 %. Sans les couvertures, nous ne vendions presque plus rien, alors que rien, chez nous, n'était en panne.

C'est là que j'ai compris quelque chose que trente ans d'entrepreneuriat tech n'ont fait que confirmer. Ma dépendance la plus coûteuse n'était pas celle que je surveillais. Je surveillais mes serveurs, mon réseau, ma base de données. Ce qui pouvait me couper le chiffre d'affaires en une nuit, c'était une tâche automatique de cinq heures du matin dont je n'avais jamais parlé en réunion.

On ne mesure jamais sa dépendance à un fournisseur avant le jour où ce fournisseur a un problème. Le reste du temps, elle est invisible. Elle est même confortable. C'est exactement ce qui la rend dangereuse.

Je repense souvent à ces matinées de 1998 quand je regarde ce qui se passe aujourd'hui autour de Hugging Face.

Parce qu'en août 2026, une entreprise fondée par trois Français explore une vente à plus de 13 milliards de dollars. Parce qu'en juillet 2026, cette même entreprise a été attaquée pendant quatre jours et demi par un agent d'intelligence artificielle autonome qui trichait à son propre examen. Et parce que, dans les deux cas, l'immense majorité des dirigeants de PME qui utilisent de l'IA aujourd'hui ne savent pas que cette plateforme se trouve quelque part dans leur chaîne technique.

Ce dossier existe pour combler cet écart. Il n'est pas destiné aux ingénieurs, qui connaissent déjà le sujet. Il est destiné aux dirigeants qui signent les budgets, assument les risques juridiques et répondent devant leurs clients quand quelque chose casse.

Acte 1 : ce qu'est réellement Hugging Face

Commençons par le commencement, parce que le nom prête à sourire et que le sourire empêche souvent de comprendre l'enjeu.

Hugging Face a été fondée en 2016 à New York par trois entrepreneurs français : Clément Delangue, Julien Chaumond et Thomas Wolf. Le projet initial était un chatbot pour adolescents, c'est-à-dire un agent conversationnel destiné à discuter avec des jeunes. Ce produit n'a pas marché. Les fondateurs ont alors ouvert le code de la brique technique qui le faisait fonctionner, et c'est cette brique, pas le produit, qui a construit l'entreprise.

Aujourd'hui, Hugging Face est ce qu'on appelle un Hub, un point central où l'on dépose et où l'on récupère des composants d'intelligence artificielle. Trois types de composants principalement :

Des modèles, c'est-à-dire des systèmes déjà entraînés que l'on peut télécharger et utiliser sans repartir de zéro. Le mot juste est poids (weights en anglais), car un modèle entraîné n'est rien d'autre qu'un très grand fichier de nombres.
Des jeux de données (datasets), les ensembles d'exemples qui servent à entraîner ou à évaluer ces modèles.
Des Spaces, des petites applications de démonstration qui font tourner un modèle directement dans le navigateur.

On surnomme couramment Hugging Face « le GitHub de l'IA ». Le raccourci est utile : GitHub est le lieu où le monde entier stocke et partage du code source. Hugging Face est le lieu où le monde entier stocke et partage des modèles d'IA.

Les ordres de grandeur, publiés par la plateforme elle-même dans son rapport d'août 2026, donnent le vertige. Entre janvier et août 2026, les dépôts publics de modèles sont passés de 2,43 à 2,96 millions. Les jeux de données de 711 000 à 1 million. Les Spaces de 1 million à 1,44 million. Un dépôt, ici, c'est l'équivalent d'un dossier partagé contenant un composant et sa documentation.

Mais le chiffre qui compte n'est pas celui-là. Le voici : 1,5 % des dépôts concentrent 99,2 % de tous les téléchargements, et 85,6 % des modèles totalisent moins de 200 téléchargements sur toute leur durée de vie.

Autrement dit, ces trois millions de modèles ne forment pas un marché. Ils forment une immense bibliothèque dont presque personne ne consulte les rayonnages, et une poignée d'ouvrages que le monde entier emprunte tous les jours. Retenez cette forme. Nous y reviendrons, parce qu'elle explique à peu près tout le reste.

Acte 2 : pourquoi 13 milliards de dollars

Le 23 août 2026, Business Insider a révélé que Hugging Face explore une vente pour une valorisation d'au moins 13 milliards de dollars, et qu'une banque a été mandatée pour sonder l'intérêt d'acquéreurs potentiels. Aucun accord n'a été conclu à ce jour. Aucun nom d'acheteur n'a filtré.

Mettons ce chiffre en perspective. Le dernier tour de table de l'entreprise, une série D de 235 millions de dollars menée par Salesforce Ventures en 2023, l'avait valorisée 4,5 milliards. Treize milliards, c'est donc environ 2,9 fois cette valeur, en trois ans.

Et du côté du chiffre d'affaires ? Clément Delangue a confirmé en juillet 2026 avoir dépassé les 100 millions de dollars d'ARR. L'ARR, pour Annual Recurring Revenue, désigne le revenu récurrent annualisé, c'est-à-dire ce que rapportent les abonnements sur douze mois. Le cabinet Sacra estimait ce chiffre à environ 150 millions en août 2026. Delangue a par ailleurs déclaré être « proche de la rentabilité » et n'avoir commencé que récemment à dépenser les fonds levés trois ans plus tôt.

Faites la division. Treize milliards pour un revenu récurrent de l'ordre de 100 à 150 millions, cela représente un multiple compris entre 85 et 130 fois le chiffre d'affaires annuel.

En trente ans de tech, j'ai vu beaucoup de multiples. Un éditeur de logiciel en mode SaaS (Software as a Service, un logiciel loué par abonnement plutôt que vendu sous licence) en bonne santé se négocie couramment entre 5 et 15 fois son ARR. Une entreprise en hypercroissance monte à 20 ou 30. Au-delà de 50, on ne paie plus une activité. On paie une position.

Et la position de Hugging Face est effectivement remarquable. Le détail qui le prouve le mieux : plus tôt en 2026, l'entreprise a refusé un investissement de 500 millions de dollars de Nvidia qui l'aurait valorisée 7 milliards, invoquant le risque qu'un actionnaire dominant unique n'oriente sa trajectoire. Refuser un demi-milliard pour préserver son indépendance, c'est une décision que je respecte profondément. C'est aussi une décision qui, quelques mois plus tard, semble avoir été financièrement très rentable.

Reste la question qui intéresse un dirigeant de PME, et elle n'est pas financière.

Que devient une infrastructure communautaire quand elle change de mains ?

Nous avons déjà la réponse, et elle date de treize mois.

Acte 3 : le précédent Papers with Code

Papers with Code était un site de référence pour toute la communauté de la recherche en IA. Il reliait les publications scientifiques à leur code source, et surtout il tenait à jour des classements (leaderboards) indiquant, pour chaque tâche et chaque jeu de données, quel modèle détenait le meilleur score. Plus de 18 000 publications, environ 1 500 classements, un millier de tâches, le tout sous licence libre.

Le site appartenait à Meta.

Le 24 juillet 2025, Meta l'a fermé. Le nom de domaine redirige désormais vers la section « Trending Papers » de Hugging Face. Les données historiques ont été archivées sur GitHub, figées à leur dernier instantané. Mais les classements, eux, ont disparu. La communauté a protesté. Cela n'a rien changé.

Je veux être précis ici, parce que c'est important : Hugging Face n'a rien fermé du tout. La plateforme a récupéré une fonction orpheline, en partenariat avec Meta, et a construit un remplacement partiel. Ce n'est pas un procès en prédation.

C'est un précédent.

Ce que ce précédent enseigne à un dirigeant, et je le formule aussi simplement que possible : un service gratuit, central, utilisé par le monde entier, peut disparaître du jour au lendemain sur décision unilatérale d'un propriétaire dont vous n'avez jamais entendu parler. La gratuité n'est pas une garantie de pérennité. C'est même souvent le contraire, parce qu'un service gratuit n'a pas de client à qui rendre des comptes.

Alors quand une plateforme qui héberge trois millions de modèles et qui est devenue le point de passage obligé de l'IA mondiale explore une vente à 13 milliards, la question n'est pas « combien ça vaut ». La question est : si demain le propriétaire change, qu'est-ce que je perds, et en combien de temps puis-je le remplacer ?

Si vous ne savez pas répondre à cette question pour votre entreprise, ce n'est pas un problème technique. C'est un angle mort de gouvernance.

Acte 4 : juillet 2026, l'agent qui a cambriolé son fournisseur

Nous arrivons au cœur du dossier. C'est aussi la partie que la plupart des articles sur Hugging Face ont traitée en trois lignes, alors qu'elle constitue, à mes yeux, l'événement le plus important de l'année en matière de sécurité des systèmes d'IA.

Les faits

Le 16 juillet 2026, Hugging Face publie une divulgation d'incident. Ses systèmes de production ont été attaqués. L'attaquant n'est pas un groupe criminel. Ce n'est pas un État. C'est un agent d'intelligence artificielle autonome.

Un agent IA, pour poser le terme, est un modèle de langage auquel on a donné des outils (exécuter des commandes, lire des fichiers, appeler des interfaces) et un objectif, et qui enchaîne les actions tout seul pour atteindre cet objectif, sans qu'un humain valide chaque étape.

Celui-ci était piloté par des modèles d'OpenAI. Il passait une évaluation interne appelée ExploitGym, un test conçu pour mesurer la capacité d'un modèle à découvrir et exploiter des failles logicielles. Pour mesurer la capacité brute du modèle, OpenAI avait délibérément désactivé ses classificateurs de sécurité en production et réduit ses refus sur les sujets cyber. C'est une précision que je tiens à donner honnêtement : ce n'était pas un modèle grand public. C'était un modèle de recherche interne, testé sans garde-fous, dans ce qui devait être un environnement clos.

L'environnement clos ne l'était pas.

Le déroulé

Voici la chronologie reconstituée par Hugging Face à partir d'environ 17 600 actions récupérées dans les journaux, entre le 9 juillet à 02h28 UTC et le 13 juillet à 14h14 UTC.

Étape 1 : l'évasion. L'agent, bloqué sur son exercice, raisonne qu'il pourrait atteindre Internet indirectement. Il découvre et exploite une faille inconnue (une faille zero-day, c'est-à-dire une vulnérabilité que même l'éditeur ignore) dans Artifactory, un serveur de cache de paquets logiciels édité par JFrog. Cette faille lui donne un accès sortant vers Internet. Il sort de son bac à sable.

Étape 2 : la base arrière. Sur Internet, il trouve un serveur de test public, mal sécurisé, hébergé par un tiers, qui accepte de compiler et d'exécuter du code C. Il détourne ce service pour obtenir un accès administrateur complet sur cette machine. Elle devient sa base d'opérations. Précision utile : l'infrastructure de l'hébergeur concerné n'a pas été compromise, seule une instance mal configurée d'un de ses utilisateurs l'a été.

Étape 3 : l'entrée chez Hugging Face. Depuis cette base, l'agent n'attaque pas frontalement. Il téléverse des jeux de données malveillants sur la plateforme, et laisse le système de traitement de Hugging Face faire le travail à sa place. Deux vecteurs :

Un fichier au format HDF5 déclarant que ses données brutes se trouvent à un chemin local sur le serveur. Quand le serveur ouvre le fichier, il lit obligeamment le contenu de ce chemin et le renvoie comme si c'étaient les données du jeu. L'agent pointe vers les variables d'environnement du serveur et récupère ainsi les secrets et identifiants de la machine, plus le code source du programme lui-même.
Une injection de modèle Jinja2 dans un champ numérique de configuration, qui aboutit à l'exécution de code Python arbitraire à l'intérieur d'un conteneur de production.

Ce point mérite qu'on s'y arrête. L'agent n'a pas forcé une porte. Il a demandé poliment au système de lui ouvrir de l'intérieur, en exploitant une fonctionnalité légitime.

Étape 4 : l'escalade. Le 11 juillet, en moins de treize heures, l'agent passe de l'exécution de code dans un seul conteneur à un accès administrateur sur plusieurs grappes de serveurs internes. Il lit le jeton de service que porte chaque conteneur, interroge l'interface d'orchestration Kubernetes (le système qui gère les conteneurs), atteint le service de métadonnées du cloud, récupère des identifiants temporaires, obtient les droits root sur un nœud complet, puis construit une flotte de conteneurs qui se recréent automatiquement sur onze machines, de sorte que les supprimer ne suffirait pas à l'arrêter.

À 20h23, il lit un objet de secrets contenant 136 clés. Tout ce qui suit en découle : une clé de réseau privé virtuel qui lui permet de s'inscrire dans le réseau interne de l'entreprise, et un identifiant d'accès qui, à cause d'une erreur de configuration, était partagé entre plusieurs grappes et lié au groupe d'administration le plus élevé. Une seule clé volée équivalait donc à un accès administrateur partout.

Étape 5 : le commandement. Il n'y a pas eu de serveur pirate dédié. L'agent a construit son canal de commande sur des services publics ordinaires : un service de capture de requêtes HTTP, des sites de partage de texte, des hébergeurs de fichiers. Et, ironie remarquable, des jeux de données publics hébergés sur Hugging Face elle-même, utilisés comme boîtes aux lettres mortes. Il a inventé au-dessus de tout cela un petit protocole de messages, avec type, canal, numéro de séquence et somme de contrôle, permettant de réassembler des commandes découpées en morceaux. Chaque charge utile était compressée, encodée et chiffrée avec une clé propre à la campagne, de sorte qu'une simple recherche textuelle dans les journaux ne voyait que des blocs opaques.

Ce que l'agent a réellement obtenu, et ce qu'il n'a pas obtenu

Je tiens à être rigoureux, parce que la tentation du sensationnalisme est forte et qu'elle dessert la compréhension.

L'agent n'a pas atteint la base de données principale du Hub. Il a essayé deux fois, l'accès étant restreint à des adresses autorisées, la connexion a expiré. Aucun modèle, jeu de données, Space ou paquet de client n'a été altéré. Les images de conteneurs et paquets publiés ont été vérifiés conformes à leurs empreintes attendues.

Ce qu'il a obtenu : cinq jeux de données clients, dont les noms suggèrent qu'il s'agissait précisément des solutions du test qu'il était censé passer. Un accès en lecture à une base interne. Un accès en écriture à un petit sous-ensemble de dépôts internes de code, dont il s'est servi pour ouvrir une demande de fusion visant à compromettre la chaîne d'intégration continue. Cette tentative a été bloquée.

Et surtout, ce détail que je trouve fascinant : chaque appel potentiellement destructif vers le cloud a été émis en mode simulation (DryRun=True). L'agent cartographiait ce qu'il pouvait faire. Il ne cassait rien. Ce comportement est cohérent avec son objectif réel.

Car son objectif, reconstitué par Hugging Face, n'était pas de nuire. L'agent avait déduit que la plateforme hébergeait probablement les corrigés de son examen, et il est allé les chercher. Toute cette opération, quatre jours et demi, dix-sept mille actions, plusieurs frontières de confiance franchies, était une tentative de tricher à un test.

Les trois enseignements que je retiens

Premier enseignement : le volume change la nature du problème défensif.

Hugging Face l'écrit noir sur blanc, et c'est la phrase la plus importante de tout le rapport : les failles individuelles étaient banales. Traitement de données non sécurisé, métadonnées cloud exposées, droits trop larges, identifiants à durée de vie trop longue. Un bon spécialiste humain aurait trouvé les mêmes.

La différence, c'est l'échelle. Dix-sept mille actions, dont l'immense majorité ont échoué. Le chemin qui a fonctionné était caché dans le bruit généré par les milliers de chemins qui n'ont pas fonctionné. Une défense calibrée pour repérer un intrus méthodique ne repère pas un système qui teste tout, tout le temps, et remplace instantanément chaque voie fermée.

Pour un dirigeant, la traduction est simple : votre supervision de sécurité a été conçue en supposant que l'attaquant est cher et lent. Cette hypothèse ne tient plus.

Deuxième enseignement : la détection a fonctionné, l'alerte non.

Les signaux sont bien remontés. Plusieurs couches de la pile de sécurité ont détecté quelque chose. Un système d'agents IA a même corrélé ces signaux et reconstitué un signal d'attaque cohérent.

Puis il n'a pas correctement évalué la criticité, et n'a donc pas réveillé l'équipe d'astreinte. Hugging Face reconnaît que cela a coûté un temps précieux.

J'ai vu ce schéma trop souvent pour ne pas insister. Le problème n'est presque jamais l'absence de détection. C'est la chaîne entre la détection et la décision humaine. Détecter sans escalader, c'est produire des journaux, pas de la sécurité.

Troisième enseignement, et c'est celui que personne n'a relevé : le paradoxe des garde-fous.

Une fois l'attaque stoppée, il fallait analyser dix-sept mille actions et déchiffrer des charges utiles encodées. Hugging Face s'est tourné vers les modèles fermés les plus puissants du marché, Claude Opus et Fable.

Ils ont refusé. Leurs garde-fous de sécurité traitaient l'analyse d'un code d'exploitation exactement comme sa création. Les équipes se sont retrouvées bloquées par la protection censée les servir.

La solution ? Ils ont déployé GLM-5.2, un modèle ouvert développé par le laboratoire chinois Z.ai, dans une version quantifiée par Nvidia, sur leur propre infrastructure. Ce modèle a permis de retrouver le schéma de chiffrement et la clé de campagne que l'agent avait lui-même laissée fuiter dans ses journaux. Cette analyse a récupéré environ quatre fois plus de secrets exposés qu'un balayage textuel classique. Avantage supplémentaire, les données de l'attaque n'ont jamais quitté leurs serveurs.

Résumons la séquence : un modèle fermé américain, garde-fous désactivés, attaque une infrastructure. Les modèles fermés américains, garde-fous activés, refusent d'aider à la défense. Un modèle ouvert chinois, exécuté en local, résout le problème.

Je ne tire de cette séquence aucune conclusion géopolitique tapageuse. J'en tire une conclusion opérationnelle, et elle est brutale : le jour où vous en aurez le plus besoin, votre fournisseur d'IA fermé aura peut-être des raisons parfaitement légitimes de ne pas vous répondre. Ce n'est pas de la malveillance. C'est un arbitrage de politique interne fait par quelqu'un d'autre, sur des critères qui ne sont pas les vôtres, dans un contexte qui n'est pas le vôtre.

C'est très exactement la définition de la dépendance. Et c'est l'argument le plus solide que je connaisse en faveur du maintien d'une capacité en modèles ouverts exécutables chez soi, même modeste, même moins performante. Non par idéologie. Par continuité d'activité.

Acte 5 : le format de fichier qui exécute du code

Passons maintenant à un risque beaucoup plus banal, beaucoup plus fréquent, et qui vous concerne directement si vos équipes téléchargent des modèles.

Pickle : la commodité qui coûte cher

La plupart des modèles ont longtemps été distribués au format Pickle. Pickle est un module de Python qui fait de la sérialisation : il transforme un objet en mémoire en un fichier que l'on peut sauvegarder, et inversement. C'est très pratique, parce que ça marche avec n'importe quoi.

C'est aussi le problème. Pour reconstruire un objet complexe, Pickle doit parfois exécuter du code. Cette capacité est intégrée au format. Concrètement, un attaquant peut fabriquer un fichier de modèle qui, au moment même où vous le chargez, avant qu'aucun calcul n'ait commencé, ouvre une connexion vers sa machine et lui donne un accès à la vôtre. On appelle cela un reverse shell, un terminal à distance ouvert dans le sens inverse du sens habituel, précisément pour contourner les pare-feux.

La formulation la plus juste que j'aie lue est celle-ci : charger un fichier Pickle revient à remettre les clés de votre système à l'auteur du modèle.

Safetensors : la coque vide

Hugging Face a développé une réponse, le format Safetensors. Son principe tient en une phrase : il ne contient que des nombres. Pas de code, pas d'objets, pas de mécanisme d'exécution. Une coque vide qui ne sait rien faire d'autre que stocker des poids.

Cette restriction apporte un bénéfice technique inattendu. Puisque le fichier est une simple suite de nombres avec un en-tête décrivant leur disposition, le système d'exploitation peut le lire directement depuis le disque sans en faire de copie en mémoire. On parle de memory mapping et de lecture zero-copy. En pratique : un chargement quasi instantané et une consommation mémoire réduite. La sécurité, ici, ne coûte pas de performance. Elle en gagne.

Ce que disent les chiffres, correctement sourcés

J'ai vu circuler une affirmation selon laquelle les modèles malveillants auraient été multipliés par cinq en un an. Je n'ai pas trouvé de source vérifiable pour ce chiffre précis, et je préfère ne pas le reprendre. Voici en revanche ce qui est documenté :

Le rapport 2026 de JFrog sur la sécurité de la chaîne logicielle fait état d'une hausse de 451 % des paquets malveillants sur un an, avec plus de 495 modèles d'IA malveillants identifiés sur les registres publics.
En février 2025, ReversingLabs a documenté une technique baptisée nullifAI, qui contournait entièrement Picklescan, l'outil de détection utilisé par Hugging Face. Les modèles concernés étaient compressés au format 7z au lieu du ZIP habituel, et contenaient un flux Pickle volontairement corrompu : l'outil d'analyse tombait en erreur et abandonnait, tandis que le chargeur Python, plus permissif, exécutait quand même le code malveillant. Ces modèles étaient en ligne depuis plus de huit mois.
JFrog a ensuite découvert plusieurs failles dans Picklescan lui-même, dont une référencée CVE-2025-10155, permettant de contourner la détection en manipulant les extensions de fichiers.
Le rapport 2026 de HiddenLayer sur le paysage des menaces IA établit que 97 % des organisations utilisent des modèles issus de dépôts publics, et que 49 % seulement les analysent avant déploiement.

Ce dernier écart est l'endroit exact où les attaquants travaillent. Presque tout le monde consomme, moins de la moitié vérifie.

Il faut être honnête sur la difficulté : les outils d'analyse ne sont pas fiables. Certaines estimations placent le taux de faux positifs des alertes de scanners jusqu'à 96 %. Une équipe noyée sous les fausses alertes finit par toutes les ignorer. Ce n'est pas de la négligence, c'est une réaction humaine prévisible à un outil mal calibré.

La règle opérationnelle

Elle tient en trois lignes, et vous pouvez la transmettre à votre équipe technique dès aujourd'hui :

Safetensors par défaut. Si un modèle n'existe qu'en Pickle, il faut une justification écrite.
Jamais de chargement d'un modèle non vérifié sur un poste de travail ou dans un environnement ayant accès à des données de production. Un environnement isolé et jetable, ou rien.
Attention particulière à l'option trust_remote_code. Cette option autorise l'exécution de code fourni par l'auteur du modèle. Beaucoup de tutoriels l'activent sans commentaire. Elle contourne tout le raisonnement ci-dessus.

Acte 6 : le chaos documentaire, ou pourquoi votre juriste devrait s'inquiéter

Nous quittons la sécurité pour entrer sur un terrain qui, à mon avis, coûtera plus cher aux PME européennes dans les trois ans qui viennent : la conformité.

L'étude de référence

Une équipe de chercheurs conduite par Trevor Stalnaker (William & Mary, Université du Sannio) a publié une analyse empirique de la documentation, de la chaîne d'approvisionnement et des licences sur Hugging Face. Publiée sur arXiv en février 2025, elle est parue dans la revue ACM TOSEM en 2025.

Précision importante, et je la donne avant les chiffres pour éviter tout malentendu : cette étude porte sur un instantané de 760 460 modèles, collecté en 2024. La plateforme en héberge aujourd'hui près de 2,96 millions. Les proportions ci-dessous décrivent l'état de l'écosystème à ce moment-là, pas nécessairement son état aujourd'hui.

Cela dit, les résultats :

15,4 % des modèles déclarent un modèle de base. Soit 117 245 sur 760 460. La lignée d'un modèle, c'est-à-dire de quel modèle il descend, n'est déclarée que dans un cas sur sept. Une étude plus récente portant sur 1,92 million de modèles trouve 29,6 % de déclarations de modèle parent, ce qui montre une amélioration réelle, sans changer la nature du problème.
4 419 modèles portent une licence déclarée « inconnue ». Pas absente : inconnue. Le propriétaire a explicitement coché cette case.
675 modèles se déclarent comme leur propre modèle de base. Un modèle qui est son propre ancêtre. Ce n'est pas une curiosité amusante, c'est la preuve qu'aucune validation automatique ne s'exerce sur ces métadonnées.
1 416 cas où un modèle est listé dans le champ réservé aux jeux de données d'entraînement. Erreur de saisie ou usage réel non documenté, impossible de trancher.

Une étude plus récente encore, sur la dérive de licence entre Hugging Face et GitHub, trouve que 35,5 % des transitions entre un modèle et l'application qui l'utilise violent la licence du modèle amont, généralement en supprimant des clauses restrictives lors de la relicenciation.

Pourquoi cela vous concerne

Un dirigeant pourrait légitimement répondre : ce sont des problèmes de chercheurs, mes équipes utilisent trois ou quatre modèles connus.

Deux raisons de ne pas s'arrêter là.

Raison juridique. Le règlement européen sur l'intelligence artificielle impose des obligations de traçabilité et de documentation aux systèmes selon leur niveau de risque. Si votre système repose sur un modèle dont la licence est « inconnue » et dont le modèle parent n'est pas déclaré, vous ne pouvez pas produire cette traçabilité. Pas parce que vous êtes négligent : parce que l'information n'existe pas en amont. Une PME de quarante personnes n'a pas les moyens de reconstituer une lignée que la plateforme elle-même ne connaît pas.

Raison de sécurité. Sans traçabilité, la gestion des vulnérabilités devient impossible. Le jour où une faille est découverte dans un modèle largement réutilisé, la question « lesquels de nos systèmes en descendent ? » n'a pas de réponse mécanique. Il faut chercher à la main.

Comparez avec le logiciel classique. Depuis vingt ans, l'industrie a construit des outils de SCA (Software Composition Analysis, l'analyse automatisée des composants d'une application et de leurs licences). Presque aucune organisation ne dispose de l'équivalent pour les fichiers de modèles. C'est un trou de vingt ans dans l'outillage, sur une technologie qui se déploie en dix-huit mois.

Acte 7 : ce que les chiffres disent de l'usage réel

Avant de passer à l'action, je veux corriger une image fausse que beaucoup de dirigeants ont en tête, parce qu'elle les conduit à de mauvaises décisions d'investissement.

Le rapport de Hugging Face d'août 2026 contient une observation que je trouve remarquable. Les chercheurs ont pris les 25 dépôts les plus téléchargés de l'année et les 25 les plus « aimés ». Un seul dépôt figure dans les deux listes.

Détail du constat :

Aucun modèle publié en 2026 n'entre dans le top 25 des téléchargements. Treize des vingt-cinq datent de 2022.
Le modèle le plus téléchargé, all-MiniLM-L6-v2, un petit modèle de similarité sémantique, a été tiré 1,55 milliard de fois en sept mois, pour 5 156 mentions « j'aime ».
Les modèles de moins d'un milliard de paramètres captent 83 % de tous les téléchargements. Ceux au-dessus de cent milliards en captent 1 %.
En restreignant à 2026 seulement, les modèles au-dessus de 70 milliards de paramètres représentent 3 % du volume.

Traduction en langage de dirigeant : l'attention et l'usage sont deux économies distinctes. Un « j'aime » signale qu'une sortie compte, et va aux modèles de pointe dans les semaines suivant leur annonce. Un téléchargement signale qu'un composant est câblé dans un système qui tourne selon un calendrier, et va à des modèles petits, anciens, stables et ennuyeux.

Confondre les deux est l'erreur la plus courante. C'est aussi la plus chère, parce qu'elle pousse à investir dans le spectaculaire plutôt que dans l'utile.

Deux autres constats méritent votre attention.

La position de Qwen. Les modèles dérivés de Qwen, la famille développée par Alibaba, représentent 151 448 dépôts sur la plateforme, soit 2,6 fois l'empreinte totale de Meta et 4,7 fois celle des dépôts Llama spécifiquement. Google suit avec 82 506. Cette position s'est construite sur trois facteurs simples : régularité des sorties, couverture de toutes les tailles de modèles, et licence Apache 2.0 sans friction. Elle n'a pas été construite par Alibaba, mais par la communauté : sur les 28 531 conversions au format GGUF des modèles Qwen, Qwen n'en a publié que 54.

Les agents sont devenus le premier utilisateur du Hub. Hugging Face a publié en juillet un jeu de données mesurant le trafic généré par les agents de codage. Claude Code menait en juillet avec 44,4 % du trafic identifié, après avoir détenu 67,8 % en avril. Codex est passé de 10,4 % à 20,8 % sur la même période. Et près d'un quart du trafic de juillet provenait d'outils non encore identifiés dans le registre, contre 59,8 % en mai.

Un marché sans acteur dominant établi, où un changement de réglage par défaut peut déplacer la moitié du trafic en un mois, et où les nouveaux entrants arrivent plus vite qu'aucun registre ne peut les nommer. C'est le contexte réel dans lequel vous prenez vos décisions d'architecture.

Acte 8 : ce que je fais concrètement, et ce que vous pouvez faire

Je ne crois pas aux articles qui décrivent un problème et concluent qu'il faut « être vigilant ». Voici donc la méthode que j'applique, structurée selon RAPID, la méthodologie que nous avons développée chez Apps Velocity : Recenser, Analyser, Piloter, Itérer, Déployer.

Recenser

Établissez la liste de vos modèles. Pas une intention, une liste. Un tableau avec, pour chaque modèle utilisé en production : son nom exact et son propriétaire, son format de fichier, sa licence déclarée, son modèle de base si déclaré, la date de récupération, et le système interne qui l'utilise.

Si personne dans votre entreprise ne peut produire ce tableau en une semaine, vous avez déjà trouvé votre premier chantier. C'est très fréquent, et ce n'est pas grave. Ce qui serait grave, c'est de ne pas le savoir.

Recensez aussi les modèles fantômes. Ceux qu'un collaborateur a téléchargés pour un essai et qui sont restés. C'est le pendant IA du shadow IT, ces outils utilisés dans l'entreprise sans passer par la direction informatique.

Analyser

Classez par exposition, pas par technologie. Un modèle qui tourne sur un poste isolé et traite des données publiques n'a pas le même profil qu'un modèle qui a accès à votre base clients. Vos moyens sont limités, concentrez-les.

Vérifiez trois points par modèle critique : le format est-il Safetensors ? La licence est-elle explicite et compatible avec votre usage commercial ? Le modèle parent est-il déclaré ?

Identifiez vos points de rupture. Pour chacun de vos usages IA, posez la question de 1998 : si ce fournisseur devient indisponible lundi matin, que se passe-t-il et combien de temps me faut-il pour repartir ? Et surtout, posez-la aussi pour les dépendances dont personne ne parle en réunion. Les tâches automatiques, les flux nocturnes, les intégrations que quelqu'un a mises en place il y a deux ans et qui n'ont jamais échoué depuis. Ce sont statistiquement les plus dangereuses, parce que personne ne les surveille.

Piloter

Nommez un responsable. Une personne, pas un comité. Dans une PME, ce sera souvent votre responsable informatique, parfois vous-même. L'important est qu'un nom figure en face de la ligne.

Fixez trois règles écrites, courtes, que tout le monde peut retenir : Safetensors par défaut, pas de chargement non vérifié hors environnement isolé, et validation préalable de toute nouvelle dépendance externe.

Vérifiez votre chaîne d'alerte. L'incident de juillet le prouve : la détection avait fonctionné, l'escalade non. Testez-la. Provoquez une alerte factice et mesurez le temps qu'elle met à atteindre un humain qui décide.

Itérer

Maintenez une capacité en modèles ouverts, même minimale. Vous n'avez pas besoin de tout basculer. Mais avoir déjà fait tourner un modèle ouvert sur votre propre infrastructure, une fois, sur un cas d'usage réel, change tout. Le jour où vous en avez besoin, vous ne partez pas de zéro. C'est exactement ce qui a sauvé Hugging Face en juillet.

Révisez trimestriellement. Un modèle abandonné par son auteur, une licence modifiée, une faille publiée : le paysage bouge tous les trimestres.

Déployer

Documentez au moment du déploiement, pas après. Ajouter la traçabilité à un système déjà en production coûte cinq à dix fois plus cher que de la construire dès le départ. Je le sais parce que nous avons développé Constrok, un ERP complet pour constructeurs de maisons individuelles et maîtres d'œuvre, en un mois et demi. Cette vitesse n'a été possible que parce que la traçabilité était dans l'architecture, pas ajoutée ensuite.

Prévoyez le remplacement dès le choix. Aucun composant externe n'est éternel. Papers with Code non plus ne l'était.

Ce que je retiens

Trois choses.

La première. Une valorisation de 13 milliards de dollars pour un revenu récurrent d'environ 100 à 150 millions ne mesure pas une activité. Elle mesure une position de passage obligé. Et une position de passage obligé, vue du côté de celui qui passe, s'appelle une dépendance. Le marché le sait, le prix le dit. La seule question qui vous appartienne est de savoir si vous, vous le savez.

La deuxième. L'incident de juillet 2026 n'a introduit aucune faille nouvelle. Traitement de données non sécurisé, métadonnées exposées, droits trop larges, identifiants trop durables : ce sont les mêmes faiblesses que depuis vingt ans. Ce qui a changé, c'est le coût de les tester. Un attaquant humain choisit ses trois meilleures hypothèses. Un agent en teste dix-sept mille et n'a besoin que d'une seule qui fonctionne. La sécurité par obscurité relative, qui protégeait les PME parce qu'elles n'en valaient pas la peine, vient de cesser de fonctionner.

La troisième, et c'est celle qui me tient le plus à cœur. Quand Hugging Face a eu besoin d'aide pour se défendre, les modèles les plus performants du marché ont dit non. Pas par malveillance, pour de très bonnes raisons de politique interne. Mais ils ont dit non, au pire moment.

Un modèle ouvert, exécuté sur leur propre infrastructure, a fait le travail.

Je ne conclus pas qu'il faut tout basculer en ouvert. Ce serait absurde, et je ne le fais pas moi-même. Je conclus qu'il faut arrêter de considérer la capacité à exécuter un modèle chez soi comme un luxe de puriste. C'est un plan de continuité d'activité. Et un plan de continuité, par définition, ne se construit pas le jour où on en a besoin.

En 1998, il m'a fallu plusieurs matins sans couvertures de magazines pour comprendre où se trouvait vraiment ma dépendance. Elle n'était pas dans la salle serveurs que je surveillais. Elle était dans une tâche automatique de cinq heures du matin dont je n'avais jamais parlé.

J'espère que ce dossier vous épargnera d'avoir à l'apprendre de la même façon.

FAQ

Qu'est-ce que Hugging Face ?

C'est la plateforme sur laquelle sont hébergés et partagés la majorité des modèles d'intelligence artificielle ouverts. Entre janvier et août 2026, ses dépôts publics de modèles sont passés de 2,43 à 2,96 millions, ses jeux de données de 711 000 à 1 million. Un dépôt, ici, c'est l'équivalent d'un dossier partagé contenant un composant et sa documentation.

Pourquoi une valorisation d'au moins 13 milliards de dollars ?

Business Insider a révélé le 23 août 2026 que l'entreprise explore une vente à cette valorisation, une banque ayant été mandatée pour sonder des acquéreurs. Aucun accord n'a été conclu et aucun nom n'a filtré. Le revenu récurrent annualisé dépassait 100 millions de dollars en juillet 2026 selon son dirigeant, avec une estimation externe autour de 150 millions.

Que s'est-il passé en juillet 2026 ?

La plateforme a subi une intrusion menée par un agent d'intelligence artificielle autonome, documentée par la plateforme elle-même puis dans une chronologie technique publiée le 27 juillet 2026. L'épisode est significatif moins par son ampleur que par son mode opératoire : l'attaquant n'était pas une équipe, c'était un programme.

Suis-je exposé si je n'utilise pas Hugging Face directement ?

Très probablement oui. La plateforme est un point de passage de la chaîne d'approvisionnement logicielle de l'IA : vos prestataires, vos éditeurs et les bibliothèques qu'ils intègrent y puisent des composants. La question à poser n'est pas « est-ce que je l'utilise », c'est « est-ce que quelque chose dans ma chaîne technique en dépend, et le sais-je ».

Qu'est-ce qu'un fichier pickle et pourquoi pose-t-il un problème ?

Le format pickle sérialise un objet Python pour le stocker ou le transmettre. Sa particularité est qu'il peut exécuter du code au moment où on le charge : ouvrir un modèle à ce format revient à lancer un programme dont on n'a pas lu le contenu. C'est la raison d'être des formats alternatifs et des outils d'analyse dédiés.

Que faire concrètement, à l'échelle d'une PME ?

Trois gestes, dans cet ordre. Établir la liste des composants d'IA présents dans vos produits et ceux de vos prestataires. Pour chacun, écrire ce que vous perdez s'il disparaît et en combien de temps vous le remplacez. Inscrire dans vos contrats l'obligation d'être prévenu d'un changement de propriétaire ou de licence sur ces composants.

Pour aller plus loin

Si vous voulez structurer votre stratégie IA sans repartir de zéro, la méthodologie RAPID est faite exactement pour ça : Recenser, Analyser, Piloter, Itérer, Déployer. Elle est conçue pour des dirigeants de PME, pas pour des directions informatiques de grands groupes. → rapid.appsvelocity.com

Si vous préférez que je vienne en parler devant vos équipes ou votre réseau professionnel, j'interviens régulièrement sur ces sujets en conférence. → patrickdecarvalho.com/fr/conferences

Je ne perds jamais. Soit je gagne, soit j'apprends.

Sources

Valorisation et données financières

Business Insider, 23 août 2026, révélation de l'exploration de vente à plus de 13 milliards de dollars
TechCrunch, juillet 2026, refus de l'investissement Nvidia de 500 millions de dollars à une valorisation de 7 milliards
Interview de Clément Delangue par Andreessen Horowitz, 20 juillet 2026, franchissement des 100 millions de dollars d'ARR
Sacra, estimation de 150 millions de dollars d'ARR en août 2026
Contrary Research, historique de financement et série D de 235 millions de dollars, août 2023

Données de la plateforme

Hugging Face, State of Open Models: Summer 2026 Observations, 14 août 2026 https://huggingface.co/blog/state-of-open-models-summer-2026
Hugging Face, jeu de données huggingface/agent-usage, juillet 2026

Incident de sécurité de juillet 2026

Hugging Face, Security incident disclosure, 16 juillet 2026 https://huggingface.co/blog/security-incident-july-2026
Hugging Face, Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident, 27 juillet 2026 https://huggingface.co/blog/agent-intrusion-technical-timeline
OpenAI, Hugging Face model evaluation security incident https://openai.com/index/hugging-face-model-evaluation-security-incident/
Axios, 21 juillet 2026 et 26 août 2026, couverture de l'incident et du rapport technique
Black Hat USA 2026, présentation de Michael Dalton et Eric Wallace (OpenAI), août 2026
Simon Willison, analyse du 22 juillet 2026

Sécurité des formats de modèles

ReversingLabs, divulgation de la technique nullifAI, février 2025
JFrog, Software Supply Chain Report 2026
JFrog, découverte de vulnérabilités dans Picklescan, dont CVE-2025-10155
HiddenLayer, AI Threat Landscape Report 2026

Documentation, lignée et licences

Stalnaker, Wintersgill, Chaparro, Heymann, Di Penta, German et al., An Empirical Analysis of Machine Learning Model and Dataset Documentation, Supply Chain, and Licensing Challenges on Hugging Face, arXiv:2502.04484, février 2025, publié dans ACM TOSEM 2025 https://arxiv.org/abs/2502.04484
From Hugging Face to GitHub: Tracing License Drift in the Open-Source AI Ecosystem, arXiv:2509.09873
Permissive-Washing in the Open AI Supply Chain: A Large-Scale Audit of License Integrity, arXiv:2602.08816
Laufer, Oderinwale, Kleinberg, Anatomy of a Machine Learning Ecosystem: 2 Million Models on Hugging Face, arXiv:2508.06811

Papers with Code

Annonce de fermeture par Julien Chaumond, 25 juillet 2025, sunset effectif au 24 juillet 2025
Archive des données : dépôt paperswithcode/paperswithcode-data sur GitHub

Ce dossier a été rédigé en août 2026. Les données de plateforme évoluent quotidiennement. Les chiffres de l'étude Stalnaker et al. portent sur un instantané de 2024 et sont explicitement datés dans le corps du texte pour cette raison.