Présentation technique de mon équipe d’agents IA

Introduction

Je ne me présente pas comme un développeur web classique, mais comme un pilote de systèmes d’IA. Ce document présente l’infrastructure que j’ai conçue pour m’aider à combler mes lacunes en développement manuel.

Ma démarche repose sur un constat honnête : plutôt que de lutter seul contre les complexités du code manuel, j’ai choisi d’investir mon énergie dans l’architecture des processus. J’ai créé cette équipe d’agents pour compenser mes limites techniques et les transformer en un dispositif structuré, où chaque étape reste sous mon pilotage.

Passionné par le monde de l’IA, je profite de ma formation pour approfondir mon apprentissage de l’IA. Le concept que j’ai créé n’est pas parfait : c’est ma première équipe. Je m’en sers pour m’entraîner à concevoir des équipes d’agents IA, à piloter l’IA, à gérer le contexte et à maîtriser la consommation de tokens. C’est un apprentissage long et complexe, mais c’est un domaine dans lequel je m’épanouis.

1. Vision générale

Mon équipe repose sur une idée simple : un agent = une mission précise.

Un agent ne doit pas tout faire. Il doit faire une seule chose, dans un seul périmètre, avec des règles claires. Cette logique me permet d’éviter plusieurs problèmes fréquents :

• les réponses trop vagues ;
• les oublis ;
• les modifications hors sujet ;
• la confusion entre design, backend, sécurité, tests et documentation ;
• la dérive du contexte quand une même IA essaie de tout faire seule.

Mon système est donc organisé comme une équipe coordonnée, avec :

• un agent de liaison et de pilotage ;
• des agents de conception ;
• des agents de développement ;
• des agents de contrôle ;
• des agents de test ;
• et des agents documentaires optionnels.

2. Socle technique

Le système s’appuie sur un framework pédagogique utilisé comme référentiel de structure, de conventions, de sécurité et de méthode de travail.

Ce socle sert de base commune à toute l’équipe. Les agents ne doivent pas le dénaturer. Ils doivent s’y aligner. Cela concerne notamment :

• la structure des dossiers ;
• le routage ;
• les conventions de nommage ;
• la manière d’écrire le code ;
• les règles de sécurité ;
• et le mode opératoire général.

Autrement dit, l’équipe ne travaille pas librement : elle travaille dans un cadre précis.

3. Référentiels et dossiers de travail

L’architecture de mon équipe s’appuie sur plusieurs dossiers de référence.

document/

C’est le dossier de cadrage du projet. Il contient les éléments de contexte, les décisions, les consignes et les documents de pilotage.

document/agent/

C’est le dossier de liaison et de traçabilité. On y trouve notamment :

• point-liaison-romain.md
• project-context.md
• etat-projet.md
• ATTRIBUTION-LOTS.md
• des checklists et des documents de validation

Ce dossier sert à garder une mémoire claire du projet.

.cursor-work/

C’est le dossier de travail interne de l’équipe. Chaque agent y dépose ses brouillons, rapports, audits, variantes, contrôles et fichiers intermédiaires.

.cursor/agents/ et .cursor/rules/

Ces dossiers servent à encadrer le comportement des agents, leurs garde-fous et certaines règles automatiques.

4. Principe de fonctionnement

Mon équipe suit un ordre d’activation précis. Chaque agent intervient au bon moment, avec les bonnes entrées, et produit le bon livrable pour l’agent suivant.

Le fonctionnement repose sur quatre principes.

a) Découpage par lots

Le travail est réparti en petits blocs. Cela permet de mieux contrôler le contexte, d’éviter les dérives et de limiter les erreurs.

b) Spécialisation

Chaque agent a un rôle fixe. Il ne doit pas empiéter sur le rôle d’un autre agent.

c) Traçabilité

Chaque étape laisse une trace écrite. Cela permet de savoir qui a fait quoi, quand, sur quelle base, et pour quel lot.

d) Vérification

Avant d’aller plus loin, un autre agent contrôle le travail précédent. Cela ajoute plusieurs couches de contrôle logique.

5. Catalogue de mon équipe

Le noyau principal repose sur 13 rôles, avec Victor qui intervient à deux moments différents dans le cycle. À cela s’ajoutent 2 agents optionnels dédiés aux documents.

1. Léonie — Liaison, initialisation et coordination

Léonie est le point d’entrée de l’équipe. Elle fait le lien entre moi et les autres agents.

Son rôle est de :

• initialiser le projet ;
• préparer l’arborescence ;
• créer les dossiers de suivi ;
• mettre en place .cursor-work ;
• organiser les lots ;
• coordonner les activations ;
• préparer les passations ;
• et maintenir la cohérence générale.

Elle est aussi responsable de la structure documentaire de départ et de l’organisation globale du travail.

2. Clara — Traduction du cahier des charges

