En juin 2026, trois personnes sont arrivées indépendamment à la même idée en l'espace d'une seule semaine.
Peter Steinberger, le créateur d'OpenClaw, a déclaré publiquement que vous devriez arrêter de donner des prompts aux agents de codage et commencer à concevoir les boucles qui les guident. Presque au même moment, Boris Cherny, qui dirige Claude Code chez Anthropic, a déclaré qu'il ne donne plus de prompts directement à Claude, qu'il a des boucles qui fonctionnent et qui donnent des prompts à Claude et déterminent quoi faire, et que son véritable travail est d'écrire des boucles. Quelques jours plus tard, Addy Osmani, un ingénieur chez Google, a formalisé le terme et lui a donné un nom : le loop engineering.
Aucun d'eux n'a inventé la pratique de toutes pièces. Ils ont nommé quelque chose qui se produisait déjà, car les outils sous-jacents avaient franchi silencieusement un seuil. Les agents de codage étaient devenus suffisamment fiables pour terminer une tâche réelle sans surveillance. La planification était devenue assez bon marché pour qu'exécuter une tâche de manière répétée, sur une minuterie, cesse de paraître un gaspillage. Le coût d'une seule exécution d'agent avait suffisamment baissé pour que tenter quelque chose cinq fois coûte moins cher que d'y réfléchir attentivement une fois.
Ce seuil est la raison d'être de cette feuille de route. Le prompting était la compétence lorsqu'un humain devait s'asseoir au clavier pour diriger un agent ligne par ligne. Le loop engineering est la compétence maintenant que l'agent peut recevoir un objectif et être laissé en autonomie. Voici le chemin complet en 20 étapes de l'un à l'autre, dans l'ordre, car l'ordre est plus important que n'importe quelle étape individuelle.
Voici pourquoi l'ordre est spécifiquement important, avant les étapes elles-mêmes. Le loop engineering n'est pas une compétence unique que l'on possède ou non. C'est une pile, où chaque couche dépend de la solidité de celle qui se trouve en dessous. Construire un déclencheur de planification, étape 14, avant d'avoir une véritable condition d'arrêt, étape 10, signifie simplement que vous avez automatisé un système qui peut désormais gaspiller de l'argent sans surveillance au lieu de seulement lorsque vous regardez. Construire la persistance, étape 11, avant d'avoir une véritable vérification, étapes 6 et 7, signifie que vous enregistrez soigneusement les leçons apprises d'un juge qui pourrait approuver automatiquement de mauvaises sorties, ce qui rend la couche de persistance activement nuisible plutôt que simplement inutile. Sauter des étapes dans cette liste ne signifie pas seulement manquer une fonctionnalité. Cela signifie construire les parties attrayantes sur une fondation qui ne peut pas réellement les supporter, et ne le découvrir qu'une fois que quelque chose a déjà mal tourné à grande échelle.
Phase un : le changement mental (étapes 1 à 4)
Étape 1 : Acceptez que vous êtes le goulot d'étranglement, pas le modèle
La première étape réelle n'est pas technique. Il s'agit d'admettre que le facteur limitant dans votre flux de travail actuel n'est pas la capacité du modèle, mais votre propre présence dans la boucle. Chaque fois que vous vous asseyez et attendez une réponse, la lisez, puis tapez l'instruction suivante, vous êtes de loin la partie la plus lente du système. Le modèle peut agir, vérifier et réessayer bien plus rapidement que vous ne pouvez superviser son action.
Cette étape n'a pas de prompt qui lui est attaché. C'est une décision. Tant que vous ne croyez pas vraiment cela, chaque étape suivante semblera être une surcharge inutile au lieu de ce qu'elle est : supprimer le véritable goulot d'étranglement.
Étape 2 : Arrêtez de confondre un prompt plus long avec un meilleur système
L'instinct, quand quelque chose ne va pas, est d'ajouter une autre instruction au même prompt. Avec les mois, cela produit un prompt qui est un mur dense de règles contradictoires que le modèle ne peut plus garder en mémoire de travail en même temps, donc il se base sur le motif le plus récent et laisse tomber silencieusement le reste.
Le loop engineering remplace complètement cet instinct. Au lieu d'ajouter une règle à un prompt, vous ajoutez un composant à un système. Une étape de vérification. Un fichier mémoire. Un déclencheur planifié. Le prompt lui-même devrait raccourcir au fur et à mesure que le système autour devient plus capable, et non l'inverse.
Étape 3 : Apprenez à voir chaque tâche comme cinq mouvements
Chaque tour d'une boucle, quel que soit le domaine spécifique, se décompose en cinq mouvements. La découverte : comprendre ce qui doit réellement se passer. La transmission : passer la tâche à ce qui va l'exécuter. La vérification : confronter le résultat à quelque chose de réel. La persistance : enregistrer ce qui s'est passé pour ne pas le perdre. La planification : décider quand cela se reproduit.
Le flux de travail actuel de la plupart des gens ne comporte que deux de ces mouvements explicites, la découverte et la transmission, effectués manuellement, dans une fenêtre de chat. Les trois autres n'existent pas ou se produisent invisiblement dans la tête de la personne. Le loop engineering est la pratique qui consiste à rendre les cinq mouvements explicites et automatiques.
Étape 4 : Identifiez votre première tâche candidate réelle
Avant de construire quoi que ce soit, choisissez une tâche que vous faites déjà de manière répétée, avec un standard que vous pourriez écrire si on vous le demandait. Pas votre problème le plus difficile. Pas quelque chose d'entièrement nouveau. Une tâche avec une définition réelle et reconnaissable de ce qui est fait, quelque chose qu'un collègue pourrait regarder et immédiatement dire si c'est fait correctement ou non. Cette contrainte est plus importante qu'il n'y paraît. Une tâche sans définition claire de ce qui est fait ne peut pas avoir d'étape trois, la vérification, construite pour elle, et une boucle sans véritable vérification n'est pas une boucle, c'est juste une supposition non supervisée.
Phase deux : construire la première boucle (étapes 5 à 9)
Étape 5 : Écrivez la définition de ce qui est fait avant d'écrire un prompt
C'est l'étape que la plupart des gens sautent et celle qui détermine si tout ce qui vient après fonctionne. Avant d'écrire une seule instruction pour l'agent, écrivez, en langage clair, exactement à quoi ressemble un résultat correct. Des critères spécifiques et vérifiables, pas un vague sentiment de qualité.
DÉFINITION DE CE QUI EST FAIT pour [nom de la tâche] :
- [Critère spécifique et vérifiable 1]
- [Critère spécifique et vérifiable 2]
- [Critère spécifique et vérifiable 3] Cette tâche n'est PAS terminée si l'un des éléments ci-dessus manque, même si le résultat semble complet ou soigné.
Si vous ne pouvez pas remplir cela pour la tâche choisie, revenez à l'étape 4 et choisissez-en une autre.
Étape 6 : Séparez le constructeur du juge
La décision architecturale la plus importante dans toute boucle. Le rôle qui produit le travail et le rôle qui vérifie le travail doivent être séparés, car un modèle qui examine sa propre production dans le même souffle qui l'a produite a tendance à défendre cette production plutôt qu'à l'examiner véritablement.
Le Constructeur reçoit une latitude créative et produit une première tentative. Le Juge reçoit la production du Constructeur plus la définition de ce qui est fait de l'étape 5, et rien d'autre pour le faire changer d'avis. Idéalement, le Juge a également accès à quelque chose que le Constructeur n'a pas, une suite de tests, le document source original, des données en direct, afin que son verdict vienne de preuves réelles, pas seulement d'un second avis formé de la même manière que le premier.
Étape 7 : Donnez au juge une vérité de terrain, pas seulement une opinion
Un juge qui ne voit que la production du Constructeur peut vous dire si elle semble cohérente. Il ne peut pas vous dire si elle est réellement correcte. Pour les tâches de codage, la vérité de terrain est la suite de tests et le résultat réel de l'exécution. Pour les tâches de contenu, c'est le matériel source original et le brief, côte à côte avec le brouillon. Pour les tâches de recherche, ce sont les documents réels qui étaient censés être utilisés.
Si vous ne pouvez pas nommer la vérité de terrain spécifique que votre Juge va vérifier, votre boucle n'a pas encore de véritable vérification, peu importe la confiance que semble avoir le langage du Juge.
Étape 8 : Écrivez le format de transmission avant d'écrire le prompt de transmission
La production du Constructeur et le verdict du Juge ont tous deux besoin d'une structure définie, pas d'une prose libre, sinon le Gestionnaire à l'étape suivante n'a rien de fiable sur quoi se baser.
PRODUCTION DU CONSTRUCTEUR : livrable + confiance + incertitudes connues
VERDICT DU JUGE : RÉUSSI / ÉCHEC / NÉCESSITE UNE RÉVISION + problèmes spécifiques trouvés + vérité de terrain contre laquelle cela a été vérifié
Étape 9 : Exécutez-la manuellement une fois, complètement, avant d'automatiser quoi que ce soit
Avant de configurer la planification ou les tentatives automatiques, exécutez la séquence complète Constructeur puis Juge vous-même, à la main, une fois. Lisez le verdict du Juge de manière critique. Auriez-vous été d'accord ? Si le Juge a approuvé quelque chose que vous savez être faux, ou a échoué quelque chose qui était en fait correct, corrigez la vérité de terrain ou les critères avant de continuer. Automatiser une étape de vérification défectueuse ne fait que produire des résultats défectueux plus rapidement.
Un exemple concret à travers les étapes 5 à 9
Pour rendre les cinq dernières étapes concrètes, voici comment elles se déroulent sur une tâche réelle et courante : transformer un document source brut en un contenu fini.
La définition de ce qui est fait, de l'étape 5 : chaque affirmation factuelle dans le brouillon remonte à quelque chose de réellement présent dans le document source. Le brouillon satisfait à chaque exigence spécifique du brief, longueur, ton, structure requise. L'argument central survit clairement, sans être dilué par du remplissage.
Le Constructeur, de l'étape 6, reçoit la source et le brief et produit un brouillon, accompagné d'une déclaration explicite de ce dont il n'était pas sûr en écrivant, un chiffre dont il n'était pas totalement certain qu'il était dans la source, une affirmation qu'il a déduite plutôt que trouvée explicitement.
Le Juge, de l'étape 7, reçoit le brouillon et la source originale côte à côte, jamais le brouillon seul, et vérifie chacun des trois critères de la définition de ce qui est fait séparément, renvoyant une réussite ou un échec pour chacun individuellement plutôt qu'un score global mélangé. Réduire trois vérifications distinctes à un seul verdict cache exactement quelle dimension a réellement échoué, ce qui est la façon la plus courante pour une boucle de travail de cesser silencieusement de fournir des retours utiles.
Le format de transmission, de l'étape 8, signifie que le verdict du Juge arrive comme un objet structuré, pas un paragraphe de prose prudente, trois résultats explicites de réussite ou d'échec avec une raison spécifique attachée à tout échec.
Exécuter cela manuellement une fois, selon l'étape 9, avant d'automatiser quoi que ce soit, permet de détecter le cas où votre Juge est trop indulgent, approuvant un brouillon avec une statistique fabriquée parce que le style d'écriture était soigné, ou trop strict, échouant un brouillon pour une préférence stylistique qui n'était jamais dans le brief. Les deux modes de défaillance sont courants lors d'une première tentative, et les deux sont bien moins coûteux à détecter manuellement une fois qu'à découvrir après que la boucle a déjà tourné cinquante fois sans surveillance.
Phase trois : ajouter les pièces manquantes de la boucle (étapes 10 à 14)
Étape 10 : Construisez le gestionnaire et sa condition d'arrêt
Le Gestionnaire lit le verdict du Juge et décide de la suite. C'est également là que vit la condition d'arrêt de la boucle, et elle doit être écrite comme une logique dure, pas une instruction molle que le modèle peut contourner en raisonnant.
CONDITIONS D'ARRÊT :
Révisions maximales : 3. Au 3ème verdict d'échec, escalader vers un humain avec l'historique complet, ne pas tenter un 4ème cycle.
Seuil de qualité : chaque élément de la définition de ce qui est fait doit montrer RÉUSSI.
Plafond budgétaire : si cette tâche dépasse [X] coût ou [Y] temps, arrêtez immédiatement quel que soit l'état actuel.
Une boucle sans véritable condition d'arrêt n'est pas un système. C'est un passif qui attend le jour où la tâche se révèle véritablement insoluble. La raison spécifique pour laquelle une instruction molle échoue ici mérite d'être comprise, pas seulement acceptée. « Arrête quand c'est assez bon » à l'intérieur d'un prompt est une suggestion, et un modèle sous assez de pression, ayant déjà échoué plusieurs révisions, se convaincra souvent que la tentative actuelle est suffisamment proche pour réussir, précisément parce qu'il veut produire une résolution satisfaisante à la tâche. Un compteur d'itérations dur vérifié mécaniquement par du code, ou par une règle explicite que le Gestionnaire ne peut pas contourner, n'a pas ce mode de défaillance.
Étape 11 : Ajoutez la persistance, pour que la boucle se souvienne d'une exécution à l'autre
Une boucle qui repart de zéro à chaque fois qu'elle s'exécute n'a aucune mémoire de ce qu'elle a appris la fois précédente. Ajoutez une couche de persistance simple, un fichier par leçon véritablement nouvelle, avec un résumé d'une ligne en haut, enregistrant ce qui a été appris ou corrigé et pourquoi c'était important. Crucialement, n'enregistrez que ce qui n'est pas déjà capturé ailleurs, la mémoire dupliquée est du bruit, pas de la connaissance.
La discipline qui fait que cette étape fonctionne réellement à long terme est la retenue au moment de l'écriture. L'instinct est de journaliser tout ce qui s'est passé dans une session, ce qui produit exactement le problème de transcript gonflé contre lequel cette feuille de route mettait en garde à l'étape 2, simplement déplacé dans un dossier mémoire au lieu d'un prompt. Une leçon qui vaut la peine d'être écrite est quelque chose qui coûterait du temps réel à redécouvrir si elle était oubliée, pas un enregistrement de travail de routine qui a réussi exactement comme prévu.
Étape 12 : Ajoutez un passage de consolidation sur un calendrier
La persistance seule produit éventuellement le même problème qu'un prompt gonflé, des dizaines de fichiers, dont beaucoup disent des versions légèrement différentes de la même chose. Sur un calendrier récurrent, une fois par semaine est raisonnable, examinez les fichiers mémoire, fusionnez les doublons en leçons uniques et plus précises, et supprimez tout ce qui s'est depuis avéré faux. L'objectif est d'avoir moins de fichiers avec plus de densité chacun, pas un tas qui ne cesse de croître.
Cette étape est celle que la plupart des gens sautent complètement, car elle ne produit à elle seule aucune nouvelle capacité visible, elle ne fait que prévenir un problème futur. Cette invisibilité est exactement pourquoi elle doit être planifiée explicitement plutôt que laissée au hasard quand quelqu'un remarque que le dossier mémoire est devenu difficile à gérer, ce qui en pratique signifie que cela n'arrive jamais jusqu'à ce que les performances de la boucle aient déjà commencé à se dégrader sous le poids de leçons contradictoires et semi-pertinentes qui se disputent la même fenêtre de contexte.
Étape 13 : Ajoutez l'étape de rappel
Au début de toute nouvelle exécution, faites en sorte que la boucle analyse les résumés d'une ligne en mémoire, identifie quelles leçons sont réellement pertinentes pour la tâche actuelle, et ne charge que celles-ci. Instruisez-la explicitement de dire quand rien en mémoire ne s'applique, plutôt que de forcer l'application d'une leçon passée non pertinente à une nouvelle situation simplement parce que la mémoire existe.
Étape 14 : Ajoutez un déclencheur de planification
Décidez quand cette boucle s'exécute sans que vous ne la démarriez manuellement. Un cron job. Un observateur de fichiers. Un déclencheur récurrent basé sur un calendrier. C'est l'étape qui transforme un système que vous exécutez à la demande en un système qui fonctionne pendant que vous dormez, et c'est généralement l'étape la plus simple de toute cette liste, et celle que la plupart des gens ne prennent jamais la peine de mettre en œuvre même après avoir construit tout le reste.
Phase quatre : mise à l'échelle et durcissement (étapes 15 à 18)
Étape 15 : Testez la boucle en conditions de stress avant de lui faire confiance
Avant de vous fier à cette boucle pour quoi que ce soit de réel, testez-la délibérément contre quatre modes de défaillance.
Donnez-lui une version véritablement insoluble de la tâche et confirmez que le Gestionnaire s'arrête réellement au lieu de boucler indéfiniment, car une boucle qui n'est testée que sur des tâches qu'elle peut accomplir n'a jamais réellement démontré qu'elle sait échouer gracieusement.
Donnez au Juge une production dont vous savez qu'elle est subtilement erronée, quelque chose qui se lit bien mais contient une erreur factuelle ou logique spécifique que vous avez délibérément plantée, et confirmez qu'il détecte réellement le défaut plutôt que d'approuver quelque chose qui semble plausible.
Si le Constructeur et le Juge partagent le même modèle sous-jacent, donnez au Juge une erreur que ce modèle commet typiquement et voyez s'il laisse passer l'erreur, car un Juge partageant les angles morts du Constructeur contredit tout l'intérêt de la séparation de l'étape 6.
Calculez le coût dans le pire des cas de la boucle fonctionnant jusqu'à sa limite de révision maximale, en utilisant vos appels de modèle les plus chers et la sortie raisonnable la plus longue, et décidez honnêtement si ce nombre, apparaissant sur une facture réelle, vous alarmerait.
Exécuter ces quatre tests avant de faire confiance à une boucle avec quoi que ce soit d'important détecte l'écrasante majorité des défaillances qui se manifesteraient autrement pour la première fois devant un client, un patron, ou votre propre relevé bancaire, plutôt que dans un test contrôlé que vous avez délibérément effectué.
Étape 16 : Acheminez les tâches vers le bon modèle, pas le même à chaque fois
Une fois qu'une boucle fonctionne, résistez à l'habitude d'exécuter chaque partie sur votre modèle préféré unique. Le rôle de Constructeur bénéficie généralement de votre modèle le plus capable, car il effectue le raisonnement difficile réel et un modèle plus faible ici produit un premier brouillon de moins bonne qualité qui coûte plus de cycles de révision à corriger qu'il n'en aurait coûté à bien générer la première fois.
Le rôle de Juge, vérifiant par rapport à un standard écrit spécifique, fonctionne souvent aussi de manière fiable sur un modèle plus petit, moins cher et plus rapide, car on ne lui demande pas d'être créatif, seulement cohérent, et un modèle plus petit vérifiant par rapport à une liste de contrôle extrêmement bien spécifiée correspond fréquemment à un modèle plus grand pour une fraction du coût et de la latence.
Le Gestionnaire, acheminant en fonction de règles que vous avez déjà écrites, n'a presque jamais besoin de votre modèle le plus cher, car son travail consiste à exécuter une logique que vous avez déjà spécifiée, pas un raisonnement ouvert, et il s'exécute au moins une fois par itération, indépendamment de la performance du Constructeur et du Juge, ce qui rend son coût par appel plus important que sa capacité brute.
Cette approche à plusieurs niveaux, modèle cher pour la construction, modèle bon marché et cohérent pour juger les vérifications de routine, modèle bon marché pour l'acheminement, est généralement là où se trouvent les véritables économies de coût dans une boucle. La plupart des gens supposent que le contrôle des coûts signifie moins de boucles ou moins de révisions. En réalité, il vient de l'adéquation du coût du modèle à la difficulté réelle de chaque rôle spécifique à l'intérieur de la boucle que vous avez déjà construite.
Étape 17 : Passez à une seconde boucle, pas cinq à la fois
La tentation, une fois que la première boucle fonctionne, est d'en construire plusieurs autres immédiatement, en attaquant cinq tâches différentes en parallèle parce que l'architecture le supporte techniquement maintenant. Résistez plus longtemps que ce qui semble confortable. Faites fonctionner une boucle de manière suffisamment fiable pour que vous ayez réellement cessé de vérifier sa sortie de près, ce qui signifie qu'elle réussit constamment vos propres contrôles ponctuels manuels sur une période de temps réelle, pas seulement une seule démonstration réussie que tout le monde a regardée attentivement. Alors seulement commencez la seconde boucle, sur une tâche différente, idéalement une qui correspond à quelque chose de complètement différent de la première, afin de tester si le squelette sous-jacent se généralise plutôt que d'optimiser davantage la même tâche.
Étape 18 : Offrez-vous une vue partagée sur toutes les boucles en cours d'exécution
Une fois que vous avez plus d'une boucle en cours d'exécution, suivez une vue partagée du coût et des déclencheurs de conditions d'arrêt sur toutes, pas par boucle isolément. Une seule boucle avec un budget par tâche raisonnable semble tout à fait correcte seule. Dix boucles chacune individuellement dans les limites du budget peuvent encore s'accumuler en un total alarmant que personne ne remarque jusqu'à ce que la facture globale arrive, précisément parce que le suivi de chaque boucle individuelle semblait correct isolément.
Enregistrez chaque déclencheur de condition d'arrêt spécifiquement, pas seulement les achèvements réussis. Une boucle qui atteint constamment son plafond de révision, alors que d'autres le font rarement, vous dit que le standard de son Juge est mal calibré, trop strict pour jamais réussir réellement, ou vérifie par rapport à une vérité de terrain complètement erronée, pas que la tâche sous-jacente est simplement difficile. Ce schéma est invisible si vous ne suivez que les succès et traitez chaque escalade comme un événement isolé et sans intérêt plutôt que comme un point de données sur la conception de cette boucle spécifique.
Phase cinq : devenir un concepteur de systèmes (étapes 19 et 20)
Étape 19 : Arrêtez de vous mesurer par le nombre de prompts écrits
Le signe le plus clair que le changement a réellement eu lieu est un changement dans ce à quoi vous prêtez attention au quotidien. Un prompteur suit combien de bons prompts il a écrits. Un concepteur de systèmes suit combien de boucles fonctionnent, à quel point chacune est fiable, et combien de son propre temps lui a été rendu par des systèmes qui n'ont plus besoin de supervision. Si vous mesurez encore votre productivité en nombre de prompts tapés, le changement mental de l'étape un n'a pas encore complètement atterri, peu importe combien de boucles vous avez techniquement construites.
Étape 20 : Enseignez les cinq mouvements à quelqu'un d'autre
La dernière étape ne concerne plus vraiment vos propres systèmes. Il s'agit de confirmer que vous avez réellement internalisé le changement en l'expliquant à quelqu'un d'autre sans recourir au jargon. Découverte, transmission, vérification, persistance, planification. Si vous pouvez guider une autre personne dans la construction de sa propre première boucle en utilisant seulement ces cinq mouvements et les étapes ci-dessus, vous avez effectué la transition réelle que cette feuille de route décrit. Vous n'êtes plus la personne à l'intérieur de la boucle, tapant l'instruction suivante. Vous êtes la personne qui l'a conçue, debout à l'extérieur, la regardant fonctionner.
Les quatre coûts qui s'accumulent silencieusement si vous sautez des étapes
Il vaut la peine de conclure sur un avertissement, car sauter des étapes dans cette feuille de route ne se manifeste pas bruyamment, cela se manifeste silencieusement, de manières qui n'apparaissent que bien plus tard.
La dette de vérification s'accumule lorsque vous sautez les étapes 6 et 7, en construisant des boucles sans véritable juge ni véritable vérité de terrain. La boucle semble fonctionner parce que la sortie semble correcte, jusqu'à ce qu'une erreur se cumule silencieusement à travers des dizaines d'exécutions avant que quelqu'un ne la remarque.
La pourriture de la compréhension s'installe lorsque vous sautez l'étape 20, en faisant fonctionner des boucles que vous avez construites une fois mais que vous ne pourriez plus expliquer ou déboguer si elles cassaient, parce que vous n'avez jamais eu à internaliser pourquoi chaque pièce existait.
La capitulation cognitive se produit lorsque l'étape 1 n'atterrit jamais vraiment, lorsque vous continuez à vérifier manuellement chaque sortie par habitude bien après que le système de vérification s'est déjà prouvé, ce qui va à l'encontre de tout l'intérêt de construire le système en premier lieu.
L'explosion de tokens est ce qui se produit lorsque vous sautez l'étape 10, en faisant fonctionner des boucles sans véritable condition d'arrêt, ne découvrant le coût réel que lorsque la facture arrive.
Chacun de ces coûts est évitable, et chacun d'eux est évité par la même discipline. Construisez les étapes dans l'ordre. Ne sautez pas celles qui semblent peu reluisantes. Les étapes ennuyeuses, la définition de ce qui est fait, la condition d'arrêt, la vérité de terrain, sont celles qui font réellement le travail. Les parties qui semblent intéressantes, le prompt astucieux, le diagramme d'architecture élaboré, importent beaucoup moins que de savoir si le système que vous avez construit sait réellement quand il a raison, quand il a tort, et quand s'arrêter.
C'est toute la distinction entre un prompteur et un concepteur de systèmes. Pas de l'intelligence. De la discipline concernant les parties qui sont ennuyeuses à construire et faciles à sauter.
Suivez @cyrilXBT pour les modèles de boucle exacts et les configurations Constructeur-Juge-Gestionnaire derrière chaque étape de cette feuille de route.
