Les systèmes font briller le génie

Les systèmes font briller le génie Image : générée par IA

Un employé de McDonald’s n’est pas un chef étoilé Michelin. Pourtant, un Big Mac à Séoul a le même goût qu’un Big Mac à New York. Les systèmes créent la constance.

À ce stade, la plupart des gens concluent : « Le talent est superflu. Le système suffit. » J’ai pensé la même chose autrefois. J’avais tort.

Le système de McDonald’s ne remplace pas les chefs. Il les libère. Parce que les employés en restaurant n’ont plus besoin de mémoriser la température du gril, les chefs au siège peuvent se consacrer entièrement au développement de nouveaux menus. Parce que le système gère la répétition, la créativité humaine ne s’écoule que là où elle est réellement nécessaire. Les systèmes ne remplacent pas le génie. Ils créent les conditions pour que le génie puisse être génial.

Le même principe s’applique aux agents IA. Un génie sans structure dérive. Une structure sans génie est médiocre. La chose intéressante se produit quand on les combine.

L’histoire de la libération par la structure

En 1935, un Boeing B-17 s’est écrasé lors d’un vol d’essai. Non pas parce que le pilote était incompétent. L’avion était devenu trop complexe pour qu’une seule personne puisse mémoriser chaque procédure. La solution n’était pas de trouver un meilleur pilote, mais de créer une checklist. Après cela, le B-17 a volé 1,8 million de miles sans accident.

L’interprétation habituelle est que « la checklist a remplacé les compétences du pilote ». Mais ce qui s’est réellement passé était différent. Parce que la checklist a pris en charge la charge cognitive de la mémoire procédurale, le pilote a pu se concentrer entièrement sur le jugement situationnel : prendre des décisions en turbulence, réorganiser les priorités en cas d’urgence. Une fois que la checklist gérait la répétition mécanique, le jugement du pilote a enfin brillé.

Le Toyota Production System (TPS) suit la même structure. Tirez le cordon andon et la ligne s’arrête. Pas une seule voiture ne sort avant que le problème soit résolu. Les Standard Operating Procedures (SOPs) créent une qualité reproductible. Mais la vraie puissance du TPS ne réside pas dans les SOPs elles-mêmes. Parce que les SOPs absorbent la variabilité des opérations quotidiennes, les ingénieurs peuvent consacrer leur temps au kaizen, l’amélioration fondamentale. La structure gère la répétition, les personnes se concentrent sur l’amélioration.

La recherche d’Atul Gawande a transposé cela au bloc opératoire. Les hôpitaux qui ont adopté la checklist de sécurité chirurgicale de l’OMS ont vu une réduction de 36 % des complications et de 47 % de la mortalité. La checklist est une simple feuille de papier avec 19 items. Elle n’a pas amélioré les compétences du chirurgien. Elle a transféré au système les charges cognitives comme « ne pas oublier une compresse », libérant les chirurgiens pour se concentrer sur les jugements véritablement difficiles : réponse immédiate à un saignement inattendu, refonte en temps réel de l’approche chirurgicale.

Le schéma est le même. Quand la structure prend en charge la répétition, les capacités humaines se concentrent sur le jugement et la créativité. La valeur d’un système ne réside pas dans le remplacement du talent. Elle réside dans le fait de s’assurer que le talent n’est pas gaspillé sur des choses qui n’en ont pas besoin.

Le même principe s’applique à l’IA

Le récit dominant dans l’IA en ce moment est « des modèles plus grands, plus de paramètres, des benchmarks plus élevés ». La conviction que des modèles plus intelligents résolvent les problèmes. Partiellement vrai. Mais seulement à moitié.

Donnez au modèle le plus puissant aucune structure et dites-lui « construis-moi une application ». Que se passe-t-il ? Les 100 premières lignes sont propres. Au-delà de 500 lignes, il oublie les interfaces qu’il a créées. À 1 000 lignes, les règles établies au début sont violées plus tard. Quand les endpoints dépassent 30, les schémas de base de données et les spécifications API commencent à diverger silencieusement.

