J'ai construit un agent IA. La vraie valeur était ailleurs.

#L'histoire commence par un malentendu

Il y a quelques mois, j'ai commencé à construire un assistant IA personnel. Un bot Telegram connecté à Claude, avec accès à Gmail, Google Calendar, des notes Obsidian, un moteur de recherche web, de la synthèse vocale, de la mémoire persistante dans Supabase. Le genre de projet qui donne l'impression de construire quelque chose de sérieux.

Et pendant longtemps, j'ai appelé ça un « agent IA ». Parce que c'est le mot qui circule partout. Un LLM qui a des outils, qui prend des décisions, qui exécute des tâches dans le monde réel — ça ressemble à un agent, non ?

Sauf qu'à un moment, une question inconfortable s'est imposée : qu'est-ce que j'avais vraiment construit ?

#Ce qu'on appelle un « agent » — démystification

Le mot « agent » est devenu un buzzword fourre-tout. Simon Willison, une des voix les plus lucides sur le sujet, donne une définition simple : « An LLM agent runs tools in a loop to achieve a goal. »

C'est tout. Un LLM. Des outils. Une boucle.

En pseudocode, ça ressemble à ça :

goal = "vérifie mes emails non lus et résume-les"
context = [system_prompt, goal]

loop:
  response = llm.complete(context)

  if response.wants_tool_call:
    result = execute_tool(response.tool_name, response.tool_args)
    context.append(tool_result)
    continue
  else:
    return response.text

Ce n'est pas une intelligence artificielle générale. Ce n'est pas un système autonome mystérieux. C'est un LLM qui tourne en boucle et qui appelle des fonctions externes jusqu'à obtenir une réponse finale.

Anthropic le dit explicitement dans leur guide Building Effective Agents : « Many patterns can be implemented in a few lines of code... don't hesitate to reduce abstraction layers and build with basic components. »

Tu n'as pas besoin de magie. Tu as besoin de comprendre le pattern.

#Le vrai problème : des couches qui n'ajoutent pas de valeur

En regardant mon assistant avec honnêteté, j'ai réalisé quelque chose de gênant. Mon bot Telegram recevait un message, construisait un contexte, et l'envoyait à Claude CLI pour avoir une réponse. Claude CLI, c'est une interface vers l'API Anthropic. Qui tourne un LLM. Avec des outils.

Trois couches. Pour accéder à un LLM.

Le provider — qu'il s'appelle Claude, ChatGPT ou Gemini — c'est fondamentalement un LLM + un system prompt + des outils. Il n'y a pas de cerveau de coordination supplémentaire là-dedans. La valeur n'est pas dans le provider. La valeur n'est pas dans la couche « agent ».

La valeur est dans les outils que tu connectes, et dans la qualité du contexte que tu fournis au modèle.

Ce que j'avais construit de vraiment utile ? L'intégration Gmail. L'intégration Google Calendar. La mémoire persistante avec Supabase et pgvector. Le scraper web. Les notes Obsidian. La recherche via Brave.

Tout ça, ce sont des outils. Pas un agent.

#Le piège des frameworks

Si tu cherches « comment construire un agent IA » sur internet, il y a de fortes chances que tu tombes sur LangChain, LlamaIndex ou un de leurs cousins. Ces frameworks promettent de te faciliter la vie avec des concepts comme les « chains », les « agents », les « retrievers ». Ça semble structuré, professionnel.

Mais il y a un problème fondamental.

La startup Octomind, qui développe des outils de test automatisé basés sur des LLMs, a publié un post-mortem honnête : après plus de 12 mois en production avec LangChain, ils l'ont retiré. Leur conclusion ? LangChain avait introduit tellement d'abstractions que déboguer un comportement inattendu du modèle devenait un cauchemar. Tu ne savais plus si le problème venait du modèle, du framework ou de ta propre logique.

Ce n'est pas un cas isolé. Sur Hacker News, un fil intitulé « Sick of AI Agent Frameworks » a généré des centaines de commentaires dans la même direction. Un des plus cités mentionnait un cabinet d'avocats qui fait tourner plus de 900 agents différents — zéro framework, juste des appels API directs. Fiables, maintenables, compréhensibles.

Martin Fowler pose le diagnostic plus profondément : les LLMs introduisent une nouvelle nature d'abstraction, combinant montée en abstraction et non-déterminisme. Empiler des frameworks par-dessus n'additionne pas de la valeur — ça additionne de l'opacité. Et l'opacité est l'ennemie du débogage.

Pour un développeur qui débute, c'est particulièrement piégeux. Un framework peut donner l'illusion de comprendre ce qui se passe. Mais si tu ne comprends pas la boucle de base, tu ne comprendras pas pourquoi ton « agent » fait des choses bizarres à 2h du matin un mardi.

#La vraie question : de quels outils le LLM a-t-il besoin ?

Qu'est-ce qu'un LLM ne peut pas faire nativement ? Il ne peut pas lire tes emails, ajouter un événement dans ton calendrier, chercher sur le web, écrire dans une base de données, ni exécuter du code. Ce sont des problèmes d'accès au monde réel. Et la solution, c'est de connecter des outils — pas de construire un « agent ».

La distinction peut sembler subtile, mais elle est importante en pratique.

