Essaim IA autonome : comment construire un système qui livre des features pendant la nuit

Tu demandes à un agent IA de construire une feature pendant la nuit. Sur le papier, c'est parfait. Au réveil, tu trouves une migration à moitié faite, deux fichiers cassés, et un message joyeux qui dit que la tâche est terminée.

Ce pattern d'échec est courant. L'agent n'a pas échoué parce que le modèle est faible. Il a échoué parce qu'un seul agent longue durée doit faire trop de choses à la fois : choisir la tâche, tenir le plan, éditer le code, vérifier la sortie, et décider si c'est bon à livrer.

C'est ce que ce post règle. Voici un essaim IA autonome, autrement dit de l'orchestration IA automatisée. Un déclencheur toutes les 30 minutes. Un orchestrateur lit l'état du projet, route un ou plusieurs spécialistes, et vérifie cinq portes avant de compter quoi que ce soit comme terminé.

Les cinq façons dont les agents nocturnes foutent tout en l'air

La plupart des démos "autonomes" cachent la partie difficile. Faire écrire du code à un agent, c'est facile. Le faire prendre des décisions correctes pendant des heures, c'est dur.

Voici les cinq modes d'échec qui apparaissent en premier.

1. Pas de déclencheur

Rien ne réveille le système au bon moment.

Tu dois encore taper le prompt toi-même. Ou tu lances un grand run avant de dormir et tu espères qu'il tient la nuit. Si le run cale après 20 minutes, tout s'arrête là.

La correction est simple. Un déclencheur planifié. Toutes les 30 minutes, le système se réveille, vérifie ce qui s'est passé, et décide quoi faire ensuite.

2. Pas de routage

Un seul agent joue chef de projet, architecte, développeur frontend, développeur backend, testeur et reviewer.

Ça semble efficace. Ça ne l'est pas. La même fenêtre de contexte contient maintenant planification, implémentation et vérification qui se battent pour l'espace. Le run dérive. L'agent perd le fil de ce qui est fait, bloqué, ou encore à prouver.

La correction : séparer les rôles. Un orchestrateur route. Des agents spécialisés exécutent. Le cerveau qui route et le cerveau qui travaille arrêtent de se marcher dessus.

3. Pas de garde-fous

L'agent écrit du code, puis marque la tâche comme terminée parce que le fichier existe.

Ce n'est pas livrer. Un fichier peut exister et quand même rater les vérifications de types, le lint, le build, fuiter un secret, ou manquer tous les tests.

La correction : une pile de portes. Le run ne compte pas sans passer les vérifications qui comptent.

4. Pas de preuve

L'agent dit que la feature est terminée, mais rien dans le système ne le prouve.

C'est le même problème qu'en sécurité. Un résultat sans preuve, c'est du bruit. Une feature sans preuve, c'est du wishful thinking.

La correction : une vérification qui tourne à chaque cycle. Le système a besoin d'une raison de faire confiance à la sortie qui soit plus forte que la confiance de l'agent en lui-même.

5. Pas de mémoire entre les runs

Un long run cale. Tu le relances. L'agent suivant ne sait pas ce que le précédent faisait.

Résultat : travail dupliqué, éditions conflictuelles, résumés vagues au lieu de vrai progrès. Le système continue d'avancer, mais en rond.

La correction : état externe. L'orchestrateur lit la condition actuelle du projet avant chaque cycle et route depuis ça, pas depuis ce qu'un agent se rappelle.

Pourquoi un seul agent ne suffit pas

La réponse habituelle : "laisse l'agent continuer jusqu'à ce que les tests passent."

C'est mieux qu'un prompt one-shot. Ce n'est toujours pas suffisant.

Un seul agent aide pour la persistance. Il ne résout pas le routage. Ni la spécialisation. Ni le problème d'un agent qui note son propre travail. Ni la décision de planifier, construire, corriger, ou s'arrêter.

C'est la différence entre un travailleur et un essaim.

Un seul travailleur continue de répéter une tâche.

Un essaim est un petit système qui se réveille, lit l'état, choisit un rôle, lance le bon travailleur, vérifie le résultat, puis avance ou dort.

C'est pourquoi cet essaim n'est pas un cluster distribué, un control plane Kubernetes, ou un "mesh d'agents" abstrait. C'est bien plus simple. Une machine. Un repo. Un déclencheur planifié. Un orchestrateur. Un ou plusieurs spécialistes. Des worktrees détachés pour le mode parallèle quand le travail se divise proprement.

La forme de l'essaim

Un essaim d'orchestration IA comme celui-ci a cinq pièces mobiles :

