Mon équipe d'agents IA

01 · Problème

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.

02 · Contexte

Plusieurs projets, une seule personne.

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.

03 · Réflexion

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.

04 · Solution

Une petite équipe d'agents, 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.

• La coordination : 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.

05 · Ce que j'ai construit

Un orchestrateur de sessions de travail.

• Lancer et reprendre une session de travail 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.

06 · Comment

Les règles du jeu.

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é

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

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.

07 · Limites actuelles

Ce que j'ai appris en la faisant tourner.

• 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.
• 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. Le protocole a été durci le jour même, puis testé.
• Ce n'est pas un produit. C'est ce qui me permet de construire les autres.

08 · Prochaine étape

La garder petite.

Une règle simple : cette é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.