Créer un workflow IA pour développer sans perdre le contrôle

Dans mon workflow, l’agent reçoit un objectif limité, les chemins concernés et la preuve attendue. Le vibecoding peut produire un premier écran à partir d’un prompt. Pour livrer un site ou un SaaS, il faut aussi cadrer le produit, préparer le dépôt, découper le travail et vérifier chaque résultat. Voici une méthode de A à Z, sans supposer qu’il faut copier une stack particulière.

Ce que vous allez apprendre

Vous allez suivre deux niveaux de travail. D’abord, une boucle courte pour chaque modification : cadrer, lire le contexte, planifier, changer peu de fichiers, puis vérifier. Ensuite, un parcours de projet complet : idée, prototype, règles et skills, développement par tranches, tests, mise en ligne et amélioration. La même boucle courte se répète à chaque étape du projet.

Prérequis

Choisissez une tâche réversible et déjà comprise, par exemple ajouter un état vide, corriger une validation ou améliorer un test. Vous devez disposer d’un dépôt versionné, d’une commande de contrôle connue et d’une personne qui peut valider les règles métier. Ne donnez pas à l’agent des secrets, des données de production ou des permissions d’administration pour gagner du temps.

Étape 1 : écrire un contrat de tâche

Définissez le résultat observable, les fichiers autorisés, les fichiers interdits et le test attendu. Exemple : « ajouter un message accessible pour une liste vide dans ce composant ; ne modifier ni l’API, ni les styles globaux ; exécuter le test ciblé ». Une tâche sans frontière donne à l’agent la liberté de résoudre un problème différent de celui que vous vouliez traiter.

Vérification : une autre personne doit pouvoir dire si le résultat est atteint sans relire toute la conversation. Si elle ne le peut pas, réduisez ou précisez le contrat.

Étape 2 : fournir le contexte minimal

Partagez le fichier concerné, un test voisin et les conventions locales nécessaires. Demandez à l’agent de résumer le rôle du module et les dépendances directes avant de proposer une modification. Les outils d’agent peuvent explorer, modifier et lancer des commandes ; ce pouvoir doit rester limité par le périmètre, pas seulement par une phrase générale comme « sois prudent ».

Vérification : contrôlez dans le dépôt les chemins et symboles cités. Une erreur de contexte à ce stade doit être corrigée avant toute écriture.

Étape 3 : faire approuver un plan avant le diff

Demandez une liste ordonnée : fichiers à lire, changements proposés, risques et commande de contrôle. Le plan est le bon moment pour retirer une dépendance inutile, séparer une migration ou relever une règle métier inconnue. N’acceptez pas l’argument « c’est plus simple » lorsqu’il élargit la zone de changement sans preuve.

Vérification : chaque fichier du plan doit avoir une raison explicite. Les fichiers de sécurité, de déploiement, de secrets et de migration exigent une tâche spécialisée distincte.

Étape 4 : appliquer un petit changement et relire le diff

Laissez l’agent produire un diff limité. Relisez les valeurs par défaut, conditions, appels externes, suppressions et imports. Consultez le diff Git, qui représente l’état réel des fichiers, plutôt que de vous fier au résumé de l’agent. Si une ligne est incomprise, demandez son rôle et le cas qui échouerait sans elle.

Vérification : recherchez les modifications hors périmètre. Si elles existent, arrêtez le lot et revenez au contrat ; ne mélangez pas une correction légitime avec des changements imprévus.

Étape 5 : exécuter la preuve et consigner l’état

Lancez d’abord le test le plus ciblé, puis le contrôle plus large requis par le projet. Gardez la commande et le résultat. Une affirmation de l’agent selon laquelle le code est « vérifié » ne remplace pas la sortie d’un outil réel. Si le test échoue, isolez le premier changement causal avant de demander une autre proposition.

Vérification : notez ce qui est prouvé, ce qui reste à faire et ce qui demande une revue humaine. Ce journal permet à la tâche suivante de reprendre sans reconstruire les hypothèses.

Du brief à un site ou un SaaS : le parcours complet

Les cinq étapes précédentes forment la boucle de travail à répéter pour chaque changement. Elles ne remplacent pas le parcours produit. Pour construire un site ou un SaaS, avancez ensuite par les étapes suivantes et gardez une validation entre chaque étape risquée.

1. Partir d’un problème, pas d’un prompt

Écrivez une fiche d’une page avant de demander du code : qui va utiliser le produit, quel problème revient, quelle action doit devenir plus simple, et comment vous saurez que la première version aide réellement. Ajoutez les contraintes connues : appareil, données à manipuler, règles métier, confidentialité, délai, budget à vérifier et personne qui maintiendra le projet.

