Création de sites internet · Publié le 14 octobre 2026 · Par Sophian Boughali · 13 min de lecture

30 prompts à copier-coller pour créer un site en vibe coding (du brief à la mise en ligne)

Réponse rapide. Un bon prompt de vibe coding contient cinq éléments : le contexte, un seul objectif, des critères de réussite vérifiables, ce qu’il ne faut pas toucher, et le format de réponse attendu. Les 30 prompts ci-dessous couvrent tout le projet : cadrage, design, construction, contenu, débogage, sécurité et mise en ligne. Ils fonctionnent avec Replit, Lovable, Bolt, Cursor et Claude Code.

En bref

• Un prompt long et précis revient souvent moins cher qu’un prompt court : il évite les allers-retours.
• Fais toujours poser des questions à l’IA avant de la laisser construire.
• Une demande, un test. Ne groupe jamais plusieurs modifications dans le même message.
• Remplace les éléments entre crochets par tes informations. Tout le reste se copie tel quel.
• Ces prompts sont originaux. Ils s’appuient sur les pratiques qui reviennent le plus souvent dans les guides et les communautés consacrés au vibe coding : cadrer par écrit, découper en petites étapes, tenir un journal du projet.

Qu’est-ce qui fait un bon prompt de vibe coding ?

Un bon prompt enlève à l’IA toute raison de deviner. Chaque fois qu’elle devine, elle ajoute quelque chose que tu n’as pas demandé ou elle modifie quelque chose qui marchait.

Quel prompt utiliser à quel moment ?

Si tu débutes, lis d’abord notre tutoriel pour créer un site avec Replit : il montre l’enchaînement complet. Cette page sert ensuite de boîte à outils.

Phase 1 : cadrer le projet (prompts 1 à 5)

1. Clarifier ton idée

À utiliser dans un assistant (ChatGPT, Claude, Gemini, Mistral Vibe), avant même d’ouvrir ton outil de vibe coding. Si tu hésites entre eux, vois quelle IA choisir.

Je veux créer un site pour [activité] à destination de [public].
Mon objectif principal : [ex. obtenir des demandes de devis].

Joue le rôle d'un chef de projet web expérimenté.
Pose-moi une question à la fois, dix questions au maximum, pour clarifier :
le public, l'objectif, les pages, les contenus dont je dispose,
et ce que je ne veux pas faire dans cette première version.
Ne propose aucune solution avant d'avoir toutes mes réponses.

2. Transformer tes réponses en brief

À partir de mes réponses, rédige un brief d'une page avec ces rubriques :
1. Objectif du site et public visé
2. Liste des pages, avec le rôle de chacune en une phrase
3. Fonctions indispensables pour la première version
4. Fonctions volontairement exclues pour l'instant
5. Ton, style visuel et couleurs
6. Contraintes : mobile, référencement, mentions légales, données personnelles
7. Questions encore ouvertes

Écris en langage simple, sans jargon technique.

3. Obtenir un plan avant toute construction

Voici mon brief : [colle ton brief].

Avant d'écrire la moindre ligne de code :
1. Pose-moi les questions nécessaires pour lever les ambiguïtés.
2. Propose un plan en étapes courtes, de la plus simple à la plus complexe.
3. Pour chaque étape, indique comment je pourrai vérifier qu'elle est réussie.
4. Signale les risques de sécurité, de coût ou de référencement.

Ne construis rien tant que je n'ai pas validé le plan.

4. Créer le fichier de règles du projet

Chaque outil a le sien : replit.md pour Replit, CLAUDE.md pour Claude Code, AGENTS.md pour d’autres agents.

Crée le fichier de règles de ce projet avec les sections suivantes :

Contexte : [activité, objectif du site].
Règles de travail :
- Ne modifie que ce qui est demandé.
- Avant toute modification importante, explique ce que tu vas faire en 3 lignes.
- N'invente jamais de chiffres, d'avis clients ni de coordonnées.
- Explique-moi tes choix en langage simple.
Contraintes techniques :
- Site lisible sur mobile.
- Contenu présent dans le HTML sans JavaScript.
- Aucune clé ni mot de passe dans le code.

Relis ce fichier au début de chaque session.

5. Choisir la solution la plus simple

