Claude Sonnet et Jarvis Pattern : pourquoi les agents IA pourraient ne nécessiter qu'un système d'exploitation

Un article publié sur Habr propose de simplifier radicalement la discussion sur les agents d'IA : au lieu de frameworks, de graphes, d'orchestrateurs et de bases de données vectorielles, l'auteur propose la formule LLM + système d'exploitation + fichiers. L'idée est que les modèles modernes sont déjà suffisamment puissants pour utiliser les terminaux, les APIs et les structures de fichiers presque comme le ferait un ingénieur, ce qui signifie que le goulot d'étranglement n'est pas la quantité d'infrastructure autour de l'agent, mais plutôt comment sa mémoire, ses accès et son environnement de travail sont organisés.

Egor Zinovyev, architecte informatique, décrit le Jarvis Pattern comme un agent réseau personnel attaché à un spécialiste spécifique. Un tel agent fonctionne dans son propre conteneur avec accès à l'infrastructure et agit au nom de la personne.

À titre d'exemple, il présente son agent DevSecOps umax basé sur Claude Sonnet, qui, selon ses dires, couvre l'ensemble complet des tâches métier : de la configuration RBAC dans Kubernetes et de l'utilisation de Vault jusqu'au déploiement de clusters, l'analyse des images Docker, la configuration CI/CD et l'analyse des vulnérabilités.

La thèse principale est que l'agent n'a pas besoin d'un arsenal d'outils préassemblé : si une requête Prometheus est nécessaire, il utilise curl ; s'il faut transformer des données, il utilise jq, sed ou awk ; s'il n'existe pas d'utilitaire approprié, il l'écrit et l'ajoute au flux de travail.

L'accent particulier est mis sur la mémoire. Selon l'auteur, elle reste la partie véritablement non résolue de l'architecture des agents. Il propose de la diviser en mémoire déclarative, procédurale et épisodique : faits, instructions et expérience. Particulièrement important est non seulement l'expérience positive, mais aussi l'expérience négative—la connaissance des chemins qui mènent à une impasse et pourquoi.

Au lieu de la recherche vectorielle et des modèles de graphes, Zinovyev mise sur le système de fichiers et les fichiers markdown comme carte naturelle des itinéraires : les dossiers définissent les catégories, les noms de fichiers indiquent la direction, et les documents d'index servent de points de départ pour se plonger dans le contexte approprié. En parallèle doit fonctionner un Memory Agent séparé qui, après chaque session, analyse ce qu'il faut sauvegarder, mettre à jour ou supprimer.

De cette logique découle une vision plus large du rôle humain. Jarvis Pattern ne concerne pas une IA complètement autonome, mais l'augmentation d'un ingénieur spécifique : la personne définit la tâche, vérifie le résultat et prend des décisions en contexte d'incertitude, tandis que l'agent assume l'exécution et la routine. L'auteur croit qu'un tel modèle peut transformer l'embauche, car les candidats peuvent être évalués non pas sur des questions abstraites, mais sur la façon dont ils travaillent avec l'agent sur des cas réels. L'article présente même des références du marché d'entreprise : cycle d'embauche de 40–60 jours, coût d'erreur représentant des dizaines de pourcentages du salaire annuel, et une part notable d'employés ne dépassant pas la première année.

Un autre résultat pratique concerne les logiciels : si l'agent fonctionne via API et CLI, les produits sans API adéquate commenceront à perdre du terrain, indépendamment de 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 isolé. À titre de preuve, il cite des idées similaires d'autres ingénieurs et de produits dans lesquels l'agent est déjà perçu comme un environnement opérationnel pour le spécialiste, plutôt que comme un chat avec des boutons.

En ce sens, Jarvis Pattern n'est ni un standard finalisé ni une nouvelle plateforme, mais une tentative de capturer un changement : une partie de l'industrie commence à voir l'agent d'IA non comme une application isolée, mais comme une couche de gestion sur l'infrastructure existante.

Si cette logique s'impose, le principal débat autour des agents d'IA basculera du choix du framework vers la conception de la mémoire, les droits d'accès et les outils API-first. Pour les équipes, cela signifie moins de magie dans l'architecture et des exigences plus strictes sur la qualité du contexte ; pour les spécialistes, cela signifie une valeur croissante des connaissances métier approfondies, que l'agent peut mettre à l'échelle mais non remplacer.