Clara lit le cahier des charges et le reformule dans un langage exploitable par les autres agents.

Elle transforme un besoin humain en éléments structurés :

• objectifs ;
• contraintes ;
• règles métier ;
• entités ;
• vocabulaire exploitable ;
• points à clarifier.

Elle ne code pas. Elle prépare le terrain.

3. Marc — Conception de la base de données

Marc s’occupe de la partie données.

Il produit notamment :

• le MCD ;
• le MLD ;
• le script SQL ;
• le dataset ;
• les données de démonstration ;
• et les identifiants de test par profil.

Son rôle est de donner une base de données cohérente avant le développement.

4. Victor — Contrôle logique métier, phase 1

Victor intervient une première fois avant le développement.

Son rôle est de vérifier la cohérence entre :

• le cahier des charges ;
• la logique métier ;
• et la structure de données proposée.

Il sert de filtre de cohérence avant de passer à la suite.

5. Hugo — Design et intégration front

Hugo a un rôle en deux temps.

Phase design avant le premier code métier

Avant le premier développement métier, Hugo produit exactement 5 packs de variantes dans .cursor-work/hugo/variantes-pre-thomas/.

Chaque pack contient :

• un gabarit ;
• un CSS ;
• un JavaScript ;
• une proposition visuelle distincte.

Après mon choix, la variante retenue devient la référence visuelle du projet.

Phase code front après le backend

Après le passage backend, Hugo intervient sur le code livré.

Il a deux types de passage :

• passage 1 : gabarit global, accueil, www/_css, www/_js ;
• passage 2 : habillage des vues métier d’une vague donnée.

Hugo ne travaille donc pas seulement sur le style. Il intervient dans un ordre précis et avec un cadre défini.

6. Thomas — Développement backend

Thomas construit la partie backend.

Il produit notamment :

• les contrôleurs ;
• les modules ;
• les classes liées aux tables ;
• les vues fonctionnelles ;
• la logique CRUD ;
• et les branchements avec la base.

Dans mon système, Thomas doit d’abord appliquer le générateur prévu par le cadre du projet avant de poursuivre les développements métier.

7. Bertrand — Contrôle backend

Bertrand vérifie le travail de Thomas.

Il contrôle par exemple :

• la structure des contrôleurs ;
• l’emplacement des requêtes ;
• la cohérence des actions ;
• le respect des conventions ;
• et la solidité générale du code backend.

Il agit comme contrôleur et correcteur du backend.

8. Victor — Vérification logique métier, phase 2

Victor intervient une seconde fois après Bertrand.

Cette deuxième passe sert à vérifier que la logique métier a bien été respectée dans le code produit, avant la phase d’intégration front suivante.

9. Béatrice — Contrôle frontend

Béatrice vérifie le travail de Hugo après ses passages sur le code.

Elle contrôle :

• les vues ;
• les gabarits ;
• les formulaires ;
• les liens ;
• la cohérence visuelle ;
• l’accessibilité ;
• et la conformité générale de l’interface.

Elle intervient juste après le passage de Hugo concerné.

10. Julien — Contrôle sécurité

Julien réalise l’audit sécurité.

Il vérifie notamment :

• les formulaires ;
• l’échappement HTML ;
• la protection CSRF ;
• les accès par profil ;
• les redirections ;
• les points sensibles du backend ;
• et certaines dérives de structure.

Dans le fonctionnement prévu, Julien intervient avant la phase de test UI/UX.

11. Valentin — Test UI/UX

Valentin teste l’expérience utilisateur.

Il vérifie :

• la navigation ;
• la lisibilité ;
• les formulaires ;
• les parcours ;
• le responsive ;
• et la compréhension globale de l’interface.

Son rôle est de tester l’usage réel du site côté utilisateur.

12. Sébastien — Test sécurité

Sébastien teste le comportement sécurité en conditions réelles.

Il vérifie par exemple :

• les accès interdits ;
• les réactions face aux erreurs ;
• les comportements anormaux ;
• les protections de session ;
• les points sensibles liés aux formulaires ou aux uploads.

Là où Julien contrôle la structure de sécurité, Sébastien teste davantage le comportement effectif.

13. Rémi — Traductions et multilingue

Rémi intervient en fin de projet, après Sébastien.

Il met en place :

• les fichiers de langue ;
• le helper de traduction ;
• le sélecteur de langue ;
• la locale en session ;
• et la suppression des textes en dur dans les vues.

Il s’occupe donc de la couche multilingue.

6. Ordre opérationnel réel

Le fonctionnement de mon équipe n’est pas seulement une liste de rôles. C’est aussi une séquence précise.

Phase A — Avant le premier code métier

L’ordre est le suivant :

1. Clara
2. Marc
3. Victor phase 1
4. synthèse validée
5. Hugo pour les 5 packs de design
6. choix de la variante retenue
7. Thomas pour le générateur puis les premiers lots backend

