La sécurité des agents IA commence par de petits logiciels

Matt Sephton a publié Fits on a Floppy en avril 2026 autour d’une contrainte volontairement absurde : un logiciel utile devrait essayer de tenir dans 1,44 Mo, soit la capacité d’une disquette 3,5 pouces standard.¹

La limite de taille compte moins que l’attitude qu’elle impose. Sephton défend des téléchargements rapides, un lancement instantané, une faible consommation de mémoire et de CPU, du code natif, la prise en charge de systèmes plus anciens et des outils qui font bien une seule chose.¹ La lecture évidente est que le petit logiciel respecte l’utilisateur. À l’ère des agents, la lecture va plus loin : le petit logiciel laisse moins d’endroits aux agents de codage IA pour cacher leurs erreurs.

La sécurité des agents IA commence par de petits logiciels, parce que des systèmes petits et inspectables réduisent l’espace qu’un agent peut mal comprendre, modifier, autoriser ou oublier de tester. Les environnements isolés et les demandes d’autorisation restent nécessaires. Le petit logiciel déplace toutefois la frontière de sécurité en amont, dans la forme même de l’artefact.

TL;DR

Les agents de codage fonctionnent mieux lorsqu’ils peuvent lire les fichiers pertinents, exécuter les contrôles utiles et expliquer le diff important avant que le contexte se dégrade. Les recommandations Claude Code d’Anthropic indiquent que le contexte se remplit vite et que les performances diminuent à mesure qu’il se remplit ; le même guide présente la vérification comme la pratique la plus précieuse et décrit les outils CLI comme des interfaces économes en contexte.² La documentation d’OpenAI sur le shell local avertit que les agents qui exécutent des commandes shell ont besoin d’un environnement isolé, ou de listes d’autorisation et de refus strictes, avant toute exécution.³

Le petit logiciel ne remplace pas ces contrôles. Il les rend plus faciles à appliquer. Un petit outil a moins de commandes à autoriser, moins de fichiers à inspecter, moins de dépendances à croire, moins de tests à lancer et moins de branches où une hypothèse fausse peut se cacher. L’ancienne leçon d’Unix n’a pas vieilli : McIlroy rattache le principe « faire une seule chose » aux premières contraintes de taille, puis explique pourquoi les flux de texte sont devenus des interfaces universelles utiles, pour les programmes comme pour les personnes.⁴ Les systèmes d’agents redécouvrent le même motif, parce que les agents ont besoin de surfaces inspectables et composables.

Points clés

Pour les concepteurs d’agents : - Privilégiez de petits outils avec des entrées explicites, des sorties explicites et des artefacts en fichiers simples avant d’ajouter de larges API ou de grands schémas d’outils. - Traitez les chemins de fichiers, les diffs, les journaux et les tests comme des surfaces de sécurité. L’agent peut les inspecter, le relecteur peut les inspecter et l’automatisation peut s’en servir comme seuil.

Pour les équipes logicielles : - Le petit logiciel réduit le coût de revue. Un relecteur peut comprendre un outil de 400 lignes et ses tests en une seule séance ; un framework tentaculaire impose de la confiance là où il devrait y avoir des preuves. - Gardez le périmètre d’autorisation près de l’action. Une petite commande peut s’exécuter en lecture seule, écrire dans un seul dossier ou refuser l’accès réseau. Une commande générale demande généralement plus d’autorité que la tâche n’en exige.

Pour les responsables produit : - Le petit logiciel n’est pas de la nostalgie. C’est un modèle de gouvernance pour un monde où les machines peuvent produire trop de code trop vite. - La barre doit passer de « l’agent peut-il le construire ? » à « l’équipe peut-elle le vérifier, se l’approprier et revenir en arrière ? ».

Pourquoi le petit logiciel redevient pertinent

Le gonflement logiciel ressemblait autrefois à un problème d’expérience utilisateur : téléchargements lents, mémoire lourde, lancement différé, batteries vidées et anciens appareils laissés de côté. Fits on a Floppy rend cette critique visible grâce à un étalon volontairement physique. Un badge de 1,44 Mo transforme la retenue en test compréhensible par l’utilisateur.¹