Séparez le nécessaire du souhaitable. Pour un site vitrine, le premier parcours peut être « comprendre l’offre, trouver une preuve, contacter l’entreprise ». Pour un SaaS, choisissez un seul parcours métier, par exemple « créer un compte, enregistrer un élément, le retrouver et le modifier ». Les autres fonctions vont dans une liste d’attente, pas dans le premier prompt.

Livrable : un objectif, un parcours utilisateur principal, trois à cinq critères d’acceptation, les éléments explicitement hors périmètre et les questions qui nécessitent une décision humaine.

2. Choisir les composants après le parcours

Ne commencez pas par copier la liste d’outils de quelqu’un d’autre. Pour chaque besoin, décidez si vous avez réellement besoin d’un frontend, d’une API, d’une base de données, d’une authentification, d’un paiement, d’e-mails, d’un hébergement, d’un suivi d’erreurs ou d’une intégration externe. Notez une option principale, une solution de repli et la raison du choix. Vérifiez la documentation, la maintenance, les possibilités d’export, les conditions et les coûts en vigueur avant de vous engager.

Un site éditorial peut n’avoir besoin d’aucune base de données applicative. Un SaaS qui stocke des comptes et des données clients doit, lui, décider tôt qui peut lire ou modifier chaque donnée, comment restaurer une sauvegarde et comment traiter une panne. Ne demandez pas à l’agent de trancher seul ces choix produit, juridiques ou de sécurité.

Vérification : vous pouvez expliquer le rôle de chaque composant et ce qui casse si vous le retirez. Si deux outils font le même travail sans raison de les garder tous les deux, simplifiez.

3. Préparer le dépôt et ses règles

Avant la première modification, confirmez le vrai dossier du projet, son état Git, sa branche, ses instructions locales et ses commandes réelles de test et de lancement. Lisez le code concerné et ses tests voisins. Ne partez pas d’un dépôt vide si le projet existe déjà.

Ajoutez ensuite des règles de projet courtes : description de l’application, structure utile, commandes vérifiées, conventions, fichiers protégés, exigences de sécurité et actions qui demandent une autorisation humaine. Gardez-les dans le format que l’agent choisi sait réellement charger. Les conventions diffèrent selon les outils :

Codex lit AGENTS.md pour charger les règles du dépôt.[3]
GitHub Copilot prend en charge ses fichiers d’instructions et AGENTS.md.[5]
Claude Code utilise CLAUDE.md pour le contexte persistant.[7]
Claude Code documente aussi les skills SKILL.md pour les procédures réutilisables.[1]

Vérifiez la documentation actuelle et l’instruction réellement chargée au lieu de supposer qu’un fichier est universel.

Ne mettez pas tout dans un énorme fichier de règles. Gardez-y ce qui doit être connu à chaque session; déplacez les procédures longues vers une skill ou un document de référence chargé au besoin.

Vérification : demandez à l’agent de nommer les instructions et commandes qu’il a trouvées, puis comparez sa réponse au dépôt. Corrigez les règles avant de lui confier une tâche importante.

4. Distinguer règles, prompts, skills, agents et outils

Ces éléments se complètent, mais n’ont pas la même fonction. Les formats, les fichiers chargés et les façons d’appeler une procédure varient selon l’outil.[1][3]

Élément	À quoi il sert	Exemple de contenu
Règle de projet	Contrainte stable à respecter dans les tâches du dépôt	Commande de test, conventions, fichiers intouchables
Prompt de tâche	Contrat ponctuel pour le changement demandé maintenant	Objectif, fichiers autorisés, critères de réussite
Skill	Procédure réutilisable appelée pour une famille de tâches	Revue de code, démarrage d’un projet, contrôle d’une release
Agent spécialisé	Travailleur distinct avec une mission et des accès définis	Exploration en lecture seule, implémentation, revue sécurité
Outil ou connecteur	Capacité technique accordée à l’agent	Lire le dépôt, lancer un test, consulter une API autorisée

Créez une skill quand une procédure revient : précisez son déclencheur, les étapes, les limites et le résultat attendu. Claude Code et Codex documentent les skills comme des procédures réutilisables; le contenu d’une skill Claude Code ne se charge que lorsqu’elle est utilisée.[1][4]

Un sous-agent peut servir à isoler une recherche, une implémentation ou une revue. Dans Claude Code, chaque sous-agent a son propre contexte et peut recevoir un accès limité aux outils; ses requêtes comptent dans les limites d’utilisation de la conversation.[2] Les détails changent selon le produit. Dans tous les cas, déléguez seulement si la séparation apporte quelque chose, puis vérifiez le résultat vous-même.

N’ajoutez pas un connecteur ou un serveur parce qu’il est à la mode. Un outil connecté peut exposer des données ou déclencher des actions. Limitez les accès au besoin réel et vérifiez les permissions avant usage.

