Bien formuler ses prompts pour générer du HTML/CSS

Vous savez maintenant lire une page et ranger son style. Vous n'aurez pourtant pas à taper tout ce HTML à la main : Claude Code le produira. Mais la qualité de ce qu'il écrit dépend presque entièrement de la façon dont vous le demandez — et c'est une compétence qui s'apprend.

1. Ce que Claude Code ne sait pas

Il connaît le HTML et le CSS mieux que vous ne les connaîtrez jamais. En revanche, il ne sait rien de votre projet : ni le nom de vos pages, ni vos couleurs, ni la structure que vous avez décidée, ni ce que contient le dossier d'à côté.

Face à un trou, un assistant ne s'arrête pas : il comble. Il inventera un nom de fichier plausible, une palette de couleurs raisonnable, trois rubriques crédibles. Le résultat aura l'air juste, et il faudra tout reprendre. Bien formuler une demande, c'est essentiellement ne pas laisser de trous.

2. Les trois ingrédients d'une bonne demande

Une demande efficace tient rarement en une phrase, et n'a pas besoin d'être longue. Elle répond à trois questions :

• Quoi — la tâche, en un verbe

  Crée, modifie, ajoute, corrige. Un seul verbe : si vous en avez trois, faites trois demandes.

• Où — le fichier concerné

  Nommez-le : pages/contact.html, css/style.css. Sans cette précision, l'assistant choisit à votre place, ou modifie plusieurs fichiers.

• Avec quoi et comment — le fichier de consignes

  La matière à utiliser et les exigences techniques se disent d'une seule phrase : « applique les consignes de programme.md ». Ce fichier, écrit une fois pour toutes et posé à la racine du projet, contient à la fois la règle de contenu — n'inventer aucune information, signaler ce qui manque — et les contraintes de production : HTML sémantique, aucun style en ligne, tout le CSS dans un fichier externe, conception mobile d'abord. Vous n'avez plus à les réécrire à chaque demande, et surtout vous ne risquez plus d'en oublier une. Et vous pouvez mettre à jour ces consignes régulièrement : chaque fois qu'un résultat ne vous convient pas, ajoutez la règle manquante au fichier — elle s'appliquera à toutes les pages suivantes.

3. Deux demandes, deux résultats

Comparons. Même intention, même assistant, deux formulations :

Fais-moi une belle page de contact pour mon site.

Résultat probable : une page correcte mais générique, avec une adresse inventée, un formulaire dont personne n'a besoin, un style qui ne ressemble en rien au reste du site, et des couleurs plantées directement dans les balises.

Crée pages/contact.html sur le modèle de index.html. Structure sémantique : header, nav, main, footer. Reprends les coordonnées du fichier infos-projet.md — n'invente rien, signale-moi ce qui manque. Aucun style dans le HTML : ajoute les règles nécessaires à css/style.css. Attention au chemin de la feuille depuis pages/.

Quatre lignes, et les trois ingrédients y sont. Le résultat est utilisable immédiatement — et surtout, vérifiable : chaque exigence de la demande est un point que vous pouvez contrôler dans le code produit.

4. Corriger : la règle du petit périmètre

Le premier jet est rarement le bon, et c'est normal. L'erreur, à ce moment-là, est de renvoyer une grande demande fourre-tout : l'assistant réécrit alors la page entière, et ce qui marchait déjà se met à casser.

1. Une correction à la fois

   « Le titre est trop gros » et « il manque le lien de retour » sont deux demandes, pas une. Enchaînez-les, mais séparément.

2. Délimiter explicitement

   « Modifie uniquement css/style.css, ne touche pas au HTML. » Sans cette phrase, rien ne garantit que le périmètre sera respecté.

3. Vérifier après chaque touche

   Rechargez la page. Si quelque chose casse, vous savez exactement quelle demande en est responsable — c'est tout l'intérêt des petits pas.

4. Demander une explication plutôt qu'un correctif

   Quand vous ne comprenez pas un bout de code : « explique-moi ce que fait cette règle, sans rien modifier ». L'assistant est aussi un professeur.

5. Relire ce qui a été produit

Un assistant produit du texte plausible, ce qui n'est pas la même chose que du texte juste. Maintenant que vous savez lire une page, vous pouvez contrôler.

C'est la règle posée dès le module 1.1, et elle ne change pas : ne jamais mettre en ligne un code qu'on n'a pas relu et compris. L'assistant supprime la corvée d'écriture, pas la responsabilité.