Le workflow

Pourquoi un workflow ?

Un workflow, c'est la chaîne d'habitudes qui transforme une idée en site en ligne : quoi faire d'abord, quoi vérifier, quand s'arrêter, quand recommencer. Sans lui, on demande tout, tout de suite, on obtient un projet qui « marche » deux minutes puis qu'on ne sait plus réparer.

Avec lui, l'IA devient ce qu'elle est vraiment : un exécutant rapide et infatigable, sous la direction d'un humain qui décide et qui vérifie. Le travail change de nature — moins de frappe, plus de réflexion — mais il ne disparaît jamais.

La boucle : cinq temps, à chaque demande

Chaque fois que vous demandez quelque chose à l'agent, le même cycle recommence. Il est court — quelques minutes — et c'est lui qui distingue un projet maîtrisé d'un enchaînement de hasards.

Le parcours du projet : cinq étapes

La boucle se répète à l'intérieur d'un parcours plus large : les cinq étapes qui font passer d'une page blanche à une adresse publique. Chacune a un critère de sortie : tant qu'il n'est pas rempli, on ne passe pas à la suivante.

Qui fait quoi

Répartir les rôles, c'est se protéger de la déception : on ne reproche pas à l'agent ce qu'il n'a jamais su faire. Voici la frontière, en deux colonnes.

Un exemple complet, du premier prompt à l'URL

Voici comment la boucle et le parcours s'enchaînent sur un vrai cas : une page d'accueil sur les abeilles. Tout ce qui suit, vous pouvez le refaire.

1. Décrire

   Cadrer le projet avant de coder

   Tu vas m'aider à construire une page d'accueil sur les abeilles. Avant de coder : pose-moi 5 questions pour préciser le sujet, le public et le style. Ne crée aucun fichier.

   L'agent pose des questions, l'élève répond. À la fin, on sait quoi construire — et on a déjà évité deux malentendus.

   💡 Un projet qui commence par des questions coûte moins cher qu'un projet qui commence par du code.

2. Décrire

   Demander une seule chose à la fois

   Crée une page d'accueil avec : un titre, un paragraphe de présentation, une image d'abeille et un bouton « En savoir plus ». Explique-moi chaque fichier que tu crées.

   Les fichiers sont créés, et l'explication permet de comprendre où vit quoi.

3. Tester

   Lancer et regarder

   Comment je lance le site pour le voir dans mon navigateur ?

   Une erreur apparaît au démarrage. L'élève copie le message d'erreur dans la conversation — c'est la meilleure façon de demander de l'aide.

4. Corriger

   Corriger avec le message d'erreur, pas avec des suppositions

   Voici l'erreur complète quand je lance le serveur : [message]. Explique ce qu'elle veut dire, puis corrige.

   L'agent explique, corrige, le serveur démarre. La page s'affiche.

   💡 Coller l'erreur ENTIÈRE fait gagner des dizaines de minutes : elle contient le fichier et la ligne.

5. Livrer

   Enregistrer un premier point de retour

   Prépare les commandes Git pour enregistrer cette première version, et explique chaque commande.

   Premier commit : la page d'accueil existe et l'historique commence. C'est le point de retour en cas de bêtise.

   💡 Une étape terminée = un commit. Ce n'est pas du rangement, c'est une assurance.

6. Tester

   Améliorer… puis casser

   Ajoute une section « Pourquoi les abeilles sont essentielles » et change les couleurs.

   La nouvelle section s'affiche, mais le CSS casse l'ancienne. C'est normal : chaque modification peut casser ce qui marchait.

   💡 Le réflexe est de re-tester TOUTE la page, pas seulement la nouveauté.

7. Corriger

   Revenir en arrière plutôt que s'enliser

   Le bouton chevauche le titre sur téléphone. Compare avec la version du commit précédent si nécessaire.

   Soit l'agent corrige et on vérifie, soit on restaure le dernier commit (git restore) et on repart d'une base saine. Dans les deux cas, on ne reste pas bloqué.

   💡 Un commit qui fonctionne vaut mieux qu'une heure de corrections empilées.

8. Livrer

   Publier et partager

   Explique-moi les étapes pour publier ce projet sur Cloudflare Pages, et ce que je dois vérifier avant.

   Le site est déployé à une URL publique. On vérifie qu'elle répond, puis on envoie le lien.

   💡 Avant de publier : la checklist de la section Sécurité.

9. Livrer

   Journaliser les prompts

   Aide-moi à résumer les prompts qui ont mené à cette version.

   Les prompts sont déposés sur le site du projet avec le code anonyme. C'est la trace du travail : ce que l'élève a demandé, compris et corrigé.

   💡 Le journal des prompts raconte la vraie histoire du projet — bien mieux qu'un fichier final.

Les règles du jeu

1. Une demande = un objectif. Deux objectifs dans un même prompt, c'est deux fois plus de chances de tout casser.
2. Toujours lire avant de valider : ce que vous acceptez sans lire devient votre responsabilité.
3. Tester après chaque modification, même petite : le rendu, pas l'impression.
4. Committer avant les grosses demandes : un commit est un point de retour.
5. Journaliser les prompts : sans trace, le travail devient invisible.
6. Ne jamais publier un secret : le dépôt, les prompts et les captures ne sont pas des coffres-forts.

Quatre idées fausses à jeter

Quatre prompts à réutiliser

Ils ne sont pas magiques : ils sont précis. Copiez-les, puis adaptez le sujet — jamais l'inverse.

Avant de coder, pose-moi les questions nécessaires pour bien comprendre ce que je veux. Ne crée aucun fichier pour l'instant.

Explique-moi ce que tu viens de faire, fichier par fichier, comme si je débutais. Signale ce que je devrais vérifier moi-même.

Voici le comportement attendu : […]. Voici ce qui se passe : […]. Voici le message d'erreur complet : […]. Propose une correction et explique-la.

La dernière modification a cassé […]. Montre-moi comment revenir au dernier état qui fonctionnait, sans perdre le reste.

La promptothèque complète — classée par intention, avec les explications — vit dans la section Promptothèque.

Pour aller plus loin