Un agent, de nombreux spécialistes : pourquoi un IA personnel doit diriger le travail plutôt que de tout faire lui-même.
Un assistant IA personnel fonctionne mieux en tant qu’orchestrateur : il dirige les tâches vers des agents de codage, des modèles et des scripts simples, avec des permissions graduées.
Sources: I Stopped Trying to Build One AI Agent That Does Everything
Qwen, Nemotron, Gemma, DeepSeek. Inférence locale, AWS Bedrock, Azure. Différents environnements d’exécution, différentes tailles, différents prix, différents degrés de déception. Une série prolongée d’expériences avec Hermes, Codex, OpenCode, des modèles locaux et des API cloud part généralement du principe qu’il existe un modèle correct à trouver. Tôt ou tard, on se rend compte que c’est le mauvais problème. Une deuxième hypothèse se cache derrière cela, et c’est la plus intéressante : pourquoi l’agent personnel devrait-il faire tout seul ?
Le rêve de Jarvis
La première architecture est presque embarrassamment simple : une personne, puis un agent, puis tout le reste.
Les messages destinés à cet agent pourraient être : vérifier l’avancement des projets, corriger un problème dans l’un des dépôts, lister le calendrier de demain, signaler si le serveur Linux fonctionne correctement, rechercher un sujet et présenter les parties importantes. Cet agent est censé gérer tout cela.
Cela semble merveilleux, mais c’est justement là que les choses commencent à mal se passer, car tout constitue une surface API énorme.
Des outils plus performants existent déjà pour certaines tâches
Le codage en est l’exemple le plus clair. Codex et OpenCode ne sont pas simplement des fenêtres de chat associées à un modèle ; ils fonctionnent à l’intérieur d’un environnement de codage. Ils comprennent la structure des dépôts, lisent et recherchent des fichiers, modifient plusieurs fichiers en même temps, exécutent des commandes, inspectent les erreurs, lancent des tests, examinent les différences et itèrent. Il s’agit d’un équipement hautement spécialisé.
Supposons maintenant que l’agent personnel reçoive l’ordre de mettre en œuvre une fonctionnalité dans un projet. Deux approches sont possibles.
Approche A. Donnez à l’agent un modèle très puissant, ainsi que des accès au système de fichiers et à la shell. Apprenez-lui les opérations sur les répertoires. Mettez en place des mécanismes de gestion du contexte, de traitement des différences, d’exécution de commandes, de boucles de test et de récupération en cas d’erreur. Continuez à affiner le flux de travail de codage. Félicitations : un agent de codage est en train d’être reconstruit de zéro.
Approche B. L’agent reconnaît une tâche de codage et la transmet à Codex ou OpenCode. C’est clairement plus judicieux.
Un assistant n’a pas besoin d’être le meilleur en tout
C’est un véritable changement de mentalité. Un assistant personnel n’a pas besoin d’être le meilleur programmeur, chercheur, ingénieur DevOps, planificateur ou système de connaissances au monde. Il doit simplement savoir qui doit effectuer le travail. C’est une responsabilité différente, et potentiellement plus importante.
Les organisations humaines fonctionnent de la même manière. Un dirigeant n’écrit pas chaque fonction backend, ne configure pas chaque cluster Kubernetes, ne recherche pas chaque marché, ne crée pas chaque feuille de calcul, ne planifie pas chaque réunion ni ne répond à chaque demande de support. Sa valeur provient en partie de sa capacité à comprendre ce qui doit être fait, qui doit s’en charger et si le résultat est acceptable. Un orchestrateur IA personnel peut être envisagé de cette façon : il ne réalise pas toutes les tâches, mais il comprend suffisamment les intentions pour acheminer le travail correctement.
Une forme différente de système
Remplacez la chaîne personne, agent, un modèle géant et tout le reste par quelque chose comme ceci :
┌──────────────┐
│ Me │
└──────┬───────┘
│
▼
┌─────────────────┐
│ Google Chat │
└────────┬────────┘
│
▼
┌─────────────────┐
│ Hermes │
│ Orchestrator │
└────────┬────────┘
│
┌─────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
Coding Agents AI Models Tools
Codex/OpenCode Local / Cloud APIs / Servers
│ │ │
└─────────────────┼──────────────────┘
│
▼
Final Result
Le rôle de l’agent devient beaucoup plus clair. Il comprend la personne, connaît les capacités disponibles, choisit celle qui convient, fournit le contexte nécessaire, surveille le résultat et fait un rapport. C’est là l’assistant qui vaut vraiment la peine d’être utilisé.
Le chat en tant que porte d’entrée unique
Une application de chat comme Google Chat prend tout son sens dans ce concept. Elle ne doit pas révéler la complexité qui se cache en dessous. Du côté de l’utilisateur, il n’y a qu’une seule conversation. Un message du type « Vérifiez s’il s’est passé quelque chose d’important concernant le Projet X aujourd’hui » peut amener l’agent à consulter le système de tâches, à examiner GitHub, à vérifier l’état du serveur, à lire des documents pertinents, à demander à un autre modèle d’analyser quelque chose, puis à résumer. L’utilisateur n’a pas besoin de connaître tout cela, ni d’ouvrir cinq applications différentes. L’interface représente l’intention, et tout le reste relève de l’implémentation.
Le codage comme cas d’usage typique
Image montrant quelqu’un éloigné de l’ordinateur. Un message téléphonique indique qu’il y a un problème dans le flux d’authentification du Projet X et demande une correction si c’est possible. En principe, la chaîne de traitement se déroule ainsi : l’agent détermine quel projet est concerné, rassemble suffisamment d’informations pour localiser le répertoire, constate que le code doit être modifié et délègue la tâche à un agent de codage. Codex ou OpenCode ouvre le répertoire, examine le contenu, modifie les fichiers pertinents, exécute des tests, vérifie les différences et renvoie le résultat. L’orchestrateur le reçoit et signale par exemple : la validation du token de mise à jour utilisait une condition d’expiration incorrecte, l’agent de codage l’a corrigée, les tests pertinents passent, et voici ce qui a été modifié.
Le modèle qui a généré tel ou tel token au cours du processus importe peu. Ce qui compte, c’est que la tâche ait été accomplie correctement.
Les modèles deviennent de l’infrastructure
Lorsque l’agent fait partie d’une couche d’orchestration, des questions telles que savoir s’il faut utiliser Qwen, DeepSeek, un modèle local, Bedrock ou Azure cessent de s’exclure mutuellement. La réponse est simplement oui, avec des niveaux d’intelligence différents pour des tâches différentes. Un petit modèle local gère le routage simple. Un modèle cloud peu coûteux rédige des résumés. Un modèle de raisonnement plus puissant prend les décisions difficiles. Un agent de codage gère les dépôts. Un autre spécialiste s’occupe d’autres types de travaux. Les modèles deviennent de l’infrastructure, et l’infrastructure doit être remplaçable.
Éviter la dépendance à un seul fournisseur
Les modèles évoluent à une vitesse absurde. Ce qui semble être le choix évident aujourd’hui peut paraître médiocre six mois plus tard. Les prix changent, les fournisseurs changent, les modèles ouverts s’améliorent, les fenêtres de contexte s’agrandissent, les capacités d’appel d’outils s’améliorent et de nouvelles architectures d’inférence apparaissent. Si toute la configuration personnelle repose sur l’idée que le modèle X fait tout, changer de modèle est problématique. Une meilleure approche est :
Task
↓
Router
↓
Best available capability
Aujourd’hui, la dernière étape peut impliquer un prestataire donné et demain un autre, et le flux de travail ne doit pas s’en soucier.
Le routeur peut être plus important que le modèle
Beaucoup de temps est consacré à comparer les modèles : A obtient 74 points, B 78 points, C dispose d’un million de tokens de contexte, D coûte 60 % de moins. Ces informations sont utiles. Imaginez maintenant un système qui sait que A est le meilleur pour une tâche de raisonnement liée au codage, que B est rapide et peu coûteux pour la classification, que C est inutile car la demande peut être répondue localement, qu’une autre demande n’a pas besoin du tout d’un LLM mais seulement d’une appel API, qu’une demande doit être envoyée directement à Codex, et qu’une autre nécessite une question posée à l’utilisateur avant toute action.
Ici, une partie de l’intelligence réside dans le système qui décide de la manière dont elle est utilisée, ce qui est bien plus intéressant qu’un simple classement.
Chaque étape n’a pas besoin d’un LLM
Les agents rendent cela facile à oublier. Lorsqu’on demande si un serveur est en ligne, un agent n’a pas besoin d’un modèle de raisonnement de 200 milliards de paramètres pour déterminer s’il existe. Il effectue une vérification de santé, interprète le résultat et répond. Lorsqu’on demande combien d’espace disque reste, il exécute :
df -h
ensuite il analyse le résultat et répond. Un modèle de raisonnement coûteux à chaque étape n’est pas de l’intelligence ; il s’agit parfois simplement d’une mauvaise conception.
Permissions
Lorsqu’un agent peut déléguer des actions, un problème plus complexe apparaît : que peut-il faire ? Lire un calendrier diffère de l’envoi d’un e-mail. Lire un répertoire diffère de la fusion d’une demande de fusion. Vérifier un serveur diffère fortement de la suppression de fichiers. Un agent personnel utile nécessite donc un modèle de permissions associé à ses outils, à peu près comme ceci :
- La lecture s’effectue sans demande.
- La préparation de brouillons et de plans s’effectue sans demande.
- Les actions à faible risque peuvent être exécutées automatiquement.
- Toute action ayant des conséquences importantes attend une confirmation humaine.
Lorsqu’on lui demande d’identifier la cause d’une panne de service, l’agent peut se mettre immédiatement au travail. S’il estime que la base de données est endommagée et envisage de la supprimer pour la recréer, une confirmation doit d’abord être obtenue. L’autonomie ne devrait pas être binaire ; elle devrait être graduée en fonction du risque.
Mémoire et contexte
Un autre argument contre la transformation de chaque outil spécialisé en assistant personnel concerne le contexte. Codex doit comprendre le répertoire de fichiers, mais pas toute la vie du utilisateur. Un outil d’infrastructure doit connaître les serveurs, mais pas chaque conversation qui a jamais eu lieu. Le calendrier gère les réunions et le gestionnaire de tâches gère les tâches. L’orchestrateur peut alors devenir la couche qui comprend comment ces systèmes sont liés entre eux.
Prenez l’exemple de ce qui se passe avec un projet donné. Aucune requête de base de données unique ne peut y répondre. Une bonne réponse prend en compte les travaux de développement récents, l’activité sur GitHub, les tâches, les décisions antérieures, l’état du déploiement ainsi que ce que l’utilisateur comptait faire ensuite. C’est dans ce contexte inter-systèmes qu’une couche d’orchestration personnalisée devient véritablement précieuse.
Le piège de l’overengineering
Le danger est évident. Penser de cette manière rend facile la création d’un diagramme comme celui-ci :
User
↓
Intent Classifier
↓
Planning Agent
↓
Model Router
↓
Memory Agent
↓
Permission Agent
↓
Coding Agent
↓
Validation Agent
↓
Reflection Agent
↓
Supervisor Agent
↓
Another Agent Watching the Other Agents
Et puis passer trois mois à créer une organisation d’IA afin de pouvoir demander ce qui est prévu pour la journée n’aide personne. La leçon de toute cette expérience est que la complexité doit mériter sa place. Douze agents simplement parce qu’un diagramme d’architecture a l’air cool n’est pas une bonne raison ; en revanche, des capacités qui permettent de gagner du temps à répétition le sont.
Délégation avant autonomie
Les agents entièrement autonomes reçoivent beaucoup d’attention : on leur donne un objectif, on les laisse fonctionner pendant des heures, on permet aux agents de communiquer et de décider entre eux, puis on revient une fois que tout est terminé. C’est intéressant, mais ce n’est pas le bon point de départ pour un système personnel. Une délégation hautement fiable doit précéder l’autonomie maximale. L’objectif est de dire « faites X » et de faire en sorte que le système choisisse de manière fiable l’outil ou l’agent approprié et rapporte ce qui s’est passé. Une fois que cela fonctionne très bien, l’autonomie peut augmenter progressivement.
Plus d’outils spécialisés, pas moins
Au début, l’objectif semble être la consolidation : il y a trop d’outils d’IA, il faut donc en créer un seul qui les remplace. Il s’avère que c’est une erreur. L’état final pourrait bien consister en des systèmes d’IA plus spécialisés, avec la différence qu’ils n’auront plus besoin d’une gestion individuelle, tâche que la couche d’orchestration permet de résoudre. L’avenir pourrait être moins caractérisé par un seul AI qui règne sur tous et plus par une seule interface pour les coordonner tous. La différence est subtile mais importante.
À quoi sert l’agent
Après avoir mis en œuvre un tel système, après avoir provoqué des pannes, configuré une interface de chat, testé divers modèles et réfléchi intensément aux agents de codage spécialisés, le rôle de l’agent personnel devient évident. Il n’a pas besoin d’être l’IA la plus intelligente du système ; il doit simplement connaître la personne et ses systèmes. Il doit comprendre ce qui est demandé, quel contexte est pertinent, quelle capacité convient, ce qu’il peut faire, quand il a besoin de confirmation et comment restituer le résultat. Cela suffit, et tout le reste peut être délégué.
L’architecture qui mérite d’être souhaitée
La structure finale ressemble à peu près à ceci :
ME
│
▼
GOOGLE CHAT
│
▼
┌─────────────────┐
│ HERMES │
│ │
│ Intent │
│ Context │
│ Memory │
│ Permissions │
│ Orchestration │
└────────┬────────┘
│
┌──────────────────┼───────────────────┐
│ │ │
▼ ▼ ▼
AI MODELS CODING AGENTS TOOLS
│ │ │
Local / Cloud Codex/OpenCode GitHub/APIs
Fast / Strong Servers/Tasks
│ │ │
└──────────────────┼───────────────────┘
│
▼
HERMES
│
▼
ME
Il ne s’agit pas d’une boîte individuelle. Tout ce qui se trouve sous l’orchestrateur doit pouvoir être remplacé à un moment donné. Un agent de codage amélioré apparaît : on le remplace. Un modèle local amélioré apparaît : on le remplace également. L’inference en cloud devient moins chère : on envoie plus de tâches là-bas. Un fournisseur devient peu fiable : on contourne ce problème. Il ne devrait jamais être nécessaire de redessiner la manière d’utiliser l’assistant à chaque fois que l’industrie de l’IA évolue.
IA personnelle, éventuellement à l’envers
La plupart des produits d’IA se font concurrence en fonction de l’intelligence de leur modèle, ce qui est compréhensible. Cependant, à mesure que les modèles s’améliorent, un autre aspect gagne en importance : la coordination. Cela signifie savoir ce que veut dire la personne, son contexte, quels systèmes sont pertinents, quels outils existent, quel modèle convient, quelles actions sont sûres, quand poser des questions et quand ne pas utiliser du tout l’IA. L’assistant qui mérite d’être souhaité n’est pas nécessairement celui qui obtient le score le plus élevé aux tests ; c’est celui qui fait en sorte que toute l’intelligence et tout le logiciel autour d’une personne fonctionnent comme un seul système.
La version courte de la conclusion
Le point de départ est le souhait d’avoir un agent IA personnel. Le déploiement d’un tel agent montre que disposer d’un assistant persistant relève en réalité d’un problème d’infrastructure. La recherche du modèle parfait révèle que le choix du modèle est en fait un problème de routage. Déterminer ce que l’agent doit faire indique que l’assistant personnel peut être, au fond, un problème d’orchestration. L’architecture évolue ainsi, passant de la recherche du modèle le plus intelligent et de la mise à sa disposition de tous les outils à un système capable de comprendre l’intention et d’envoyer les tâches au bon endroit. Il s’agit d’une description bien moins magique de Jarvis, mais bien plus proche de quelque chose qui peut réellement être construit et utilisé au quotidien.
Lectures complémentaires
- Créer un agent de planification dans LangGraph : planifier, exécuter, replanifier, rapporter — Un agent de planification LangGraph à quatre nœuds pour la recherche financière : plans structurés, un registre d’outils conscient du nom d’espace, des limites de replanification et un exemple d’exécution traçée.
- MiniCPM5-2B contre les rivaux 4B : pourquoi un environnement d’agent raconte une histoire différente — Un modèle de 2,5 milliards de paramètres qui surpasse ses concurrents de 4 milliards de paramètres en termes de scores en une seule tentative reste deux à trois fois en retrait dans les environnements d’agent. Confusion entre versions d’index, débit local et situations où cela fonctionne.