Ingénierie rapide pour les concepteurs : des cahiers des charges vagues aux résultats exploitables de l’IA

Si le rendu de votre IA ressemble à une photo d'illustration, votre consigne sonne comme un souhait.

C'est tout le problème de la façon dont la plupart des designers ont appris à utiliser les outils d'IA. « Crée-moi une image principale pour une startup fintech » n'est pas une consigne. C'est plutôt une idée. Une consigne, c'est ce que vous diriez à un illustrateur freelance qui facture 400 dollars de l'heure et pose des questions pointues.

Les designers savent déjà faire cela. Vous avez rédigé des briefs à l'école. Vous en rédigez chaque semaine au travail. Vous savez à quoi ressemblent la clarté, les références et les contraintes lorsqu'elles sont écrites. Rédiger des consignes pour une IA requiert la même compétence, mais pour un public différent.

Une consigne est un brief de conception sous forme de texte

Cessez de considérer les invites comme des formules magiques. Voyez-les plutôt comme le premier paragraphe d'un brief créatif, complété par les spécifications finales à la fin.

Un bon brief indique au créateur qui il est, à quoi sert le projet, quelles sont les règles, quelles références utiliser et à quoi doit ressembler le livrable. Si vous omettez l'un de ces éléments, votre travail sera techniquement correct, mais émotionnellement décalé. Demandez à un junior de « concevoir un logo pour un café » et vous obtiendrez douze grains de café. Demandez-lui plutôt de « concevoir un logo pour un café de troisième vague destiné aux freelances, avec un logotype, une police sans empattement géométrique, sans pictogrammes, inspiré par la sobriété de Blue Bottle », et vous obtiendrez un résultat satisfaisant.

Les consignes fonctionnent de la même manière. L'instinct de rester vague sous prétexte que le modèle est intelligent est l'erreur la plus coûteuse en conception assistée par IA. Être précis n'est pas de la pédanterie ; c'est la clé du succès.

Une bonne consigne se lit comme un cahier des charges. Une mauvaise consigne ressemble à un souhait.

Les cinq éléments essentiels de toute consigne exploitable

Toute consigne produisant un résultat commercialisable comporte cinq éléments. Vous pouvez les mémoriser, les intégrer à un modèle, les imprimer sur un post-it. Ces éléments :

1. Rôle. Quel rôle l'IA cherche-t-elle à jouer ? (« Vous êtes illustrateur éditorial senior et vous avez dix ans d'expérience au New Yorker. »)

2. Contexte. À quoi sert cette image et à qui est-elle destinée ? (« Cette image est l'illustration principale d'un article de blog sur l'apprentissage des outils d'IA par les designers. Le public cible est composé de designers professionnels, pionniers, sceptiques mais curieux. »)

