Faire tourner un modèle chez soi

Éditorial

Faire tourner un modèle de langage sur sa propre machine garantit une chose précise : le prompt ne part pas chez un fournisseur. Tout le reste (provenance des poids, outils qui appellent l'extérieur, journaux locaux, sécurité du poste, qualité des réponses) reste à la charge de celui qui a cru se débarrasser du problème.

Mis à jour le 25 septembre 2026~24 min de lecture13 sections

papy cyber

→ Lire l’explication complète de la marmotte

Le prompt ne sort pas

Il y a une satisfaction particulière, que tout amateur connaît, à débrancher le câble réseau d’une machine et à constater qu’elle répond encore. Le modèle de langage local procure cette satisfaction à l’état pur. On télécharge quelques gigaoctets de poids, on lance un moteur d’inférence, on tape une question, et la réponse arrive sans qu’aucun octet ait quitté la pièce. Pour qui a passé des années à lire des conditions générales d’utilisation en se demandant ce que devenait ce qu’il tapait, c’est un soulagement presque physique.

Ce soulagement est légitime, et cet éditorial ne vise pas à le gâcher. Il vise à le délimiter, ce qui est une autre manière de le gâcher, mais plus lente, et avec des notes de bas de page. On pardonnera à un papy ce goût pour les plaisirs qu’on raisonne : à un certain âge, on sait que l’euphorie est un état transitoire entre l’installation et la première mise à jour.

Car l’argument du modèle local tient en une phrase, et cette phrase est exacte : le prompt ne part pas chez un fournisseur. Tout ce que l’on tape, tout ce que l’on colle, tous les documents qu’on donne à lire au modèle restent sur la machine. Aucun tiers ne les journalise, ne les conserve, ne les relit pour améliorer son service, ne peut être contraint de les remettre. C’est un gain réel, parfois décisif, et il est bon de le formuler avec précision parce qu’on va voir qu’on a tendance à lui faire dire beaucoup plus.

Le glissement est toujours le même. De « le prompt ne sort pas », on passe à « c’est confidentiel », puis à « c’est sûr », puis à « je n’ai plus à y penser ». Chacune de ces étapes est une extrapolation, et la dernière est une faute. Un modèle local supprime un destinataire. Il ne supprime pas une surface d’attaque ; il la déplace chez soi, où elle est gardée par quelqu’un dont ce n’est généralement pas le métier, et qui a souvent d’autres choses à faire le samedi.

Ce qu’on gagne vraiment

Commençons par rendre justice à l’argument, puisqu’on va passer le reste de l’éditorial à le raboter.

On supprime le tiers de confiance pour le contenu. Avec un service hébergé, le contenu de chaque requête traverse l’infrastructure du fournisseur, y est traité, et peut y être conservé pour des durées et des usages définis par un contrat qu’on a accepté sans le lire, comme tout le monde, dans ce grand acte de foi collectif qu’est le bouton « J’accepte ». Même lorsque le fournisseur s’engage à ne pas entraîner ses modèles sur les données de ses clients et à ne les conserver que brièvement, ces engagements reposent sur sa parole, sur son exécution correcte et sur le droit auquel il est soumis. Localement, il n’y a pas de parole à croire, parce qu’il n’y a personne pour la donner.

On supprime une catégorie entière de fuites. Les incidents chez un fournisseur, les erreurs de configuration de sa part, la réquisition par une autorité, le salarié indélicat qui consulte des conversations : aucun de ces scénarios ne concerne un contenu qui n’a jamais été transmis. On ne peut pas voler chez quelqu’un ce qu’il n’a pas.

On simplifie certaines questions de conformité. Soumettre à un service externe des données personnelles, des documents couverts par le secret professionnel ou des informations classifiées pose des questions de transfert, de sous-traitance et d’autorisation qui ne se posent pas, ou pas de la même manière, lorsque le traitement reste sur une machine maîtrisée. Je dis « simplifie », pas « résout » : un traitement local de données personnelles reste un traitement, avec ses obligations.

On gagne en maîtrise de la version. Un modèle local ne change pas sans qu’on le décide. Un service hébergé peut modifier son modèle, ses filtres, son comportement, du jour au lendemain, et le prompt qui fonctionnait lundi peut échouer mardi. Ce n’est pas de la confidentialité à proprement parler, mais c’est une forme de souveraineté sur l’outil qui a sa valeur.

Voilà ce qu’on gagne. C’est substantiel. Et c’est tout : ce qui suit est la liste de ce qu’on croit gagner en plus, et qu’on ne gagne pas. Elle est plus longue, ce qui est l’ordre naturel des choses ; les illusions ont toujours été plus nombreuses que les acquis, et mieux logées.

Les poids : un fichier qu’on n’a pas écrit

Un modèle local est d’abord un fichier, ou quelques fichiers, de plusieurs gigaoctets, qu’on a téléchargé depuis un dépôt public. Personne ne les a lus, pour une raison simple : ils ne se lisent pas. Ce sont des milliards de nombres dont aucun humain ne peut dire ce qu’ils font en les regardant. On exécute du comportement dont on ne connaît ni l’auteur réel, ni la fabrication, ni le contenu. La même personne qui refuserait d’installer un exécutable trouvé sur un forum télécharge avec enthousiasme un fichier de quatre gigaoctets publié par un pseudonyme, au motif qu’il s’agit « juste de poids ».

Il faut distinguer deux risques, qui n’ont ni la même nature ni la même gravité.

Le fichier qui exécute du code

Le premier risque est classique et bien documenté. Certains formats de sérialisation historiquement utilisés pour distribuer des modèles, en particulier ceux qui reposent sur le mécanisme pickle de Python, permettent d’embarquer du code arbitraire qui s’exécute au moment du chargement. Charger un tel fichier, c’est exécuter un programme. Ce n’est pas une faiblesse du modèle, c’est une propriété du format, et elle est connue depuis longtemps de quiconque a lu la documentation de pickle, qui l’écrit en toutes lettres.

Des formats conçus pour ne contenir que des tenseurs, comme safetensors, ou les formats employés par les moteurs d’inférence locaux les plus répandus, comme GGUF, réduisent fortement ce risque : ils décrivent des données, pas des instructions. Cela ne dispense pas de se méfier des analyseurs qui les lisent, qui sont du code et ont des défauts comme tout code ; mais la différence de nature est réelle. De même, certaines bibliothèques offrent une option qui autorise un dépôt de modèle à fournir son propre code Python, exécuté à l’import ; l’activer revient, sans métaphore, à exécuter le code d’un inconnu.

Règle de conduite : préférer les formats qui ne contiennent que des données, et traiter tout autre fichier de modèle comme un exécutable, c’est-à-dire le charger dans un environnement cloisonné, ou pas du tout.

Le modèle qui se comporte mal exprès

Le second risque est plus subtil et, à ce jour, moins bien maîtrisé. Un modèle peut avoir été entraîné, ou réentraîné, pour adopter un comportement particulier dans certaines conditions : produire du code subtilement vulnérable lorsqu’un certain contexte est présent, orienter certaines réponses, ignorer certaines consignes. Des travaux de recherche publiés ces dernières années ont montré qu’il est possible d’implanter de tels comportements conditionnels et qu’ils peuvent résister à des procédures ultérieures d’alignement. Je ne connais pas de méthode générale, accessible à un utilisateur ordinaire, pour établir qu’un modèle donné n’en contient pas.

Ce risque est, pour l’instant, surtout théorique pour un usage de conversation : un modèle qui ment dans une fenêtre de discussion ne fait que ce que font les humains depuis l’invention de la parole. Il cesse d’être théorique dès qu’on donne au modèle la capacité d’agir, ce qui est précisément la pente naturelle de tout usage local un peu ambitieux, comme on va le voir.

La seule parade réaliste est la provenance : télécharger depuis la source d’origine plutôt que depuis une copie republiée, vérifier les empreintes lorsqu’elles sont publiées, se méfier des variantes « améliorées » ou « débridées » republiées par des tiers, dont l’amélioration porte parfois sur autre chose que ce qui est annoncé. L’histoire récente du logiciel libre, avec la porte dérobée insérée patiemment dans xz-utils et découverte en 2024, rappelle qu’une chaîne d’approvisionnement ouverte n’est pas une chaîne d’approvisionnement vérifiée. Et un fichier de poids est encore moins lisible qu’un script de compilation.

Le moteur et ses extensions

Le modèle ne tourne pas seul. Il est servi par un moteur d’inférence, lui-même souvent piloté par une interface, elle-même enrichie de fonctions qui la rendent utile. C’est dans cet empilement que le « rien ne sort » commence à fuir, non par malveillance, mais par commodité.

Le moteur et l’interface ont leur propre comportement réseau. Vérification de mises à jour, téléchargement automatique de modèles, statistiques d’usage, chargement de ressources depuis un réseau de diffusion de contenu, polices et scripts tirés d’Internet par l’interface web : chacun de ces comportements est anodin pris isolément, et documenté, ou pas, selon les projets. Aucun n’envoie nécessairement le prompt. Mais « aucun ne l’envoie nécessairement » n’est pas la même phrase que « rien ne sort », et l’utilisateur qui croyait avoir débranché le monde découvre qu’il l’a simplement mis en sourdine.

Les outils envoient, eux, le contenu. C’est le point décisif. Un modèle local devient utile lorsqu’on lui donne des outils : une recherche sur le web, la lecture d’une page, l’appel d’une API, l’accès à un agenda ou à une messagerie. Les protocoles qui standardisent ce branchement, comme MCP, rendent cela trivial, et c’est leur mérite. Mais chaque outil qui appelle l’extérieur y envoie quelque chose, et ce quelque chose est construit par le modèle à partir du contexte de la conversation. Une requête de recherche formulée par le modèle pour répondre à une question sur un document confidentiel contient, par construction, un morceau de ce document. Le prompt ne sort pas ; ses paraphrases, si.

Il faut ajouter à cela un risque propre aux modèles outillés : l’injection indirecte. Un modèle qui lit une page web, un courriel ou un document peut y trouver des instructions et, faute de distinguer structurellement les données des consignes, les suivre. Une page piégée peut ainsi demander au modèle d’envoyer à une adresse donnée le contenu de ce qu’il a lu précédemment, en l’encodant dans une URL qu’il ira « consulter ». Qu’il tourne localement ne change rien au mécanisme ; cela change seulement le fait que la victime et l’hébergeur sont la même personne.

Les extensions sont du code tiers. Les interfaces locales disposent souvent d’un écosystème de greffons, installés d’un clic, qui s’exécutent avec les droits de l’interface et voient passer tout ce qu’elle voit. On a quitté un fournisseur unique, identifié, lié par un contrat, pour une constellation de contributeurs dont on ne sait rien. C’est un choix qui peut se défendre ; ce n’est pas, à l’évidence, un gain de confidentialité par défaut.

La conclusion est sans appel : un modèle local sans outils est confidentiel ; un modèle local avec outils est exactement aussi confidentiel que le moins discret de ses outils. Il faut donc raisonner outil par outil, se demander pour chacun ce qu’il envoie et à qui, et désactiver par défaut tout ce qui franchit la frontière de la machine.

Les journaux qu’on tient soi-même

Il y a dans l’usage local une ironie que l’on remarque rarement, sans doute parce qu’elle est chez soi et qu’on ne regarde jamais ses propres placards. On l’a choisi pour que personne ne conserve ses conversations. Puis on installe une interface qui, pour être agréable, conserve toutes les conversations. En clair, dans une base locale, sans durée de conservation, sauvegardée chaque nuit avec le reste du répertoire personnel. On a renvoyé le fournisseur pour devenir soi-même le fournisseur, avec des pratiques de conservation que l’on reprocherait à n’importe quel fournisseur.

L’éditorial sur ce qu’on garde examinait ce mécanisme pour les journaux de sessions d’agents, et tout ce qu’il établissait s’applique ici. Le corpus des conversations est un concentré de ce qu’on avait de plus sensible à demander, puisque c’est précisément pour cela qu’on a choisi le local. Il est stocké sans classification. Il est répliqué par les sauvegardes, qui ont leurs propres durées. Et il grossit sans que personne ait jamais décidé qu’il devait exister.

L’usage local ajoute ses propres sédiments. Les index de recherche sémantique construits pour permettre au modèle d’interroger des documents (le mécanisme du RAG) contiennent des fragments des documents et leurs représentations vectorielles, dont il serait imprudent de supposer qu’elles ne permettent pas de reconstituer une partie du texte d’origine. Les caches du moteur peuvent conserver des états intermédiaires. Les journaux de débogage, activés un jour pour comprendre un problème et jamais désactivés, peuvent contenir les requêtes complètes. Chacun de ces fichiers est une copie du contenu confidentiel, dans un endroit où l’on ne pensait pas en avoir mis.

Le remède n’a rien d’original, ce qui ne l’empêche pas d’être rarement appliqué : savoir où l’interface stocke l’historique, fixer une durée de conservation, exclure ou chiffrer ces répertoires dans les sauvegardes selon leur sensibilité, désactiver l’historique pour les usages les plus sensibles. Le chiffrement des données au repos protège contre la perte de la machine ; il ne protège pas contre ce qui s’exécute dessus avec les droits de l’utilisateur, ce qui nous amène au point suivant.

La machine devient une cible

Avec un service hébergé, la sécurité de l’infrastructure qui traite le prompt est le problème du fournisseur. Il s’en acquitte plus ou moins bien, mais il dispose d’équipes, d’outils de détection, de procédures de réponse et d’une réputation à perdre. Avec un modèle local, cette infrastructure est votre poste, et son équipe de sécurité, c’est vous, pendant vos heures libres.

Le premier piège est l’exposition réseau. Un moteur d’inférence local expose généralement une API HTTP, pour que l’interface et les autres outils puissent l’interroger. Selon les outils et les versions, elle écoute par défaut sur la boucle locale, ce qui est raisonnable ; mais il suffit d’une variable d’environnement, d’une option glissée dans un tutoriel pour « y accéder depuis la tablette », ou d’un conteneur qui publie son port sur toutes les interfaces, pour qu’elle écoute sur le réseau local. Ces API n’ont souvent aucune authentification par défaut, puisqu’elles sont conçues pour un usage local. Quiconque atteint le port peut alors interroger le modèle, lister les modèles installés, en télécharger d’autres, parfois consulter ce que l’interface expose. Sur un réseau domestique partagé avec des objets connectés dont personne ne met à jour le micrologiciel, c’est une invitation.

Quelques vérifications, en lecture seule, permettent de savoir où l’on en est :

# Quels services écoutent, et sur quelle adresse ?
# 127.0.0.1 ou ::1 : boucle locale. 0.0.0.0 ou :: : toutes les interfaces.
ss -tlnp

# Quelles connexions sortantes sont établies en ce moment, et par quel processus ?
ss -tnp state established

# Si le moteur est Ollama (port par défaut 11434, à vérifier selon la version) :
# depuis la machine elle-même, la liste des modèles doit répondre...
curl -s http://127.0.0.1:11434/api/tags
# ...et, depuis une AUTRE machine du réseau, la même requête vers l'adresse
# du poste ne devrait PAS répondre. Si elle répond, l'API est exposée.

Le second piège est la concentration, et il est d’une logique implacable, comme toutes les catastrophes bien préparées. La machine qui fait tourner le modèle local est, par construction, celle sur laquelle on a rassemblé les documents les plus sensibles pour les lui faire lire, l’historique des questions les plus délicates, et souvent des outils qui ont accès à la messagerie, aux fichiers, parfois à des secrets. On a construit un point de collecte, et un point de collecte est une cible. Un logiciel malveillant ordinaire, une extension de navigateur compromise, une session laissée ouverte : n’importe lequel de ces incidents banals donne accès à tout ce que le modèle local était censé protéger, sans qu’il soit besoin de s’intéresser au modèle.

Le troisième piège est le matériel lui-même. Les cartes graphiques qui font tourner les modèles viennent avec des pilotes volumineux, propriétaires pour certains, mis à jour à leur rythme, qui s’exécutent avec des privilèges élevés. Ce n’est pas un argument pour s’en passer ; c’est un rappel que « local » ne veut pas dire « simple », et que la pile logicielle d’une machine d’inférence est plus épaisse que celle d’un poste de bureautique.

Le coût en qualité

Il faut maintenant parler de ce dont les passionnés parlent le moins volontiers, avec cette pudeur qu’ont les propriétaires de voiliers quand on leur demande combien de fois ils sont sortis cette année. Il n’est pas question de sécurité, mais de résultat.

Un modèle qui tient sur une machine ordinaire n’est pas, en général, aussi capable qu’un modèle servi par une infrastructure spécialisée. La taille du modèle est bornée par la mémoire disponible ; pour la faire tenir, on la réduit par quantification, en représentant les poids avec moins de précision, ce qui dégrade la qualité dans des proportions variables selon la méthode et le modèle. L’écart entre les meilleurs modèles ouverts et les meilleurs services hébergés s’est réduit à plusieurs reprises et s’est rouvert à d’autres ; je me garde d’en donner une mesure, parce qu’elle serait fausse avant la fin de l’année. Mais l’écart existe, surtout pour le raisonnement long, le code complexe, les longs contextes et les langues moins représentées que l’anglais, dont le français fait partie à des degrés divers.

Cet écart n’est pas qu’une question de confort. Il a une conséquence de sécurité directe, et contre-intuitive : un modèle moins capable produit des erreurs plus nombreuses, qu’il faut détecter. Un modèle qui affirme des choses fausses avec assurance est un risque quelle que soit sa localisation, mais un modèle plus faible le fait plus souvent. Un script de configuration subtilement faux, une analyse juridique qui confond deux notions, un résumé qui omet l’essentiel : le coût de ces erreurs peut dépasser de beaucoup le bénéfice de confidentialité, si la vérification n’est pas à la hauteur.

Il y a enfin l’effet de bascule, que chacun peut prédire sans avoir besoin de l’avoir commis, ce qui ne l’empêchera pas de le commettre. Quand le modèle local échoue sur une question difficile, la tentation de « juste poser cette question-là » au service hébergé est considérable. Et la question difficile est souvent la plus sensible : c’est parce qu’elle touche au cœur de l’éditorial qu’elle est difficile. On se retrouve alors à envoyer à l’extérieur exactement ce qu’on voulait garder, précédé de dix questions anodines traitées localement avec une rigueur exemplaire. Une politique de confidentialité qui cède sur les cas difficiles ne protège que les cas faciles.

Le coût en exploitation

Le dernier coût est le moins spectaculaire et le plus durable. Faire tourner un modèle chez soi, c’est devenir l’exploitant d’un service, avec tout ce que cela suppose et que le fournisseur faisait auparavant sans qu’on y pense.

Il faut choisir les modèles, suivre leurs versions, lire leurs licences, qui ne sont pas toutes aussi ouvertes que leur réputation. Il faut mettre à jour le moteur, l’interface, les pilotes, et vérifier que la mise à jour n’a pas changé un comportement par défaut, une adresse d’écoute ou une option de télémétrie. Il faut surveiller les avis de sécurité de chaque composant, ce qui suppose de savoir lesquels on a installés. Il faut gérer l’espace disque, que les modèles consomment par dizaines de gigaoctets, et les sauvegardes, en décidant ce qu’on sauvegarde de cet ensemble. Il faut gérer la consommation électrique et la chaleur, qui ne sont pas des considérations de sécurité mais finissent par en devenir une le jour où l’on désactive une protection parce qu’elle ralentit tout.

Aucune de ces tâches n’est difficile. Toutes ensemble, elles demandent un temps régulier, et c’est ce temps qui fait défaut, l’être humain ayant une aptitude remarquable à s’engager dans l’entretien de choses qu’il n’entretiendra pas. Un service local mal entretenu est moins sûr qu’un service hébergé bien entretenu, et la plupart des services locaux sont entretenus avec l’enthousiasme décroissant qu’on accorde à tout projet personnel passé la troisième semaine.

Pour une organisation, la question se pose en d’autres termes, mais elle se pose. Un serveur d’inférence partagé entre plusieurs utilisateurs est un service à part entière, avec des comptes, des droits, une journalisation, une politique de conservation, une supervision, des sauvegardes, un plan de continuité. Le monter est l’affaire d’un après-midi ; l’exploiter correctement est l’affaire d’un poste. Entre les deux, il y a la démonstration au comité de direction, moment de grâce où le service fonctionne parfaitement parce que personne ne s’en sert encore. C’est souvent un bon investissement. Ce n’est jamais un investissement gratuit, et le présenter comme tel prépare les désillusions.

Le meilleur argument contre

Il serait malhonnête de conclure sans formuler la meilleure objection à la démarche locale elle-même, et elle mérite d’être prise au sérieux.

Pour beaucoup d’usages, un service hébergé sérieux, contractualisé et configuré avec soin, est plus sûr qu’un modèle local exploité par un non-spécialiste. Le fournisseur dispose d’équipes de sécurité, de détection, de réponse à incident, de procédures de mise à jour éprouvées. Ses engagements contractuels (non-utilisation des données pour l’entraînement, durée de conservation limitée, localisation, certifications) sont vérifiables dans une certaine mesure et opposables. Son modèle est meilleur, donc produit moins d’erreurs à détecter. Face à cela, un poste personnel qui cumule un moteur exposé par erreur sur le réseau local, un historique conservé en clair et un greffon installé sur la foi d’un tutoriel n’offre pas une confidentialité supérieure : il offre une confidentialité différente, dont l’utilisateur est le seul garant et souvent le seul à ignorer les faiblesses.

L’objection est forte, et elle a raison sur un point que les partisans du local préfèrent taire : la confiance ne disparaît pas, elle change de destinataire. Avec un service hébergé, on fait confiance à un fournisseur ; avec un modèle local, on fait confiance aux auteurs des poids, du moteur, de l’interface, des greffons, et à soi-même. Rien ne garantit que cette seconde confiance soit mieux placée.

Je maintiens pourtant que le local garde un avantage irréductible, et qu’il est précisément celui qu’on a nommé au début : certaines informations ne doivent pas être transmises, quelles que soient les garanties offertes par le destinataire. Le secret professionnel, les informations classifiées, les données dont la simple transmission constitue une faute : pour elles, la qualité du contrat n’entre pas en ligne de compte. Le local n’est pas la meilleure solution pour tout ; il est la seule solution pour certaines choses. Le travail consiste à savoir lesquelles, et à exploiter correctement la solution pour celles-là, au lieu de l’étendre à tout par principe, puis de la négliger par lassitude.

Ce que je ne sais pas

Je ne sais pas établir qu’un modèle ne contient pas de comportement caché. Je ne connais pas de méthode générale, accessible à un utilisateur, pour le vérifier. La recherche avance, et il est possible que des outils d’inspection deviennent un jour praticables ; en attendant, la provenance reste la seule défense, et c’est une défense de confiance, pas de preuve.

Je ne sais pas mesurer l’écart de qualité de manière durable. Il change à chaque génération de modèles, dépend fortement de la tâche, de la langue et de la quantification. Toute mesure que je donnerais serait périmée à la lecture. Le seul conseil stable est de mesurer soi-même, sur ses propres tâches, avant de décider.

Je ne sais pas ce que les outils d’agent feront à ce raisonnement. Plus on donne au modèle la capacité d’agir (lire des fichiers, exécuter des commandes, appeler des services), plus la frontière entre local et distant devient une question de configuration d’outils plutôt que d’emplacement du modèle. Il est possible que, d’ici peu, « local » ne veuille plus dire grand-chose pour un agent qui passe son temps à appeler l’extérieur. Il est aussi possible que des mécanismes de cloisonnement standardisés rendent enfin cette frontière contrôlable. Je n’ai pas de pronostic.

Je ne sais pas si les représentations vectorielles sont réversibles en pratique. Je raisonne ici avec prudence, en supposant qu’elles peuvent l’être partiellement, parce que c’est l’hypothèse la moins dangereuse. Je n’ai pas de mesure qui me permette d’être plus précis, et je me méfie des affirmations catégoriques dans un sens comme dans l’autre.

Ce qui reste

Faire tourner un modèle chez soi garantit une chose, et une seule, et cette chose est précieuse : le prompt ne part pas chez un fournisseur.

Trois choses me semblent acquises au-delà. Que le gain de confidentialité s’arrête aux frontières de la machine, et que chaque outil, chaque greffon, chaque fonction de recherche en ligne les franchit avec un morceau du contexte. Que l’usage local recrée localement tous les problèmes qu’il prétendait fuir (conservation, sauvegardes, exposition réseau, code tiers) et qu’ils ne se règlent pas d’eux-mêmes parce qu’ils se trouvent sous notre toit. Et que le coût en qualité est aussi un coût de sécurité, à la fois parce qu’un modèle plus faible se trompe plus souvent et parce que la tentation de basculer vers le service hébergé frappe précisément les questions les plus sensibles.

Rien de cela n’est une raison de renoncer ; le pessimisme n’a jamais protégé aucune donnée, il donne seulement un air entendu à ceux qui les perdent. C’est une raison de savoir ce qu’on fait : choisir ses poids comme on choisit un exécutable, désactiver par défaut tout ce qui sort, fixer une durée de vie à ce qu’on conserve, vérifier ce qui écoute, et réserver le modèle local aux usages qui le justifient vraiment, plutôt que de s’en servir comme d’une absolution générale. La section IA de ce site traite de la mise en œuvre ; cet éditorial voulait seulement rappeler que, dans ce domaine comme ailleurs, débrancher le câble ne dispense pas de réfléchir. Cela dispense seulement d’en accuser quelqu’un d’autre.

🐝 Ce qui arrive si on s’en passe

Traiter le modèle local comme une absolution a un coût précis : les protections qu’on appliquerait à n’importe quel service disparaissent, précisément sur la machine qui concentre les documents les plus sensibles. Personne ne recense les outils qui franchissent la frontière, si bien qu’après coup, impossible de dire quels fragments d’un dossier confidentiel sont partis dans des requêtes de recherche, ni vers qui. L’historique conservé sans durée transforme une compromission ordinaire du poste en fuite de toutes les questions posées depuis l’installation. Et un fichier de poids chargé sans vérification de provenance ne laisse aucune prise à l’enquête : si un comportement caché se déclenche un jour, rien ne le distinguera d’une banale erreur du modèle.

🦫 Explication de la marmotte 🍫

Un modèle de langage est un programme qui produit du texte à partir de milliards de nombres appelés poids, obtenus par entraînement. Le faire tourner sur sa propre machine garantit une seule chose : les questions et les documents qu’on lui donne ne sont pas envoyés à une entreprise extérieure, qui ne peut donc ni les conserver, ni les perdre, ni être obligée de les remettre. Tout le reste devient la responsabilité de l’utilisateur. Les poids forment un fichier téléchargé que personne ne peut lire ; certains formats de fichier exécutent même un programme au moment du chargement, et un modèle peut avoir été entraîné pour mal se comporter dans certaines situations. Il faut donc vérifier la provenance du fichier et préférer les formats qui ne contiennent que des données. Le modèle est ensuite servi par un moteur et une interface qui peuvent contacter Internet, et surtout par des outils, comme la recherche sur le web, qui envoient à l’extérieur des requêtes construites à partir de la conversation, donc des morceaux du contenu confidentiel. Une page lue par le modèle peut aussi contenir des consignes cachées qu’il suivra. L’interface garde souvent tout l’historique en clair, recopié par les sauvegardes. Le moteur peut être joignable depuis le réseau local sans mot de passe. La machine concentre alors les données les plus sensibles et devient une cible. Enfin, un modèle plus petit se trompe plus souvent, et l’ensemble doit être entretenu dans la durée.

Pages voisines

La citent

Faire tourner un modèle chez soi

Elle cite

: les deux pages se citent l’une l’autre.

Faire tourner un modèle chez soi

Le prompt ne sort pas

Ce qu’on gagne vraiment

Les poids : un fichier qu’on n’a pas écrit

Le fichier qui exécute du code

Le modèle qui se comporte mal exprès

Le moteur et ses extensions

Les journaux qu’on tient soi-même

La machine devient une cible

Le coût en qualité

Le coût en exploitation

Le meilleur argument contre

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