Quand tu penses « je construis un agent », tu réfléchis à un système global, une architecture, une couche de coordination. Tu commences à parler d'« orchestration », de « mémoire d'agent », de « planification de tâches ». Et tu finis par construire de l'infrastructure pour de l'infrastructure.

Quand tu penses « je connecte des outils à un LLM », tu penses à des interfaces claires. Chaque outil a une responsabilité définie, un schéma d'entrée/sortie précis, des cas d'erreur documentés. C'est du vrai génie logiciel. C'est ce qu'on sait faire.

La boucle de décision — « est-ce qu'il faut appeler un outil ? lequel ? avec quels paramètres ? » — le LLM s'en charge très bien si tu lui donnes des outils bien définis et un contexte de qualité.

#MCP : connecter proprement

C'est là qu'entre en scène le Model Context Protocol (MCP). Annoncé par Anthropic fin 2024, MCP est un protocole standardisé pour connecter des outils à un LLM. L'idée centrale : au lieu que chaque application réinvente la roue, on définit un protocole universel.

Un serveur MCP expose des outils. Un client MCP (ton application, ou Claude directement) découvre ces outils et les utilise. Le protocole est basé sur JSON-RPC — lisible, déboguable, interopérable.

Voici un exemple concret — un outil MCP pour récupérer des emails non lus :

server.tool(
  "get_unread_emails",
  "Fetch unread emails from Gmail. Returns sender, subject, snippet, date.",
  {
    days: z.number().optional().default(7)
      .describe("Number of past days to search"),
  },
  async ({ days }) => {
    const emails = await getUnreadEmails(days);
    return {
      content: [{ type: "text", text: JSON.stringify(emails, null, 2) }],
    };
  },
);

Un nom d'outil. Une description que le LLM lira pour savoir quand l'utiliser. Un schéma Zod pour les paramètres. Une fonction d'implémentation. C'est tout.

#Ce que MCP apporte concrètement

L'adoption a été massive. En mars 2025, OpenAI a adopté MCP dans son Agents SDK. En décembre 2025, Anthropic a fait don du protocole à l'Agentic AI Foundation sous la Linux Foundation — un signal fort de neutralité. Le protocole est passé de 100 000 téléchargements en novembre 2024 à plus de 8 millions en avril 2025.

#Les nuances honnêtes

MCP n'est pas une solution parfaite. Voici les points à garder en tête.

La sécurité. Un serveur MCP expose des capacités d'action dans le monde réel. Si tu exposes un outil send_email sans mécanisme de confirmation, un prompt injection dans un email que tu lis pourrait déclencher l'envoi d'un autre email. La surface d'attaque d'un système avec des outils puissants est réelle.

La complexité du protocole. MCP est plus complexe qu'un simple appel de fonction. Tu dois gérer un processus séparé (le serveur), la communication via stdio ou HTTP, les négociations de capacités, les timeouts. Pour des projets simples, c'est du surcoût réel.

L'écosystème encore jeune. Les outils de débogage, les bonnes pratiques, les patterns d'erreur courants — tout ça est en train de se construire. Tu vas rencontrer des problèmes dont la réponse n'existe pas encore sur Stack Overflow.

#Ce que j'en retiens

Quatre leçons tirées de cette expérience.

L'agent n'est pas la valeur. La boucle LLM + outils + contexte, n'importe qui peut l'implémenter en trente lignes. Ce qui fait la qualité d'un système, c'est la richesse des outils, la précision de leurs descriptions, et la qualité du contexte passé au modèle.

Les frameworks cachent des problèmes qu'ils ne résolvent pas. LangChain ne résout pas le problème de « mon LLM fait des choses bizarres ». Il ajoute une couche entre toi et le comportement du modèle. Si tu ne comprends pas la boucle de base, tu ne comprendras pas ce que le framework fait pour toi — ni contre toi.

MCP est la bonne abstraction. Pas parce qu'Anthropic l'a inventé. Parce que la séparation entre « exposer un outil » et « décider quand l'utiliser » est fondamentalement juste. Tu fais du bon travail d'ingénierie côté outil. Tu laisses le LLM faire ce qu'il fait bien côté décision.

La complexité se paie toujours. Chaque couche d'abstraction supplémentaire, c'est de la complexité que tu devras déboguer à 23h quand quelque chose ne fonctionne pas. Commence simple. Reste simple aussi longtemps que possible.

#Par où commencer

Si tu démarres un projet similaire aujourd'hui — un assistant personnel, un outil de productivité, un bot avec des capacités réelles — oublie la question « comment je construis un agent ? ».

Pose-toi plutôt la question : de quels outils mon LLM a-t-il besoin pour être utile ?

Implémente ces outils proprement. Documente leur interface correctement — une bonne description d'outil, c'est la moitié du travail. Donne au LLM un contexte de qualité. Et laisse-le faire le reste.

MCP est un bon format pour structurer cette approche, surtout si tu veux que tes outils soient réutilisables et interopérables avec plusieurs clients.

Le reste — orchestration complexe, mémoire d'agent, planification de tâches — soit tu en as vraiment besoin et tu l'implémentes spécifiquement, soit tu n'en as pas besoin et tu t'es sauvé des mois de travail inutile.

Sources :

• Building Effective Agents — Anthropic
• Designing agentic loops — Simon Willison
• Why we no longer use LangChain — Octomind
• LLMs bring new nature of abstraction — Martin Fowler
• Model Context Protocol — Anthropic