5. Concevoir un premier parcours visible

Dessinez les écrans ou décrivez-les avant de générer les composants : entrée, état vide, chargement, erreur, succès, navigation et version mobile. Pour une fonctionnalité de SaaS, précisez aussi l’état des données, les erreurs possibles, les rôles et les règles d’accès. Une maquette, même simple, évite de demander à l’agent d’inventer le produit pendant qu’il code.

Faites relire le parcours par une personne qui représente l’utilisateur visé. Modifiez le brief si elle ne sait pas quoi faire ou si une étape suppose une décision non documentée. La validation du produit ne se délègue pas à un modèle.

6. Construire une tranche complète à la fois

Découpez le parcours en morceaux qui peuvent être compris et vérifiés séparément. Une tranche utile traverse le chemin nécessaire à l’utilisateur : interface, validation côté serveur, lecture ou écriture des données, état de retour et tests. Pour un site, une première tranche peut être une page complète avec navigation, formulaire et confirmations. Pour un SaaS, elle peut couvrir un seul cas métier après authentification, sans simuler une facturation réelle.

Faites travailler chaque outil à sa place : le gestionnaire de tâches conserve le brief et l’état, l’agent de code prépare un diff, le terminal exécute les contrôles, Git montre les changements et le navigateur sert à vérifier la documentation ou le parcours. C’est une organisation possible, pas une stack à copier.

Si vous déléguez, gardez des missions distinctes : le coordinateur fixe le périmètre et intègre; le chercheur reste en lecture seule et remet ses sources; l’implémenteur ne touche qu’aux fichiers autorisés; le reviewer compare le diff aux critères sans corriger lui-même. En solo, vous pouvez demander ces rôles au même agent dans des étapes séparées.

Attribuez un propriétaire à chaque tranche et indiquez les chemins autorisés. Ne demandez pas à trois agents de modifier les mêmes fichiers. Parallélisez seulement les travaux indépendants, par exemple une recherche documentaire en lecture seule pendant qu’un autre agent travaille sur une zone isolée. Les tâches qui touchent une même base, un même fichier ou des artefacts partagés restent séquentielles. Le coordinateur suit les frontières, rassemble les preuves et intègre après revue; il ne traite pas un résumé d’agent comme une preuve.

7. Donner un prompt de travail exploitable

Un prompt utile décrit le résultat, le contexte à lire, les limites et la façon de prouver que le changement fonctionne. Copiez ce squelette et remplissez-le pour une seule tâche :

Objectif : [changement observable pour l’utilisateur]

Contexte à lire : [instructions, fichiers, tests, documentation]

Fichiers autorisés : [chemins exacts]
Hors périmètre : [fichiers, données, décisions ou actions interdites]

Critères d’acceptation :
- [comportement attendu]
- [cas d’erreur ou limite]

Sécurité : n’expose aucun secret; n’utilise pas de données de production;
ne publie, ne déploie et ne modifie aucun service externe sans autorisation.

Avant d’écrire : inspecte l’existant et signale les décisions manquantes.
Après le changement : lance [commande vérifiée], relis le diff et rapporte
les fichiers touchés, la sortie réelle des commandes et les limites restantes.

Si l’agent pose une question qui change le produit ou l’accès aux données, répondez avant de poursuivre. Si les faits manquent, demandez une recherche ou marquez l’incertitude; ne laissez pas l’agent remplacer une absence d’information par une supposition.

8. Tester et relire ce qui a été produit

Écrivez ou définissez les cas qui prouvent le parcours avant de considérer la tranche finie. Utilisez les tests unitaires pour la logique isolée, les tests d’intégration pour les frontières entre modules et un parcours navigateur pour les interactions importantes. Pour l’authentification, les permissions, les paiements et les données clients, ajoutez une revue dédiée et vérifiez les cas de refus, d’erreur, de doublon et de reprise.

Lisez le diff complet, y compris les fichiers inattendus, les valeurs par défaut, les appels externes et les dépendances. Relancez vous-même les commandes importantes dans le dépôt. Le compte rendu d’un agent dit ce qu’il affirme avoir fait; le diff et la sortie des tests permettent de le vérifier.

Porte de sortie : chaque critère d’acceptation a une preuve, une limite ou une décision restante. Ne présentez pas comme réussi un test qui n’a pas été exécuté.

9. Préparer la mise en ligne puis observer

Commencez par un environnement de prévisualisation ou de test. Vérifiez les variables d’environnement sans les imprimer, les routes, l’authentification, les erreurs, l’affichage mobile et les opérations importantes. Pour Next.js, la checklist officielle recommande de lancer next build avant la production puis next start pour observer une exécution proche de la production; elle couvre aussi des points de sécurité, d’erreur et de performance.[6] Adaptez les contrôles au framework réellement utilisé.

