Claude Sonnet et le Jarvis Pattern : pourquoi un système d'exploitation peut suffire aux agents d'IA

Un texte publié sur Habr propose de simplifier radicalement le débat sur les agents d'IA. Au lieu de frameworks, de graphes, d'orchestrateurs et de bases vectorielles, l'auteur avance une formule : LLM + système d'exploitation + fichiers. Son argument : un modèle actuel est déjà assez puissant pour utiliser le terminal, les API et une arborescence de fichiers presque comme le ferait un ingénieur. Le goulot d'étranglement n'est donc pas la quantité d'outillage autour de l'agent, mais la conception de sa mémoire, de ses accès et de son environnement de travail.

L'auteur du concept, l'architecte IT Egor Zinoviev, décrit le Jarvis Pattern comme un agent personnel en réseau, rattaché à un spécialiste précis. Cet agent ne vit ni dans un navigateur ni sur un ordinateur portable, mais dans son propre conteneur, avec accès à l'infrastructure, et agit au nom de la personne. Il cite en exemple son agent DevSecOps umax, basé sur Claude Sonnet, qui couvrirait selon lui l'ensemble des tâches du métier : de la configuration du RBAC dans Kubernetes et du travail avec Vault jusqu'au déploiement de clusters, à l'analyse d'images Docker, à la mise en place du CI/CD et à l'analyse de vulnérabilités.

La thèse centrale : l'agent n'a pas besoin d'un zoo d'outils assemblé à l'avance. S'il doit interroger Prometheus, il utilise curl ; s'il doit transformer des données, il prend jq, sed ou awk ; et s'il n'existe aucun utilitaire adapté, il en écrit un lui-même et l'ajoute à son environnement de travail.

La mémoire fait l'objet d'une insistance particulière. Pour l'auteur, c'est la seule partie vraiment non résolue de l'architecture des agents. Il propose de la répartir en mémoire déclarative, procédurale et épisodique : faits, instructions et expérience. L'expérience négative compte autant que la réussite : savoir quelle voie a déjà mené à une impasse, et pourquoi.

À la recherche vectorielle et aux modèles de graphes, Zinoviev préfère le système de fichiers et les fichiers markdown, vus comme une carte naturelle des itinéraires : les dossiers définissent les catégories, les noms de fichiers indiquent la direction, et un document d'index sert de point de départ pour plonger dans le bon contexte. Un Memory Agent distinct doit fonctionner en parallèle : après chaque session, il détermine ce qu'il faut conserver, mettre à jour ou jeter.

De ce schéma découle une vision plus large du rôle de l'humain. Le Jarvis Pattern ne vise pas une IA entièrement autonome, mais le renforcement d'un ingénieur précis : la personne fixe la tâche, vérifie le résultat et décide en situation d'incertitude, tandis que l'agent prend en charge l'exécution et la routine. L'auteur estime que ce modèle pourrait changer le recrutement, car les candidats pourraient être évalués non sur des questions abstraites, mais sur leur façon de travailler avec l'agent sur un cas réel.

L'article donne même des repères du marché de l'entreprise : un cycle de recrutement de 40–60 jours, un coût de l'erreur de plusieurs dizaines de pourcents du salaire annuel et une part notable de salariés qui ne passent pas la première année.

Une autre conclusion pratique concerne les logiciels : si l'agent travaille via des API et des CLI, les produits dépourvus d'API sérieuse commenceront à perdre du terrain, quelle que soit la beauté de leur interface.

Bien que le texte soit présenté comme un manifeste, l'auteur souligne qu'il ne se considère pas comme un cas isolé. Pour l'étayer, il renvoie à des idées similaires chez d'autres ingénieurs et à des produits où l'agent est déjà perçu davantage comme un environnement d'exploitation pour le spécialiste que comme un chat doté de boutons.

En ce sens, le Jarvis Pattern n'est ni un standard prêt à l'emploi ni une nouvelle plateforme, mais une tentative de consigner un basculement : une partie de l'industrie commence à voir l'agent d'IA non comme une application autonome, mais comme une couche de pilotage au-dessus de l'infrastructure existante. Si cette logique s'impose, le débat principal sur les agents d'IA passera du choix du framework à la conception de la mémoire, des droits d'accès et des outils API-first. Pour les équipes, cela signifie moins de magie dans l'architecture et davantage d'exigences sur la qualité du contexte ; pour les spécialistes, une valorisation accrue des connaissances métier approfondies, que l'agent peut démultiplier mais pas remplacer.