Agent ia 24h : mon architecture 3 couches construite en 6 mois (carnet de bord)

Quand on me demande si j'ai un agent qui tourne 24h/24, ma réponse est gênée : oui, mais pas comme on l'imagine. Mon agent n'est pas un petit génie qui répond seul à mes clients à 3h du matin. C'est un système de 3 couches — perception, décision, exécution — qui surveille, qualifie, déclenche 200 à 400 actions par jour sans que j'y pense. La promesse marketing du "agent IA autonome 24/7" et la réalité opérationnelle, ce sont deux produits différents.

Cet article est le carnet de bord des 6 mois que j'ai passés à construire ce système. Si tu pars de zéro, lis d'abord mon article sur le fonctionnement d'un agent autonome pour le vocabulaire, et mon test de 30 jours sur N8N pour le choix de stack initial. Ici, on parle d'architecture, pas de théorie.

Pourquoi 99% des agents "24/7" plantent au bout de 48h

Le piège classique : tu vois une démo de 90 secondes sur YouTube, l'agent répond à un email, qualifie un lead, met à jour un CRM, tout le monde applaudit. Lundi tu le mets en prod, mardi il a crashé 3 fois, mercredi tu le débranches, samedi LinkedIn te dit que les agents c'est overrated.

Le problème n'est pas l'agent. Le problème, c'est qu'on confond démo et système résilient. Une démo, c'est 1 scénario nominal, 1 set de données propres, 1 opérateur qui supervise. Un système 24/7, c'est 6 000 scénarios par mois, 12 types d'erreurs différents, 0 opérateur en S3. La distance entre les deux, c'est exactement les 6 mois qu'il m'a fallu.

Voici les 3 raisons pour lesquelles ça plante, classées par fréquence observée sur les setups que j'ai audités (clients, membres, prospects) depuis janvier 2026 :

1. Pas de couche de supervision. L'agent agit, mais personne ne regarde s'il agit correctement. Un humain doit être alerté quand l'agent dévie, sinon la première erreur se propage en cascade. 80% des setups que je vois n'ont aucun système d'alerte. L'agent est un feu de camp sans personne à côté.

2. Pas de garde-fous sur les actions irréversibles. Envoyer un email, poster sur les réseaux, déclencher un paiement — aucune de ces actions ne devrait être exécutée sans validation pour les 30 premiers jours. La plupart des setups les exécutent dès le jour 1. Surprise : ça dérape.

3. Pas de gestion du rate limiting. Les API externes (Gmail, Stripe, LinkedIn, Meta) ont des limites. Un agent qui tourne 24/7 les atteint en quelques heures. Si tu n'as pas de file d'attente et de backoff, l'agent crash, se relance, crash, se relance, et spam l'API jusqu'à se faire bannir.

Si tu ne règles que ces 3 points, ton agent a 80% de chances de tenir plus d'un mois. Le reste, c'est du détail. Le reste, c'est l'architecture.

L'architecture 3 couches que j'ai construite (perception / décision / exécution)

J'ai essayé 2 architectures avant celle-ci. La première était un monolithe N8N de 47 nodes — un bordel impossible à débugger, qui faisait tout dans le même workflow. La deuxième était un setup multi-agents avec un orchestrateur LangChain — élégant sur le papier, lent en prod, debugging cauchemardesque. La troisième, celle qui tourne, c'est 3 couches distinctes qui communiquent par messages.

Couche 1 — Perception. Cette couche surveille. Elle ne décide rien, elle ne fait rien, elle observe. 4 agents cron tournent toutes les 5 à 15 minutes : 1 surveille les nouveaux emails (Gmail API), 1 surveille les nouveaux leads (formulaires + webhook), 1 surveille les prix concurrents (scraping Airtable), 1 surveille les commentaires YouTube (API YouTube). Chaque agent de perception produit un événement normalisé (JSON) et le pousse dans une file Postgres. Coût de cette couche : 0,40€/jour en API Claude Haiku pour la normalisation.

Couche 2 — Décision. Cette couche est le cerveau. Elle ne s'exécute pas en cron, elle réagit aux événements de la couche 1. Quand un événement arrive, elle prend une décision : "ignorer", "alerter Ilyass", "déclencher une action". C'est un agent Claude Sonnet qui reçoit l'événement + le contexte (historique du contact, dernière interaction, score) et retourne une décision structurée. Coût : 0,10 à 0,30€ par décision, 200 à 400 décisions/jour, soit 6 à 12€/jour en API. C'est le poste de coût principal du système.

Couche 3 — Exécution. Cette couche fait. Elle ne décide rien, elle applique la décision de la couche 2. Pour chaque type d'action (envoyer un email, mettre à jour un CRM, créer une facture), il y a un worker dédié avec ses propres garde-fous. Aucun worker n'a accès à Internet au-delà de l'API qu'il doit appeler. Aucun worker ne prend de décision seul. Cette couche ne fait qu'exécuter ce que la couche 2 a décidé.

