workflow.nsi.xyz Piloter une IA, publier un site
Menu
Banque de prompts

La promptothèque

Des prompts prêts à copier, classés par intention : créer, corriger, vérifier, déployer. Chacun est expliqué, aucun n'est magique.

Une bibliothèque de prompts, pas un grimoire

Tous les prompts de cette page ont été écrits avec la même méthode : un objectif, du contexte, des contraintes, un critère de réussite. Ils ne sont pas magiques et ne remplacent pas votre jugement — ils vous évitent de repartir d'une page blanche.

Étape 1

Choisir une intention

Filtrez par catégorie : démarrer, construire, corriger, vérifier, comprendre, publier, sécurité.

Étape 2

Adapter les crochets

Chaque prompt contient des parties entre crochets [comme ceci]. Remplacez-les par vos chemins, vos textes, vos attentes.

Étape 3

Tester et corriger

Envoyez le prompt, lisez la réponse, puis corrigez une phrase à la fois. Le prompt est un point de départ, pas un contrat.

Comment lire un prompt de la bibliothèque

Le bloc foncé est le texte à copier. En dessous, Pourquoi ça marcheexplique chaque choix, et À adapter dit ce qu'il faut changer pour votre projet. Lisez ces deux parties : c'est là que se trouve la méthode.

Les prompts

Démarrer

Premier contact avec un projet

Comprendre ce qu'on a sous les yeux avant de toucher à quoi que ce soit.

Fais le point sur ce projet, sans modifier aucun fichier :

1. liste les fichiers importants et explique le rôle de chacun en une phrase ;
2. indique comment lancer le site et comment le construire ;
3. signale ce qui te semble inachevé ou fragile.

Réponds en français, en langage simple.

Pourquoi ça marche

  • Aucune modification demandée : la réponse est un état des lieux, pas un chantier.
  • L'agent est obligé de lire les fichiers — il ne peut pas inventer un projet qu'il a sous les yeux.
  • La dernière phrase force un langage compréhensible par un débutant.

À adapter : Rien à adapter au départ. Plus tard, remplacez le point 3 par une question précise sur ce qui vous intéresse.

Démarrer

Cadrer avant de coder

Faire poser les bonnes questions avant d'écrire la première ligne.

Je veux ajouter [décrivez la fonctionnalité en une phrase], mais je ne sais pas par où commencer.

Avant de coder quoi que ce soit : pose-moi les questions nécessaires pour bien comprendre
ce que je veux, puis propose un plan en étapes courtes.

Ne crée et ne modifie aucun fichier pour l'instant.

Pourquoi ça marche

  • Les questions révèlent les zones floues du projet — celles qui auraient coûté des allers-retours.
  • Un plan en étapes courtes se teste et se corrige ; un gros bloc de code, non.
  • L'interdiction finale évite le classique « j'ai déjà commencé » avant la validation.

À adapter : Remplacez le crochet par votre besoin réel, même s'il vous paraît évident.

Démarrer

Initialiser un projet proprement

Partir sur des fondations saines : structure, README, .gitignore.

Propose la structure de base de ce projet et explique chaque dossier en une phrase.

Prépare ensuite :
- un README qui dit ce que fait le projet et comment le lancer ;
- un .gitignore qui protège .env, .env.*, node_modules/ et les fichiers de build ;
- un fichier d'exemple .env.example, sans aucune valeur réelle.

Avant d'agir, montre-moi la liste des fichiers que tu vas créer.

Pourquoi ça marche

  • Le README et l'exemple de configuration sont ce qu'on relit six mois plus tard.
  • Le .gitignore est demandé dès le départ : c'est la première protection contre les fuites de secrets.
  • La validation préalable garde la main sur la structure.

À adapter : Ajoutez les dossiers propres à votre projet si vous savez déjà où ils vont (images, données, contenus).

Construire

Ajouter une section

Obtenir exactement la section voulue, sans toucher au reste.

Ajoute une section [titre de la section] sous [emplacement précis].

Contexte : la page concernée est [chemin du fichier] ; les styles sont dans [dossier des styles] ;
les autres sections suivent [décrivez le modèle à imiter].

Contraintes : ne modifie que ce fichier (et la feuille de style si nécessaire). Réutilise les classes
existantes, n'ajoute aucune dépendance, ne touche pas au pied de page.

C'est réussi quand la section s'affiche à l'emplacement voulu, avec [contenu attendu], et que le reste
de la page est identique.

Décris d'abord ton plan, puis attends ma validation.

Pourquoi ça marche

  • Le contexte cite les fichiers : l'agent modifie le bon endroit du premier coup.
  • Les contraintes protègent le reste de la page — la régression est l'accident le plus fréquent.
  • Le critère de réussite est vérifiable : on ouvre la page et on regarde.

À adapter : Remplacez les crochets. Si vous ne connaissez pas un chemin, demandez-le d'abord à l'agent.