Phase B — Développement par vagues

Pour chaque vague de développement, l’enchaînement est le suivant :

1. Thomas
2. Bertrand
3. Victor phase 2
4. Hugo
5. Béatrice

Une particularité importante existe sur la première vague : Hugo effectue un passage 1 global. Ensuite, sur les vagues suivantes, il effectue surtout des passages 2 sur les vues de la vague concernée.

Phase C — Fin de projet

La fin de projet suit cet ordre :

1. Julien
2. Valentin
3. Sébastien
4. Rémi

Cet ordre permet d’éviter qu’un test d’interface soit fait avant le contrôle sécurité prévu.

7. Agents optionnels hors flux principal

En plus du noyau principal, j’utilise deux agents optionnels.

Camille — Documents Word

Camille est un agent ponctuel dédié à la rédaction et à la structuration de documents Word .docx.

Il me sert à :

• rédiger un document ;
• hiérarchiser les titres ;
• organiser les paragraphes ;
• mettre en forme les tableaux ;
• et produire un livrable Word clair.

Camille n’entre pas dans le flux principal de l’équipe. Il intervient seulement quand j’en ai besoin.

Lucas — Documents PDF

Lucas est lui aussi un agent ponctuel. Il sert à produire des PDF.

Son fonctionnement passe d’abord par un document Word propre, puis par une conversion en PDF. Il me sert pour :

• les dossiers ;
• les synthèses ;
• les présentations ;
• et les exports finaux.

Camille et Lucas ont été créés à partir de skills open source fournis par Anthropic. Ce sont donc des modules documentaires optionnels, séparés du flux principal.

8. Outils et mécanismes utilisés

Mon équipe ne repose pas seulement sur des prompts. Elle s’appuie aussi sur des outils, des règles et des mécanismes de contrôle.

MCP

Définition : un pont qui permet à un agent de dialoguer avec un outil externe.

Selon le besoin, mon équipe peut utiliser des outils comme :

• Browser ;
• Playwright ;
• Git ;
• MySQL ;
• office-word ;
• Excel ;
• et d’autres outils de support.

Watchers locaux

Définition : petits scripts de surveillance qui vérifient automatiquement certains points.

Dans mon système, ces watchers servent notamment à surveiller :

• la sécurité ;
• le backend ;
• le frontend ;
• certaines alertes internes ;
• et des contrôles de cohérence.

Documentation de liaison

La documentation sert de mémoire partagée entre les agents.

Elle passe par des fichiers comme :

• point-liaison-romain.md
• project-context.md
• les rapports d’audit
• les variantes de Hugo
• les documents de décision
• les documents de passation

Cela évite qu’un agent travaille sans contexte.

9. Garde-fous importants

Mon équipe fonctionne avec plusieurs garde-fous obligatoires.

Respect du cadre du projet

Les agents ne doivent pas casser la structure du framework pédagogique ni s’écarter de ses conventions.

Pas d’invention en cas de doute

Si un agent ne sait pas, il ne doit pas inventer. Il doit s’arrêter et demander une clarification.

Contradiction et relecture

Le système prévoit une logique de contradiction, de vérification et de relecture afin de limiter les oublis et les dérives.

Travail local encadré

Le fonctionnement est prévu dans un environnement local précis, avec des règles strictes sur les chemins, les fichiers et les manipulations sensibles.

Aucune suppression massive

Le système interdit les suppressions massives ou dangereuses. L’objectif est d’éviter toute action destructrice mal contrôlée.

10. Ce que cette équipe m’apporte

Apprentissage de la structure

Elle m’apprend à organiser une mission complexe en plusieurs rôles clairs.

Maîtrise du contexte

Elle m’aide à mieux gérer la mémoire de travail, les passations et la consommation de tokens.

Fiabilité

Elle réduit les risques de mélange entre les rôles et améliore la lisibilité du processus.

Relecture critique de l’IA

Cette méthode ne me fait pas progresser directement sur le code. En revanche, je regarde quand même le code produit par l’IA et, à force de m’entraîner à piloter, j’arrive de mieux en mieux à voir les erreurs faites par l’IA dans certains aspects du code. Cette façon de travailler m’entraîne aussi à mieux structurer l’IA pour qu’elle livre un code plus simple pour la maintenance et la compréhension pédagogique, mais cela prend du temps.

11. Limites assumées

Je présente cette équipe avec honnêteté.

Ce système n’est pas parfait. C’est une première équipe, et il dépend encore :

• de la qualité du cadrage ;
• de la précision des consignes ;
• de la discipline dans les passations ;
• de ma capacité à bien piloter l’ensemble ;
• et de ma capacité à choisir le bon niveau de contrôle au bon moment.

Mais c’est aussi ce qui fait sa valeur pour moi : ce n’est pas un objet figé, c’est un terrain d’apprentissage actif.