Pour ce projet, propose-moi l'architecture la plus simple possible.
Je ne suis pas développeur : privilégie ce qui est standard, bien documenté
et facile à faire reprendre par quelqu'un d'autre.
Explique ton choix en cinq lignes, et dis-moi ce que tu écartes et pourquoi.

Phase 2 : définir le design (prompts 6 à 9)

6. Fixer une direction visuelle

Propose-moi trois directions visuelles différentes pour ce site.
Pour chacune : une palette de 4 couleurs avec leurs codes, deux polices,
le style des images et l'ambiance générale en une phrase.
Mon activité : [activité]. Mon public : [public].
Sites que j'aime : [adresses] parce que [raisons].
Ne construis rien : je choisis d'abord.

7. Partir d’une capture d’écran

Joins l’image à ton message. La plupart des outils savent la lire.

Voici la capture d'un site dont j'aime la mise en page.
Inspire-toi de sa structure (organisation des blocs, espacement, hiérarchie)
sans copier ses textes, ses images ni son logo.
Applique mes couleurs : [codes] et mes polices : [noms].
Construis uniquement la section du haut de la page d'accueil.

8. Garantir la cohérence visuelle

Regroupe les couleurs, les tailles de texte, les espacements et les arrondis
dans un seul endroit du projet, sous forme de variables.
Remplace ensuite toutes les valeurs écrites en dur par ces variables.
Ne change rien à l'apparence actuelle : le site doit être identique avant et après.
Liste-moi les variables créées.

9. Corriger l’affichage sur mobile

Vérifie chaque page en largeur 375 pixels.
Liste tout ce qui dépasse de l'écran, se chevauche ou devient illisible.
Propose les corrections, attends ma validation, puis corrige une page à la fois.
Ne modifie pas l'affichage sur ordinateur.

Phase 3 : construire (prompts 10 à 14)

10. Lancer la première étape, et seulement elle

Le plan est validé. Construis uniquement l'étape 1 : [description].

Critères de réussite :
- [critère 1]
- [critère 2]

Ne fais rien d'autre. Quand c'est terminé, dis-moi précisément ce que je dois tester.

11. Ajouter une page

Ajoute une page [nom] accessible depuis le menu.
Contenu : [colle ton texte].
Utilise exactement les mêmes styles que la page [page de référence].
Ne modifie aucune page existante, à part le menu.
Critère de réussite : le lien du menu fonctionne sur ordinateur et sur mobile.

12. Créer un bloc réutilisable

Crée un bloc réutilisable « [ex. carte de témoignage] » avec : [liste des éléments].
Utilise-le sur la page [page] pour afficher les éléments suivants : [contenus].
Je veux pouvoir ajouter un nouvel élément en modifiant un seul endroit.
Explique-moi où et comment le faire.

13. Ajouter un formulaire de contact

Ajoute un formulaire de contact sur la page Contact : nom, e-mail, téléphone, message.
Je veux recevoir chaque demande par e-mail à l'adresse [adresse].
Propose la solution la plus simple et explique ce que je dois configurer.
Protège le formulaire contre les envois vides et les envois en rafale.
Affiche un message de confirmation clair après l'envoi.
Ajoute sous le formulaire une mention d'information sur l'usage des données,
avec un lien vers la politique de confidentialité.

14. Faire expliquer avant de faire

À utiliser pour toute modification qui te paraît risquée.

Je veux [modification].
Avant d'agir, explique-moi en langage simple :
1. Quels fichiers tu vas modifier.
2. Ce qui pourrait casser.
3. Comment revenir en arrière si ça se passe mal.
Attends mon accord avant de commencer.

Phase 4 : rédiger et référencer (prompts 15 à 19)

15. Titres et descriptions de pages

Pour chaque page du site, propose :
- un titre de 60 caractères maximum contenant l'expression « [mot-clé] » quand c'est naturel ;
- une description de 155 caractères maximum qui donne envie de cliquer.
Chaque titre et chaque description doivent être uniques.
Présente le résultat dans un tableau, puis applique-le après ma validation.

16. Structure des titres

Vérifie la structure des titres de chaque page :
un seul titre principal, puis des sous-titres dans un ordre logique.
Liste les anomalies page par page et corrige-les sans changer l'apparence.

17. Textes alternatifs des images

Liste toutes les images du site sans texte alternatif.
Propose pour chacune une description factuelle de 5 à 15 mots,
sans commencer par « image de ».
Applique après ma validation.

