Comment aborder le développement avec des agents IA
La maîtrise du résultat, l’humain comme architecte et testeur, et un skill qui oblige l’agent à expliquer sa conception avant d’écrire du code.
Je pense qu’il existe quantité d’avis sur la manière d’utiliser correctement les agents dans le développement. Dans cet article je partage le mien. Il différera probablement de celui des autres, mais les idées principales seront certainement très proches.
1. Comment garder la maîtrise de ce que produit l’agent
Je crois que la base d’un bon usage des agents dans le développement, c’est la maîtrise du résultat. Nous n’avons pas à connaître chaque ligne de code. Nous devrions en revanche connaître chaque décision d’architecture et la comprendre.
La différence est de taille. Une ligne de code se réécrit en une minute et, la plupart du temps, rien n’en dépend. Une décision d’architecture vous revient six mois plus tard, quand plus personne ne sait pourquoi c’est ainsi — et la réécrire ne prend pas une minute, mais des semaines.
2. Quel rôle joue l’humain dans le développement avec des agents IA
À mon avis, dans le développement avec des agents, l’humain doit être avant tout architecte, designer UX et testeur. Bien sûr, l’IA peut aider dans ces rôles aussi — mais l’humain doit fournir une part considérable de l’effort de vérification.
C’est la part qui ne se délègue pas. L’agent vous écrira du code qui fonctionne. Savoir si c’est le bon code au bon endroit, et si ce que vous avez demandé était seulement une bonne idée — cela reste chez vous.
3. Comment écrire un skill Claude Code qui impose la conception
Par expérience, je recommande de se créer un skill dans lequel vous dites à l’agent qu’avant toute implémentation il doit d’abord vous expliquer les étapes d’architecture qu’il a choisies — sous la forme d’une structure prédéfinie dans un fichier Markdown.
Dites à l’agent d’utiliser largement les diagrammes mermaid, les exemples et les graphiques. Un diagramme met au jour une absurdité qui se cache bien dans un texte suivi : quand l’agent dessine le flux de données et que deux composants se parlent dans les deux sens, cela saute aux yeux.
Un tel skill peut ressembler à ceci :
.claude/skills/it-analysis/SKILL.md
---
name: it-analysis
description: Rédige une analyse informatique
---
# Analyste informatique
Tu es analyste informatique senior. Tu es spécialisé dans les analyses des systèmes informatiques et de leur architecture.
## Workflow
1. **Comprends ce que tu dois résoudre** — Comprends la demande et réfléchis-y. Comment la résoudre ? quelles sont les variantes de solution ? Edge cases ?
2. **Rédige l’analyse selon le modèle template.md**
3. **S’il y a des réponses aux questions existantes** - Reprends l’analyse à partir des réponses aux questions ouvertes. N’efface ni les questions ouvertes ni les réponses, laisse les originales. Tu peux ajouter d’autres questions. À la fin de l’analyse, mets un récapitulatif des changements (changelog).
## Rules
- La sortie doit suivre le modèle `template.md`.claude/skills/it-analysis/template.md
# Modèle pour la rédaction d’analyses
## Sommaire
1. [Architecture](#1-architecture)
2. [Base de données](#2-base-de-donnees)
3. [Backend](#3-backend)
4. [Frontend](#4-frontend)
5. [Risques de mise en œuvre](#5-risques-de-mise-en-oeuvre)
6. [Questions ouvertes à trancher](#6-questions-ouvertes-a-trancher)
## 1) Architecture
Cette partie traite de l’architecture proposée pour la fonctionnalité mise en œuvre. Elle traite également de la façon dont l’architecture existante sera modifiée et du raccordement à celle-ci. Des diagrammes UML appropriés en mermaid sont souhaitables.
## 2) Base de données
Cette partie traite du modèle de données proposé au moyen d’un diagramme ER. Elle traite également des modifications du modèle existant et du raccordement à celui-ci. Les diagrammes ER sont souhaitables.
## 3) Backend
Ici seront traités sous forme de liste les impacts sur le backend — c’est-à-dire ce qu’il faudra y ajouter / supprimer / modifier.
## 4) Frontend
Ici seront traités sous forme de liste les impacts sur le frontend — c’est-à-dire ce qu’il faudra y ajouter / supprimer / modifier.
## 6) Questions ouvertes à trancher
Une liste numérotée de questions à trancher. Chaque point de la liste ressemblera à ceci :
- **Nom descriptif de la question** : Le texte détaillé de la question, à partir duquel je dois pouvoir comprendre ce que tu demandes.
`Réponse` : Le texte de la réponse, ou `-` s’il n’y a encore aucune réponse.4. Pourquoi laisser l’agent concevoir la solution en premier
Sur la base de ce skill, vous faites toujours d’abord proposer une solution, que vous validez toujours avant tout le reste. Il faut évidemment relire sérieusement ce que produit ce skill, mais le résultat en vaut assurément la peine.
De plus, à mon avis, il est important de comprendre ces questions fondamentales même si c’est l’agent qui écrit le code. C’est la seule partie où se décide si le projet vaudra encore quelque chose dans un an.
La section des questions ouvertes du modèle est là exactement pour cela. Un agent a tendance à lever les ambiguïtés tout seul et en silence — et vous l’apprenez une fois le code terminé. Si vous l’obligez à écrire les questions, vous les obtenez avant que quoi que ce soit ne repose dessus.
5. Comment discuter d’une conception que vous ne comprenez pas
Si certaines parties du document vous laissent dans le doute, n’hésitez pas à en discuter avec l’agent de façon itérative. En échangeant avec lui, vous comprendrez mieux la solution proposée, et cela vous aidera à livrer un produit de qualité.
Il vaut la peine de remarquer que cette discussion a aussi un second effet. Quand vous demandez quelque chose et que la réponse n’a pas de sens, ce n’est généralement pas parce que vous n’avez pas compris — mais parce que la conception est fautive. Votre propre incertitude est un détecteur de problèmes tout à fait convenable.
6. Pourquoi traiter un agent IA comme un junior
À mon avis, nous devrions toujours traiter un agent IA comme un junior à un poste donné — celui que nous lui faisons justement occuper.
À un junior, vous confiez un travail, vous lui faites expliquer comment il compte s’y prendre, puis vous relisez le résultat. Vous ne lui laissez pas les décisions difficiles à revenir en arrière et vous ne le laissez pas travailler une semaine sans regarder. En même temps, vous ne restez pas derrière son épaule à chaque ligne, sinon autant le faire vous-même.
C’est exactement ainsi que le travail avec un agent a fait ses preuves pour moi.
7. Résumé : trois règles pour développer avec des agents
Cette façon de faire est celle qui m’a le mieux réussi jusqu’ici. Je la résumerais en trois phrases : connaissez chaque décision d’architecture, faites-vous l’expliquer avant qu’il n’existe du code, et posez des questions sur tout ce que vous ne comprenez pas.
Vous voyez les choses autrement ? Écrivez à support@coden-app.com.