Construire des agents IA qui fonctionnent vraiment

Tout le monde construit des agents. Beaucoup cassent au troisième run.

Le problème vient rarement du modèle seul. Le plus souvent, on lui demande de décider, corriger, router, réessayer, sauvegarder et expliquer en même temps. À ce niveau-là, même un bon modèle finit par produire un truc fragile.

Voilà la structure que je garde quand je veux qu'un agent tienne dans le temps sans devenir fragile.

L'anatomie d'un agent fiable

Un agent fiable a trois parties. Une seule devrait vraiment impliquer l'IA.

Déclencheur : quelque chose de déterministe démarre l'agent. Un planning, un webhook, un dépôt de fichier, une soumission de formulaire. Pas "quand l'IA pense que c'est le bon moment".

Contexte : l'agent rassemble ce dont il a besoin avant d'appeler l'IA. Le document, les données, les préférences utilisateur, les contraintes. L'appel IA se fait avec un contexte complet, pas au milieu d'une exploration floue.

Action : après la réponse de l'IA, quelque chose de déterministe se passe. On sauvegarde, on envoie, on log ou on publie. Cette étape n'improvise pas. Elle exécute.

Les agents cassent quand l'IA est responsable du déclencheur, ou quand l'étape d'action attend que l'IA gère des erreurs qu'elle ne peut pas gérer.

Trois patterns qui tiennent

Pattern 1 : chaîne linéaire

Déclencheur → récupérer contexte → appel IA → formater → sauvegarder/envoyer

Le pattern le plus simple. Chaque étape a un seul rôle. L'appel IA est à l'étape 3, pas à l'étape 1.

Mon agent de repurposing de contenu suit ce schéma : un nouveau post LinkedIn (déclencheur) → récupérer le texte du post (contexte) → demander à Claude de le réécrire en thread Twitter + paragraphe newsletter (appel IA) → sauvegarder les drafts dans Notion (sauvegarde).

Il tourne tous les jours de la semaine depuis trois mois sans intervention.

Pattern 2 : routage conditionnel

Déclencheur → récupérer contexte → appel IA → classifier → router vers A ou B

L'IA classifie ou prend une décision, puis une logique déterministe gère chaque branche. Les branches n'utilisent pas l'IA. Elles utilisent sa réponse comme signal.

Exemple : email entrant → extraire l'intention → si "support", créer un ticket Linear ; si "vente", ajouter au CRM ; si "newsletter", transférer vers Notion. L'IA fait une chose (classifier). Le routage est du code.

Pattern 3 : boucle de feedback

Déclencheur → récupérer contexte → appel IA → vérifier → (réessayer ou terminer)

L'agent vérifie sa propre sortie avant de considérer la tâche terminée. La vérification repose sur des règles, pas sur un deuxième avis de l'IA : le format est-il correct ? Le schéma passe-t-il ? Le champ requis est-il présent ?

Réessaie une fois au maximum. Si ça échoue deux fois, log et alerte. Ne boucle pas en silence.

Erreurs courantes

Chaîner des appels IA sans checkpoints. Si l'étape 2 produit quelque chose de mauvais, l'étape 3 va traiter quelque chose de mauvais et produire encore pire. Ajouter une gate de validation entre les appels IA.

Utiliser l'IA pour de l'extraction quand une regex suffit. Extraire une adresse email, un prix ou une date, c'est souvent du pattern matching. L'IA ajoute de la latence, du coût et de l'incohérence pour rien.

Pas d'idempotence. Si l'agent tourne deux fois, crée-t-il deux enregistrements ? Envoie-t-il deux emails ? Rendre chaque action idempotente : vérifier avant d'insérer, utiliser des clés uniques, logger les complétions.

Gérer les erreurs à l'intérieur de l'agent. Les agents ne devraient pas attraper leurs propres erreurs et essayer de se rétablir. Ils devraient échouer vite, logger clairement, et laisser un humain investiguer. Les échecs silencieux sont pires que les bruyants.

n8n vs code

Utilise n8n quand :

• Les étapes sont principalement des intégrations tierces (Slack, Notion, Gmail, Linear)
• Tu veux voir le flux visuellement
• Des non-développeurs doivent le modifier
• Tu prototypes et tu veux éviter l'infrastructure

Utilise du code quand :

• La logique est assez complexe pour qu'un graphe visuel devienne illisible
• Tu as besoin de gestion d'erreurs ou de retry personnalisés
• L'agent est dans le chemin critique et doit être testé comme du code
• Tu as déjà un backend qui peut l'héberger

J'utilise n8n pour les opérations de contenu (social, newsletter, CRM). J'utilise du code pour tout ce qui touche le produit directement. Dans les deux cas, l'agent a besoin d'accéder à tes outils pour récupérer le contexte - connecter Claude à Notion, Gmail et Drive via MCP est la façon dont je branche ça côté code.

Le test

Avant de shipper un agent, je pose les questions : que se passe-t-il quand l'IA ne retourne rien d'utile ? Que se passe-t-il quand l'API tierce est en panne ? Que se passe-t-il s'il tourne deux fois ?

Si la réponse à l'une de ces questions est "je ne sais pas" ou "ça crashe", l'agent n'est pas prêt. Ces cas limites arrivent dans la première semaine. Les prévoir en amont.

Les agents fiables sont ennuyeux. Ils tournent, font leur truc, et tu oublies qu'ils existent. C'est l'objectif.

---

Tu ne sais pas encore si tu construis un prompt, un workflow ou un agent ? La distinction compte plus que le label.

Tu construis des agents directement dans ton codebase ? Un bon CLAUDE.md est ce qui fait que Claude génère du code d'agent qui suit tes conventions au lieu de boilerplate générique.