18. Section de questions fréquentes

Sur la page [page], ajoute une section « Questions fréquentes » avec ces questions
et ces réponses : [colle tes questions et réponses].
Chaque question est un sous-titre, chaque réponse commence par une phrase
qui répond directement.
N'invente aucune réponse : utilise uniquement mon texte.

19. Préparer le site pour Google et pour les IA

Prépare le site pour le référencement :
1. Génère un fichier sitemap.xml et un fichier robots.txt.
2. Vérifie que le contenu de chaque page est présent dans le HTML
   sans exécuter de JavaScript. Si ce n'est pas le cas, propose une solution.
3. Ajoute les balises nécessaires au partage sur les réseaux sociaux
   (titre, description, image).
4. Ajoute les données structurées adaptées à une entreprise locale :
   nom, adresse, téléphone, horaires. Utilise uniquement ces informations : [infos].
Liste ce que tu as fait.

Phase 5 : déboguer (prompts 20 à 24)

20. Signaler un bug correctement

Bug constaté.
Ce que j'ai fait : [actions, dans l'ordre].
Ce que j'attendais : [résultat attendu].
Ce qui s'est passé : [résultat obtenu].
Message d'erreur : [colle le message exact].
Appareil et navigateur : [ex. iPhone, Safari].

Ne corrige rien pour l'instant. Donne-moi d'abord les trois causes les plus probables,
de la plus probable à la moins probable.

21. Trouver la cause avant de corriger

Avant de corriger, vérifie ton hypothèse principale : ajoute les traces nécessaires
pour confirmer la cause, dis-moi quoi tester, et attends mon retour.
Une fois la cause confirmée, propose la correction la plus petite possible.

22. Sortir d’une boucle de corrections

À utiliser dès que l’agent échoue trois fois sur le même problème.

Stop. Les trois dernières corrections n'ont pas résolu le problème.
Ne modifie plus rien.
1. Résume ce que tu as essayé et pourquoi ça n'a pas marché.
2. Liste les hypothèses que tu n'as pas encore testées.
3. Dis-moi s'il vaut mieux revenir au dernier état qui fonctionnait
   et repartir avec une autre approche.

23. Vérifier qu’on n’a rien cassé

