Construire des agents IA qui fonctionnent vraiment

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

Le mode d'échec est toujours le même : l'IA est chargée de faire trop de choses, au mauvais endroit. L'agent ne tombe pas en panne parce que l'IA est peu fiable — c'est parce que l'architecture a rendu la fiabilité impossible.

Voici ce que j'ai appris en construisant des agents qui tournent semaine après semaine.

L'anatomie d'un agent fiable

Tout agent qui fonctionne a trois parties, et une seule devrait impliquer l'IA.

Déclencheur — quelque chose de déterministe démarre l'agent. Un schedule, un webhook, un dépôt de fichier, une soumission de formulaire. Pas "quand l'IA décide que c'est le 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 à mi-chemin d'une exploration.

Action — après que l'IA produit son output, quelque chose de déterministe se passe avec. Ça se sauvegarde, s'envoie, se log ou se publie. L'étape d'action ne réessaie pas et 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 elles-mêmes n'utilisent pas l'IA — elles utilisent l'output de l'IA 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 son propre output avant de considérer la tâche terminée. L'étape de vérification est basée sur des règles, pas sur l'IA : l'output a-t-il le bon format ? Passe-t-il un schema check ? Le champ requis est-il présent ?

Réessayer au maximum une fois. Si ça échoue deux fois, logger et alerter — ne pas boucler.

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 la regex suffit. Extraire une adresse email, un prix, une date — ce sont des problèmes de pattern matching. L'IA ajoute de la latence, du coût et de l'incohérence pour zéro bénéfice.

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.