Humain + IA : un système de collaboration multi-fenêtres
Non pas chercher un modèle plus intelligent, mais concevoir une organisation qui empêche des IA ordinaires de dériver.
Ce site a été fait par une seule personne, mais il n’a pas été fait seul. Au moment où j’écris ces lignes, trois fenêtres d’IA sont ouvertes sur ma machine : une fenêtre de gestion vient d’émettre la fiche de mission de cet article, une fenêtre d’exécution écrit du code, une troisième attend pour la recette. Je suis assis au milieu, et je fais passer les messages.
Le problème de la fenêtre unique
Quiconque a travaillé longtemps avec une IA a sans doute rencontré le même phénomène : plus la conversation s’allonge, plus elle ressemble à un collègue épuisé. Une fois le contexte saturé, les accords passés tombent silencieusement dans l’oubli ; elle annonce joyeusement que « tout est terminé », et quand on vérifie, les tests n’ont jamais tourné. Ce n’est pas le défaut d’un modèle en particulier — c’est un problème structurel des longues conversations : la mémoire est finie, et l’auto-recette est par nature indigne de confiance.
Ma réponse n’a pas été d’attendre un modèle plus fort, mais de changer de structure d’organisation.
Diriger des IA comme une petite équipe
Aujourd’hui, je monte pour chaque projet un « établi » fixe, avec à peu près ces règles :
- La fenêtre de gestion ne fait que trois choses : écrire les décisions d’architecture, ouvrir les fiches de mission, prononcer la recette. Elle n’écrit pas une ligne de code produit.
- Les fenêtres d’exécution travaillent sur fiche de mission. La fiche est un contrat : objectif, périmètre et critères d’acceptation listés point par point, cochés point par point.
- Je suis le bus de messages. Les fenêtres ne se parlent jamais directement ; chaque consigne et chaque résultat passe par moi. Cela paraît inefficace, mais c’est le cœur de la gouvernance : chaque transmission est une occasion de plus de contrôle humain.
Quelques disciplines complètent le dispositif. « Vérifié » doit signifier « commande + sortie » — un « ça devrait aller » ne compte pas. La fenêtre qui écrit le code ne recette jamais son propre travail : la recette est menée par une fenêtre au contexte vierge, sur une épreuve scellée dont l’exécutant n’a jamais vu les questions — précisément pour empêcher le bachotage. Les fenêtres peuvent partir à la retraite et être remplacées à tout moment, selon un protocole de passation fixe ; les gens passent, l’établi et les règles restent.
D’où vient cette habitude
L’un de ses points de départ date de fin juin 2026, quand j’ai décortiqué le projet phare de mon équipe. En suivant ce code, j’ai découvert des outils open source comme superpowers — des cadres pour « fixer des règles à l’IA » — que j’ai disséqués ligne à ligne pour en apprendre la pensée d’architecture. Ce processus m’a fait voir une chose : la fiabilité d’un agent ne vient pas du modèle lui-même, mais de la structure de contraintes qui l’entoure. Une fois mis en pratique, la vitesse comme la qualité finale de mon vibe coding se sont visiblement améliorées.
Mais plus je l’utilisais, plus je constatais que mon vrai problème se situait hors de sa portée. superpowers gouverne la manière dont une chose est correctement construite — idéation, spécification, plan, développement piloté par les tests, revue de clôture — à l’échelle d’une tâche, d’une branche. Ce qui m’épuisait, c’était la manière dont un projet au long cours évite de dériver en silence sur plusieurs mois : le contexte sature, les fenêtres partent à la retraite, les décisions d’architecture s’oublient, et la recette se transforme peu à peu en auto-satisfaction. C’est un problème situé sur un autre axe ; mieux faire le premier axe ne le résout pas.
J’ai donc systématisé les outils et méthodes accumulés au fil de mon vibe coding pour en faire murDrift — gouvernance, recherche, continuité, recette infalsifiable, visant précisément la dérive entre sessions, entre fenêtres et entre mois. Avec superpowers, ce sont deux systèmes orthogonaux : utilisables ensemble, et aucun n’exige l’autre. La discipline multi-fenêtres décrite dans cet article ne dépend d’aucun cadre externe pour fonctionner.
| superpowers (obra · MIT) | murDrift | |
|---|---|---|
| Gouverne | comment une chose est correctement construite | comment un projet évite de dériver |
| Chaîne | idéation → spéc. → plan → TDD → revue → clôture | gouvernance / recherche / continuité / recette infalsifiable |
| Échelle | une tâche, une branche | sessions, fenêtres, mois |
J’ai transporté cette idée du « runtime d’un agent unique » vers « l’organisation de plusieurs fenêtres d’IA », et j’ai poli le processus ci-dessus par essais et erreurs. Le site que vous lisez est passé du dépôt vide à une page d’accueil en ligne en deux jours, à l’intérieur même de ce processus — y compris cet article : à cet instant, il n’est encore qu’un brouillon remis par une fenêtre d’exécution, et selon les règles, il ne compte pour rien tant que je ne l’ai pas révisé mot à mot.
Si vous aussi vous travaillez avec l’IA sur la durée, je n’ai qu’un conseil : ne vous précipitez pas vers un modèle plus intelligent. Donnez d’abord une constitution à votre collaboration.