Trois accès sur un portable : les trois verrous qui protègent les assistants

L'année 2025 a appartenu aux assistants d'intelligence artificielle, et la vague a déferlé sur les portables des développeurs. Une consigne en langage courant ouvre des fichiers, déplace des dossiers et expédie des requêtes vers des services externes, tandis que chaque tâche fait circuler des requêtes vers un modèle et rend un travail fini. La puissance naît de cette portée, et la crainte aussi : le même assistant regarde vos fichiers privés, lit des textes venus de l'internet et peut pousser des données vers l'extérieur. L'anecdote de l'orateur frappe fort ; un créateur qui vantait son produit avec joie a écrit deux jours plus tard que le même assistant avait effacé sa base de production. Je lis cet épisode moins comme un accident que comme un avertissement de conception.

SimonWillison décrit la situation avec trois accès : l'assistant atteint des données privées, reste ouvert aux contenus douteux et peut parler au monde extérieur. Un seul accès se gère ; un outil qui lit seulement des fichiers ou qui sort seulement sur l'internet n'alarme personne. Deux accès réunis changent le tableau, et avec les trois la question n'est plus de savoir si un incident arrivera, mais quand. SimonWillison montre aussi combien la fuite peut rester silencieuse : un chiffre demandé au modèle se retrouve codé puis caché dans une balise d'image anodine, avant de voyager vers l'extérieur. Le vol de données n'a besoin d'aucune alerte clignotante à l'écran.

Le premier piège qui exploite ce trio s'appelle l'injection de consigne. L'assistant travaille en lisant des journaux d'erreur, des billets d'assistance et des sorties de compilation, et un attaquant peut glisser des ordres dans ces textes. L'assistant prend la ligne piégée pour une mission confiée et l'exécute. Son cousin, l'empoisonnement du contexte, avance plus masqué : de fausses matières sont semées tôt dans des documents, des notes et des jeux de données, et l'assistant les tient pour vraies le jour venu. Le troisième péril est la montée silencieuse des privilèges. Chacun reçoit normalement un accès minimal, mais l'assistant se voit ouvrir toutes les portes pour livrer son travail ; une seule ligne trompeuse lui donne alors assez de pouvoir pour effacer une table ou lancer une requête vers l'extérieur.

Ces périls vivent sur l'ordinateur familial, pas dans la théorie. Les outils d'assistance personnelle évoqués sur scène tournent, selon le conseil d'installation, dans un petit boîtier séparé de l'ordinateur quotidien ; personne ne veut les voir sur le portable principal. Un dossier Kaspersky confirme la prudence : une étude de février 2026 décrit des vols de clés privées et de jetons ainsi que des failles d'exécution à distance dans une telle pile d'assistance. Pire, ces outils exigent un large accès aux fichiers, aux terminaux et aux comptes pour tourner à plein régime. Plus la portée s'élargit, plus chaque texte vu par l'assistant peut devenir un ordre. Le conseil du boîtier séparé ressemble à une assurance bon marché plutôt qu'à de la paranoïa.

Le premier verrou déplace l'assistant du portable vers un espace de travail distant déjà préparé. Dans la conception décrite par Coder, un développeur ouvre une adresse et le travail tourne dans un boîtier scellé validé par l'équipe de sécurité. Ce boîtier ne contient que le logiciel installé, les identifiants déposés et les données placées ; l'assistant ne peut s'étendre vers les fichiers personnels, par construction. Le dossier des espaces de travail de Coder précise que ces boîtiers naissent de recettes d'infrastructure et peuvent rester sur les serveurs de l'entreprise. Le bénéfice annexe est grand : dépendances, versions et chemins arrivent prêts, si bien que l'assistant démarre aussitôt et n'a jamais l'occasion de rapatrier des téléchargements douteux depuis une source contaminée.

