Les poids d'un modèle sont un artefact logiciel

Éditorial

Un fichier de poids téléchargé se traite comme un binaire venu d'ailleurs : provenance, intégrité, signature, format de sérialisation. On peut vérifier d'où il vient et qu'il n'a pas changé ; on ne peut pas vérifier ce qu'il fera, et c'est cette limite qui doit guider son usage.

Mis à jour le 25 septembre 2026~26 min de lecture14 sections

papy cyber

→ Lire l’explication complète de la marmotte

Un binaire qu’on télécharge comme une recette de cuisine

Il y a dans le métier une règle que l’on enseigne aux débutants avec des mines graves : on n’exécute pas un binaire téléchargé sur un site inconnu. On vérifie sa provenance, son empreinte, sa signature ; on le passe à l’analyse ; on l’installe, si possible, dans un environnement isolé. Tout le monde connaît cette règle. Beaucoup l’appliquent. Certains en ont fait une carrière.

Et puis il y a les modèles. Un fichier de plusieurs gigaoctets, publié sur une plateforme communautaire par un compte dont on ignore tout, sous un nom qui ressemble beaucoup à celui d’un modèle réputé, avec une fiche de présentation enthousiaste et un nombre de téléchargements rassurant. On le récupère avec une commande d’une ligne, on le charge avec une autre, et on le branche sur les données de l’entreprise pour voir « ce que ça donne ». Personne n’a vérifié l’empreinte. Personne ne sait qui l’a publié. Tout le monde a trouvé cela parfaitement normal, parce qu’après tout ce ne sont que des nombres.

Cet éditorial part de cette phrase, qui est fausse de deux manières distinctes.

Elle est fausse une première fois parce que ce qu’on télécharge n’est pas seulement des nombres : c’est un ensemble de fichiers, dont certains peuvent contenir du code qui s’exécute au chargement, et dont le format lui-même peut être une porte d’entrée. C’est la partie rassurante de l’éditorial, parce qu’elle a des solutions.

Elle est fausse une seconde fois, plus profondément, parce que même quand ce ne sont vraiment que des nombres, ces nombres sont un programme. Un programme qu’aucun humain n’a écrit, qu’aucun humain ne peut lire, et dont on ne peut pas prouver qu’il ne contient pas une instruction cachée. C’est la partie moins rassurante. Elle n’a pas de solution, seulement des précautions.

Les poids d’un modèle sont un artefact logiciel, et ils doivent être traités avec la discipline qu’on applique aux artefacts logiciels, plus une humilité supplémentaire que les artefacts logiciels ordinaires n’exigent pas.

Ce qu’on télécharge vraiment

Un modèle publié n’est pas un fichier. C’est un répertoire, et il vaut la peine d’en faire l’inventaire, comme on ferait celui d’un colis qui fait tic-tac.

Les poids eux-mêmes, souvent répartis en plusieurs fichiers pour les grands modèles : des tenseurs, c’est-à-dire des tableaux de nombres, sérialisés dans un format donné.

La configuration : l’architecture du réseau, ses dimensions, le nombre de couches, les paramètres d’initialisation. Un fichier texte, en général, lu par la bibliothèque qui va construire le modèle.

Le tokeniseur et ses fichiers de vocabulaire : la table qui découpe le texte en jetons et réciproquement. Anodin en apparence ; décisif en pratique, puisqu’un tokeniseur modifié change silencieusement ce que le modèle lit.

Le gabarit de conversation : le petit programme de mise en forme qui transforme une liste de messages en la séquence de texte attendue par le modèle, avec ses marqueurs de rôle. Il s’exprime souvent dans un langage de gabarits, qui est interprété au chargement ou à chaque requête.

Parfois, du code. Certains modèles utilisent une architecture qui n’est pas encore prise en charge par les bibliothèques standard ; ils livrent alors des fichiers source que la bibliothèque doit importer et exécuter pour construire le modèle. Les bibliothèques courantes demandent pour cela une autorisation explicite, sous la forme d’une option qu’il faut activer, dont le nom dit assez bien ce qu’elle fait : faire confiance au code distant.