Avant la production, prévoyez qui peut autoriser la mise en ligne, comment revenir en arrière et où regarder si une erreur apparaît. Après déploiement, testez le parcours réel avec des données non sensibles et surveillez les erreurs. Une page qui s’ouvre n’est pas la preuve que l’inscription, le paiement ou la récupération de données fonctionne.

10. Transformer les retours en méthode

Après une tranche ou une release, notez les bugs évités, les hypothèses fausses, le temps perdu à retrouver le contexte et les erreurs répétées de l’agent. Si une règle se répète, ajoutez-la au niveau projet. Si une procédure revient, écrivez une skill. Si un prompt particulier a aidé une tâche unique, gardez-le comme modèle plutôt que de le transformer immédiatement en règle universelle.

Gardez les documents courts et réexaminez-les quand le dépôt, les outils ou leurs formats changent. Une règle obsolète peut faire plus de dégâts qu’une règle absente.

Exemple de fiche de passage entre deux étapes

Une fiche courte réduit les malentendus. Elle peut contenir : l’objectif, le commit ou l’état de départ, les fichiers effectivement lus, le diff attendu, le résultat du test ciblé et une question non résolue. Par exemple : « Le composant affiche désormais un état vide ; le test X passe ; le comportement mobile a été observé ; la traduction allemande n’est pas dans le périmètre. » Cette précision évite qu’un agent suivant prenne une hypothèse pour une tâche terminée.

Ne transformez pas cette fiche en compte rendu interminable. Son rôle est de rendre une décision vérifiable et de signaler les limites. Si une tâche implique plusieurs personnes, associez aussi un propriétaire à l’approbation finale. L’agent peut préparer les éléments, mais ne peut pas être seul juge de son propre résultat.

Adapter le niveau d’autonomie au risque

Le même workflow ne convient pas à tous les changements. Pour une correction de texte, la revue du diff peut suffire. Pour une règle d’autorisation, une migration ou un paiement, ajoutez un validateur humain, un environnement isolé et un plan de retour arrière. Cette gradation est plus utile qu’une interdiction générale de l’autonomie : elle laisse les tâches simples avancer tout en protégeant les frontières sensibles.

Définissez aussi ce que l’agent n’a pas le droit de faire. Il peut lire des fichiers, proposer un patch et lancer un test ciblé ; il ne peut pas pousser, déployer, changer les secrets ou supprimer des données sans une autorisation distincte. Les permissions explicites restent valables même quand la tâche paraît urgente.

Problèmes fréquents et solutions

L’agent enchaîne trop de modifications

Limitez la consigne à une étape et imposez une validation entre les étapes. Un workflow n’est pas plus rapide quand il accumule des diffs impossibles à diagnostiquer.

Les tests sont générés mais ne testent pas le besoin

Fournissez les scénarios valides, invalides et limites. Les tests suggérés doivent être relus et complétés à partir du contrat, surtout pour les règles métier.

Une décision produit est ambiguë

Arrêtez le workflow et obtenez la décision. L’agent peut proposer des options, mais ne doit pas choisir une règle commerciale, légale ou de permission par défaut.

FAQ

Un workflow IA remplace-t-il la revue de code ?

Non. Il rend la revue plus structurée en produisant des diffs plus petits et des preuves explicites.

Faut-il automatiser les commandes ?

Seulement quand les permissions et l’impact sont maîtrisés. Les commandes qui écrivent dans une base ou déploient exigent des garde-fous séparés.

Quelle tâche choisir pour commencer ?

Une correction locale avec un test connu. Évitez les migrations, refontes et secrets pour le premier workflow.

Comment mesurer l’amélioration ?

Mesurez le temps de revue, les régressions détectées, les tests réellement exécutés et la taille des diffs, pas seulement le nombre de tâches produites.

Que faire si le contexte manque ?

Demandez une lecture ou une question précise, puis ajoutez seulement le fichier indispensable. Un contexte maximal n’est pas automatiquement un contexte meilleur.

Conclusion

Pour le prochain projet, choisissez un parcours utilisateur et faites-le passer par toute la boucle : cadrage, règles, tâches limitées, diff relu et preuve de test. Quand ce parcours fonctionne dans l’environnement prévu, attaquez le suivant. Si un point reste incertain, résolvez-le avant d’ajouter des fonctions.

Limites

Les fichiers de contexte, les permissions et le chargement des skills varient selon l’outil et sa version. Ce workflow décrit une méthode de travail, pas une garantie de qualité ou de sécurité.

Sources

Sources officielles revérifiées le 19 octobre 2026. Les commandes et exemples de ce tutoriel décrivent un workflow ; aucun projet complet, déploiement ou test de production n’a été exécuté pour l’article.