Construire un agent IA fonctionnel : un glossaire pratique

Un agent IA est un programme qui reçoit un objectif, décide d'une séquence d'actions, et exécute ces actions en utilisant des outils jusqu'à ce que l'objectif soit atteint ou qu'il abandonne. C'est différent d'un chatbot, qui répond simplement aux messages. Un agent planifie, appelle des fonctions, vérifie les résultats, et s'ajuste. Si vous n'avez utilisé ChatGPT que par un navigateur, construire votre premier agent est le moment où le modèle cesse d'être un générateur de texte et devient un composant dans un système plus large.

La boucle centrale

Tout agent, peu importe comment il est commercialisé, exécute une version du même type de boucle : observer, réfléchir, agir, répéter. Concrètement :

1. L'agent reçoit une tâche (« trouver le vol le moins cher pour Lisbonne le mois prochain et rédiger un résumé par email »).
2. Il appelle le LLM avec la tâche plus une description des outils disponibles.
3. Le modèle retourne soit une réponse finale, soit un appel d'outil, comme search_flights(destination="Lisbon", month="2025-06").
4. Votre code exécute cette fonction, obtient un résultat réel, et le réinjecte dans le contexte du modèle.
5. Le modèle décide quoi faire ensuite : appeler un autre outil, demander une clarification, ou terminer.

Ce modèle s'appelle souvent la boucle ReAct (reason plus act), et c'est la base de frameworks comme les exécuteurs d'agents de LangChain, les agents LlamaIndex, et l'API de function-calling d'OpenAI. Vous pouvez implémenter tout cela vous-même en moins de 100 lignes de Python avec juste une API LLM et une boucle while — les frameworks ajoutent de la commodité, pas de la magie.

Les outils font que c'est un agent

Un modèle sans outils ne peut que parler. Donnez-lui des fonctions et il peut agir. Les outils sont typiquement des fonctions Python ordinaires emballées avec un schéma qui décrit leur nom, paramètres et objectif, pour que le modèle sache quand et comment les appeler. Exemple :

def get_weather(city: str) -> str:
    """Return current weather for a given city."""
    resp = requests.get(f"https://api.weather.example/v1/{city}")
    return resp.json()["summary"]

Avec le function-calling d'OpenAI, vous passez un schéma JSON avec cette fonction, et le modèle produit un appel structuré comme {"name": "get_weather", "arguments": {"city": "Lisbon"}} au lieu de texte libre. Votre code analyse cela, exécute la vraie fonction, et retourne le résultat comme un nouveau message dans la conversation. Répétez jusqu'à ce que le modèle ait assez d'informations pour répondre.

Mémoire et état

Un appel API unique n'a pas de mémoire au-delà de sa fenêtre de contexte. Les agents ont besoin d'un état explicite : une liste courante de messages (l'historique de conversation), et souvent un stockage séparé pour des faits à plus long terme. Pour des tâches courtes, une liste Python de dicts représentant la conversation suffit. Pour les agents qui doivent se souvenir de choses entre les sessions, vous aurez recours à une base de données vectorielle (Chroma, Pinecone, Qdrant) pour stocker et récupérer les informations passées pertinentes via des embeddings.

Ne sur-engineerez pas cela au départ. Un nombre surprenant de projets « agent » échouent non pas parce que le LLM est faible mais parce que la gestion d'état est bâclée : des messages dupliqués, une croissance illimitée du contexte, ou une perte de trace sur quel appel d'outil correspond à quel résultat.

Un exemple minimal de fonctionnement

Voici la forme d'un agent au strict minimum en utilisant l'API d'OpenAI, sans framework :

messages = [{"role": "user", "content": "What's the weather in Lisbon?"}]

while True:
    response = client.chat.completions.create(
        model="gpt-4o",
        messages=messages,
        tools=[weather_tool_schema],
    )
    msg = response.choices[0].message
    if msg.tool_calls:
        for call in msg.tool_calls:
            result = get_weather(**json.loads(call.function.arguments))
            messages.append(msg)
            messages.append({
                "role": "tool",
                "tool_call_id": call.id,
                "content": result,
            })
    else:
        print(msg.content)
        break

C'est un vrai agent fonctionnel. Tout le reste — les stratégies de planification, la coordination multi-agent, les pipelines de récupération — s'appuie sur cette boucle.

Où ça casse

Les agents échouent de manières prévisibles : des boucles infinies d'appels d'outils quand le modèle ne peut pas dire qu'il a réussi, des arguments de fonction hallucines, et des coûts incontrôlés en réappelant des outils chers. Protégez-vous contre les boucles avec un plafond d'itération dur (disons, 10 étapes) et enregistrez chaque appel d'outil pendant le développement. Validez les arguments avant d'exécuter quoi que ce soit qui touche à un système réel — un agent qui peut envoyer des emails ou exécuter des commandes shell a besoin de la même sanitisation d'entrée que vous appliqueriez au code côté utilisateur, parce que le LLM est, en effet, un utilisateur non fiable générant cette entrée.

Où aller ensuite

Une fois la boucle fonctionnelle, les problèmes intéressants commencent : choisir entre des designs mono-agent et multi-agent, décider combien d'autonomie accorder, et tester les agents de manière fiable quand leur sortie n'est pas déterministe. Les parcours IA et Python de Korra Studio couvrent la retrieval-augmented generation, la conception de prompts, et les motifs de tool-calling en plus de profondeur si vous voulez continuer à construire à partir d'ici.