Articles
Arrêtez le Fan-out aveugle : architecture d’orchestration à 4 couches avec Claude Haiku 5.5
Claude Haiku 5.5 est rapide et économique, mais lui déléguer toutes les tâches en parallèle ne fait qu’amplifier les erreurs d’interprétation, le biais d’évaluation et les risques de Supply Chain. Décryptage d’une architecture en couches : cadrage par Fable, orchestration par Opus, implémentation par Sonnet et Haiku, validation par CI et recette par Opus, ainsi que les critères pour savoir quelles tâches méritent vraiment un Fan-out.
· 7 min de lecture
Claude Haiku 5.5 est sorti le 7 octobre 2026. Pour un prompt de moins de 100,000 tokens, son coût représente un vingtième de celui de Sonnet 5.5, avec la latence la plus faible de la génération actuelle de Claude.
Aussi économique que rapide, la tentation est grande : découper l’ensemble des tâches de dev et les distribuer en parallèle à une armée de Haiku pour aller au plus vite.
Pour un prototype, cette approche peut suffire. En environnement d’ingénierie de production, on se heurte très vite à trois problèmes :
- Les petits modèles gèrent mal l’ambiguïté. Le positionnement officiel de Haiku 5.5 cible la classification, l’extraction, le routage et les rôles de subagent — des opérations à fort volume et faible latence. Dès qu’un besoin comporte des ambiguïtés métier ou requiert le contexte global du système, il a tendance à produire un résultat en apparence complet, mais parti sur une mauvaise interprétation.
- Faire choisir la réponse par un modèle introduit un biais d’évaluation. Soumettre plusieurs dizaines de propositions à un grand modèle le pousse à privilégier la version qui « présente bien architecturalement », plutôt que celle dont la logique et l’exécution sont réellement correctes.
- La surface d’exposition grandit avec le nombre de Workers. Si des subagents exécutés en parallèle ont l’autorisation d’installer des dépendances ou d’altérer les configurations, lancer N Workers ouvre N portes d’entrée potentielles pour des paquets malveillants.
C’est pourquoi j’ai adopté une orchestration hiérarchique (Hierarchical Orchestration) : chaque couche se concentre sur ce qu’elle maîtrise, et la parallélisation de Haiku n’est mobilisée que là où elle apporte une réelle valeur.
En résumé : Fable cadre la réflexion, Opus distribue et valide la recette, Sonnet prend en charge le gros de l’implémentation, et Haiku se cantonne aux tâches mécaniques ou aux recherches vérifiables automatiquement. Les solutions candidates passent d'abord par la CI avant d’être soumises au modèle.
L’architecture à 4 couches : arbitrage, orchestration, vérification, recette#
Entrée du besoin
│
▼
[Couche d’arbitrage] Fable : décisions d’architecture, découpage des tâches, critères d’acceptation
│
▼
[Couche d’orchestration] Opus Main Session : dispatch uniquement, pas de redécoupage
├─► Trajectoire A : complexe mais périmètre net ──► Implémentation Sonnet
├─► Trajectoire B : tâches mécaniques ──► Un seul Haiku
├─► Trajectoire C : exploration, solutions multiples ──► Plusieurs Haiku, chacun dans son Git Worktree
│
▼
[Couche de vérification] Build, Type Check, Test, Benchmark (la trajectoire C ne retient que le top 2–3)
│
▼
[Couche de recette] Opus converge selon les critères d’acceptation
En cas d’échec, escalade : 2 corrections Haiku infructueuses ➔ Sonnet ➔ retour à Opus
L’affectation de chaque modèle repose sur son positionnement officiel et sa tarification. Voici les chiffres issus de la documentation officielle d’Anthropic au 8 octobre 2026, exprimés en dollars par million de tokens :
| Modèle |
Positionnement officiel |
Latence |
Prix Input / Output |
| Claude Fable 5.1 |
Raisonnement de haute intensité et travail agentique long terme |
Plus lente |
$10 / $50 |
| Claude Opus 5.5 |
Travail de connaissances et coding agentique long terme |
Modérée |
$4 / $20 |
| Claude Sonnet 5.5 |
Meilleur compromis entre rapidité et capacités |
Rapide |
$2 / $10 |
| Claude Haiku 5.5 |
Tâches de subagent, classification, extraction et routage massives à faible latence |
La plus rapide |
À partir de $0.10 / $0.50 |
La tarification de Haiku 5.5 comporte deux paliers : au-delà de 100,000 tokens de prompt, elle passe à $0.50 / $2.50.
Couche d’arbitrage : Fable pilote l’architecture et les critères d’acceptation#
Tous les besoins n’exigent pas Fable. C’est la couche la plus onéreuse et la plus lente ; je la réserve aux exigences ambiguës, aux intégrations inter-systèmes ou aux décisions d’architecture structurantes.
Fable doit produire trois livrables précis :
- Le design de la solution
- Le découpage en tâches
- Les Acceptance Criteria de chaque sous-tâche, vérifiables par des tests
Le raisonnement et le découpage doivent émaner du même niveau. C’est la couche capable d’anticiper les angles morts du système qui saura tailler des sous-tâches aux frontières nettes. Confier l’architecture à A et le découpage à B conduit presque toujours à des interfaces mal définies.
Les tâches de sécurité font exception. La génération actuelle des modèles Claude intègre des classifieurs de sécurité ; lorsqu’une requête est bloquée, elle renvoie un stop_reason: "refusal", ce qui peut générer des faux positifs sur des opérations de sécurité légitimes. Le classifieur de Fable 5.1 couvre une large part des thématiques de sécurité, la documentation précisant qu’il n’est pas conçu pour ce domaine. À l’inverse, Opus 5.5 autorise la recherche de vulnérabilités dans le code source. Pour l’analyse amont de remédiation de failles, je passe donc directement par Opus.
Couche d’orchestration : Opus dispatche sans redécouper#
Opus agit en Main Session : il gère le routage et l’assignation. Cette couche ne remet pas en cause l’architecture et n’opère aucun second découpage.
- Trajectoire A, complexe mais périmètre net : les tâches à la logique dense, dont les interfaces sont rigoureusement délimitées, reviennent à Sonnet. C’est le moteur principal de l’implémentation.
- Trajectoire B, tâches purement mécaniques : le code Boilerplate, le renommage de variables, l’ajout de tests unitaires simples ou la documentation sont confiés à une instance unique de Haiku.
- Trajectoire C, exploration et optimisation : optimisation de performances, variantes d’implémentation en SQL complexe ou Regex, diagnostic de Flaky Test. C’est ici qu’intervient le Fan-out : plusieurs Haiku sont instanciés, chacun explorant une piste distincte dans son propre Git Worktree isolé.
Quelle que soit la trajectoire empruntée, chaque livrable doit transiter par la couche de vérification.
Couche de vérification : les machines d’abord, les modèles ensuite#
Une pratique répandue consiste à soumettre l’intégralité du code produit en parallèle à Opus ou Sonnet pour une revue via un prompt.
Le problème est qu’à la lecture, un modèle se laisse facilement séduire par un code propre, bien indenté et rigoureusement typé, sans que cela garantisse le passage des cas aux limites. Les solutions candidates doivent donc d’abord franchir le filtre automatisé :
- Build et Type Check : le code compile et les types sont valides
- Unit / Integration Tests : les tests unitaires et d'intégration passent au vert
- Benchmark / Profiling : mesure de la performance et de l’empreinte mémoire
Tout ce qui échoue aux tests automatisés est éliminé d’office. Pour la trajectoire C, Opus n’examine que les 2–3 propositions qui ont passé les contrôles avec les meilleures métriques, préservant ainsi la context window et les tokens.
Couche de recette : Opus arbitre, avec escalade en cas d’échec#
Enfin, Opus consolide les résultats en s’appuyant sur les Acceptance Criteria fixés par la couche d’arbitrage. Si un Worker se retrouve bloqué, on applique un Escalation Path précis :
- Haiku échoue : après 2 tentatives d’auto-correction infructueuses, on stoppe les retries.
- Sonnet prend le relais pour corriger le tir.
- Si Sonnet ne parvient pas non plus à valider la recette, cela révèle généralement une contradiction dans le découpage ou dans les hypothèses initiales. La tâche revient à Opus, qui détermine s’il faut la renvoyer à Fable pour un nouveau découpage.
Trois règles avant de passer en production#
Évitez le Fan-out aveugle#
Une tâche triviale n’a pas besoin de multiples Workers, et une tâche hautement ambiguë dépasse les capacités d’un petit modèle. Seules les tâches d’exploration présentant un large espace de solutions ET vérifiables rapidement par des tests automatisés justifient une exécution parallèle avec plusieurs Haiku.
Isolez l’environnement, verrouillez le Lockfile#
Un Git Worktree isole uniquement les modifications de code pour éviter que des Workers parallèles n’écrasent leurs fichiers mutuels ; il ne restreint ni l’accès réseau, ni le périmètre d’exécution de la machine. Pour se prémunir d’une Supply Chain Attack, il faut impérativement un sandbox et interdire aux Workers d’installer des dépendances non auditées ou de modifier le Lockfile. Ouvrir les droits d’installation sans contrôle revient à laisser un agent importer des paquets et des scripts douteux dans votre codebase.
Fondez la recette sur des métriques, pas sur les avis d’un modèle#
Les résultats de tests, la couverture de code, la consommation mémoire et la latence constituent les seules bases reproductibles et comparables. L’évaluation textuelle d’un modèle peut servir d’indice, mais ne doit en aucun cas servir de critère de recette pour la qualité logicielle.
Un modèle économique doit être utilisé au bon endroit#
Haiku 5.5 rend la parallélisation accessible, mais paralléliser n’a jamais suffi à rendre un résultat correct. En isolant nettement arbitrage, dispatch, vérification et recette, le faible coût et la vitesse deviennent enfin de véritables atouts.
Cette organisation en couches correspond précisément au Graph décrit dans Un agent IA n'est rien d'autre qu'une équipe agile : qui intervient en premier, à qui passer le relais une fois terminé, et vers qui escalader quand un problème survient.