Agents IA : architecture et implémentation en Python

Comment construire des agents IA : architecture, ReAct et mise en œuvre pratique en Python

Les agents IA ne sont pas de simples 'chatbots intelligents' ; ce sont des systèmes autonomes capables de planifier, de sélectionner des outils, d’effectuer des appels externes et d’ajuster leurs actions en temps réel. Contrairement à RAG, qui se contente de fournir un contexte avant la génération, un agent gère l’intégralité du cycle de résolution de tâches — de l’analyse de l’objectif jusqu’au résultat final, avec vérification interne. Cela représente un niveau d’automatisation fondamentalement nouveau pour les développeurs, notamment dans les scénarios nécessitant des interactions multi-étapes avec des API, du code, des bases de données ou des services externes.

Pourquoi RAG est insuffisant pour les tâches complexes

RAG répond à un problème spécifique : mettre à jour les connaissances grâce à des sources externes. Toutefois, il est statique : le modèle reçoit un ensemble de fragments et génère une réponse une seule fois. Il n’existe aucun mécanisme permettant de refaire une requête lorsque les résultats s’avèrent inappropriés, aucune évaluation de la fiabilité des sorties intermédiaires ni de replanning. Dans les flux de travail réels, cela est crucial :

• Lors de l’analyse de documentation technique, il peut être nécessaire de suivre des liens séquentiellement, d’extraire du code de différents fichiers et de le valider ;
• Lors de la génération d’un rapport basé sur des données Excel, il faut d’abord lire le tableau, puis déterminer les indicateurs, les calculer et seulement ensuite formater le résultat ;
• Lors de l’automatisation de CI/CD, il faut interpréter les journaux d’erreurs, exécuter des diagnostics, appliquer des correctifs et confirmer le résultat.

Tous ces scénarios vont bien au-delà d’une simple génération ponctuelle. C’est précisément là qu’une architecture dynamique — c’est-à-dire un agent — est nécessaire.

Les composants clés d’un agent IA moderne

Un agent n’est pas un monolithe ; c’est un système coordonné de modules interagissant entre eux. Chaque composant remplit une fonction strictement définie et peut être remplacé ou étendu sans avoir à réécrire l’ensemble de la logique.

LLM comme cœur décisionnel

Le modèle ne génère pas directement la réponse finale ; il agit plutôt comme le « cerveau » : il formule un plan, sélectionne les outils, interprète les résultats des appels et décide de la prochaine étape. Son rôle est la gestion stratégique, et non la production de texte.

Outils comme interface avec l’environnement

Il s’agit de toutes les capacités externes : requêtes HTTP vers des API REST, exécution de code Python dans un bac à sable, lecture/écriture de fichiers, exécution de requêtes SQL, appel d’utilitaires CLI. Un outil doit disposer d’une description claire (docstring), d’arguments typés et d’une gestion des erreurs — seulement ainsi le LLM peut l’utiliser en toute sécurité.

Mémoire : à court et à long terme

La mémoire à court terme comprend le contexte actuel de la conversation et les résultats intermédiaires (par exemple, l’ID d’une ressource créée). La mémoire à long terme inclut des bases de connaissances vectorielles, des réponses mises en cache et des données historiques de la session utilisateur. Elle permet à l’agent de « se souvenir » du contexte entre deux appels et d’apprendre de l’expérience.

Planificateur et contrôleur d’erreurs

Le planificateur décompose l’objectif en étapes, suit les progrès et prévient les boucles. Le contrôleur d’erreurs vérifie la validité des résultats des outils, recoupe les faits avec les sources et initie des réessais si quelque chose tourne mal. Sans ces composants, l’agent est instable et imprévisible.

ReAct : un modèle de comportement transparent pour les LLM

ReAct (Reason + Act + Observe) n’est pas un framework — c’est un modèle de comportement qui définit un cycle de travail clair pour l’agent. Il rend le raisonnement interne du modèle visible et contrôlable :

• Reason — le modèle analyse l’état actuel, formule une hypothèse sur la prochaine action et explique pourquoi elle est nécessaire ;
• Act — le modèle appelle un outil avec des arguments spécifiques ;
• Observe — le modèle reçoit le résultat de l’appel et évalue son applicabilité à la tâche.

Ce cycle se répète jusqu’à ce que l’objectif soit atteint. Par exemple, lorsqu’on cherche des informations sur la compatibilité d’une bibliothèque avec Python 3.12, le modèle « reasonne » d’abord qu’il faut consulter PyPI et GitHub ; puis « acte » en appelant get_pypi_info('requests') ; après avoir « observé » la réponse, il décide s’il faut analyser le code source du dépôt.