Ce n’est pas parce que le modèle est stupide. Maintenir la cohérence de chaque décision dans une fenêtre de contexte est structurellement quasi impossible. Les humains n’y arrivent pas non plus. Pour la même raison que le pilote du B-17 n’y arrivait pas. Quand la complexité dépasse la capacité cognitive d’un seul agent, peu importe à quel point cet agent est talentueux, des choses passent à travers les mailles.

J’appelle cela la dérive. Le phénomène par lequel un agent, tournant en boucles itératives, s’écarte progressivement de la spécification originale. Sans structure, la dérive est inévitable. Mettre à niveau le modèle ne fait que retarder l’apparition de la dérive. Elle ne l’élimine jamais.

Voici le point essentiel. Sans structure, même Opus gaspille sa puissance de raisonnement à mémoriser des noms de champs. Avec une structure, Opus peut concentrer son raisonnement sur « comment devrais-je décomposer ce domaine ? ». Un modèle intelligent ne fait un travail intelligent que quand la structure gère le travail répétitif.

43 minutes, 32 endpoints, zéro bug

Il y a des preuves. Le benchmark ZenFlow.

Claude Sonnet 4.6, pas le modèle haut de gamme (Opus) mais un modèle intermédiaire, a construit une application de bout en bout dans la structure SSOT de yongol.

Résultats :

32 endpoints, 9 tables de base de données, 9 fichiers de requêtes, 37 tests Hurl, tous validés
Environ 43 minutes
Bugs de génération de code : 0

Le modèle n’a pas évité toutes les erreurs. Il y a eu 4 erreurs (BUG-077~080). Ce qui compte, c’est que les 4 ont été classées comme « erreurs de rédaction SSOT ». Pas des bugs du générateur de code : l’agent a écrit la spécification incorrectement. Et le système les a détectées. validate a signalé les échecs, l’agent a corrigé les spécifications, relancé, et tout a passé.

Environ 16 des 43 minutes ont été consacrées à cette boucle validate. C’était le système qui enseignait à l’agent.

Sonnet est « moins intelligent » qu’Opus, avec des scores de benchmark inférieurs dans l’ensemble. Pourtant, dans une structure, il a produit du code de qualité production. Non pas parce que le génie est superflu, mais parce que la structure gérait l’exécution, dispensant le génie de le faire.

Parce que la structure permet à Sonnet de gérer l’exécution à une qualité suffisante, le modèle génial peut être déployé uniquement pour la conception et le jugement, les domaines vraiment difficiles. Le même mécanisme que les employés de McDonald’s produisant des hamburgers de manière constante pour que les chefs au siège puissent inventer de nouveaux menus.

Trois engrenages

Décomposez cette structure et trois composants émergent. J’appelle cela le Ratchet Pattern. Chaque engrenage prend en charge une chose dont le génie n’a plus besoin de se soucier.

1. SSOT : ce qu’il faut construire

Single Source of Truth. Dans yongol, 9 fichiers de spécifications déclaratives remplissent ce rôle. OpenAPI définit les endpoints, DDL définit les tables, Rego définit les permissions. L’essentiel est que les 9 sont chaînés par un identifiant unique : operationId. Pour un endpoint donné, la spécification API, la requête de base de données, le test et la règle de permission sont tous liés à la même clé.

Ce que le SSOT prend en charge : la mémoire. Les noms de champs, les relations, les contraintes. Le génie n’a pas besoin de s’en souvenir. La spécification s’en souvient.

2. Codegen : comment le construire

Le code est généré à partir du SSOT. L’agent n’écrit pas du code librement ; il écrit du code dérivé de la spécification. La dérive est structurellement supprimée. Ce qui n’est pas dans la spécification ne peut pas être créé ; ce qui y est ne peut pas être omis.

Ce que Codegen prend en charge : la répétition. Écrire le boilerplate pour 32 endpoints un par un n’est pas du travail pour le génie. La structure s’en charge.

3. Gate : a-t-il été construit correctement ?

