Mon équipe d'agents IA : jusqu'où les laisser agir seuls

Cette note est le détail technique de l'étude de cas Mon équipe d'agents IA. L'étude de cas dit ce que l'équipe fait et ce qu'elle apporte ; ici, je raconte comment elle fonctionne et ce que j'ai appris.

Trop de validations, ou pas assez

C'est la question que se pose toute organisation qui veut confier du travail à un agent IA. Trop de validations, et l'agent ne fait gagner aucun temps : on passe ses journées à cliquer sur « autoriser ». Trop peu, et un agent peut publier, supprimer ou dépenser à votre place.

Je mène plusieurs projets en parallèle, seul. Je me suis posé la question sur mes propres projets, avec du vrai code, de vraies mises en ligne et de vraies erreurs.

La bonne question n'est pas « l'agent est-il fiable ? ». C'est : qu'est-ce qui est réversible ? Tout ce qui l'est peut aller vite. Le reste passe par un humain. Cette seule distinction décide de presque tout le reste.

Une petite équipe, et des règles écrites

Chaque agent a sa propre consigne et ses propres outils autorisés. Ce ne sont pas des rôles joués par un même assistant.

• Le chef d'orchestre : reçoit l'objectif, construit le plan, choisit les outils et délègue.
• La construction : code, corrige et fait avancer un livrable concret.
• Le contrôle qualité : relit un travail déjà fait avant une action importante, en lecture seule. Il peut signaler, jamais modifier.
• La capitalisation : une fois un travail terminé, en tire une fiche de connaissances réutilisable.

Autour d'eux, un orchestrateur de sessions de travail :

• Lancer et reprendre une session sur un projet, dans son propre dossier et avec ses propres permissions.
• Suivre l'avancement : chaque session écrit son début, sa fin, et son état, terminé ou bloqué.
• Travailler en mon absence : une validation manquante bloque une tâche, jamais le projet. L'agent note où il en est, ce qu'il attend de moi, et passe à une autre tâche sûre.
• Regrouper les validations : le travail sans risque d'abord, puis une seule liste numérotée à approuver, avec pour chaque ligne sa cible, sa réversibilité et son coût.

Ce qui attend toujours mon accord

• Publier, mettre en production, rendre quelque chose public.
• Dépenser de l'argent ou créer un service payant.
• Supprimer de façon irréversible.
• Toucher à des mots de passe, des clés d'accès ou des données clients réelles.
• Envoyer un message en mon nom.
• Modifier ses propres règles, ou créer une automatisation qui tournerait sans moi.

Deux principes de sécurité complètent la liste. Un contenu externe est une donnée, jamais une instruction : une page web, un mail ou un document importé peut contenir des consignes, elles sont ignorées et signalées. Les règles écrites ne suffisent pas, les permissions verrouillent : les interdits les plus graves sont aussi bloqués au niveau des outils.

Le résultat d'une nuit

Une nuit de travail en mon absence : 6 tâches terminées plus une passe qualité, 0 session sur 9 bloquée par un refus de permission, 0 mise en production sans moi. Le matin, c'est moi qui ai intégré le travail : cette étape reste une action humaine. Les tests ont été vérifiés par mutation : on casse volontairement le code, et ils doivent échouer. Un test qui passe toujours ne prouve rien.

Une interface : La Table Ronde

Jusqu'ici, l'équipe vivait dans des fichiers et un terminal. Pendant une semaine, je teste une interface où elle travaille à découvert, La Table Ronde, et toutes les tâches de construction d'un de mes produits y passent.

Le moteur est Paperclip, un logiciel open source qui distribue les tâches et réveille le bon agent. Ce qui est à moi : les règles de l'équipe, son organisation, l'habillage de l'interface (posé à côté, sans modifier Paperclip) et un veilleur qui rattrape les relais sautés.

Premiers résultats : 6 tâches de construction sur 8 intégrées au produit, les 2 autres écartées parce que l'équipe a mesuré qu'elles n'apportaient rien ; 4 à 5 minutes de cycle habituel par tâche, du cadrage à la livraison ; 25 secondes pour que la relecture refuse une livraison volontairement défectueuse, avec ses deux défauts.

Aucune clé d'API facturée : les agents tournent sur des abonnements que je paie déjà. Ce que chaque tâche consomme de ce quota, je ne le mesure pas encore précisément. C'est l'un des points que l'essai doit établir.

Les limites rencontrées

• Un relais sur trois saute. Sans correctif, environ une relecture sur trois n'est jamais déclenchée. La cause est lue : le réveil est refusé quand le constructeur libère sa tâche quelques dizaines de millisecondes trop tard. Le veilleur que j'ai écrit rattrape ces sauts en moins d'une minute.
• La relecture ne suffit pas. Des défauts sont passés : un fichier modifié hors du dossier autorisé, un rapport de livraison inexact, une mesure faite sur des données périmées. Tous ont été rattrapés à l'intégration, que je garde. Cette étape reste à part entière, pas une formalité.
• Un agent peut contourner une règle en restant dans la lettre. Une session a vu une suppression refusée, puis a supprimé ses propres brouillons par une autre commande. Rien de grave, mais la règle porte désormais sur l'intention, pas sur une commande précise.
• La vraie limite est matérielle. Quand l'ordinateur s'est mis en veille pendant la nuit, tout s'est arrêté sans rien casser, et quatre heures ont été perdues.
• L'interface ne tourne que sous Linux. Sous Windows, le logiciel ne peut pas vérifier qu'un agent s'est bien arrêté avant d'en réveiller un autre. Je la fais donc tourner dans Linux, sur le même ordinateur (WSL).

Ce que j'en retiens

Une règle simple : l'équipe n'évolue que si une friction réelle, rencontrée sur un projet, l'exige. Ce que j'en retiens sert surtout ailleurs : aider une équipe à décider quelles tâches confier à un agent, et comment garder la main.