Un chatbot répond. Un agent agit.
C'est la distinction qui compte quand un client me demande "est-ce qu'on peut automatiser ça avec l'IA ?" La réponse dépend de si le problème nécessite une réponse unique ou une séquence de décisions. La plupart des problèmes intéressants tombent dans la deuxième catégorie.
Ce qu'est vraiment un agent autonome
Un agent IA, c'est un LLM qui a accès à des outils (fonctions qu'il peut appeler) et qui reçoit le résultat de ses propres actions pour décider de la suite. Le modèle ne génère pas juste du texte — il raisonne, agit, observe, et recommence jusqu'à accomplir l'objectif.
Le pattern de base s'appelle ReAct (Reason + Act) :
Objectif → Réflexion → Action → Observation → Réflexion → Action → ...→ Résultat final
Exemple concret : qualifier un lead LinkedIn.
- Réflexion : "J'ai besoin du CA de l'entreprise et de la stack technique."
- Action : Appel outil
search_linkedin(company="Acme Corp") - Observation : "50 employés, secteur SaaS B2B, Paris"
- Réflexion : "Il me faut la stack — je vais regarder leur site."
- Action : Appel outil
scrape_website(url="acmecorp.com") - Observation : "HubSpot, Stripe, Intercom détectés via BuiltWith"
- Réflexion : "Score ICP élevé. Je peux générer le résumé."
- Résultat : Fiche lead enrichie, scorée, prête pour le CRM.
Tout ça sans intervention humaine entre chaque étape.
Architecture d'un agent en production
Voici la stack que j'utilise sur les projets réels :
GPT-4o (cerveau)
↓ tool_calls JSON
Orchestrateur LangChain / LangGraph
↓
Outils disponibles :
- scrape_web() → Playwright + proxies
- search_linkedin() → API ou scraping
- query_database() → PostgreSQL / Supabase
- send_email() → Resend API
- update_crm() → HubSpot API
- generate_report() → GPT-4o en mode structuré
↓
Memory (court terme : messages, long terme : résumés compressés)
↓
Logs + monitoring (LangSmith ou custom)
Le point critique : chaque outil doit retourner un résultat structuré (JSON ou texte court). Le LLM ne lit pas des pages entières — il lit des résumés.
LangGraph pour les workflows complexes
LangChain suffit pour les agents linéaires. Dès que vous avez des branches conditionnelles (si le score est > 70, envoyer à l'équipe commerciale ; sinon, mettre en nurturing), LangGraph est plus adapté.
from langgraph.graph import StateGraph, END
def route_lead(state):
if state["score"] >= 70:
return "commercial"
elif state["score"] >= 40:
return "nurturing"
else:
return "disqualified"
graph = StateGraph(AgentState)
graph.add_node("enrich", enrich_lead)
graph.add_node("score", score_lead)
graph.add_conditional_edges("score", route_lead, {
"commercial": "notify_sales",
"nurturing": "add_to_sequence",
"disqualified": END,
})
Le graph est visualisable, testable par nœud, et les erreurs sont localisées. Beaucoup plus maintenable qu'un agent libre qui fait n'importe quoi.
Les 3 cas d'usage où ça change vraiment quelque chose
1. Qualification de leads à grande échelle
Entrée : liste de 500 entreprises. Sortie : 50 leads scorés avec fiche complète. L'agent fait le travail d'un commercial junior en 20 minutes, sur critères objectifs et documentés.
2. Reporting automatique multi-sources
Chaque semaine/mois : l'agent se connecte à Stripe, HubSpot, GA4, extrait les KPIs, les analyse avec GPT-4o, génère un résumé narratif, et l'envoie sur Slack + Notion. Zéro intervention.
3. Support documentaire (RAG avec agent)
L'agent lit la question de l'utilisateur, décide quels documents chercher, lance la recherche vectorielle, synthétise la réponse, cite les sources. Si la question est ambiguë, il demande une clarification avant de répondre.
Ce que l'agent ne peut pas encore faire
Être honnête sur les limites évite les déceptions :
- Raisonnement quantitatif précis : les LLMs font des erreurs sur les calculs complexes. Déléguez ça à du code Python, pas au modèle.
- Décisions irréversibles sans supervision : envoyer un email en masse, modifier une base de données critique — toujours mettre un humain dans la boucle pour ces actions.
- Contexte infini : même GPT-4o avec 128k tokens a des limites. Pour les corpus longs, le RAG reste nécessaire.
Le garde-fou qu'on oublie : les boucles infinies
Un agent qui décide lui-même de sa prochaine action peut, dans de rares cas, se retrouver coincé dans une boucle : il appelle un outil, l'observation ne le satisfait pas, il rappelle le même outil avec des paramètres légèrement différents, indéfiniment. Sans garde-fou, c'est une facture OpenAI qui explose en silence.
Trois protections que je mets systématiquement en place :
MAX_ITERATIONS = 8
MAX_COST_PER_RUN = 0.50 # USD
def run_agent(objective: str) -> AgentResult:
iterations = 0
total_cost = 0.0
while iterations < MAX_ITERATIONS:
action, cost = agent_step(objective)
total_cost += cost
iterations += 1
if total_cost > MAX_COST_PER_RUN:
return AgentResult(status="aborted", reason="cost_limit_exceeded")
if action.type == "final_answer":
return AgentResult(status="success", data=action.data)
return AgentResult(status="aborted", reason="max_iterations_reached")
Un agent qui n'a pas convergé après 8 étapes ou 0,50$ de coût cumulé n'ira probablement pas mieux à l'étape 20 — mieux vaut arrêter, logger le cas, et l'envoyer en revue manuelle plutôt que de laisser tourner indéfiniment. Sur les pipelines que j'ai en production, ce plafond se déclenche rarement (moins de 1% des runs), mais le jour où un outil externe renvoie une réponse inattendue en boucle, c'est ce qui évite la mauvaise surprise en fin de mois.
Pour aller plus loin
Si vous avez un processus répétitif qui nécessite plusieurs étapes de décision et plusieurs outils, un agent est probablement la bonne approche. Décrivez votre cas d'usage — je peux évaluer la faisabilité et vous donner une première architecture en 48h.
Le tl;dr : un agent bien architecturé n'est pas magique, mais il est redoutablement efficace sur les tâches où l'humain passe du temps à faire des allers-retours entre outils.