Un agent IA en cron toutes les 10 minutes, headless, sans personne aux commandes : l'architecture

L'agent de démo vs l'agent de production

Tout le monde sait désormais faire un agent qui impressionne. Vous lui branchez quelques outils, vous tapez une consigne, et il enchaîne les appels comme par magie. Ça marche. Une fois. Dans un notebook. Avec vous qui regardez chaque étape, prêt à appuyer sur Ctrl-C si ça part en vrille.

Cet agent-là n'a aucune valeur en production. Parce qu'en production, personne ne regarde. Il tourne à 2h47 du matin, le réseau hoquette, l'API renvoie un timeout, le modèle hallucine une adresse email, et il n'y a pas de main humaine au-dessus du Ctrl-C. La différence entre les deux n'est pas le modèle ni le prompt. C'est tout ce qu'il y a autour.

Un agent de démo répond à la question « est-ce que ça marche ? ». Un agent de production répond à « qu'est-ce qui se passe quand ça casse, à 3h du matin, sans personne ? »

Un cas concret : le tri de la boîte support, toutes les 10 minutes

Prenons un scénario que je déploie régulièrement, le genre de tâche « héros » qui ne paie pas de mine mais qui mange des heures humaines chaque jour. Une boîte mail de support qui se remplit en continu. L'objectif : qu'un agent la trie et prépare le travail avant qu'un humain n'ouvre sa session, sans jamais agir à sa place sur ce qui compte.

Concrètement, un cron déclenche un agent headless toutes les 10 minutes. À chaque tour, il :

• Lit les nouveaux emails via l'API Gmail en OAuth (scope lecture + brouillon, jamais l'envoi).
• Charge le contexte client depuis la base, en lecture seule : historique, contrat, tickets passés.
• Rédige des réponses contextuelles, en brouillon, visibles dans la boîte, prêtes à être relues.
• Escalade le cas ambigu vers Slack #review quand il n'est pas sûr, un humain tranche.
• N'envoie jamais rien automatiquement. Aucune réponse ne part sans validation humaine. Jamais.

Voici à quoi ressemble un log de run réel. C'est volontairement bavard : à 3h du matin, ce log est la seule chose qui permettra de comprendre ce qui s'est passé.

[2026-06-11 02:40:00] run #4173  trigger=cron  mode=live
[2026-06-11 02:40:01] gmail.fetch        → 6 nouveaux threads (depuis lastSeen=02:30:02)
[2026-06-11 02:40:02] dedup.check        → 6 nouveaux, 0 déjà traités (idempotence ok)
[2026-06-11 02:40:03] db.context.load    → 6 clients résolus  (read-only, 0 write)
[2026-06-11 02:40:09] draft.write        → 5 brouillons rédigés et déposés (Gmail draft)
[2026-06-11 02:40:09] triage.ambiguous   → 1 cas incertain (remboursement hors délai)
[2026-06-11 02:40:10] slack.escalate     → #review  thread=THR-9f2a  ("avis humain requis")
[2026-06-11 02:40:10] guard.autosend     → 0 envoi automatique  (policy: never)
[2026-06-11 02:40:11] run #4173 done     → 5 drafts, 1 escaladé, 0 doublon, 0 envoi auto  ✓

Et la ligne de crontab qui orchestre tout ça, banale, et c'est tout l'intérêt :

# tri de la boîte support, toutes les 10 minutes, headless
*/10 * * * *  /opt/agents/support-triage/run.sh >> /var/log/agents/support-triage.log 2>&1

Ce qui rend le « sans surveillance » réellement sûr

Le scénario ci-dessus est joli sur le papier. Ce qui le rend déployable, c'est sept garde-fous, chacun répondant à une façon dont un agent autonome peut faire des dégâts. Aucun n'est optionnel.

1. Idempotence, un re-run ne doit jamais agir deux fois

C'est la fondation. Le cron va se relancer, un run va planter à mi-chemin et être rejoué, deux exécutions vont parfois se chevaucher. Si rejouer le même travail produit un brouillon en double, ou pire un effet de bord dupliqué, vous n'avez pas un agent, vous avez une bombe à retardement. Chaque action doit porter une clé qui permet de dire « ça, c'est déjà fait ».

Dans le log plus haut, la ligne dedup.check → 0 déjà traités n'est pas cosmétique : c'est la garantie qu'un thread déjà transformé en brouillon ne le sera pas une seconde fois. J'ai écrit un article entier sur ce seul sujet, parce que c'est là que 80% des agents de production se cassent les dents : l'idempotence des agents IA.

2. Simulation / dry-run avant la première action réelle

Avant de laisser un agent écrire le moindre brouillon en vrai, je le fais tourner en mode dry-run : il prend toutes les décisions, génère tout, mais n'exécute aucun effet de bord, il logge seulement ce qu'il aurait fait. On lit ce log à froid, on compte les actions, on vérifie qu'il n'allait pas répondre n'importe quoi à 200 clients. Le passage en mode=live n'est qu'un flag, basculé une fois la confiance établie.