Pourquoi cette séparation marche : quand un truc plante, tu sais exactement où. Si l'agent n'a pas vu un email, c'est la couche 1. Si l'agent a mal qualifié un lead, c'est la couche 2. Si l'agent a envoyé un email bizarre, c'est la couche 3. Le debugging passe de 3 heures à 10 minutes. C'est la différence entre un système qui survit et un système que tu débranches en panique.

Le stack exact après 6 mois d'itération

Je vais être précis, parce que c'est la question que je reçois le plus. Voici le stack en prod depuis janvier 2026, après avoir testé et abandonné 2 setups :

• Orchestration : N8N self-hosted (v1.74, sur un VPS à 8€/mois). Pas le cloud N8N, le self-hosted. Le cloud te bride à 24€/mois avec des limits bizarres, le self-hosted te donne un contrôle total pour 8€/mois. J'ai écrit un article dédié à N8N qui détaille pourquoi je l'ai choisi, je ne reviens pas dessus.
• Cerveau : Claude Sonnet 4.5 via API (Anthropic). Pas GPT-4o, pas Mistral, pas Llama. J'ai testé les 4, Sonnet 4.5 est le seul qui produit des décisions structurées fiables sur 1 000+ appels. Coût réel : 11€/jour en moyenne, 18€/jour en pic.
• Stockage événements : Postgres 16 sur le même VPS, 2GB, jamais plein. Table unique events avec index sur created_at et processed_at. Pas de Redis, pas de queue managée, pas de Kafka. Pour 400 événements/jour, Postgres suffit et tu n'as pas une infra à maintenir.
• Monitoring : UptimeRobot (gratuit) + un dashboard custom en Next.js qui affiche les événements non traités. Si un événement est dans events depuis plus de 30 minutes, c'est rouge. J'ai regardé ce dashboard 3 fois par jour pendant 2 mois, maintenant 1 fois par semaine.
• Cron / scheduling : Cron classique du VPS. Pas de Airflow, pas de Temporal, pas de Prefect. Pour mon volume, crontab -e suffit. Quand tu dépasses les 50 cron jobs, on reparle de Temporal.
• Secrets : .env chiffré + Vault si tu es à l'aise. Pour un solopreneur, .env + permission chmod 600 + backup local fait le job.

Coût mensuel total du système en prod (juin 2026) : 412€. Décomposé : 8€ VPS, 11€ × 30 = 330€ API Claude, 24€ monitoring premium (0€ en gratuit), 50€ de buffer pics. C'est le coût pour faire tourner 200 à 400 actions/jour avec un uptime de 99,2%.

Le 0,8% d'indisponibilité, c'est moi : quand je touche au code, migre un workflow, ou teste un prompt, l'uptime baisse. En prod stable, il est de 99,8%. Mesuré.

Les vrais chiffres après 6 mois (pas les chiffres des démos)

Je vais te donner les chiffres que personne ne donne dans les articles. Les chiffres que j'ai réellement observés en regardant mon dashboard tous les jours depuis janvier 2026.

200 à 400 actions/jour exécutées par le système. Ce n'est pas 10 000, ce n'est pas 100. C'est la réalité d'un solopreneur avec 1 business. Plus, et tu n'as pas la capacité de superviser. Moins, et le système ne se rentabilise pas.

11€/jour en API Claude en moyenne, 18€ en pic. Le pic arrive en début de mois, quand mes séquences email et la prospection tournent à fond. En moyenne, sur 30 jours glissants, c'est 11€. Soit 330€/mois. C'est le poste principal, et c'est non négociable. Si tu veux un agent qui marche vraiment, il faut payer le LLM qui pense.