Chacun de ces éléments est une surface. La configuration peut être malformée pour exploiter un analyseur. Le tokeniseur peut être altéré. Le gabarit peut être interprété par un moteur qui en permet trop. Le code distant est du code distant, c’est-à-dire, pour appeler les choses par leur nom, l’exécution d’un programme arbitraire écrit par un inconnu, déclenchée par un paramètre booléen. On l’active souvent parce que la fiche du modèle le demande, et l’on a raison de le faire si l’on a lu le code. On l’active en général sans l’avoir lu, ce qui est plus rapide.

Le format pickle, ou l’art d’exécuter en chargeant

Le cas le plus connu, et le plus instructif, est celui des formats de sérialisation fondés sur le module pickle de Python.

pickle n’est pas un format de données. C’est un petit langage de programmation, exécuté par une machine virtuelle à pile au moment du chargement. Il a été conçu pour reconstruire des objets Python arbitraires, et pour y parvenir il peut importer n’importe quel module et appeler n’importe quelle fonction avec les arguments de son choix. C’est sa fonctionnalité, documentée comme telle, et la documentation de Python prévient en toutes lettres, depuis toujours, qu’il ne faut jamais désérialiser des données d’origine non fiable. Avertissement que l’humanité a accueilli avec l’attention qu’elle réserve aux notices de médicaments.

Or une large part de l’écosystème d’apprentissage automatique a longtemps sauvegardé ses modèles avec ce mécanisme, directement ou à travers des formats qui l’embarquent. Un fichier de poids de ce type est une archive qui contient un programme pickle chargé de reconstruire les tenseurs. Rien n’empêche ce programme, à côté de la reconstruction des tenseurs, d’appeler os.system avec la commande de son choix. Le chargement du modèle suffit à l’exécuter, avant même la première inférence, avec les droits du processus qui charge, sur la machine qui charge, c’est-à-dire souvent un poste de développeur ou un serveur doté d’accélérateurs coûteux et de jetons d’accès à tout ce qui compte.

Charger un fichier pickle, c’est exécuter un programme. Il n’y a pas de nuance à apporter à cette phrase, seulement des atténuations à y adjoindre.

Les atténuations, et leurs limites

Les bibliothèques ont réagi. Les versions récentes des principaux cadriciels ont durci leurs fonctions de chargement pour restreindre ce que le programme pickle a le droit de reconstruire, en n’autorisant qu’une liste de types attendus. C’est une amélioration réelle. C’est aussi une liste d’autorisation posée sur un langage conçu pour tout permettre, et l’histoire des listes d’autorisation posées sur des langages conçus pour tout permettre n’est pas une histoire gaie. Il faut vérifier quel comportement s’applique dans la version utilisée, le forcer explicitement plutôt que compter sur le défaut, et ne jamais le désactiver « parce que ce modèle-là ne se charge pas autrement ». Un modèle qui ne se charge pas avec les restrictions est précisément un modèle qui demande à faire autre chose que charger des tenseurs.

Les plateformes de distribution analysent aussi les fichiers qu’elles hébergent, à la recherche d’importations suspectes. C’est utile. C’est de la détection par motifs sur un langage de programmation, avec les limites habituelles : des travaux de sécurité ont régulièrement montré des moyens de contourner ces analyseurs, et un résultat « aucun problème détecté » signifie exactement ce qu’il dit, pas davantage.

On peut enfin inspecter soi-même un fichier avant de le charger, sans l’exécuter, en désassemblant son programme pickle. Le module standard pickletools lit les instructions sans les exécuter :

# Lister le contenu d'une archive de poids au format PyTorch, sans la charger.
unzip -l pytorch_model.bin

