Introduction aux agents IA : au-delà des simples LLM

Depuis l’émergence des grands modèles de langage, on entend partout le mot « agent ». Pourtant, la frontière entre un LLM classique et un vrai agent IA reste floue pour beaucoup. Cet article démêle le tout — de la définition jusqu’à l’implémentation d’un premier agent fonctionnel.

Qu’est-ce qu’un agent IA ?

Un modèle de langage, dans sa forme la plus basique, est une fonction : il prend du texte en entrée et produit du texte en sortie. C’est tout. Il ne peut ni lire un fichier, ni appeler une API, ni mémoriser une conversation au-delà de sa fenêtre de contexte.

Un agent IA brise ces contraintes. C’est un système qui :

• Perçoit son environnement (via des outils, des APIs, des fichiers…)
• Raisonne à partir de ses observations en s’appuyant sur un LLM
• Agit en sélectionnant et en exécutant des actions
• Itère jusqu’à atteindre l’objectif fixé

La différence fondamentale, c’est la boucle. Un LLM fait un aller-retour. Un agent tourne jusqu’à ce que le problème soit résolu — ou qu’il échoue.

“An agent is an LLM that can take actions in the world and observe the results of those actions.” — Une définition sobre, mais qui capture l’essentiel.

Comment fonctionne la boucle agentique

Le cœur d’un agent, c’est ce qu’on appelle la boucle ReAct (Reason + Act). À chaque tour :

1. Le LLM reçoit l’état courant (instruction initiale + historique des observations)
2. Il décide soit de répondre directement, soit d’appeler un outil
3. Si un outil est appelé, son résultat est injecté dans le contexte
4. On recommence jusqu’à ce que le LLM produise une réponse finale

flowchart TD
    U([Utilisateur]) -->|Instruction| A(LLM)
    A --> D(Outil nécessaire ?)
    D -->|Oui| T(Appel d'outil)
    T -->|Résultat| O(Observation)
    O --> A
    D -->|Non| R([Réponse finale])
    R --> U

Ce qui rend ce pattern puissant, c’est que le LLM voit les résultats intermédiaires et peut adapter sa stratégie. S’il pensait trouver un fichier à un endroit et qu’il n’y est pas, il peut chercher ailleurs.

Anatomie d’un agent : les outils

Un outil (ou tool) est une fonction que le LLM peut choisir d’appeler. Il est décrit par :

• un nom unique
• une description en langage naturel (c’est ce que lit le LLM pour décider)
• un schéma d’entrée (JSON Schema ou Zod)
• une implémentation qui fait le vrai travail

Exemple minimal : un outil météo

Voici un exemple minimal en TypeScript avec le SDK Vercel AI :

import { tool } from 'ai';
import { z } from 'zod';

// Outil qui récupère la météo courante pour une ville
const getWeather = tool({
  description: 'Retourne la température actuelle et les conditions météo pour une ville donnée.',
  parameters: z.object({
    city: z.string().describe('Nom de la ville, ex: "Paris"'),
    unit: z.enum(['celsius', 'fahrenheit']).default('celsius'),
  }),
  execute: async ({ city, unit }) => {
    // En prod : appel à une vraie API météo
    const data = await fetchWeatherAPI(city, unit);
    return {
      temperature: data.temp,
      condition: data.condition,
      humidity: data.humidity,
    };
  },
});

Le LLM ne voit jamais le code de la fonction. Il voit uniquement le nom, la description, et le schéma. C’est la description qui détermine si et quand l’outil sera utilisé — soignez-la.

Brancher l’agent : configuration et exécution

Une fois les outils définis, on assemble l’agent. Avec generateText du SDK AI de Vercel, c’est une dizaine de lignes :

import { generateText } from 'ai';
import { anthropic } from '@ai-sdk/anthropic';

const result = await generateText({
  model: anthropic('claude-sonnet-4-5'),
  tools: { getWeather },
  maxSteps: 10, // nombre max d'itérations de la boucle agentique
  system: `Tu es un assistant météo. Réponds toujours en français.
Utilise l'outil getWeather pour obtenir des données précises avant de répondre.`,
  prompt: 'Quel temps fait-il à Lyon et à Marseille aujourd\'hui ?',
});

console.log(result.text);
// → "À Lyon, il fait actuellement 14°C avec des nuages. À Marseille..."

Pour lancer cela en local, installez les dépendances nécessaires :

npm install ai @ai-sdk/anthropic zod

Et configurez votre clé API :

# .env
ANTHROPIC_API_KEY=sk-ant-...

# Ou en variables d'environnement système
export ANTHROPIC_API_KEY="sk-ant-..."

Architectures multi-agents

Pour les tâches complexes, on ne se limite plus à un seul agent. On compose des réseaux d’agents :

• Orchestrateur : reçoit la tâche globale, la décompose, délègue aux sous-agents
• Agents spécialisés : chacun excellent dans un domaine précis (recherche web, écriture de code, analyse de données…)
• Agent critique : évalue les outputs des autres avant de les retourner à l’utilisateur

Ce pattern, qu’on appelle parfois supervisor pattern, permet de paralléliser le travail et d’appliquer le principe de responsabilité unique aux agents eux-mêmes.

Les outils à surveiller dans cet espace : LangGraph (Python, très mature), Mastra (TypeScript, en pleine montée), CrewAI (abstraction haut niveau), et le protocole MCP d’Anthropic pour standardiser les interfaces d’outils.

Ce que les agents ne font pas (encore)

Gardons les pieds sur terre :

• Les agents font des erreurs — souvent là où un humain ne se tromperait pas
• Leur fiabilité baisse avec le nombre d’étapes : une chaîne de 10 actions à 95% de précision chacune donne 60% de chance d’aboutir
• Ils sont non-déterministes par nature — le même prompt peut donner des chemins d’exécution différents
• Le coût (tokens consommés) et la latence sont bien plus élevés qu’un simple appel LLM

Pour des tâches critiques, prévoyer une supervision humaine dans la boucle — ce qu’on appelle le pattern human-in-the-loop.

Cela dit, même imparfaits, les agents ouvrent une classe entière de problèmes qui étaient jusqu’ici inattaquables par du code classique : naviguer le web, déboguer un dépôt entier, coordonner des workflows complexes. L’infrastructure s’améliore vite — c’est le bon moment pour apprendre.