L'auteur d'un CRM en Django a assemblé un pipeline de cinq rôles d'IA qui mène seul la tâche jusqu'à la capture d'écran

Une scène familière : vous lancez Claude ou Codex, envoyez un prompt et recevez un « terminé ». Vous ouvrez le code, et ce sont les mêmes formulaires, avec seulement des variables renommées. L'auteur de cette analyse publiée sur Habr vient du développement de bases de données et, à l'automne 2025, s'est attaqué à un CRM pour la location de voitures et les aéroclubs. Il a vécu cela quatre fois de suite et a fini par construire un pipeline qui mène lui-même la tâche et apporte les preuves.

Pourquoi un seul prompt ne suffit pas

Il développait en Django des ressources partagées pour les voitures, les instructeurs et les sites. Les formulaires se ressemblaient, et il voulait réutiliser le code. Codex a annoncé que le refactoring était fait, mais la relecture a montré que presque rien n'avait changé. Trois autres tours dans des conversations différentes ont donné le même résultat. Le principal grief de l'auteur : ce que le modèle avait réellement fait, il ne le comprenait qu'à la fin. Il fallait transférer à la main les connaissances d'une conversation à l'autre, et la compression du contexte perdait des détails.

Il lui fallait un système où l'on voit d'avance comment le modèle a compris la tâche, où le travail est découpé en étapes et où chaque étape est vérifiée par quelqu'un d'autre. Tout vérifier lui-même était impossible.

Cinq rôles et un fichier

Les rôles sont nés d'un ensemble de wrappers console pour Codex CLI, Claude Code et GLM. Au début, ils étaient quatre :

• l'architecte conçoit la solution de haut niveau (modèles GPT dans Codex) ;
• le planificateur détermine l'ensemble des fichiers et esquisse un brouillon de code ;
• le codeur écrit les modifications ;
• le relecteur vérifie le résultat. Ce rôle a été confié à GLM, notamment pour rester dans les limites des abonnements.

Quand le travail parallèle dans cinq git worktrees a englouti l'attention de l'auteur, le manager est apparu. C'est un rôle presque mécanique, qui passe la main. L'auteur en a fait un agent plutôt qu'un script parce qu'il voulait pouvoir demander « où en est-on ». Il y a aujourd'hui deux relecteurs, répartis par zones de responsabilité.

Tout le monde est relié par un artefact de coordination : le fichier de plan. Il est tenu par l'architecte, les autres ajoutent leurs sections, et le manager se contente de lire et de passer la main. L'en-tête consigne le statut et qui a le droit de le fixer : Ready for Planner, Ready for Coder, Ready for Review, Done. C'est la même idée que dans les frameworks SDD comme Spec Kit, OpenSpec, BMAD et Kiro. La tâche vit dans le fichier et survit à la compression du contexte.

Un détail amusant : les rôles n'aimaient pas relire le plan et se fiaient à leur « mémoire ». L'architecte a un jour déclaré que c'était au tour du planificateur, alors que celui-ci avait déjà terminé. Le remède est simple. Le statut est fourni par un helper ; le rôle l'interroge et n'invente rien.

À quoi cela ressemble sur une tâche réelle

La tâche, tirée du CRM pour aéroclubs : réserver un avion, un instructeur et un élève sur un créneau. Le planificateur a remarqué qu'il n'y avait pas de place dans le modèle de données pour le champ « Leçon de la section de l'ATO » et a posé à l'architecte une question marquée « bloquant ». L'architecte a indiqué où mapper les champs, et le codeur s'est mis au travail sans questions.

Le relecteur a renvoyé deux fois le formulaire au codeur. La seconde fois, le test avait même figé l'erreur et passait, c'est pourquoi des tests au vert ne suffisent pas. La troisième fois, le relecteur a lancé les vérifications (119 et 67 tests, contrôle des migrations, doc-lint), pris des captures d'écran selon le scénario du plan et confronté chacune au plan. L'architecte a ouvert six captures et n'a pas accepté la tâche du premier coup : trois fichiers du commit ne faisaient pas partie de l'ensemble annoncé. Après correction, il l'a acceptée. L'humain soumet la tâche en entrée et vérifie que le plan, la relecture, les tests et les captures concordent.

Le pipeline s'améliore en plus tout seul. Après chaque plan, les rôles font un docs closeout : ils proposent ce qu'il reste à finaliser et comment améliorer le processus. Les propositions s'accumulent dans des registres, et le triage décide de ce qu'il faut mettre en œuvre.

L'auteur puise aussi des idées à l'extérieur. Les golden paths, de courtes recettes du type « pour un formulaire standard, ouvre ces 3 à 5 documents », et le doc gardening viennent d'un article d'OpenAI sur le harness engineering. La recherche QMD sur le markdown a été essayée puis écartée : la recherche plein texte de SQLite a suffi.

Contre les boucles, une limite : après 12 itérations sur un même plan, le manager arrête le travail.

Limites et ce qu'il faut en retenir

C'est l'expérience d'une personne sur un projet, sans mesures du type « j'ai économisé tant d'heures ». L'auteur n'a finalement pas ramené les formulaires à un code unique, s'arrêtant à un « niveau d'uniformité compréhensible ». Toutes les modifications ne passent pas par le pipeline, seulement celles qui exigent une trace dans le dépôt. La vérification par un autre modèle se fait désormais surtout hors pipeline. Les modèles précis qu'il cite ne sont pas l'essentiel : ils changent plus vite que le processus.

Ce qu'il vaut la peine d'emporter dans votre projet :

• Exigez des preuves, pas des rapports : tests, captures d'écran, confrontation avec le plan.
• Créez un fichier de tâche unique avec des statuts et une règle sur qui fixe quel statut.
• Ne confiez pas au modèle le calcul du statut, déléguez-le à un helper.
• Autorisez les rôles à poser des questions bloquantes avant d'écrire du code.
• Fixez une limite d'itérations pour que les agents ne patinent pas indéfiniment.

La leçon principale : le prompt convient pour une solution ponctuelle. Dès qu'un projet doit évoluer et être maintenu, il faut un processus dont le résultat se vérifie à l'œil.