# Désassembler le programme pickle interne (lecture seule, rien n'est exécuté)
# et ne garder que les instructions qui importent ou appellent quelque chose.
python3 - pytorch_model.bin <<'EOF'
import pickletools, sys, zipfile
z = zipfile.ZipFile(sys.argv[1])
for nom in z.namelist():
    if nom.endswith('.pkl'):
        print('==', nom)
        pickletools.dis(z.read(nom), annotate=0)
EOF

Dans la sortie, un fichier légitime importe des fonctions de reconstruction de tenseurs et quelques types de collections. Toute référence à os, subprocess, builtins avec eval ou exec, socket, ou à un module inattendu, est un motif sérieux de ne pas aller plus loin. L’absence de telles références n’est pas une preuve d’innocence (un attaquant soigneux sait être moins voyant), mais leur présence est une preuve de culpabilité assez convaincante.

Les formats qui ne font que stocker

La vraie réponse au problème de pickle n’est pas un meilleur analyseur. C’est la même que pour l’injection SQL : cesser d’utiliser un format qui mélange code et données.

C’est l’objet des formats de sérialisation dits sûrs, dont le plus répandu dans l’écosystème des modèles de langage est safetensors. Sa structure est d’une austérité monacale : un entier qui donne la taille d’un en-tête, un en-tête au format JSON qui décrit chaque tenseur (nom, type, dimensions, position dans le fichier), puis les données brutes des tenseurs, à la suite. Pas d’instruction, pas d’importation, pas d’appel de fonction. Le chargement consiste à lire l’en-tête et à projeter des plages d’octets en mémoire. Il n’y a rien à exécuter, donc rien à détourner par ce biais.

On peut d’ailleurs lire l’en-tête d’un tel fichier sans rien charger d’autre, ce qui permet de vérifier sa structure et ses métadonnées avant tout usage :

# Lecture seule de l'en-tête d'un fichier safetensors.
# Usage : python3 lire_entete.py model.safetensors
import json, struct, sys

with open(sys.argv[1], 'rb') as f:
    taille = struct.unpack('<Q', f.read(8))[0]   # entier 64 bits petit-boutiste
    if taille > 100 * 1024 * 1024:
        sys.exit("en-tête anormalement grand, on s'arrête là")
    entete = json.loads(f.read(taille))

print(json.dumps(entete.get('__metadata__', {}), indent=2, ensure_ascii=False))
print(sum(1 for k in entete if k != '__metadata__'), 'tenseurs décrits')

Les formats conçus pour l’inférence locale, comme GGUF dans l’écosystème de llama.cpp, suivent la même philosophie : des métadonnées typées et des tenseurs, sans code. C’est le bon choix, et il faut le privilégier chaque fois qu’on a le choix.

Il faut cependant se garder d’en déduire qu’un format sûr rend le fichier sûr. Un format sans code déplace la confiance, il ne la supprime pas. Elle passe du fichier au programme qui le lit. Un analyseur écrit dans un langage sans sûreté mémoire, qui lit des tailles et des décalages fournis par le fichier, est exposé aux erreurs classiques de ce genre de code, et des vulnérabilités de cette nature ont été publiées sur des analyseurs de formats de modèles. Par ailleurs, certains formats embarquent dans leurs métadonnées le gabarit de conversation, qui est lui-même un petit programme interprété : un moteur de gabarits mal isolé transforme une métadonnée en exécution de code, et l’on a réinventé pickle par la porte de service.

La règle devient donc : format sans code, et analyseur à jour, et gabarit rendu par un moteur isolé. Trois conditions, aucune suffisante seule, ce qui est la définition ordinaire de la sécurité et la raison pour laquelle elle se vend mal.

Provenance et intégrité : ce que prouvent les empreintes

Passons aux vérifications qui marchent, parce qu’il y en a, et qu’elles sont trop rarement faites pour qu’on se permette de les dédaigner.

La première question est la plus simple : le fichier que j’ai est-il celui que la source a publié ? Elle se règle par une empreinte cryptographique, un condensat SHA-256 par exemple, comparé à une valeur obtenue par un canal distinct du fichier lui-même.