1. Déclencheur : un réveil toutes les 30 minutes.
2. Orchestrateur : une session principale lit le contexte et choisit le prochain mouvement.
3. Spécialistes : planificateur, constructeur, designer, testeur, et garde. L'orchestrateur peut en router un ou plusieurs.
4. Portes : lint, types, build propre, commit guard, suite de tests.
5. Sortie : si toutes les vérifications passent, la feature est prête. Sinon, l'essaim continue ou dort.

Voilà la forme complète :

30-minute trigger
      ↓
orchestrator reads state
      ↓
pick the next task
      ↓
dispatch one specialist or several
      ↓
run quality gates
      ↓
ship, continue, or sleep

L'important n'est pas "plus d'agents". L'important, c'est que chaque cycle a un job.

Les orchestrateurs détachés sont le mode parallèle. On les utilise quand le travail se divise en deux ou trois features indépendantes avec des frontières claires.

Étape 1 : le déclencheur

Le déclencheur, c'est un ping toutes les 30 minutes.

Tu peux l'implémenter avec un vrai cron système. Ou avec les tâches planifiées de Claude Code Desktop. Le point, ce n'est pas le nom du scheduler. C'est la cadence.

La cadence fait deux choses.

D'abord, elle donne au système plus d'une chance de récupérer. Si un run meurt à 2h07, le cycle suivant se réveille à 2h30 et continue.

Ensuite, elle garde le système cheap et lisible. Pas besoin d'un agent qui tourne en permanence en brûlant des tokens chaque seconde. Juste un pattern d'automatisation qui se réveille, décide, agit, et s'arrête.

Un seul cron job. Il planifie tout l'essaim.

C'est le bon modèle mental. Un scheduler. Pas une plateforme cloud.

Étape 2 : l'orchestrateur

L'orchestrateur, c'est le cerveau.

Il n'essaie pas de faire toute la feature lui-même. C'est la première règle.

Son job : lire l'état actuel et répondre à une seule question : quel est le prochain mouvement ?

Cette question est plus précise qu'elle n'en a l'air. L'orchestrateur n'invente pas de stratégie produit. Il lit un contexte qui existe déjà :

• quelle tâche a été tentée en dernier
• quels fichiers ont changé
• quelles vérifications ont passé
• quelles vérifications ont échoué
• ce qui est bloqué
• quelle feature est la plus proche d'être terminée

Une fois cet état lu, il route le travail vers le bon spécialiste, ou vers plusieurs si le travail se divise proprement.

Il choisit le prochain mouvement.

Cette phrase compte parce qu'elle définit l'orchestrateur correctement. Ce n'est pas "le travailleur principal". C'est le dispatcheur.

Étape 3 : les spécialistes

Cet essaim utilise cinq rôles spécialisés.

Tu peux les renommer. Les noms ne sont pas l'essentiel.

L'essentiel : chaque agent a un job plus étroit que "construire la feature". Ça réduit la dérive et rend la sortie plus cohérente cycle après cycle.

C'est aussi là où la plupart des équipes d'agents se trompent. On spawn cinq agents, puis on leur donne le même prompt à tous les cinq. Ce n'est pas une équipe. C'est de la duplication.

Un vrai spécialiste n'a besoin que du contexte nécessaire à son job.

Le planificateur a besoin de la tâche et de la forme du projet.

Le constructeur a besoin des fichiers cibles et des critères d'acceptation.

Le designer a besoin des exigences UI et des contraintes des composants.

Le testeur a besoin des conditions d'échec et des vérifications.

Le garde a besoin de la politique.

L'orchestrateur n'a pas à réveiller les cinq à chaque fois.

Parfois un spécialiste suffit. Parfois le travail se divise et l'orchestrateur fan-out vers plusieurs spécialistes en parallèle.

La version propre utilise des sessions isolées ou des Git worktrees séparés. Chaque spécialiste obtient sa propre copie du repo, fait sa partie, et évite de marcher sur les fichiers d'un autre spécialiste. C'est comme ça qu'on garde le travail parallèle réel plutôt que chaotique.

Comment le travail parallèle fusionne

Le travail parallèle est utile jusqu'à ce que deux spécialistes touchent les mêmes fichiers.

C'est pourquoi chaque spécialiste travaille dans son propre Git worktree. La branche principale reste propre pendant que les spécialistes construisent en parallèle.

Quand un spécialiste termine, sa branche ne fusionne pas directement. En mode détaché, elle passe par un merge helper borné. Une branche à la fois. Une branche cible. Des règles de fallback simples.

Si le merge est propre, il atterrit.

S'il y a un conflit, le système essaie trois étapes. D'abord, un git merge propre. Ensuite, une résolution automatique déterministe pour les cas simples. Enfin, une résolution LLM par fichier avec rejet strict pour la prose. Ça garde le chemin de merge serré et prévisible.