Dans les entreprises le tableau se brouille encore, car l'obstacle est organisationnel plutôt que technique. Une nouvelle initiative d'assistance doit d'abord gagner l'aval du responsable de la sécurité, puis le soutien de l'équipe qui fait tourner l'exploitation. Quand l'aval ne vient pas, les gens avancent quand même avec leurs abonnements personnels. Le secteur nomme cela l'usage fantôme, et l'orateur donne un nom propre à la version en essaim. Des dizaines d'assistants invisibles touchent des données avant que personne ne s'en aperçoive. Une enquête Okta menée en janvier auprès de 150 décideurs technologiques et sécurité rapporte que 81 pour cent des responsables de la sécurité craignent une surveillance insuffisante des systèmes d'intelligence artificielle. La crainte tient la majorité, pas la marge.

Les responsables s'inquiètent à raison, car la responsabilité des actes de l'assistant retombe sur eux. Les équipes posent trois questions : que font exactement ces assistants, puis-je voir chaque requête vers le modèle sur un seul écran, et qui me prévient quand quelque chose déraille ? Même une fois les écrans d'observation en place, la lassitude des alertes s'installe ; quand chaque petit événement déclenche un signal, la vraie menace se noie dans le bruit. Les déploiements doivent aussi rester identiques, reproductibles et fiables pour tout le monde. OWASP trace le cadre général de ces attentes : sa liste 2026 des applications à assistants, bâtie avec plus d'une centaine de spécialistes, énumère une par une des rubriques comme l'exécution à distance surprise. Les entreprises se défendent désormais avec la liste plutôt qu'au jugé.

Sur un autre front pèsent les doutes des développeurs eux-mêmes. Certains des noms les plus chevronnés se méfient encore des productions de l'assistant ; ils redoutent des produits boursouflés, des charges de maintenance croissantes et des failles de sécurité cachées. Quelques-uns disent que reprendre les brouillons de l'assistant prend plus de temps qu'écrire de zéro. La responsabilité ajoute un nœud : quand un assistant propose des dizaines de modifications en mode libre, qui répond de celle qui tourne mal ? Ces questions ont du poids, et la réponse tient dans des garde-fous plutôt que des interdits. Isolez l'assistant et consignez son trafic, et l'ingénieur comme le dirigeant respirent ; la confiance naît du contrôle.

Le deuxième verrou place une passerelle d'inspection entre le modèle et l'assistant. Normalement l'assistant envoie ses requêtes droit au fournisseur du modèle ; dans la conception avec passerelle, chaque requête visite d'abord la passerelle de l'entreprise, où chaque appel entre dans un journal lié à un nom d'utilisateur. La passerelle peut retirer des fragments sensibles, comme des données de carte glissées par mégarde dans une consigne, avant qu'ils n'atteignent le fournisseur. Le dossier de gouvernance de Coder explique que la passerelle authentifie chaque requête, garde les clés du fournisseur dans le plan de contrôle et tient les accès derrière une liste fermée. Quel assistant a demandé quoi à quel modèle, et combien de jetons il a brûlés, se rassemble dans un seul registre ; la facture et l'audit passent par la même porte.

Le troisième verrou est un pare-feu qui retient les commandes lancées par l'assistant. Même dans un boîtier scellé, l'assistant peut tenter un ordre nuisible ; les suppressions de dépôt ou les chutes de table heurtent ce mur et ne s'exécutent jamais. Le mur surveille les journaux de processus, bloque les domaines et les commandes non approuvés, et écrit chaque blocage dans des dossiers centraux. Lus ensemble, les trois verrous éclaircissent le tableau : l'un rétrécit l'accès aux données, l'autre gère la parole vers l'extérieur, le dernier resserre les privilèges. La phrase de clôture de l'exposé pointe dans le même sens ; avancer lentement, penser l'architecture et apprendre ce que l'infrastructure veut vraiment n'a rien de honteux. Ma seule ligne ajoutée : ces trois verrous ne sont pas un luxe mais la liste minimale de toute équipe qui fait tourner des assistants.