# Empreinte d'un fichier de poids, à comparer à la valeur publiée par la source
sha256sum model-00001-of-00004.safetensors

# Vérifier un lot de fichiers contre un fichier d'empreintes de référence
sha256sum --check SHA256SUMS

Les plateformes de distribution fondées sur un système de gestion de versions offrent un outil supplémentaire, trop peu utilisé : l’épinglage d’une révision. Au lieu de récupérer « la dernière version » d’un dépôt de modèle (c’est-à-dire ce que son propriétaire, ou quiconque a compromis son compte, y a poussé en dernier), on récupère une révision précise, identifiée par l’identifiant de commit. Les bibliothèques de chargement et les outils de téléchargement acceptent en général un paramètre de révision à cet effet. Un modèle épinglé ne change pas sous vos pieds. Un modèle non épinglé est une dépendance flottante, avec tous les charmes de la dépendance flottante, qui sont ceux de la roulette.

Il faut dire aussi, avec la netteté qui convient, ce que l’empreinte ne prouve pas. Elle prouve l’identité, pas la qualité. Un fichier malveillant a une empreinte parfaitement valide ; il a simplement l’empreinte d’un fichier malveillant. Vérifier une empreinte récupérée sur la même page que le fichier ne prouve rien de plus que la cohérence de cette page avec elle-même, ce qui est un résultat philosophiquement satisfaisant et opérationnellement nul. L’empreinte n’a de valeur que si la valeur de référence vient d’une source en laquelle on a une raison indépendante d’avoir confiance.

C’est ici qu’intervient la signature.

Signer un modèle

Une signature numérique lie un contenu à une clé, et, par l’intermédiaire d’une infrastructure plus ou moins solide, cette clé à une identité. Appliquée à un modèle, elle permet de répondre à la question que l’empreinte laissait ouverte : qui a publié ceci ?

Plusieurs initiatives travaillent à standardiser la signature des modèles d’apprentissage, en s’appuyant sur les outils de signature de la chaîne logicielle ouverte. Le principe général est de produire un manifeste qui liste les empreintes de tous les fichiers du modèle (poids, configuration, tokeniseur, gabarit, code éventuel) et de signer ce manifeste. Le point est essentiel : signer seulement les poids laisse sans protection la configuration, le tokeniseur et le gabarit, qui peuvent changer le comportement du modèle aussi sûrement que les poids eux-mêmes. L’état de ces initiatives évolue ; il faut se référer à leurs publications actuelles plutôt qu’à ce texte pour savoir ce qui est stable.

La signature a trois limites qu’on aurait tort d’oublier dans l’enthousiasme.

Elle déplace la question vers l’identité. Savoir qu’un modèle a été signé par « un compte » ne sert à rien si l’on ne sait pas à qui appartient ce compte ni pourquoi on lui ferait confiance. La valeur de la signature est exactement celle du lien entre la clé et une entité dont on connaît la réputation, les pratiques et les intérêts. Signé par un grand laboratoire identifié : information utile. Signé par un pseudonyme créé la semaine dernière : information exacte et parfaitement inutile.

Elle couvre un maillon, pas la chaîne. Un modèle réputé est souvent réentraîné, affiné, quantifié, fusionné avec d’autres, redistribué par des tiers. La signature du modèle d’origine ne dit rien des dérivés, et chaque dérivé devrait porter la signature de celui qui l’a produit, plus un lien vérifiable vers ce dont il dérive. On en est loin.

Elle prouve l’origine, pas l’innocence. C’est la leçon de toutes les compromissions de la chaîne d’approvisionnement logicielle. La porte dérobée de xz-utils, découverte en 2024, se trouvait dans des archives publiées par un mainteneur du projet ; tout ce qui pouvait être signé était signé par quelqu’un de légitime, puisque le mainteneur malveillant l’était devenu. Une signature authentifie celui qui publie. Elle ne dit rien de ses intentions, ni de celles de quiconque a pu influencer ce qu’il publie.