Si rien de tout ça ne marche, le merge s'arrête et la branche est marquée comme échouée.

Un essaim, ce n'est pas "merge tout et espère". C'est du travail parallèle avec des règles.

Étape 4 : le chemin d'exécution full-stack

La phase de construction, c'est là que le système gagne sa valeur.

Beaucoup de démos d'agents s'arrêtent à "l'agent a écrit un fichier". On voulait l'inverse. Un chemin de la base de données à la sortie live.

C'est pourquoi la phase de construction n'est pas décrite comme "écrire du code". Elle est décrite comme :

Les agents exécutent le stack complet.

Dans un système comme celui-ci, ça signifie que l'orchestrateur peut router à travers les couches réelles que touche une vraie feature :

• travail en base de données
• logique backend
• pages et câblage UI
• polish design
• tests

Base de données au live. Une feature, zéro étape manuelle.

Définissons "full stack" en termes clairs. Dans ce système, ça ne veut pas dire "toutes les technologies du monde". Ça veut dire les couches nécessaires pour rendre une feature réelle du stockage à l'écran.

Si la base de données change mais pas la page, la feature n'est pas terminée.

Si la page change mais que les tests échouent, la feature n'est pas terminée.

Si tout build en local mais que le commit guard détecte un secret, la feature n'est pas terminée.

L'essaim continue à travers ces couches jusqu'à ce que la chaîne se ferme.

Étape 5 : les cinq portes

La phase de garde, c'est ce qui rend le système digne de confiance.

Sans elle, l'essaim n'est qu'un moyen rapide de générer du travail cassé.

La pile de portes a cinq vérifications :

C'est l'opposé exact de "laisse l'agent livrer et espère".

Rien ne passe sans valider.

Ce n'est pas un slogan. C'est la règle.

Les cinq portes font deux jobs.

D'abord, elles empêchent le mauvais code d'atteindre main.

Ensuite, elles donnent à l'orchestrateur un signal fiable sur quoi faire ensuite. Si le type check échoue, le prochain mouvement n'est pas "célébrer". C'est "router un fix".

Les portes ne sont pas juste des vérifications de sécurité. Ce sont des signaux de routage.

À quoi ressemble la sortie

Le but n'est pas "l'agent a tourné pendant quatre heures".

Le but : tu reviens et la feature est vraiment terminée.

Un run nocturne peut ressembler à ça :

• 2h00 : système d'auth planifié
• 2h30 : trois endpoints API construits
• 3h00 : 47 tests exécutés
• 3h30 : déployé en production

Cette séquence prouve que le système fait du travail ordonné, pas aléatoire.

Un exemple simple :

4 heures. L'auth a été construite, testée, et livrée.

C'est exactement le bon format de preuve pour un système de build autonome. Court. Concret. Vérifiable.

Pas "le modèle a bien raisonné". Une feature a franchi la ligne.

Comment l'automatisation tourne vraiment

L'"autonome" veut dire peu de choses si le déclencheur est flou.

L'automatisation n'est pas magique. Elle part d'un réveil planifié.

La version la plus simple est une entrée cron système qui démarre un nouveau run toutes les 30 minutes. Conceptuellement ça ressemble à ça :

*/30 * * * * cd /path/to/repo && claude -p "run the swarm orchestrator for the next task"

C'est suffisant pour créer la cadence.

Tu peux aussi exécuter le même pattern avec les tâches planifiées de Claude Code Desktop. Dans ce modèle, l'app Desktop tient le planning et démarre une session fraîche à l'intervalle choisi. Le job fonctionne de la même façon après le réveil :

1. un run planifié démarre
2. l'orchestrateur lit l'état actuel du projet
3. un spécialiste ou plusieurs reçoivent la prochaine tâche
4. le résultat passe par les portes qualité
5. le système livre, réessaie, ou dort

Le choix entre cron et tâches planifiées Desktop est opérationnel, pas architectural.

Utilise cron si tu veux le déclencheur machine le plus simple.

Utilise les tâches planifiées Desktop si tu veux un planning visible, un historique intégré, et une session Claude fraîche à chaque fois sans câbler des scripts shell à la main.

Ce qui compte : chaque run démarre frais et chaque run peut voir l'état actuel. C'est ce qui rend l'essaim durable plutôt que fragile.

Que se passe-t-il quand rien n'est prêt

Un bon essaim automatisé a besoin d'un état de sommeil.

Ça semble petit. Ce ne l'est pas.

Si rien n'a changé, aucune porte n'a échoué, et aucune feature n'est assez proche pour être poussée, l'orchestrateur devrait logger l'état et s'arrêter. Il ne devrait pas forcer du travail juste parce que le scheduler a tiré.