3. Human-in-the-loop sur l'irréversible et l'ambigu

Toutes les actions ne se valent pas. Déposer un brouillon est réversible (on le supprime). Envoyer un email à un client, rembourser, supprimer une donnée : irréversible. La règle que j'applique est simple, tout ce qui est irréversible ou ambigu remonte à un humain. Dans notre cas, l'envoi est interdit par construction, et le cas de remboursement hors délai, que l'agent ne sait pas trancher avec certitude, part dans Slack #review. L'agent connaît ses limites et les déclare.

4. Moindre privilège, read-only par défaut

Un agent n'a besoin que d'une fraction des droits qu'on lui donne par paresse. Ici : OAuth Gmail limité aux scopes lecture + brouillon (jamais gmail.send), accès base de données en lecture seule via un rôle dédié, aucun droit de suppression large. Si l'agent est compromis ou déraille, le périmètre des dégâts possibles est borné par ce qu'on lui a accordé, et on lui a accordé le strict minimum.

5. Gestion des secrets, rien en clair, jamais dans les logs

Un agent observable produit beaucoup de logs. Le piège évident : qu'une clé d'API, un token OAuth ou un secret de base finisse écrit en clair dans support-triage.log, lisible par quiconque a accès au serveur. Les secrets vivent dans un coffre (variables d'environnement injectées, gestionnaire de secrets), jamais en dur dans le code, et les logs sont filtrés pour ne jamais recracher une valeur sensible. L'observabilité ne doit pas devenir une fuite.

6. Observabilité totale, un run de 3h du matin doit être auditable

C'est ce qui distingue un système qu'on peut exploiter d'une boîte noire qu'on subit. Chaque étape, emails récupérés, contexte chargé, brouillons écrits, cas escaladé, vérification de non-double-envoi, est tracée avec un horodatage et un identifiant de run. Quand un client se plaint d'une réponse étrange, je remonte au run #4173, je vois exactement ce que l'agent a lu, décidé et écrit. Sans cette traçabilité, déboguer un agent autonome relève de la divination.

7. Dégradation gracieuse en cas de panne

Le réseau tombera. L'API Gmail renverra un 503. Le modèle timeoutera. La bonne réponse n'est jamais « continuer quand même » ni « tout casser ». L'agent doit échouer proprement : il logge l'erreur, il ne marque rien comme traité (pour que le prochain run reprenne là où il s'est arrêté, grâce à l'idempotence), et au pire il alerte. Un run raté ne doit jamais laisser le système dans un état incohérent. Le prochain cron, dans 10 minutes, rattrapera.

Le cycle de vie d'un déploiement

Comment on passe d'« on aimerait automatiser ça » à un agent qui tourne seul sur l'infra du client. En quatre temps.

• Cadrage, on choisit une tâche à forte valeur et faible risque. Répétitive, pénible, bornée, où l'erreur est rattrapable. Le tri de boîte support coche toutes les cases : utile tous les jours, et le pire scénario (un brouillon bancal) est sans conséquence.
• Architecture & garde-fous, on conçoit l'idempotence, les scopes, le dry-run, les points d'escalade humaine et les logs avant d'écrire la logique métier. Les garde-fous ne sont pas une couche qu'on ajoute après : ils sont le squelette.
• Déploiement sur l'infra du client, l'agent tourne chez eux, sur leur serveur, avec leurs secrets sous leur contrôle. Pas de données qui partent ailleurs. C'est exactement l'approche Gérer.ai : modèles open-source auto-hébergés, souveraineté par défaut.
• Run & itération, on démarre en dry-run, on observe, on bascule en live sur un périmètre réduit, on élargit. On lit les logs, on ajuste les seuils d'escalade, on étend à d'autres tâches une fois la confiance acquise.

Ce que je retiens

• « Headless » se mérite par les garde-fous, pas par le courage. Retirer l'humain de la boucle n'est pas un acte de bravoure, c'est le résultat d'un travail d'architecture qui rend sa présence inutile.
• On conçoit pour le redémarrage et la panne de 3h du matin, pas pour le happy path. Le chemin nominal est la partie facile. Tout le métier est dans la reprise après échec.
• On commence par une seule tâche ennuyeuse, répétitive et supervisée. Puis on élargit. Ceux qui veulent tout automatiser d'un coup finissent avec un agent que personne n'ose laisser tourner seul.
• Ne jamais auto-agir sur l'irréversible. Un brouillon, oui. Un envoi, un paiement, une suppression : un humain valide. Cette frontière n'est pas une limitation, c'est ce qui permet de dormir.

Cette discipline, je ne l'ai pas inventée pour l'IA. Elle vient de ~20 ans à faire tourner des systèmes en production, des crons, des workers, des pipelines qui doivent survivre à la nuit sans personne. Un agent IA, c'est un worker de plus : plus malin, certes, mais soumis aux mêmes lois. Ce qui casse à 3h du matin ne se soucie pas de savoir s'il y a un LLM dedans.