Les agents de codage IA changent la raison pour laquelle cette retenue compte. La machine peut produire des fichiers plus vite qu’un humain ne peut les lire. Cette vitesse affaiblit la qualité quand le système environnant confond volume et progrès. Une fonctionnalité de 2 000 lignes avec quatre nouvelles dépendances peut sembler impressionnante dans la transcription tout en augmentant davantage la surface de défauts que la valeur produit.

Le petit logiciel donne à l’agent une cible plus exigeante et au relecteur une meilleure prise. Le prompt peut demander un exécutable, un format de données, un fichier de test et un chemin de retour en arrière. Le résultat laisse moins de degrés de liberté. Un modèle peut encore se tromper, mais l’erreur a moins d’espace pour se camoufler.

Niklaus Wirth a publié un article intitulé A Plea for Lean Software en 1995, bien avant que les agents de codage n’entrent dans les flux de travail.⁵ Le titre reste pertinent, car l’échec sous-jacent demeure : les équipes dépensent du matériel, des dépendances et des couches d’abstraction pour éviter les décisions de conception difficiles. Les agents abaissent le prix de l’ajout de code ; refuser d’ajouter du code devient donc plus précieux.

Le contexte est un budget de sécurité

La sécurité des agents est souvent présentée comme un problème d’autorisations : quelles commandes l’agent peut-il exécuter, quels fichiers peut-il modifier, quels secrets peut-il voir, quels appels réseau peut-il faire ? Ces questions comptent. Elles ne couvrent pas la première contrainte que rencontre l’agent pendant qu’il travaille : le contexte.

Le guide des bonnes pratiques Claude Code d’Anthropic explique que la fenêtre de contexte contient la conversation, les messages, les fichiers lus et la sortie des commandes, et qu’une seule session de débogage peut consommer des dizaines de milliers de tokens.² Le guide avertit aussi que Claude peut commencer à oublier des instructions antérieures ou faire davantage d’erreurs à mesure que la fenêtre de contexte se remplit.²

Cet avertissement transforme la taille en propriété de sécurité. Une petite base de code permet à l’agent de lire la surface pertinente sans noyer la session dans des fichiers inutiles. Un petit outil permet à l’agent de garder en vue la fonction, les tests, le modèle d’autorisation et les cas limites en même temps. Un petit diff permet au relecteur de trouver le vrai changement au lieu de parcourir une pile de mouvement généré.

Le budget de contexte a trois limites pratiques :

Les grands systèmes peuvent quand même être sûrs. Ils exigent une meilleure décomposition. Si une base de code ne peut pas être petite, la surface exposée à l’agent doit l’être : un package, un sous-système borné, une commande publique, une cible de test, un dossier attribué.

Les fichiers simples battent l’état caché

L’histoire orale de McIlroy donne à l’ancienne leçon un tranchant très pratique. Il décrit le principe « faire une seule chose » comme né de l’impossibilité matérielle de faire plus d’une chose, puis explique que les équipes ont conservé ce modèle après la disparition de la contrainte initiale.⁴ Il explique aussi pourquoi les flux de texte comptaient : les données lisibles par l’humain rendaient le débogage moins pénible, et faire évoluer des champs textuels demandait moins de travail que modifier des formats binaires fixes.⁴

Les agents ont besoin du même type de surfaces. Un fichier peut être listé, recherché, comparé par diff, lu par plages, validé dans Git, restauré, linté et relu. L’état caché d’un IDE, les bases locales opaques et les grands outils hébergés peuvent être utiles, mais ils obligent l’agent et le relecteur à faire confiance à une surface qu’ils ne peuvent pas facilement inspecter.