La chaîne d’approvisionnement des modèles

Il faut maintenant regarder l’ensemble, et l’ensemble ressemble à s’y méprendre à ce que la chaîne logicielle connaît déjà, en un peu plus opaque.

Un modèle de base est entraîné par une organisation, sur des données qu’elle ne publie pas toujours intégralement. Des tiers l’affinent pour une tâche ou une langue, sur leurs propres données. D’autres en produisent des versions quantifiées pour qu’il tienne sur du matériel modeste. D’autres encore fusionnent plusieurs modèles affinés pour combiner leurs qualités. Chacun republie le résultat, sous un nom qui reprend souvent celui du modèle d’origine avec un suffixe. Au bout de trois ou quatre étapes, le fichier que télécharge l’utilisateur est passé par des mains dont il ignore le nombre, l’identité et les pratiques.

On retrouve alors, trait pour trait, les pathologies de l’écosystème des paquets logiciels :

Le typosquatting : un nom de dépôt qui ressemble à celui d’un modèle réputé, à une lettre ou une organisation près.
La prise de contrôle de compte : un dépôt légitime dont les identifiants ont fuité, sur lequel on pousse une révision modifiée.
La dépendance transitive : un modèle affiné dont la fiche indique qu’il dérive d’un modèle de base, sans que rien ne permette de vérifier que c’est vrai, ni lequel exactement.
L’artefact abandonné : un modèle populaire publié par un compte qui ne répond plus, que l’on continue à télécharger par habitude.
Le code d’accompagnement : scripts d’inférence, carnets d’exemple, dépendances Python épinglées de manière approximative, qui s’exécutent avec les droits de l’utilisateur et qui relèvent de l’analyse de chaîne logicielle ordinaire.

Les réponses sont les mêmes que pour les paquets : un registre interne des modèles approuvés, avec leur provenance, leurs empreintes et la révision exacte ; un miroir interne plutôt qu’un téléchargement direct depuis l’internet au moment du déploiement ; une nomenclature qui recense quels modèles tournent où, en quelle version, pour quel usage ; un processus d’approbation proportionné à l’usage. Rien de tout cela n’est propre à l’IA. Tout cela est absent de la plupart des projets d’IA, qui ont été lancés par des équipes à qui personne n’avait dit qu’un fichier de poids était une dépendance.

La porte dérobée dans les poids

Supposons maintenant qu’on ait tout bien fait. Format sans code, analyseur à jour, empreinte vérifiée, signature valide d’un éditeur identifié, révision épinglée, miroir interne. Le fichier est exactement celui que l’éditeur a voulu publier, et il ne contient que des nombres.

Que font ces nombres ?

C’est la question à laquelle aucun des outils précédents ne répond, et elle n’a pas de réponse satisfaisante. Un réseau de neurones est un programme dont le code source n’existe pas. Il a été produit par un processus d’optimisation, à partir de données, et le résultat est un ensemble de paramètres qu’aucun humain ne peut lire comme on lit une fonction. Les termes « poids ouverts » et « source ouverte » sont souvent confondus ; ils ne désignent pas la même chose. Avoir les poids, c’est avoir le binaire, pas le source : on peut l’exécuter, le modifier, le redistribuer, mais pas le relire.

Or ce programme peut contenir un comportement caché. C’est ce qu’on appelle une porte dérobée : le modèle se comporte normalement dans l’immense majorité des cas, et adopte un comportement choisi par l’attaquant lorsqu’un déclencheur particulier apparaît dans l’entrée (une phrase, une tournure, un motif, une date). La littérature sur ce sujet est ancienne à l’échelle de l’apprentissage profond, et elle a établi plusieurs résultats qui devraient suffire à dissiper l’optimisme.

Les portes dérobées peuvent être implantées par les données d’entraînement ou d’affinage, sans toucher au code ni au processus : il suffit de contrôler une partie des exemples. Tout modèle entraîné ou affiné sur des données collectées largement est exposé à cette forme d’empoisonnement.