Vérification déterministe. validate vérifie la cohérence entre les 9 spécifications. Si un operationId existe dans OpenAPI mais pas dans les tests Hurl, échec. Si une colonne existe dans DDL mais n’est pas référencée dans les requêtes sqlc, avertissement. Rien ne passe à l’étape suivante sans avoir validé.

Ce que le Gate prend en charge : l’inspection. Vérifier visuellement la cohérence entre 32 endpoints est la même chose qu’un pilote de B-17 essayant de mémoriser les procédures de tête. Les mesures déterminent l’acceptation.

Quand ces trois engrenages s’imbriquent, ils forment un cliquet. Ce qui a passé ne régresse pas. Si l’agent fait une erreur, le gate la détecte. L’agent la corrige. La vérification se relance. La seule sortie de cette boucle est « validé ». Et pendant que toute cette boucle tourne, le génie peut concevoir le prochain problème.

Quand le génie brille

Alors, où intervient le génie ? Partout en dehors de la structure. C’est là que se trouve la vraie valeur.

La personne qui a écrit le manuel de McDonald’s n’était pas un employé au comptoir. La personne qui a conçu les recettes, décomposé les processus et décidé où placer les points de contrôle était un expert. Il en va de même pour le cordon andon de Toyota. C’est l’intuition de Taiichi Ohno qui a défini les conditions d’arrêt de la ligne. Les systèmes gèrent l’exécution, pas la conception. La conception est le domaine du génie. Parce que la structure a allégé le fardeau de l’exécution, le génie peut se consacrer entièrement à la conception.

Il en va de même en IA. Écrire le SSOT de yongol (juger quels endpoints sont nécessaires, concevoir les relations entre tables, décider du modèle de permission) demande un raisonnement profond. L’exploration avant que la structure ne soit établie, les jugements architecturaux sans précédent, la question « comment devrais-je décomposer ce problème ? ». Rien de tout cela ne rentre dans une structure. C’est là qu’un modèle puissant mérite son coût.

Dans la pratique, je répartis les modèles entre les rôles. La conception et le jugement vont à Opus ; l’exécution dans la structure va à Sonnet. Ce pattern à double modèle est la réalisation la plus directe de « les systèmes font briller le génie ». Opus ne brûle pas de tokens sur les noms de champs ou le boilerplate. La structure s’en charge. Opus se concentre uniquement sur les décisions d’architecture, la décomposition du domaine, le jugement sur les cas limites, le travail que seul Opus peut faire.

Un architecte qui ne transporte pas de briques ne manque pas de respect envers la maçonnerie. L’équipe s’en charge pour que l’architecte puisse se concentrer sur les plans. Mettre vos meilleurs talents sur chaque tâche n’est pas de la rigueur ; c’est du gaspillage.

Non pas économiser sur les modèles chers : les utiliser correctement

Regardons les prix.

Le prix des tokens de sortie de Claude Sonnet est de 15 $/M-token. Opus est à 75 $/M-token. Une différence de 5x. Sans structure, confier l’ensemble du pipeline à Opus signifie que la majeure partie de la capacité d’Opus est consacrée à la génération de boilerplate et à la cohérence des noms de champs. Comme payer un architecte à 75 $/heure pour transporter des briques.

Avec une structure, l’histoire change. L’exécution (génération de code, maintien de la cohérence, validation des tests) est gérée par Sonnet dans la structure. Comme ZenFlow l’a prouvé, à une qualité qui passe les gates à 100 %. Opus est déployé uniquement pour la conception et le jugement. Le même budget concentre l’attention d’Opus à une densité 5x.

Appelez cela une allocation budgétaire, pas une réduction des coûts. Le génie là où le génie est nécessaire ; la structure là où la structure suffit. Un coût total plus bas est un effet secondaire ; le véritable effet est une sortie de meilleure qualité. Ce que le génie produit quand il fait un travail de génie est d’un tout autre ordre que ce que le génie produit quand il est enseveli sous des tâches répétitives.

Questions ouvertes

Pour être honnête, certaines choses restent à prouver.