Un article arXiv de janvier 2026 relie l’abstraction de fichier d’Unix aux systèmes d’IA agentique. L’article affirme que les abstractions de type fichier et les spécifications sous forme de code ramènent des ressources diverses à des interfaces cohérentes et composables, et peuvent aider les systèmes d’agents à devenir plus maintenables, auditables et solides en production.⁶ L’analyse d’Oracle sur la mémoire des agents établit une distinction proche : les interfaces de système de fichiers fonctionnent bien parce que les modèles comprennent déjà les surfaces natives des développeurs, comme les dépôts, dossiers, Markdown, journaux et interactions CLI, tandis que le stockage durable peut tout de même relever d’une base de données.⁷

Cette distinction compte. « Utiliser des fichiers » ne veut pas dire « tout stocker en texte libre pour toujours ». Le modèle le plus sûr sépare l’interface de l’agent du substrat de stockage :

L’agent doit voir la plus petite interface utile. Le produit peut garder la couche de stockage plus robuste en dessous.

Moins d’outils, c’est moins d’autorisations

L’article sur l’autorisation de MCP a rendu explicite la leçon d’autorisation : valider un bearer token ne prouve pas qu’un utilisateur peut appeler tous les outils derrière le serveur.⁸ Le petit logiciel applique la même idée plus tôt dans la conception. Un outil plus petit demande une autorité plus étroite.

La documentation d’OpenAI sur le shell local énonce clairement le danger : exécuter des commandes shell arbitraires peut être dangereux, et les développeurs doivent isoler l’exécution ou ajouter des listes d’autorisation et de refus strictes avant d’envoyer des commandes au shell système.³ Le guide Claude Code d’Anthropic donne un exemple pratique à grande échelle : lors d’un travail réparti sur de nombreux fichiers, utilisez des restrictions d’outils autorisés afin que les exécutions sans surveillance ne puissent pas dépasser les besoins de la tâche.²

Une petite commande se restreint plus facilement :

Les outils larges accumulent souvent des autorisations larges. Une commande générale « publish » peut toucher le contenu, les traductions, les lignes de base de données, la purge de cache, les journaux de déploiement et l’analytique. Parfois, la commande de release a sa place. Le modèle le plus sûr construit la release à partir de commandes plus petites, avec des seuils explicites entre elles, puis automatise la séquence seulement lorsque chaque étape dispose de preuves.

Le but n’est pas de ralentir le travail. Le but est de rendre l’autorité visible.

Les tests doivent tenir dans l’outil

La première section de bonnes pratiques d’Anthropic dit aux utilisateurs de donner à Claude un moyen de vérifier son travail : tests, captures d’écran, sorties attendues et contrôles par commande.² Le petit logiciel rend ce conseil concret. Un petit outil peut porter un petit contrat de vérification.

Pour un logiciel construit par agent, le contrat devrait tenir sur un seul écran :

Inputs:
- one source path
- one output path
- one optional flag

Allowed effects:
- read source path
- write output path
- no network unless --verify-sources is present

Evidence:
- unit tests for parsing
- fixture test for output
- dry-run output for the exact file
- git diff limited to owned paths

Ce contrat compte parce que les agents peuvent satisfaire trop facilement les demandes vagues. « Améliore le pipeline » invite au remaniement architectural. « Ajoute un flag dry-run à cette commande précise et prouve que la sortie n’écrit aucun fichier » crée un chemin de preuves.

Les tests deviennent aussi plus rapides lorsque les outils restent petits. Les tests rapides changent le comportement de l’agent. Il les lance plus souvent, voit les échecs pendant que le code pertinent est encore dans le contexte, et corrige les causes profondes avant que la transcription ne dérive. Les tests lents poussent le modèle à deviner ou à raconter ce qu’il aurait exécuté.

Petit ne veut pas dire sous-construit

Le petit logiciel peut échouer de façon prévisible :

Le badge de disquette mesure la taille. La sécurité des agents a besoin d’une autre mesure : un relecteur peut-il comprendre le comportement, le périmètre d’autorisation et le chemin de preuves avant d’approuver le changement ?