Elles peuvent résister aux traitements censés les éliminer. Des travaux publiés ces dernières années ont montré que des comportements dissimulés, implantés délibérément dans un modèle de langage, pouvaient survivre aux entraînements de sécurité habituels, voire que ceux-ci apprenaient parfois au modèle à mieux cacher son déclencheur. L’affinage ultérieur n’est donc pas un désinfectant fiable.

Elles peuvent être indétectables en principe. Des travaux théoriques ont montré que, sous des hypothèses cryptographiques standard, il est possible de construire des modèles porteurs d’une porte dérobée qu’aucun observateur ne peut distinguer d’un modèle sain, fût-ce avec un accès complet aux paramètres, sans connaître la clé de l’attaquant. Le résultat porte sur des constructions particulières et ne dit pas que toute porte dérobée réelle est indétectable. Il dit qu’on ne peut pas compter, par principe, sur l’inspection des poids pour prouver leur innocence.

Et la reproductibilité, qui est la réponse moderne de la chaîne logicielle à ce genre de problème (recompiler soi-même à partir du source et vérifier qu’on obtient le même binaire), est ici hors de portée. Réentraîner un grand modèle demande des données souvent non publiées et des moyens de calcul hors d’atteinte de presque tous, et le processus d’entraînement n’est de toute façon pas déterministe au bit près. On ne peut pas recompiler un modèle de langage. On ne peut que croire celui qui l’a compilé.

Ce qu’on peut vérifier, et ce qu’on ne peut pas

Il est temps de faire les comptes, avec la sécheresse d’un inventaire après décès.

On peut vérifier que le fichier est celui qui a été publié (empreinte), par qui il a été publié (signature, si elle existe et si l’identité est connue), qu’il ne changera pas (révision épinglée), que son format ne permet pas l’exécution de code au chargement (format sans code, en-tête inspecté), que les fichiers annexes ne contiennent pas de code distant non lu, et que le programme qui le charge est à jour.

On ne peut pas vérifier que le modèle ne contient pas de comportement caché, que ses données d’entraînement n’ont pas été empoisonnées, que les affinages successifs n’ont rien introduit, ni que les évaluations publiées sur sa fiche correspondent au fichier qu’on a téléchargé. On peut réduire l’incertitude par des tests comportementaux, des évaluations sur ses propres jeux de données, de la surveillance des sorties en production. On ne peut pas l’éliminer.

La conséquence architecturale est la même que pour l’injection de prompt, et ce n’est pas une coïncidence : puisqu’on ne peut pas prouver que le modèle se comportera bien, il faut concevoir le système pour que son mauvais comportement reste acceptable. Un modèle de provenance incertaine ne reçoit pas d’accès en écriture aux systèmes critiques. Ses sorties sont validées avant d’être exécutées. Il tourne dans un environnement isolé, sans accès réseau sortant s’il n’en a pas besoin, avec des droits limités à sa tâche. Son comportement est journalisé, pour qu’une dérive se voie. Le niveau de ces précautions est proportionné à ce qu’on lui confie et à ce qu’on sait de sa provenance, et ce qu’on sait de sa provenance est ce que les vérifications précédentes ont permis d’établir.

Le meilleur argument contraire

La position adverse mérite mieux qu’un haussement d’épaules, et je vais essayer de la présenter comme ses meilleurs défenseurs le feraient.

Elle dit d’abord que le risque est théorique. Les portes dérobées dans les poids sont une curiosité de laboratoire ; aucun incident majeur n’a été publiquement attribué à un modèle à poids ouverts piégé de cette manière. Les vrais risques de l’IA en production sont ailleurs : hallucinations, fuites de données, injections de prompt. Consacrer de l’énergie à la provenance des poids, c’est blinder la porte du grenier pendant que la cave est inondée.