L’avantage de ReAct est sa reproductibilité et sa facilité de débogage. Chaque étape est enregistrée : plan → appel → résultat → nouvelle décision. Cela est crucial pour les systèmes de production, où l’audit et le traçage sont obligatoires.

Systèmes multi-agents : l’échelle par la spécialisation

Un seul agent universel atteint rapidement ses limites de complexité. Les systèmes multi-agents (MAS) résolvent ce problème en répartissant les rôles. Au lieu d’un monolithe, on a une équipe d’agents spécialisés coordonnés par un orchestrateur.

Les rôles typiques dans un MAS incluent :

• Planner — décompose l’objectif, détermine l’ordre des sous-tâches et les attribue aux exécutants ;
• Researcher — travaille avec des sources externes : API, documentation, bases de données ;
• Executor — exécute du code, modifie des fichiers, applique des configurations ;
• Validator — vérifie la conformité des résultats aux exigences et leur sécurité.

Le coordinateur collecte les résultats, résout les conflits et forme la réponse finale. Cette approche offre trois avantages majeurs :

• Parallélisme : plusieurs agents peuvent traiter des sous-tâches indépendantes simultanément ;
• Fiabilité accrue : le validateur détecte les erreurs que l’exécutant pourrait manquer ;
• Débogage simplifié : une défaillance dans un rôle n’entraîne pas la paralysie de l’ensemble du système.

Cependant, les MAS nécessitent un protocole d’interaction bien pensé et une protection contre les dépendances cycliques — par exemple, lorsque le researcher demande des données au validator, mais que le validator attend la confirmation du researcher.

Pratique : un agent assistant minimal sur LangChain

Construisons un agent simple mais entièrement fonctionnel, capable de récupérer la météo, de trouver des événements et d’envoyer des e-mails. L’objectif est de montrer comment les composants s’assemblent en un système unifié, plutôt que de créer une solution prête à la production.

Initialisation du modèle et de l’environnement

Nous utiliserons Qwen 3.5 (9B) via Ollama — un modèle suffisamment puissant pour les tâches d’agent et assez léger pour tourner dans Google Colab. La connexion est standard :

from langchain_openai import ChatOpenAI

llm = ChatOpenAI(
    model="qwen3.5:9b",
    base_url="http://localhost:11434/v1",
    api_key="ollama",
    temperature=0.3,
)

Définition des outils

Chaque outil est une fonction Python décorée avec @tool, complète d’une docstring claire et d’arguments typés. Par exemple, get_weather :

@tool
def get_weather(city: str) -> str:
    """Retourne la météo actuelle dans la ville spécifiée.
Accepte le nom de la ville en russe ou en anglais."""
    # ... implémentation utilisant l’API Open-Meteo
    return f"{name} : {weather['temperature_2m']}°C, {desc}, vent {weather['wind_speed_10m']} km/h"

Il est important que la fonction gère les erreurs de réseau, les villes inexistantes et les codes météo invalides — sinon l’agent recevra du texte non structuré au lieu de la réponse attendue.

Prompt utilisateur et contexte

Le prompt définit le rôle, les contraintes et le ton de la réponse. Pour un agent technique, il est crucial d’indiquer explicitement :

• Quels outils sont disponibles et quand les utiliser ;
• Que faire en cas d’erreur (réessayer, demander des précisions à l’utilisateur ou refuser) ;
• Comment formater la réponse finale (par exemple, uniquement en JSON, sans explications).

USER_CONTEXT contient des données personnalisées — nom, préférences, historique d’interactions. Cela permet à l’agent d’adapter le ton et le niveau de détail.

Ce qui compte

• Un agent IA n’est pas un LLM avec un prompt étendu ; c’est un système architecturalement complexe, avec une division claire des responsabilités entre les composants.
• ReAct n’est pas seulement une « fonctionnalité » — c’est un modèle indispensable pour garantir la transparence, la débogabilité et la sécurité en production.
• Les outils doivent être typés, documentés et résilients aux erreurs — sinon l’agent perd le contrôle de l’exécution.
• Les systèmes multi-agents ne se justifient pas par la mode ; ils sont nécessaires pour gérer la complexité à grande échelle : un seul agent ne peut pas gérer de manière fiable des dizaines d’outils et de sources.
• Les agents de production nécessitent des mécanismes de traçage, qui enregistrent chaque étape du cycle, ainsi qu’une validation rigoureuse des données d’entrée et de sortie.

— Editorial Team