0,40€/jour en API Haiku pour la couche de perception. C'est la normalisation des événements bruts en JSON structuré. Haiku suffit, c'est 100x moins cher que Sonnet et le travail est trivial (extraction d'entités, classification binaire).

2,3 erreurs/jour en moyenne, dont 0,7 qui nécessitent une intervention humaine. Les 2,3 erreurs sont principalement des événements que la couche 2 a mal qualifiés (un client mécontent classifié en "neutre" au lieu de "chaud"). Les 0,7 qui nécessitent intervention sont des cas où l'agent a refusé de prendre une décision (sécurité, "je ne suis pas sûr") et m'a alerté. C'est exactement le comportement qu'on veut : l'agent demande quand il doute.

4 minutes/jour de supervision. C'est le temps que je passe à regarder le dashboard et à valider les alertes. 4 minutes, pas 1 heure. C'est le but. Si tu passes 1 heure par jour à superviser ton agent, il ne t'a pas libéré, il t'a ajouté du travail.

ROI : 1 850€/mois de valeur générée, pour 412€ de coût, soit 4,5x. Calcul : 2 clients signés en mai (1 200€ MRR × 2 = 2 400€), moins 550€ de perte de leads mal qualifiés récupérés manuellement. Pas 10x comme certains te le promettent. 4,5x, honnête.

Les 4 erreurs qui m'ont coûté 2 mois

Je te les donne cash, parce que c'est ce qui m'a pris le plus de temps. Si tu les évites, tu gagnes 2 mois.

Erreur 1 — Trop d'agents en parallèle. J'ai lancé 8 agents semaine 1. 6 ont crashé en 72h, j'ai passé 3 semaines à stabiliser. Le bon pattern : 1 agent, 1 cas d'usage, en prod 2 semaines, puis 1 de plus. Quand j'ai compris ça, j'ai tout coupé sauf 1, stabilisé, puis ajouté les autres 1 par 1. Rétro : 1 mois gagné.

Erreur 2 — Pas de logs structurés au début. J'ai commencé avec des logs N8N natifs. Illisibles, impossibles à requêter. Quand un truc plantait, je perdais 30 minutes à chercher. J'ai migré vers une table events Postgres avec JSON structuré. Maintenant, en 30 secondes je trouve le problème. Le coût de mise en place : 1 journée. Le coût de ne pas l'avoir fait : 1 mois de debug cumulé.

Erreur 3 — Confier des actions irréversibles trop tôt. Premier mois, l'agent envoyait des emails, publiait sur les réseaux, modifiait des factures. Au jour 23, il a envoyé une relance à un prospect qui venait de signer. Le prospect a annulé. 3 200€ de MRR perdu en 5 minutes. Depuis : aucune action irréversible sans validation humaine pendant 30 jours. Si tu ne retiens qu'une chose, retiens ça.

Erreur 4 — Ne pas monitorer le coût API. Le premier mois, j'ai dépensé 720€ en API Claude sans m'en rendre compte. Pas de plafond, pas d'alerte. Depuis, j'ai mis une alerte à 15€/jour et un kill switch à 25€/jour. Le système s'arrête et m'alerte si on dépasse. Coût de la mise en place : 20 minutes. Coût de l'absence : 1 mois de marge en moins.

Le détail financier complet est dans mon article sur les vrais coûts d'un agent IA. Tu y verras les mêmes leçons sous un autre angle.

Comment répliquer ça en 30 jours (la méthode)

Si je devais tout recommencer demain, voici les 4 étapes que je ferais. C'est exactement ce que j'enseigne dans mon article sur l'architecture système, version compressée.

Semaine 1 — Fondations. Choisis UN cas d'usage. UN seul. Le plus simple, le plus répétitif, celui qui te bouffe le plus de temps. Installe N8N self-hosted sur un VPS à 8€. Crée 1 workflow qui fait ce cas d'usage, avec validation humaine à chaque étape. Pas d'agent intelligent, juste de l'automatisation bête.

Semaine 2 — Couche de décision. Remplace 1 node de ton workflow par un appel Claude Sonnet qui prend la décision. Garde la validation humaine à côté, en mode "shadow" (l'agent décide, tu valides, tu corriges si besoin). Construis ta table events Postgres. Commence à logger.

Semaine 3 — Boucle autonome. Si l'agent a pris 50 bonnes décisions d'affilée sans intervention, retire la validation humaine sur les actions réversibles. Garde-la sur les irréversibles. Mets en place ton alerting (UptimeRobot + dashboard simple). C'est là que ton agent commence à te libérer du temps.

Semaine 4 — Scale et durcissement. Ajoute 1 cas d'usage. Pas 3, pas 5. Un seul. Mesure le coût API, le taux d'erreur, le temps gagné. Si les chiffres sont OK, passe à 1 autre cas d'usage le mois suivant. Si les chiffres sont KO, itère encore 2 semaines avant d'ajouter.

En 30 jours, tu auras 1 agent en prod qui te libère 1 à 2 heures par jour. C'est pas "scaler à 1M€/mois en automatique". C'est 1 à 2 heures. C'est déjà énorme. Le reste, c'est du stack additionnel, mois par mois.

Ce que ça veut dire pour toi (sans bullshit)

Trois choses que personne ne te dit.

Premièrement, ça prend 6 mois, pas 2 semaines. Les 2 premières semaines, tu as une démo. Les 5 mois et demi suivants, tu construis la résilience. Pas la patience ou pas le cash pour tenir 6 mois, ne commence pas : tu vas cramer 200 à 500€ en API pour rien.

Deuxièmement, ça coûte 400 à 600€/mois pour 1 business solo. Si quelqu'un te vend un agent IA pour 29€/mois qui fait ça, c'est un template Zapier avec un wrapper LLM. Tu le verras en 2 semaines.

Troisièmement, c'est un système de 3 couches, 4 à 8 workers, 200 à 400 actions/jour — pas un magicien, une équipe. Comme une équipe, il faut la manager, la superviser, la faire évoluer. Déléguer à une IA et ne plus y penser, c'est pas pour tout de suite.

Si tu veux construire ton premier agent en 30 jours, en partant de zéro, en ayant quelqu'un pour débugger avec toi quand ça plante, et en évitant les 4 erreurs que j'ai payées 2 mois : c'est exactement ce qu'on fait dans /agentise. 30 jours, 1 cas d'usage, ton premier agent en prod avec 0 à 2 erreurs/jour. Le early-access Founding 30 ouvre par batches de 10 places. Si tu veux le prochain batch, rejoins /agentise →

Et si tu veux aller plus loin tout de suite, j'ai détaillé le stack exact, les prompts, et les 3 couches dans mon guide pragmatique sur Claude. C'est le même système, sous l'angle des prompts et des coûts.