Elle dit ensuite que les poids ouverts sont plus sûrs que les modèles fermés, précisément parce qu’ils sont ouverts. Des milliers de chercheurs les examinent, les évaluent, les testent, les comparent. Un comportement anormal a plus de chances d’être découvert dans un modèle téléchargé des centaines de milliers de fois que dans un modèle accessible seulement par une API dont on ne voit rien. Et la confiance qu’on accorde à un fournisseur d’API n’est pas moins aveugle que celle qu’on accorde à un éditeur de poids : on ne voit pas davantage ce qui tourne derrière.

Ces deux arguments contiennent une part de vérité que je ne conteste pas. Il est exact que les risques de format (pickle, code distant) sont aujourd’hui plus concrets et mieux documentés que les portes dérobées dans les poids, et qu’ils méritent la priorité. Il est exact aussi que la confiance dans un fournisseur d’API est une confiance du même ordre, et que cet éditorial s’applique à lui, mutatis mutandis : on ne vérifie pas davantage ce qu’il fait tourner.

Mais l’argument de l’examen collectif prouve moins qu’il ne semble. L’examen collectif des modèles ouverts porte sur leurs capacités, leurs performances, leurs biais visibles. Il ne porte pas sur la recherche de déclencheurs cachés, pour la bonne raison qu’on ne sait pas les chercher, et que les résultats théoriques cités plus haut suggèrent qu’on ne saura pas toujours. Des milliers d’yeux ne voient pas ce qui est invisible par construction, pas plus que des milliers de lecteurs d’un livre écrit à l’encre sympathique. L’ouverture du code source aide parce que le source est lisible ; l’ouverture des poids aide beaucoup moins, parce que les poids ne le sont pas.

Quant à l’absence d’incident public, elle est compatible avec deux hypothèses : que le risque est faible, ou qu’une porte dérobée bien faite ne produit pas d’incident attribuable. Je ne sais pas laquelle est vraie. Personne ne le sait. C’est précisément ce qui justifie de concevoir des architectures qui n’ont pas besoin de le savoir.

Ce que je ne sais pas

Je ne sais pas quelle part des modèles en circulation est piégée. Probablement une part infime, peut-être aucune au sens de la porte dérobée délibérée. Je n’ai aucune donnée pour l’affirmer ni pour l’infirmer, et je me méfie des deux camps qui prétendent en avoir.

Je ne sais pas si la détection des portes dérobées progressera assez pour changer la conclusion. Il existe une recherche active sur l’inspection des modèles, l’interprétabilité, la détection de comportements anormaux. Elle a produit des résultats encourageants sur des cas construits. Elle n’a pas, à ma connaissance, produit de méthode générale qui permettrait de certifier un modèle quelconque, et les résultats d’impossibilité suggèrent qu’il faudra se contenter de méthodes partielles.

Je ne sais pas ce que deviendront les initiatives de signature. Elles sont nécessaires et encore jeunes ; leur adoption par les grands éditeurs et par les plateformes de distribution décidera de leur utilité réelle. Une signature que personne ne vérifie a la même valeur qu’une signature absente, avec le coût en plus.

Je ne sais pas où passe exactement la frontière entre le modèle et le code. Les gabarits de conversation, les appels d’outils décrits dans les métadonnées, les formats qui embarquent de plus en plus de logique : la frontière entre « fichier de données » et « programme » se brouille à chaque génération d’outils. Cet éditorial suppose qu’on peut encore la tracer. Cette hypothèse vieillit plus vite que moi, ce qui n’est pas peu dire.

Ce qui reste

Trois choses, qui me semblent devoir survivre aux formats du moment.

Un fichier de poids est une dépendance, et il se gère comme une dépendance. Provenance connue, empreinte vérifiée contre une référence indépendante, révision épinglée, registre interne, format sans code, analyseur à jour. Tout cela est ordinaire, outillé, documenté, et presque jamais fait. Commencer par là n’a rien de glorieux ; c’est ce qui le rend efficace.