C'est comme ça qu'on garde le système propre.

Le déclencheur crée une opportunité. Il ne crée pas une fausse urgence.

Pourquoi ça marche mieux qu'un framework générique

La plupart des frameworks d'agents génériques te donnent les pièces mais pas les règles d'opération.

Tu as des outils pour spawner des agents. Des outils pour passer des messages. La sensation de structure. Et tu dois quand même décider :

• quand le système se réveille
• quel état il lit
• comment il choisit la prochaine tâche
• comment il évite le travail dupliqué
• ce qui rend une étape complète
• ce qui bloque une livraison

Ce sont les vraies questions.

L'essaim fonctionne parce qu'il y répond à l'avance.

Le déclencheur lui donne la cadence.

L'orchestrateur lui donne le routage.

Les spécialistes lui donnent le focus.

Les portes lui donnent la preuve.

La sortie lui donne une ligne d'arrivée.

Un framework générique peut héberger cette forme. Il ne peut pas la remplacer.

Comment construire ta propre version

Tu n'as pas besoin d'un stack géant pour copier ça.

Commence avec cette forme minimum :

one scheduler
one orchestrator
one or several specialists
three to five quality gates
one state file or report directory

Puis suis ces règles.

1. Garde le déclencheur cheap

Ne fais pas tourner un agent en permanence si un réveil planifié suffit.

Un ping toutes les 30 minutes convient à la plupart des systèmes de build nocturnes. Tu as le comportement de retry sans payer une activité constante.

2. Sépare le routage de l'exécution

Ne fais pas faire le travail d'implémentation à l'orchestrateur.

Si le cerveau est aussi le travailleur, la qualité de ton routage chute et ton contexte se pollue vite.

3. Donne à chaque spécialiste un job étroit

Un agent ne devrait pas planifier, coder, designer et vérifier dans le même passage.

Les prompts étroits sont plus faciles à noter, à retenter, et à remplacer.

Si plusieurs spécialistes tournent en parallèle, donne à chacun une frontière claire. Des worktrees séparés sont la version la plus propre : chaque spécialiste édite son propre checkout au lieu de se battre sur les mêmes fichiers.

4. Fais des portes qui bloquent, pas qui conseillent

Une porte qualité qui n'écrit qu'un warning n'est pas une porte.

Si le build est cassé, le système doit router un fix au lieu de prétendre que la feature est terminée.

5. Garde la preuve hors du rapport de l'agent

L'agent qui dit "terminé" n'est pas une preuve.

La preuve vient des vérifications, des tests, des logs, et des builds réussis. Les signaux externes battent la confiance interne à chaque fois.

6. Dors exprès

Si rien n'est prêt, log l'état et dors.

C'est plus important qu'il n'y paraît. Les systèmes deviennent chers et chaotiques quand ils ne savent pas décider de s'arrêter.

Ce que ce système est vraiment

Voici la réponse directe : est-ce un crontab ?

Au niveau du déclencheur, oui, c'est en forme de cron.

Il y a un scheduler qui réveille le système toutes les 30 minutes. Ce scheduler peut être :

• une vraie entrée crontab sur ta machine
• une tâche planifiée Claude Code Desktop

L'essaim n'est pas le scheduler seul, cependant.

Le flux complet est :

1. le scheduler tire
2. une session fraîche se réveille
3. l'orchestrateur lit l'état
4. l'orchestrateur choisit le prochain mouvement
5. un spécialiste ou plusieurs tournent
6. les portes vérifient le résultat
7. le système livre, réessaie, ou dort

C'est pourquoi la bonne réponse n'est pas "c'est un crontab" ni "c'est un framework IA".

C'est un essaim IA automatisé.

Une forme valide :

main session -> route work -> sub-agents -> gates -> sleep

Une autre forme valide :

main session -> partition 2-3 independent features -> spawn isolated worktree sessions -> merge back safely

C'est la même idée. Orchestration IA automatisée avec des rôles clairs, des règles de merge bornées, et une seule ligne d'arrivée.

Où ce pattern s'applique ailleurs

Une fois que tu vois la forme, tu peux l'utiliser au-delà des builds de features.

Le même pattern fonctionne pour :

• la revue de sécurité
• les audits de dépendances
• la production de contenu
• le triage d'analytics
• la surveillance de PR

Le scheduler réveille le système. L'orchestrateur vérifie l'état. Un ou plusieurs spécialistes font le travail étroit. Les portes décident si la sortie est assez bonne. Puis l'essaim dort de nouveau.

C'est tout le modèle.

Un ping. Un cerveau. Un ou plusieurs spécialistes. Cinq portes. Des features terminées quand tu te réveilles.