Construire

Changer le style d'un détail

Un petit ajustement visuel, sans effet de bord.

Sur [page ou composant précis], [décrivez le changement visuel : mettre le titre en deux lignes maximum,
espacer les cartes, agrandir le bouton…].

Ne touche ni aux couleurs générales, ni à la disposition des autres éléments.
Montre-moi la liste des fichiers modifiés et explique chaque changement en une phrase.

Pourquoi ça marche

  • Le périmètre est minuscule : l'agent ne peut pas réécrire la page entière.
  • Les interdictions évitent la refonte spontanée du design.
  • La liste des fichiers modifiés rend le changement vérifiable.

À adapter : Décrivez l'effet voulu, pas la technique : l'agent choisit les propriétés CSS.

Corriger

Corriger une erreur au démarrage

Transformer un message d'erreur en correction ciblée.

Le site ne démarre pas. Voici le message d'erreur complet :

[collez ici l'intégralité du message, sans le raccourcir]

Explique d'abord ce que dit cette erreur, en français simple.
Corrige ensuite uniquement la cause de cette erreur : ne refactorise rien d'autre et ne change pas le design.

Termine en indiquant la commande à relancer pour vérifier.

Pourquoi ça marche

  • Le message complet contient le fichier et la ligne : c'est l'information la plus utile du projet à ce moment-là.
  • « Uniquement la cause » empêche la refonte opportuniste.
  • La commande de vérification évite de croire sur parole.

À adapter : Ne coupez jamais le message d'erreur : la première ligne est souvent moins informative que la dernière.

Corriger

Réparer une régression

Quelque chose qui fonctionnait ne fonctionne plus.

La dernière modification a cassé [décrivez ce qui ne marche plus].
Avant, [décrivez le comportement attendu] ; maintenant, [décrivez ce qui se passe].

Compare avec l'état précédent si nécessaire, puis propose la correction la plus petite possible.

Ne touche pas aux fonctionnalités qui n'ont rien à voir avec ce problème.

Pourquoi ça marche

  • « Avant / maintenant » est la description la plus efficace d'un bug.
  • La correction minimale limite le risque de nouvelle régression.
  • La dernière ligne évite les « pendant que j'y étais ».

À adapter : Si vous avez un commit qui fonctionnait, dites-le : « l'état du commit [message ou numéro] fonctionnait ».

Corriger

Revenir à l'état qui marchait

Arrêter d'empiler les corrections et repartir d'une base saine.

La situation s'est dégradée après plusieurs modifications.

1. fais la liste des fichiers modifiés depuis le dernier commit ;
2. propose deux options : corriger, ou revenir au dernier état enregistré ;
3. explique ce qu'on perd dans chaque option.

N'applique rien avant que je choisisse.

Pourquoi ça marche

  • L'agent documente avant d'agir : on décide sur des faits, pas sur une impression.
  • Deux options chiffrées valent mieux qu'une correction imposée.
  • Le dernier état enregistré est un point de retour : c'est le rôle des commits.

À adapter : Si vous avez déjà committé, précisez-le : « le dernier commit est propre, je peux revenir dessus ».

Vérifier

Relire avant de livrer

Demander à l'agent de chercher ce qui ne va pas, pas de confirmer que tout va bien.

Relis le projet comme un relecteur exigeant, sans modifier de fichier.

Cherche en priorité :
- les liens et les images qui ne mènent nulle part ;
- les textes provisoires, fautes et incohérences ;
- les endroits qui casseraient sur un téléphone étroit ;
- les incohérences entre le README et le site.

Classe tes remarques par gravité, avec le fichier concerné pour chacune.

Pourquoi ça marche

  • « Cherche ce qui ne va pas » évite la complaisance d'un « tout est bon ».
  • La liste de critères guide la relecture au lieu de la laisser vague.
  • Le classement par gravité aide à choisir quoi corriger en premier.

À adapter : Ajoutez un critère propre à votre projet : orthographe des noms propres, mentions légales, crédits photo.

Vérifier

Vérifier l'affichage sur téléphone

Le rendu mobile est le premier point de rupture d'une page.

Analyse la mise en page de [page ou composant] pour un écran de téléphone (largeur 360 à 400 pixels).

Signale ce qui risque de poser problème : texte trop petit, éléments qui débordent, boutons trop
rapprochés, images trop lourdes, tables qui forcent un défilement horizontal.

Pour chaque problème, indique le fichier et la règle concernée, puis propose une correction.
N'applique rien encore.

Pourquoi ça marche

  • Une largeur cible précise rend la réponse concrète au lieu de théorique.
  • La liste de symptômes vient de vrais accidents, pas d'une checklist inventée.
  • Fichier et règle concernés : la correction est ciblée.

À adapter : Si la page est surtout lue sur ordinateur, gardez tout de même le contrôle : c'est là que les débordements se voient.

Comprendre

Faire expliquer un fichier

Comprendre ce qu'on a sous les yeux — et pouvoir le raconter.

Explique-moi [chemin du fichier] comme à un débutant, sans modifier de fichier.

Structure ta réponse en trois temps :
1. à quoi sert ce fichier dans le projet ;
2. ce qui se passe ligne par ligne, dans l'ordre ;
3. les deux ou trois endroits où il faudra faire attention en le modifiant.

Puis pose-moi deux questions pour vérifier que j'ai compris.

Pourquoi ça marche

  • L'explication structurée évite le pavé impossible à relire.
  • Le point 3 prépare les modifications futures.
  • Les questions de contrôle transforment la lecture en vrai apprentissage.

À adapter : Demandez la même chose pour une fonction précise plutôt qu'un fichier entier quand il est long.

Publier

Préparer le déploiement

Vérifier que tout est en ordre avant de mettre le site en ligne.

Le site est prêt à être publié. Fais la vérification complète, sans modifier de fichier :

1. le build passe-t-il, et qu'a-t-il produit comme dossier de sortie ?
2. reste-t-il des textes provisoires, des liens de test ou des images manquantes ?
3. y a-t-il un secret, une clé ou une donnée personnelle dans les fichiers suivis par Git ?
4. quelles variables d'environnement seront nécessaires en production ?

Donne la liste des points à corriger avant publication, classée par gravité.

Pourquoi ça marche

  • Un déploiement raté se voit tout de suite ; un secret publié, beaucoup plus tard.
  • Les quatre questions couvrent les échecs les plus fréquents.
  • La liste classée évite de tout corriger avant de publier ce qui est prêt.

À adapter : Lancez d'abord npm run build vous-même : l'agent ne doit pas être la seule source d'information.

Publier

Diagnostiquer un échec de build

Comprendre pourquoi la mise en ligne refuse de se faire.

Le build échoue. Voici le journal complet :

[collez ici le journal, de la première erreur jusqu'à la fin]

1. indique quelle est la PREMIÈRE erreur et recopie-la ;
2. explique sa cause probable en français simple ;
3. propose la correction minimale, puis la commande à lancer pour vérifier.

Si l'erreur cache un avertissement antérieur, remonte-le.

Pourquoi ça marche

  • La première erreur est la seule qui compte : les suivantes en découlent souvent.
  • Une correction minimale se vérifie facilement.
  • Le rappel de l'avertissement antérieur évite de traiter un symptôme.

À adapter : Si le build passe chez vous mais échoue en ligne, précisez-le : la différence est souvent la version de Node.

Sécurité

Auditer les secrets avant publication

Chercher les fuites avant qu'elles ne partent en ligne.

Audite ce dépôt à la recherche de secrets, sans modifier de fichier et sans afficher la valeur trouvée.

Cherche : les fichiers .env et équivalents suivis par Git, les clés d'API et jetons écrits en clair,
les mots de passe dans le code, les adresses ou numéros personnels, les captures d'écran montrant
des identifiants.

Pour chaque alerte : indique le fichier, la ligne et la nature du secret — jamais sa valeur.
Termine par la marche à suivre si un secret a déjà été poussé.

Pourquoi ça marche

  • L'agent relit tout le dépôt en quelques secondes : c'est un contrôle systématique, pas un espoir.
  • « Jamais sa valeur » évite d'afficher à nouveau le secret dans la conversation.
  • La marche à suivre rappelle que la rotation de la clé passe avant le nettoyage.

À adapter : À lancer avant chaque publication et à la fin de chaque séance de travail sur un projet qui manipule des clés.

Trois règles d'or

  1. On adapte, on ne colle pas à l'aveugle. Un prompt sans vos chemins de fichiers ni votre objectif précis reste vague. Les crochets sont là pour ça.
  2. On n'y met jamais de secret. Aucun prompt de cette bibliothèque ne contient de clé, de mot de passe ni de donnée personnelle — et les vôtres ne doivent pas en contenir non plus.
  3. On vérifie avant de remercier. Une réponse convaincante n'est pas une preuve. Ouvrez la page, lancez le serveur, lisez le résultat.

Votre prompt n'est pas dans la liste ?

Écrivez-le avec le constructeur : il assemble les quatre blocs et vérifie qu'aucun ne manque. Vous pouvez ensuite le déposer dans votre journal de prompts.

Outil

Constructeur de prompt

Objectif, contexte, contraintes, critère : assemblez et copiez.

Journal

Déposer un prompt

Gardez la trace de ce qui a été demandé à l'agent, étape par étape.

Vigilance

Sécurité

Ce qu'on ne met jamais dans un prompt, et la procédure en cas de fuite.

Quand ça coince

Dépannage

Les erreurs les plus fréquentes, traduites en actions.