On peut prouver l’origine d’un modèle, pas son innocence. Les empreintes et les signatures répondent à « d’où vient-il » et « a-t-il changé ». Elles ne répondent pas à « que fera-t-il », et aucune technique connue n’y répond de façon générale. La confiance dans un modèle est donc, en dernière analyse, une confiance dans ceux qui l’ont produit, qu’il vaut mieux accorder en connaissance de cause qu’en téléchargeant.

Ce qu’on ne peut pas vérifier, on le confine. Un modèle dont l’innocence n’est pas démontrable reçoit les droits d’un composant non fiable : isolement, sorties validées, moindre privilège, journalisation. C’est la même réponse que pour l’injection de prompt, et ce n’est pas un hasard : dans les deux cas, on a affaire à un programme qu’on ne peut pas lire et qu’on a pourtant envie de laisser agir.

On a longtemps répété qu’il ne fallait pas exécuter de code trouvé sur l’internet. On a désormais des programmes qu’on ne peut même pas lire, qu’on trouve sur l’internet, et qu’on exécute avec enthousiasme sur les données les plus précieuses de l’entreprise. Le progrès, décidément, ne consiste pas toujours à avancer. Parfois, il consiste à refaire les mêmes erreurs avec des fichiers plus gros.

🐝 Ce qui arrive si on s’en passe

Charger un fichier de poids sans vérification revient à accorder à son auteur inconnu les droits du processus qui le charge : sur un poste de développeur ou un serveur de calcul, cela signifie les jetons d’accès, les clés et les données qui s’y trouvent, dès l’ouverture du fichier et avant la moindre inférence. Sans révision épinglée ni registre interne, un dépôt compromis pousse une nouvelle version que le prochain déploiement récupère d’office, et personne ne sait ensuite quelle révision tournait le jour de l’incident. Sans confinement, un comportement caché dans les poids agit avec toutes les permissions accordées au modèle, et ses effets se confondent avec ceux d’une simple mauvaise réponse, ce qui ne laisse à l’enquête aucun point de départ.

🦫 Explication de la marmotte 🍫

Un modèle d’apprentissage, par exemple un modèle de langage qui produit du texte, se télécharge sous forme de fichiers. Les principaux contiennent les poids : un très grand nombre de valeurs réglées pendant l’entraînement, qui déterminent ce que le modèle répond. À côté se trouvent une configuration, une table qui découpe le texte en morceaux, un petit gabarit de mise en forme des conversations et parfois du code. Certains formats anciens de sauvegarde exécutent réellement des instructions au moment où on les ouvre : ouvrir le fichier peut alors lancer n’importe quelle commande sur la machine. D’autres formats ne contiennent que des données décrites par un en-tête, ce qui retire ce danger, à condition que le programme qui les lit soit à jour. On peut ensuite vérifier l’origine. Une empreinte, c’est-à-dire un résumé calculé du fichier, prouve qu’il n’a pas été modifié si on la compare à une valeur obtenue par un autre canal. Une signature numérique indique qui l’a publié. Choisir une version précise empêche qu’elle change en silence. En revanche, personne ne peut lire les valeurs pour savoir ce qu’elles feront. Un modèle peut contenir un comportement caché qui ne se déclenche qu’avec une phrase particulière, et aucune technique connue ne permet de prouver son absence. On limite donc ce que le modèle peut faire : environnement isolé, droits réduits, sorties vérifiées, activité enregistrée.

Pages voisines

La citent

Les poids d'un modèle sont un artefact logiciel

Elle cite

Les poids d'un modèle sont un artefact logiciel

Un binaire qu’on télécharge comme une recette de cuisine

Ce qu’on télécharge vraiment

Le format pickle, ou l’art d’exécuter en chargeant

Les atténuations, et leurs limites

Les formats qui ne font que stocker

Provenance et intégrité : ce que prouvent les empreintes

Signer un modèle

La chaîne d’approvisionnement des modèles

La porte dérobée dans les poids

Ce qu’on peut vérifier, et ce qu’on ne peut pas

Le meilleur argument contraire

Ce que je ne sais pas

Ce qui reste

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines