Un humain + une équipe d'IA : mon système de collaboration multi-fenêtres

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 fenêtres 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. Plus tard, j’ai franchi un pas de plus : systématiser les outils et méthodes accumulés au fil de mon vibe coding pour en faire murDrift — une discipline d’ingénierie qui empêche un projet au long cours de dériver en silence.

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.