Après cette modification, vérifie que ces fonctions marchent toujours :
- [fonction 1, ex. le formulaire de contact s'envoie]
- [fonction 2, ex. le menu s'ouvre sur mobile]
- [fonction 3]
Teste-les une par une et donne-moi le résultat de chaque test.

24. Comprendre ce que fait le code

Explique-moi ce que fait le fichier [nom] comme si je n'avais jamais codé.
Trois paragraphes au maximum : à quoi il sert, quand il est utilisé,
et ce qui se passerait si on le supprimait.

Phase 6 : sécuriser et nettoyer (prompts 25 à 28)

25. Audit des accès

Fais un audit de sécurité de ce projet. Ne modifie aucun fichier pendant l'audit.
1. Quelles pages ou routes sont accessibles sans être connecté ?
2. Un utilisateur peut-il voir ou modifier les données d'un autre utilisateur ?
3. Chaque formulaire valide-t-il les données côté serveur et limite-t-il les envois ?
4. Quelles données personnelles sont collectées, et où sont-elles stockées ?
Pour chaque problème : le fichier concerné, le risque en une phrase, la correction proposée.
Attends ma validation avant de corriger.

26. Recherche de clés et de mots de passe

Cherche dans tout le projet les clés d'API, mots de passe, jetons
et adresses e-mail écrits en clair.
Liste chaque occurrence avec son fichier.
Propose de les déplacer dans le coffre-fort de secrets de l'outil,
et dis-moi quelles clés je dois régénérer parce qu'elles ont été exposées.

27. Nettoyer le code

Sans changer le comportement ni l'apparence du site :
1. Supprime le code inutilisé et les fichiers orphelins.
2. Regroupe les éléments dupliqués.
3. Renomme ce qui est mal nommé.
Procède fichier par fichier et montre-moi la liste des changements.
Critère de réussite : le site est strictement identique avant et après.

28. Accessibilité

Vérifie l'accessibilité de chaque page :
contraste des textes, navigation au clavier, libellés des champs de formulaire,
textes alternatifs, taille des zones cliquables sur mobile.
Liste les problèmes par ordre de gravité, puis corrige après ma validation.

Phase 7 : publier et transmettre (prompts 29 et 30)

29. Checklist de mise en ligne

Avant la publication, vérifie et réponds par oui ou non, avec une preuve pour chaque point :
1. Mentions légales et politique de confidentialité accessibles depuis chaque page.
2. Aucun outil de mesure ou de publicité chargé avant le consentement du visiteur.
3. Aucune clé ni mot de passe dans le code.
4. Page d'erreur 404 personnalisée.
5. Titres et descriptions uniques sur chaque page.
6. Fichiers sitemap.xml et robots.txt présents.
7. Toutes les pages testées en largeur mobile.
8. Formulaires testés avec un envoi réel.
Liste ce qui reste à faire.

30. Journal de bord et passation

Rédige un document de passation pour ce projet :
1. À quoi sert le site et comment il est organisé.
2. Les décisions importantes prises, et pourquoi.
3. Les services externes utilisés et ce qu'il faut pour y accéder.
4. Comment publier une modification.
5. Les problèmes connus et les améliorations prévues.
Écris pour quelqu'un qui découvre le projet et qui ne me connaît pas.

Ce dernier document est ce qui permettra à un développeur, ou à toi dans six mois, de reprendre le site sans repartir de zéro.

Les 5 réflexes qui valent mieux que n’importe quel prompt

1. Fais poser des questions. La phrase « pose-moi tes questions avant de commencer » est la plus rentable de toute cette page.
2. Montre plutôt que décrire. Une capture d’écran ou un message d’erreur copié tel quel vaut mieux qu’une longue explication.
3. Garde un carnet. Note les prompts qui ont marché pour ton projet. Tu les réutiliseras.
4. Reviens en arrière sans hésiter. Un point de sauvegarde restauré coûte moins cher que dix corrections.
5. Relis tout ce qui sera publié. L’IA peut inventer un chiffre, un avis ou une adresse avec beaucoup d’assurance.

Ces réflexes protègent aussi contre les risques décrits dans les 7 dangers du vibe coding.

Besoin d’un regard extérieur ?

Si ton projet avance mais que tu doutes du résultat, un audit avant mise en ligne évite bien des soucis. Tu peux nous décrire ton projet ou réserver un appel.

Questions fréquentes

Ces prompts fonctionnent-ils avec tous les outils de vibe coding ?

Oui. Ils sont écrits en langage courant et ne dépendent d’aucun outil. Seul le nom du fichier de règles change : replit.md pour Replit, CLAUDE.md pour Claude Code, AGENTS.md pour d’autres agents.

Faut-il écrire ses prompts en anglais ?

Non. Les modèles actuels comprennent très bien le français. Écris dans la langue où tu es le plus précis. Garde simplement en anglais les noms de boutons et les messages d’erreur, tels qu’ils s’affichent.

Quelle longueur pour un prompt de vibe coding ?

Aussi long que nécessaire pour ne rien laisser deviner. Un prompt de dix lignes avec un objectif, des critères de réussite et des limites donne de meilleurs résultats qu’une phrase vague, et t’épargne des allers-retours coûteux.

Pourquoi l’IA modifie-t-elle des choses que je n’ai pas demandées ?

Parce que ta demande laissait une marge d’interprétation. Ajoute systématiquement « ne modifie rien d’autre » et précise les pages ou fichiers concernés. Un fichier de règles relu à chaque session réduit aussi ce comportement.

Qu’est-ce qu’un PRD en vibe coding ?

PRD signifie « product requirements document ». C’est le document de cadrage qui décrit l’objectif, les pages, les fonctions et les limites du projet. Les prompts 1 à 3 de cette page permettent d’en produire un en une demi-heure.

Peut-on réutiliser ces prompts pour une application et pas seulement un site ?

Oui. La méthode est la même. Pour une application qui gère des comptes ou des paiements, ajoute une relecture par un développeur avant la mise en ligne.

Sources

• Documentation Replit, démarrer avec l’agent (structure d’un bon prompt)
• Documentation Replit, le fichier replit.md
• Documentation Claude Code, présentation et fichier CLAUDE.md
• John Damask, « Vibe Coding Cheatsheet »
• Modèle de workflow de vibe coding en quatre étapes (GitHub)
• Karo Zieminski, « Is your Replit looping? »
• CSO Online, étude Tenzai sur la sécurité des outils de vibe coding