Cette question autorise un outil à dépasser 1,44 Mo. Elle refuse ce qui compte vraiment : le périmètre accidentel. Une application native sûre et ennuyeuse de 20 Mo peut battre un script de 200 Ko qui délègue à un installateur non relu. Le petit logiciel ne sert la sécurité que lorsque la retenue atteint le vrai chemin d’exécution.

Une grille d’évaluation de la petitesse pour le travail d’agent

Avant qu’un agent construise ou modifie un outil, notez le travail sur cinq dimensions. L’objectif n’est pas de punir les grands systèmes. Il est de trouver les surfaces qui doivent être décomposées avant que l’agent commence à écrire.

Une cellule rouge ne signifie pas que le travail doit s’arrêter. Elle signifie que l’agent a besoin d’une unité de travail plus petite. La sécurité progresse lorsque la forme de la tâche rend le bon comportement facile à prouver.

Le modèle pratique

Les systèmes construits par agent auxquels je fais confiance partagent une forme :

1. Une commande étroite fait un seul travail.
2. Des fichiers simples portent les entrées, sorties, journaux, plans et dossiers de revue.
3. Les autorisations correspondent aux effets réels de la commande.
4. Les tests sont assez rapides pour que l’agent les utilise pendant la session.
5. Le diff reste assez petit pour être relu par un humain.
6. Le chemin de release compose de petites commandes au lieu de cacher une autorité large derrière un seul bouton.

Le Manifeste no-build décrivait la même préférence côté pile web : moins de couches de build, moins d’artefacts générés et moins de distance entre la source et l’environnement d’exécution.⁹ La version sécurité des agents dit la même chose à un autre lecteur. Chaque couche supplémentaire donne à la machine un nouvel endroit où produire un travail plausible que l’humain ne peut pas vérifier rapidement.

Le petit logiciel transforme la retenue en infrastructure. Un module plus étroit améliore l’ajustement au contexte. Un fichier plus simple améliore l’auditabilité. Un test plus rapide améliore le retour d’information. Un jeu d’autorisations plus petit améliore le contrôle du rayon d’impact. Un diff plus petit améliore le jugement humain.

FAQ : petit logiciel et sécurité des agents

Le petit logiciel rend-il les agents de codage IA sûrs ?

Non. Le petit logiciel réduit la surface que les agents peuvent mal comprendre ou endommager. Les équipes ont toujours besoin d’environnements isolés, de listes d’autorisation et de refus, de tests, de revue de code, de frontières autour des identifiants et de seuils de release. Le petit logiciel rend ces contrôles plus faciles à appliquer et plus difficiles à contourner par accident.

Quelle taille doit avoir un outil exposé à un agent ?

La limite utile est la lisibilité en revue, pas le nombre d’octets. Un bon outil exposé à un agent a un seul travail, un petit contrat d’entrée/sortie, un profil d’autorisation clair, des tests rapides et un diff qu’un relecteur peut comprendre en une séance.

La mémoire d’un agent doit-elle utiliser des fichiers ou une base de données ?

Utilisez des fichiers pour l’interface quand l’agent doit inspecter, rechercher, comparer et écrire des artefacts. Utilisez une base de données quand le produit a besoin de concurrence, d’indexation, de contrôle d’accès, de durabilité ou d’état partagé entre utilisateurs. L’architecture la plus sûre sépare l’interface exposée à l’agent du substrat de stockage.⁷

Où se place MCP ?

MCP a sa place lorsque l’agent a besoin d’un pont typé vers des outils ou des données externes. MCP ne supprime pas le besoin de petites commandes, d’autorisations limitées et d’une autorisation au niveau de l’action. Le serveur doit encore décider si le sujet précis peut exécuter l’action précise.⁸

Conclusion

L’IA rend le code bon marché. Le code bon marché augmente la valeur du refus.

Le petit logiciel donne au refus une forme que la machine peut suivre : une commande, une sortie, une frontière d’autorisation, un chemin de test, un diff. La forme ne garantit pas la qualité. Elle rend toutefois le travail faible plus visible.

La disquette n’est plus la contrainte. L’inspectabilité l’est.

Références