Itérer progressivement

Le développement itératif avec l’IA

La tentation est grande de tout demander en un seul prompt. Mais avec grok-build-0.1 comme avec tout modèle de code, l’approche itérative donne de meilleurs résultats. Vous construisez progressivement, en validant chaque étape avant de passer à la suivante.

Pourquoi itérer ?

Les limites du prompt unique

Un prompt qui demande de créer un système complet d’authentification avec JWT, refresh tokens, middleware, routes, tests et documentation va produire un résultat volumineux, difficile à vérifier, et probablement incomplet sur certains aspects.

L’avantage de l’itération

Découper la même demande en étapes change trois choses, et elles se renforcent mutuellement. Vous vérifiez chaque étape avant de continuer : une erreur dans les fondations — un mauvais choix de structure de données, une signature de fonction bancale — est corrigée quand elle ne coûte que cinq minutes, au lieu de se propager dans tout le code généré ensuite. Vous ajustez le cap en cours de route : si la première itération révèle un problème d’architecture, vous le traitez avant d’aller plus loin, exactement comme dans une revue de conception. Et vous gardez le modèle focalisé : un prompt court et ciblé produit systématiquement de meilleures réponses qu’une spécification-fleuve où le modèle doit arbitrer seul entre dix exigences — chaque tour ne lui pose qu’une question, et il y répond bien.

Stratégie d’itération

Étape 1 : La fondation

Commencez par la structure de base, sans les détails :

“Crée le schéma de la table users avec Drizzle ORM : id, email, passwordHash, createdAt. Ajoute les types TypeScript correspondants.”

Validez, testez, puis passez à la suite.

Étape 2 : La logique métier

Ajoutez la logique sur la fondation validée :

“Maintenant, crée le service d’inscription dans @src/services/auth.ts. Il doit hasher le mot de passe avec bcrypt, vérifier que l’email n’existe pas déjà, et insérer l’utilisateur. Utilise le schéma @src/db/schema.ts qu’on vient de créer.”

Étape 3 : Le raffinement

Une fois la logique en place, affinez :

“Ajoute la validation d’entrée avec Zod sur le service d’inscription. L’email doit être valide, le mot de passe doit avoir au moins 8 caractères avec une majuscule et un chiffre.”

Étape 4 : Les cas limites

Enfin, traitez les edge cases :

“Que se passe-t-il si la connexion à la base de données échoue pendant l’inscription ? Ajoute une gestion d’erreur appropriée avec des messages utilisateur clairs.”

Référencer les échecs précédents

L’itération inclut aussi l’apprentissage des erreurs. Si une suggestion du modèle ne fonctionne pas, dites-le explicitement :

“La solution précédente ne fonctionne pas parce que TypeORM ne supporte pas cette syntaxe dans la version 0.3. L’erreur est : [coller l’erreur]. Propose une alternative compatible.”

Le modèle utilise cette information pour éviter de reproduire la même erreur et pour mieux comprendre votre environnement.

Ajuster le contexte en cours de route

L’itération a un bénéfice moins visible mais tout aussi précieux : le contexte s’affine au fil des tours. Vous découvrez en cours de développement qu’un fichier de configuration pilote le comportement que vous modifiez — ajoutez-le au tour suivant. Une contrainte que vous n’aviez pas identifiée émerge — le middleware doit aussi gérer les clés API, pas seulement les JWT — précisez-la au moment où elle devient pertinente. Une hypothèse initiale se révèle fausse — corrigez-la explicitement plutôt que de laisser le modèle continuer à construire dessus. En un seul prompt monolithique, toutes ces découvertes seraient arrivées trop tard.

“En fait, le middleware d’authentification doit aussi gérer les clés API en plus des JWT. Voici le format de clé actuel dans @src/config/api-keys.ts.”

Quand tout demander en un coup

L’itération n’est pas toujours nécessaire. Pour les tâches simples et bien définies, un prompt unique suffit :

• Renommer une variable dans tout un fichier
• Convertir un callback en async/await
• Ajouter des types TypeScript à une fonction JavaScript existante
• Générer un test unitaire pour une fonction pure

Points clés à retenir

• Découper les demandes complexes en étapes validées progressivement
• Chaque itération construit sur la précédente après vérification
• Référencer les erreurs précédentes pour éviter les répétitions
• Ajuster le contexte au fur et à mesure des découvertes
• Les tâches simples ne nécessitent pas d’itération