3. Contraintes. Quelles sont les règles ? (« Image éditoriale, non institutionnelle. Pas d'ordinateurs visibles. Pas de photos libres de droits. Couleurs unies, silhouette marquée, contraste élevé, faible niveau de détail. »)

4. Références. Quel aspect doit-elle avoir ? (« Le style de Saul Steinberg associé à la sobriété des affiches touristiques suisses des années 1960. Palette de couleurs de la marque : fond #080404, accents #ff6434. »)

5. Spécifications de livraison. Quelles sont les spécifications du livrable ? (« Format 16:9, 1200x630, PNG, sans texte dans l'image. »)

Omettez le rôle et vous obtiendrez un résultat médiocre. Omettez le contexte et vous obtiendrez un résultat générique. Omettez les contraintes et vous obtiendrez ce que le modèle devine que vous souhaitez, généralement une photo d'illustration. Omettez les références et le résultat dérivera vers les données d'entraînement dominantes. Omettez les spécifications de sortie et vous obtiendrez des dimensions incorrectes.

| Partie Invite | Fonctionnement | Conséquences si vous l'omettez |

|-------------|--------------|-----------------------------|

| Rôle | Définit le niveau de goût et d'expertise | Sortie générique |

| Contexte | Indique au modèle l'objectif du travail | Résout le mauvais problème |

| Contraintes | Définit ce qu'il faut éviter | Obtient les clichés que vous détestez |

| Références | Ancre la direction visuelle ou tonale | Dérive vers les moyennes d'entraînement |

| Spécifications de sortie | Contrôle le format et le livrable | Dimensions et format incorrects |

Exemple concret : génération d'une image principale

La version vague que tout designer a déjà écrite au moins une fois :

« Image principale pour un article de blog sur l'ingénierie des prompts pour les designers. »

Résultat : un designer devant son ordinateur portable, un cerveau lumineux, un robot tenant un crayon, ou une combinaison des trois. Classique. Sans intérêt.

La version structurée :

Vous êtes illustrateur éditorial et avez travaillé pour The New Yorker et Wired pendant dix ans. Créez une image principale pour un article de blog intitulé « Ingénierie des prompts pour les designers ». Le public cible est composé de designers professionnels sceptiques face au battage médiatique autour de l'IA, mais prêts à utiliser sérieusement ces outils.

Composition : un brief de designer sur papier à gauche de l'image, esquissé à la main avec des annotations, se fondant progressivement dans le texte clair du prompt à droite. Cela suggère la transition entre le brief et le prompt structuré.

Style : éditorial, aplats de couleur, silhouette marquée, contraste élevé, peu de détails. Texture papier acceptable. Pas d'ordinateurs. Pas de robots. Pas de cerveaux. Pas de sphères lumineuses.

Références : Dessin au trait de Saul Steinberg pour le brief. Affiche touristique suisse sobre pour le verso. Palette de la marque : #080404 fond, #ff6434 accent, #d0d3d8 neutre.

Format de sortie : 1200x630, sans texte dans l'image.

Résultat : une image principale prête à être diffusée, sans avoir à la régénérer quatre fois.

La différence ne réside pas dans le talent, mais dans la structure.

Exemple fonctionnel : Prototype d'interface utilisateur en v0 ou Lovable

Exemple vague :

« Créez-moi une landing page pour une agence de design. »

Résultat : un modèle Tailwind avec un dégradé standard, trois fiches de présentation, une image principale standard et un texte générique, comme celui de toutes les autres agences sur Internet.

Structuré :

Créer une landing page pour Brainy, un studio de design reconnu pour ses plus de 2 millions d'abonnés sur Instagram et Threads. Public cible : fondateurs de startups SaaS (séries A à C) ayant besoin de services de branding, de développement web et de design. Ils ont déjà visité de nombreux sites d'agences et quittent immédiatement ceux qui semblent impersonnels.

Mise en page : une page d'accueil sur une seule colonne avec un titre en gras et un appel à l'action unique, suivie d'une bande horizontale de logos clients, puis d'une présentation des services en trois parties (branding, web, contenu) organisée selon une grille bento, suivie d'une section témoignages avec trois citations, et enfin d'un simple formulaire de contact en bas de page.

Contraintes : pas de dégradés, pas d'images libres de droits, pas d'illustrations génériques pour la page d'accueil. Mode sombre uniquement, fond #080404, couleur d'accentuation #ff6434. Typographie : une seule police sans empattement pour tout, gras pour les titres, léger pour le corps du texte. Espacement de 4 px partout.

Références : contraintes d’espacement de Linear, graisse typographique de Vercel, structure en grille bento de Apple. Aucun de ces éléments n’est une copie.

Résultat : composants responsifs, conçus pour mobile-first et utilisant Shadcn.

Même outil. Résultat complètement différent.

Exemple fonctionnel : agent de développement créant un composant

Vague :

« Créez-moi un composant Bouton. »

Résultat : un bouton. Une seule variante. Aucune accessibilité. Aucun état de focus. Couleurs non spécifiées.

Structuré :

Vous êtes ingénieur système de conception senior. Créez un composant Bouton dans notre système de conception. >

Contexte : ce bouton remplace nos anciens styles de boutons ad hoc dispersés sur douze pages marketing. Il doit prendre en charge les variantes principale, secondaire et fantôme, trois tailles (petite, moyenne, grande) et les états de chargement, désactivé et sélectionné.

Contraintes : utiliser nos jetons existants de tokens.css (ne pas introduire de nouvelles couleurs). L’anneau de sélection doit avoir un décalage de 2 px avec l’option --color-accent. Ne jamais utiliser px pour l’espacement, toujours utiliser les jetons --space. La typographie est toujours --font-sans avec --text-sm ou --text-base selon la taille. L’état de chargement affiche une icône de chargement et empêche les clics.

Références : primitives d’interface utilisateur Radix pour les modèles d’accessibilité. Notre composant Card existant sur /components/Card.tsx pour référence sur la structure des fichiers.

Sortie : TypeScript, Tailwind, scénario Storybook qui teste chaque variante et état. Tests couvrant le comportement désactivé, en chargement et sélectionné.

Donnez ceci à un développeur, et vous obtiendrez un vrai bouton. Donnez-lui « créez-moi un bouton », et vous obtiendrez quelque chose que vous devrez réécrire à la main.

La bibliothèque de contraintes que tout designer devrait s'approprier

Les contraintes sont l'arme secrète. C'est aussi l'aspect le plus sous-utilisé par les designers. Copiez cette bibliothèque, collez les lignes pertinentes dans vos invites, et adaptez-les à votre marque.

| Domaine | Contraintes à inclure |

|--------|------------------------|

| Illustration | Couleur unie, silhouette marquée, contraste élevé, faible niveau de détail, pas de texte dans l'image, pas d'ordinateurs/téléphones/robots/cerveaux sauf si explicitement requis, style éditorial et non institutionnel |

| Style photographique | Pas de photos d'illustration, pas d'éclairage artificiel, pas de rendus 3D sauf demande expresse, composition naturelle, les imperfections du monde réel sont les bienvenues |

| Génération d'interface utilisateur | Utilisation des composants existants, pas de nouvelles couleurs en dehors des jetons, approche mobile-first, accessibilité requise (états de focus, rapports de contraste), pas de dégradés sauf si la marque l'exige |

| Typographie | Une police sans empattement pour l'interface utilisateur, une police avec empattement uniquement si la marque l'exige, pas plus de trois graisses par composition, pas de texte justifié, pas de phrases de plus de quatre mots en majuscules |

| Couleur | Utilisez des jetons et non des valeurs hexadécimales, jamais de texte blanc sur fond noir, ni de rouge sur fond vert, contraste minimum de 4,5:1 pour le corps du texte |

| Mise en page | Espacement de 4 ou 8 px, jamais de centrage du texte principal, jamais de justification complète, 75 caractères maximum par ligne, images ancrées à gauche sauf indication contraire dans la composition |

| Code | TypeScript strict, exportations nommées non définies par défaut, aucune nouvelle dépendance sans autorisation, couverture de test pour chaque nouveau composant |

Utilisez ces éléments comme blocs prêts à l'emploi. Vous aurez peut-être l'impression d'être un peu bête au début. Puis vous constaterez que le résultat est deux fois meilleur du jour au lendemain.

Pour plus d'exemples de flux de travail d'IA, consultez le reste de Brainy Papiers. Si vous souhaitez une véritable bibliothèque de prompts conçue pour l'image de marque de votre équipe, et non pas votre historique aléatoire ChatGPT, embauche Brainy.

Comment itérer sans tout recommencer

La pire habitude en matière de conception de prompts est de supprimer l'intégralité du prompt et de le réécrire lorsque le résultat est incorrect. Dans neuf cas sur dix, le prompt était presque parfait. Une seule variable était erronée.

Itérez avec précision. Modifiez un élément à la fois.

1. Exécutez le prompt une première fois. Notez ce qui ne va pas.

2. Identifiez laquelle des cinq parties pose problème. Si le résultat est trop générique, les références sont faibles. S'il contient des éléments incorrects, il manque une contrainte « pas de X ». S'il est destiné au mauvais public, le contexte est insuffisant.

3. Modifiez uniquement cette partie. Ne réécrivez pas tout.

4. Exécutez à nouveau. Comparez avec le premier résultat. Mieux, moins bien, identique ? 5. Répétez. Trois à cinq itérations suffisent généralement.

À ce sujet : pourriture du contexte est bien réel. Si vous itérez dans la même conversation et que le résultat se dégrade au lieu de s'améliorer, la session est polluée. Ouvrez une nouvelle conversation, collez la meilleure suggestion actuelle et continuez.

Les trois erreurs qui garantissent un résultat médiocre

Trois erreurs que je constate chaque semaine, et chacune d'elles nuit gravement à la qualité du résultat.

Erreur n° 1 : « Améliorer ». Le modèle ne sait pas ce que « mieux » signifie pour vous. « Mieux » correspond à la moyenne des résultats « mieux » du modèle, ce qui revient à une régression vers la moyenne. Soyez précis. « Renforcez le contraste des couleurs. » « Rendez la composition plus asymétrique. » « Réduisez de moitié les détails de l'arrière-plan. »

Erreur n° 2 : Demander cinq options à la fois. Vous obtenez cinq options médiocres au lieu d'une seule bonne. Demandez-en une seule. Itérez. Acceptez la première bonne option.

Erreur n° 3 : Ne pas fournir de références. Les références permettent au modèle de mieux cerner ses préférences. Sans elles, vous obtiendrez une moyenne des données d'entraînement. Avec trois références bien choisies, vous obtiendrez un résultat proche de ce que vous recherchiez.

FAQ

L'ingénierie des prompts : une véritable compétence ou un effet de mode ?

C'est une véritable compétence, au même titre que la rédaction d'un bon brief créatif. Si vous savez briefer un freelance, vous savez aussi donner des prompts à un modèle. Le terme à la mode est « ingénierie ». En réalité, il s'agit plutôt de « directives claires ».

Quel outil gère le mieux les prompts ?

Pour les images, Midjourney et Gemini Pro sont les plus performants avec des prompts textuels détaillés. Pour l'interface utilisateur, v0 et Lovable réagissent bien aux contraintes structurées. Pour le code, Claude Code et Cursor sont les plus performants, surtout avec un fichier CLAUDE.md bien rédigé. La qualité du prompt importe moins que l'outil lui-même.

Dois-je utiliser une bibliothèque de prompts ?

Oui. Créez-en une. Organisez-les par cas d'utilisation. À chaque prompt réussi, enregistrez-le. À chaque échec, notez pourquoi. Après trois mois, vous disposerez d'une bibliothèque plus précieuse que n'importe quel abonnement à un outil.

Quelle doit être la longueur d'un prompt ?

Assez longue pour couvrir les cinq parties, assez courte pour que chaque phrase soit pertinente. La plupart des miens font entre 100 et 300 mots. Plus court, et vous manquez de précision. Beaucoup plus long, et vous risquez de vous répéter.

Dois-je apprendre des astuces techniques pour les prompts, comme temperature ou top_p ?

Pas pour la plupart des projets de conception. Ces fonctionnalités sont utilisées dans les appels d'API, pas dans les interfaces de chat. Maîtrisez d'abord les cinq parties. Vous pourrez vous préoccuper des paramètres une fois que vous effectuerez des appels d'API.

Rédigez avec conviction

Chaque prompt vague est un détour de dix minutes qui produit un résultat médiocre. Chaque prompt structuré est un investissement de dix minutes qui mène à un résultat concret.

Décrivez le rôle, le contexte, les contraintes, les références et le résultat attendu. Modifiez une variable à la fois. Sauvegardez les versions fonctionnelles.

Vous savez déjà rédiger un brief. Le modèle, lui, est encore novice.

Rédigez-le avec conviction.