ZenFlow est un seul benchmark. 32 endpoints représentent une échelle moyenne en production. La question de savoir si le même pattern tient à 200 endpoints est encore en cours de validation. Il existe des mesures montrant la compression de contexte de yongol à environ 10x, mais si cela évolue linéairement à des centaines d’endpoints nécessite des données supplémentaires.

Autre point. Écrire le SSOT lui-même demande une expertise. Pour revenir à l’analogie McDonald’s : quelqu’un qui peut écrire le manuel doit d’abord exister. Pour que la structure fasse briller le génie, un génie capable de concevoir la structure est d’abord nécessaire. Pas circulaire. Séquentiel. Un acte de conception soutient un nombre infini d’actes d’exécution.

Mais le schéma fondamental tient.

Multiplication

« À quel point votre IA est-elle intelligente ? » n’est que la moitié de la question.

L’autre moitié est celle-ci : « Où votre structure concentre-t-elle cette intelligence ? »

Quand le B-17 n’avait pas de checklist, même les meilleurs pilotes s’écrasaient. Après la checklist, des pilotes ordinaires ont volé 1,8 million de miles sans incident, et les pilotes exceptionnels ont gagné l’espace pour s’attaquer à des défis qui n’avaient jamais existé auparavant. Si Toyota avait dit « embauchons de meilleurs ingénieurs » au lieu d’implémenter le cordon andon, la fabrication lean n’aurait jamais existé. Parce que le cordon andon existait, les ingénieurs pouvaient se concentrer sur le kaizen.

L’IA est pareille. De nouveaux modèles sortent chaque année. Le modèle le plus puissant de l’année dernière est le modèle intermédiaire de cette année. Mais l’investissement dans la structure perdure à travers les changements de modèles. Les spécifications SSOT fonctionnent avec Sonnet, fonctionnent avec Opus, et fonctionneront avec le modèle de l’année prochaine. Et au fur et à mesure que les modèles deviennent plus puissants, ce que la structure libère grandit avec eux. La valeur de la structure augmente aux côtés du modèle.

Le génie seul dérive. La structure seule est médiocre. Quand génie et structure se multiplient, alors seulement atteignent-ils des endroits qu’aucun des deux ne pourrait atteindre seul.

Les systèmes ne battent pas le génie. Ils font briller le génie plus fort. Pas une nouvelle découverte. Prouvé depuis 1935. Nous n’avions simplement pas encore appliqué cela à l’IA.

Lectures complémentaires (externes)

Atul Gawande, The Checklist Manifesto — La source originale des cas B-17 et checklist de l’OMS. Comment les systèmes complètent les experts quand la complexité dépasse la capacité individuelle.
Haynes et al., “A Surgical Safety Checklist to Reduce Morbidity and Mortality in a Global Population” (NEJM, 2009) — L’article original de la checklist chirurgicale de l’OMS. 36% de complications en moins, 47% de mortalité en moins dans 8 pays.
Mike Mason, “AI Coding Agents in 2026: Coherence Through Orchestration, Not Autonomy” — Pourquoi l’orchestration, pas l’autonomie, maintient la cohérence de l’agent.
“Spec-Driven Development with AI Coding Agents” (ZeroShot, 2026) — Comment les spécifications versionnées (SSOT) préviennent le drift des agents IA.
“Guardrails for AI Coding Agents” (Earthly) — Intégrer les politiques dans le workflow pour capturer le drift avant le PR.

Sources

Ohno, T. (1988). Toyota Production System: Beyond Large-Scale Production. Productivity Press.
Gawande, A. (2009). The Checklist Manifesto: How to Get Things Right. Metropolitan Books.
Haynes, A. B., et al. (2009). “A Surgical Safety Checklist to Reduce Morbidity and Mortality in a Global Population.” New England Journal of Medicine, 360(5), 491-499.
World Health Organization. (2009). WHO Surgical Safety Checklist. WHO Patient Safety.
Cas de la checklist B-17 : Schamel, J. (2012). “How the Pilot’s Checklist Came About.” Flight Safety Australia Magazine.