Agent IA
Définition
Programme qui utilise un LLM pour comprendre une demande, planifier des actions et appeler des outils (recherche, calculs, API) pour accomplir une tâche complète, sans intervention humaine à chaque étape.
Comment ça marche
Un agent IA est une boucle qui combine un LLM, un objectif, une liste d'outils et un état partagé. Le modèle reçoit le contexte de la tâche, choisit l'outil à invoquer (recherche dans une base, appel d'API, envoi d'e-mail), lit le résultat, puis décide de l'étape suivante. Tant que l'objectif n'est pas atteint, la boucle continue. Côté code, on l'orchestre avec le tool use du LLM, des sorties structurées pour les décisions clés, et un état persisté (souvent en base) qui survit aux redémarrages. Le tout tourne dans une route serveur, une queue (Inngest, Trigger.dev) ou un worker dédié selon la durée des tâches.
À quoi ça sert
Un agent prend tout son sens quand une tâche demande plusieurs étapes conditionnelles que des règles statiques ne couvrent pas. Cas concrets : qualifier un lead entrant (chercher dans LinkedIn, recouper avec le CRM, scorer, router vers le bon commercial), trier une boîte mail support (classer, répondre aux questions simples, escalader le reste), générer un rapport hebdomadaire en croisant Stripe, Google Analytics et le CRM, enrichir un catalogue produit depuis des fiches PDF. Le gain n'est pas la qualité d'une seule réponse mais la suppression d'une heure de travail manuel répétitif chaque jour.
Quand l'utiliser
On déploie un agent quand la tâche cible coche trois cases : elle prend assez de temps humain pour justifier l'investissement (au moins quelques heures par semaine), elle suit des règles métier identifiables mais avec des variations qu'un script ne capte pas, et son échec est rattrapable. À l'inverse, pour une tâche stricte et bien définie (recalcul TVA, validation de schéma JSON, export CSV planifié), un script classique reste plus rapide à écrire, moins cher à exécuter et plus prévisible. L'agent paie son coût quand la flexibilité du LLM ajoute une vraie valeur, pas par défaut.
Comment l'intégrer
On commence par cadrer le périmètre d'actions : quelles fonctions l'agent peut appeler, quelles données il peut lire, quelles écritures il a le droit de faire. Chaque tool est décrit avec une signature claire (nom, paramètres, description). On ajoute des garde-fous métier : validation côté serveur sur chaque action sensible, plafond de coût par exécution, timeout global. Pour l'orchestration, n8n suffit sur les workflows courts ; pour des tâches longues ou complexes, on passe sur des frameworks comme Mastra, LangGraph ou un orchestrateur custom Next.js + Inngest. Tout doit être loggé pour pouvoir rejouer ou auditer.
Les pièges à éviter
Le premier piège est l'agent trop libre qui appelle des tools dans le mauvais ordre, oublie une étape ou rentre en boucle infinie. On le borne par des limites explicites : nombre maximum d'itérations, validation entre chaque étape critique, sorties structurées plutôt que texte libre. Le second piège est le prompt injection via les données externes : un e-mail malveillant peut contenir des instructions pour rediriger l'agent. On sépare strictement le contexte de confiance (vos instructions) du contenu utilisateur. Le troisième piège est l'absence de monitoring : sans logs ni alertes sur les coûts, un agent peut consommer des milliers d'euros en quelques heures.
Les coûts et la latence
Chaque itération d'un agent consomme des tokens en entrée (contexte, historique, résultats des tools) et en sortie (décisions). Une tâche complexe peut enchaîner 10 à 30 appels, donc multiplier les coûts unitaires. Sur un volume sérieux, on bascule sur des modèles plus économiques pour les étapes simples et on garde le modèle haut de gamme pour les décisions critiques. Côté latence, un agent met typiquement de quelques secondes à plusieurs minutes selon le nombre d'étapes, ce qui exclut souvent une exécution synchrone : on lance la tâche, on stocke l'ID, et l'utilisateur reçoit le résultat par notification ou rafraîchissement.
Notre approche
On démarre tous les projets d'agent par un cas d'usage unique et mesurable, pas par une plateforme générique. Si l'objectif est de traiter les leads entrants, on construit un agent qui fait ça et rien d'autre, avec ses logs, ses alertes et son tableau de bord. Une fois rentabilisé, on ajoute un deuxième agent à côté. Cette discipline évite l'erreur classique du projet IA tentaculaire qui ne livre rien. Côté stack, on combine Next.js + Supabase pour l'orchestration légère, n8n pour les workflows visuels, et Mastra ou un orchestrateur custom quand la logique métier dépasse ce que ces outils gèrent proprement.