Concevoir un agent en 2 heures au lieu de 2 jours

Le problème

Cadrer un agent prend des jours, et un cadrage raté se paie ensuite

Avant de construire un agent, il faut cadrer le besoin de l'équipe qui va s'en servir. En vingt ans de projets, cadrer une solution m'a toujours pris plusieurs jours, et deux jours en est l'estimation basse.

Il faut rassembler les besoins et les écrire en spécifications, le document qui dit quoi construire. Il faut aussi dessiner les flux et leur enchaînement dans le temps, puis choisir l'architecture, la façon dont les pièces s'assemblent.

Un cadrage mal fait se paie plus tard, en heures de développement et de réunion.

Un cadrage se mène mieux à deux. Un binôme pose les questions auxquelles on n'aurait pas pensé, celles qui évitent ces heures perdues.

Ce que j'ai décidé et fait

Un binôme de cadrage qui suit une procédure, une question à la fois

J'ai construit ce binôme sous forme d'agent, un programme qui s'appuie sur une IA pour mener une tâche en plusieurs étapes. Il tourne sur Claude Code, l'outil d'Anthropic qui fait travailler des agents IA sur un poste de travail.

Il est relié par MCP, un connecteur standard entre une IA et un logiciel, à n8n, l'outil qui enchaîne des étapes automatiques entre logiciels. Quand le besoin le demande, il y publie l'agent conçu et son workflow, sans que le métier écrive une ligne de code.

• Poser une seule question par messageL'agent mène l'entretien de cadrage avec l'équipe métier, une question à la fois. C'est ce qui le rend utilisable par quelqu'un du métier.
• Reconnaître d'abord la sorte d'agentJ'ai défini trois sortes d'agents : celui qui traite des données, celui qui converse, et l'agent autonome qui enchaîne ses outils vers un objectif. L'Architecte reconnaît d'abord laquelle construire, car chaque sorte a ses propres questions.
• Couvrir chaque point avant de conclureIl passe en revue ce qui fait perdre du temps, les données réelles qui entrent, la sortie attendue, les règles métier, les interdits et la sécurité, et le critère de succès. Chaque point a sa condition pour être tenu pour acquis.
• Garder le calcul exact hors de l'IACe qui relève du calcul exact, il le sort de l'IA. Il sait aussi conclure « IA oui, agent non » quand un agent serait de trop.
• Livrer de quoi construire et testerIl rédige les instructions de l'agent, les consignes qui lui disent quoi faire et comment, avec la liste de ce qu'il faut brancher autour. Il y joint un plan de test, dont un cas piège : une donnée qui contient une instruction malveillante.

Ce que j'ai écarté

La première version décrivait une posture, celle d'un « architecte senior », avec un vocabulaire flatteur. Je l'ai remplacée par une procédure vérifiable, étape par étape.

J'ai aussi écarté le gros fichier d'instructions unique, qui grossissait et se contredisait. À la place, j'ai conçu un socle qui appelle un module selon la sorte d'agent à construire.

L'agent a connu neuf versions. Chacune est passée sur un banc de test, une série d'essais qui contrôle son comportement, avant la suivante.

Le résultat

2 heures au lieu de 2 jours

pour concevoir un agent avec l'Architecte d'IA

2h

pour le même travail, sans lui

2jours

Ce que ça change pour une équipe

L'équipe métier sort de l'entretien avec un agent prêt à construire. L'équipe IA reçoit des instructions complètes au lieu de notes à reprendre.

Ce que j'en retiens

Devant un chiffre, je demande s'il décrit l'existant ou la cible

J'ai mené un vrai cadrage avec l'Architecte, sur un besoin à moi. Il a duré deux heures, en 36 échanges.

Au début, j'ai parlé de « 3 offres par jour ». C'était une limite que je subissais, alors que ma cible était 20.

L'agent a retenu 3 comme objectif. Aucune relecture de ses instructions n'aurait trouvé l'erreur, car il fallait connaître mon intention.

J'en retiens qu'un chiffre donné au début décrit souvent ce qui existe. Il faut toujours demander si c'est ce qu'on vise.

J'ai corrigé les instructions de l'agent en ce sens. C'est aussi la question que je poserai à vos équipes métier.