Il était 23h43 un jeudi et je fixais 340 lignes de code React que GPT-4 avait généré avec une confiance totale. Propre. Bien commenté. Complètement cassé en production. Le hook personnalisé gérait l'état d'une manière qui causait des boucles de re-rendu silencieuses, le genre qui ne lance pas d'erreurs, qui assassine juste discrètement votre performance jusqu'à ce qu'un client vous appelle vendredi matin en demandant pourquoi sa page de paiement prend neuf secondes à charger.
Cette nuit m'a enseigné plus sur l'ingénierie de prompt que n'importe quel tutoriel YouTube ou thread Twitter ne l'aurait jamais fait. Et j'ai eu pas mal de ces nuits depuis.
Je construis sur le web depuis neuf ans. Chez Seahawk Media, nous avons livré bien plus de 12 000 sites, WordPress, builds headless, applications React sur mesure, magasins WooCommerce gérant des volumes de transactions sérieux. Les assistants de codage IA sont entrés correctement dans mon flux de travail autour de début 2023, et j'ai oscillé entre penser qu'ils sont miraculeux et avoir envie de jeter mon ordinateur dans la Tamise.
Voici ce que j'ai réellement appris. À la dure.
---
Le modèle ne connaît pas votre base de code. Vous devez la lui expliquer.
Cela semble évident. Ce ne l'est pas, pas dans la pratique.
La plus grande erreur que je vois les développeurs commettre, y compris moi-même pendant les six premiers mois, c'est de traiter un LLM comme un ingénieur senior qui a déjà lu tout votre code. Vous demandez « écris une fonction pour gérer l'authentification utilisateur » et il écrit quelque chose techniquement correct dans le vide. Mais votre projet utilise Supabase, pas Firebase. Vos tokens vivent dans des cookies httpOnly, pas dans localStorage. Votre format d'erreur est { status, message, data }, pas ce que le modèle a par défaut.
Le modèle n'a pas tort. Il ne vous connaît simplement pas.
Donnez-lui un préambule de projet, chaque fois
Je commence maintenant chaque session de codage significative avec ce que j'appelle un « bloc de contexte ». Cela prend environ 90 secondes à écrire. Cela ressemble à quelque chose comme :
- Stack: Next.js 14 (App Router), TypeScript, Supabase, Tailwind CSS 3.4
- State: Zustand, pas de Redux nulle part
- Auth: Supabase Auth avec cookies httpOnly via middleware
- Error shape: { success: boolean, error?: string, data?: unknown }
- Convention de style : utilitaire d'abord, pas de fichiers CSS personnalisés sauf si absolument nécessaire
Collez ceci avant toute demande non triviale. Je fais cela dans Cursor en gardant un fichier _context.md à la racine du projet. Deux frappes pour coller. La qualité de sortie augmente noticeablement, moins d'hypothèses, moins de choses que j'ai à arracher.
---
La Spécificité, C'est Tout le Jeu
En 2022, avant d'utiliser massivement l'IA, un client m'a remis un brief qui était littéralement deux phrases : « Construis-nous un système de réservation. Fais-le bien. » On a passé trois semaines à discuter de la portée. Cette expérience m'a marqué et elle façonne directement la façon dont j'écris les prompts maintenant.
Prompt vague → code vague. À chaque fois.
« Écris une fonction qui récupère les commandes » te donnera quelque chose. « Écris une fonction TypeScript async appelée fetchOrdersByUser qui accepte un userId: string, interroge la table orders dans Supabase où user_id correspond et status n'est pas cancelled, ordonne les résultats par created_at décroissant, et retourne Order[] ou lève une erreur typée » te donnera quelque chose que tu peux vraiment déployer.
La différence n'est pas la capacité du modèle. C'est la spécificité du prompt.
Quoi Inclure dans un Code Prompt
- Nom de fonction et signature, ne laissez pas le modèle inventer des conventions de nommage
- Types d'entrée et types de sortie, génériques TypeScript si pertinent
- La source de données, quelle table, quel point d'extrémité API, quelle couche de cache
- Les cas limites que vous connaissez déjà, « gérer le cas où le tableau est vide »
- Ce qu'il NE faut PAS faire, « n'utilisez pas useEffect pour ça, utilisez une server action »
Ce dernier point compte plus que les gens ne le réalisent. Dire au modèle ce qu'il faut éviter économise un temps énorme. J'ai commencé à tenir une petite note « anti-patterns » par projet, des choses comme « pas de composants client sauf si l'interaction utilisateur l'exige », et j'inclus les lignes pertinentes dans les prompts pour ce projet.
---
Chaînez vos prompts. Ne demandez pas tout à la fois.
Seahawk avait un client fintech fin 2023, je ne dirai pas qui, où nous construisions un flux KYC multi-étapes. Du truc complexe. Upload de documents, intégration de vérification de vivacité, polling de statut. J'ai commis l'erreur au départ de demander à GPT-4 de « construire le composant flux KYC complet ». Il a produit 600 lignes de code héroïque qui ne valait rien. De la logique enchevêtrée, des préoccupations mélangées, pas de vraie séparation entre l'état UI et la logique métier.
Donc j'ai tout supprimé et j'ai recommencé avec une chaîne.
Premier prompt : « Concevez la machine d'état pour un flux KYC à 4 étapes. Étapes : identité, upload de document, vivacité, examen. Donnez-moi juste le type d'état et les transitions, pas d'UI. »
Deuxième prompt : « Étant donné cette machine d'état [coller], écris le store Zustand. »
Troisième prompt : « Étant donné ce store [coller], écris le composant StepIdentity. Juste cette étape. »
La sortie de l'approche chaînée était utilisable. Pas parfaite, j'ai quand même réécrit environ 30%, mais utilisable. L'approche monolithique ne m'a rien donné.
Les propres directives d'Anthropic sur les prompts parlent de diviser les tâches complexes en sous-tâches, et honnêtement, cela s'aligne exactement avec ce que j'ai découvert par essais et erreurs. Divise le problème avant de diviser ta base de code.
---
Fais-le S'argumenter Contre Lui-même
Celle-ci, je l'ai découverte complètement par hasard. Je relisais une fonction utilitaire générée et au lieu de simplement l'exécuter, j'ai ajouté un prompt de suivi : « Quels sont les bugs potentiels ou les cas limites dans le code que tu viens d'écrire ? »
Le modèle a trouvé trois problèmes qu'il n'avait pas pris en compte. L'un d'eux était un vrai problème, une condition de concurrence dans une boucle asynchrone qui aurait été un cauchemar à déboguer en production.
Maintenant je fais ça régulièrement. Écrire le code, puis lui demander de critiquer le code. Puis lui demander de corriger la critique. Ça semble un peu absurde, demander au modèle de revoir son propre travail, mais ça détecte systématiquement des choses que j'aurais seulement attrapées après une session de débogage douloureuse.
Tu peux aller plus loin. Après avoir obtenu une fonction fonctionnelle, essaie : « Réécris ceci en mettant l'accent sur la performance » ou « Comment cela se comporterait-il sous une forte concurrence ? » Les réponses ne sont pas toujours applicables, mais environ 40 % du temps elles mettent au jour quelque chose qui vaut la peine d'être traité.
---
Le cadre « Rôle + Contrainte »
Il y a un schéma de prompt que j'utilise constamment maintenant et que j'aurais aimé découvrir en première année. Il va comme suit : « Tu es un [type d'ingénieur spécifique]. Ta contrainte est [règle stricte]. Maintenant [tâche]. »
Exemple : « Tu es un ingénieur backend qui tient beaucoup à l'efficacité des requêtes de base de données. Ton contrainte est que tu ne peux récupérer que ce qui est nécessaire pour ce rendu, pas de sur-récupération. Écris une requête Supabase pour le tableau de bord admin qui retourne le nombre de commandes, le chiffre d'affaires total, et les cinq commandes les plus récentes. »
Ce cadrage fait deux choses. Il aligne la « persona » du modèle avec ce dont j'ai réellement besoin. Et la contrainte agit comme un garde-fou, quelque chose que le modèle vérifie explicitement contre lui-même en générant.
Les meilleures pratiques de prompting d'OpenAI décrivent une idée similaire autour de donner au modèle une persona avec des instructions explicites. Ça vaut le coup de lire si tu ne l'as pas fait, mais je dirais que la partie contrainte est sous-estimée dans leur documentation.
Compare le résultat de ce prompt encadré à « écris une requête Supabase pour le tableau de bord d'administration ». C'est le jour et la nuit. Franchement.
---
Quand arrêter de faire des prompts et juste écrire le code
C'est la partie que personne ne veut dire à haute voix.
Les outils de codage IA excèlent à : le boilerplate, les opérations CRUD, les fonctions utilitaires, écrire des tests pour du code déjà écrit, traduire entre formats (schéma JSON vers type TypeScript, SQL vers requête Supabase, etc.), et les premières versions de choses que vous allez fortement modifier.
Ils sont vraiment mauvais à : comprendre l'architecture réelle de votre app, savoir quel compromis compte pour votre échelle spécifique, écrire n'importe quoi qui touche une interaction stateful délicate sans guidance lourde, et n'importe quoi où le spec est fondamentalement ambigu.
J'ai une règle personnelle maintenant : si j'ai envoyé plus de quatre prompts de suivi en essayant d'obtenir un morceau de code correct, je ferme la conversation et l'écris moi-même. Le coût en temps du prompt debugging peut dépasser le coût en temps de simplement l'écrire, surtout pour n'importe quoi en dessous d'environ 50 lignes.
Le Stack Overflow Developer Survey 2024 a trouvé que 76% des développeurs utilisent ou prévoient d'utiliser des outils IA, mais les mêmes données ont montré une confiance relativement faible dans la précision. Cet écart entre l'utilisation et la confiance est exactement où vit le bon prompt engineering.
---
Versionnez Vos Prompts Comme Vous Versionnez Votre Code
L'année dernière j'ai commencé à garder un dossier prompts/ dans les projets où l'assistance IA est significative. Fichiers Markdown. Un par zone de feature majeure. Quand un prompt produit une sortie particulièrement bonne, je la sauvegarde. Quand je trouve une meilleure version, je mets à jour le fichier.
Ça semble obsessionnel. Ça m'a probablement économisé six heures sur le dernier gros projet seul, une construction WooCommerce headless pour un détaillant qui passait de Shopify. J'ai réutilisé un prompt de requête produit (avec des modifications mineures) sur quatre composants différents au lieu de ré-ingéniérer le contexte à partir de zéro à chaque fois.
Versionnez-le avec Git. Sérieusement. La qualité des prompts est reproductible si vous traitez les prompts comme des artefacts et non comme des inputs jetables. Les modèles de prompts de LangChain formalisent cette idée dans un contexte de framework, mais vous n'avez pas besoin de framework, un dossier de fichiers Markdown suffit pour la plupart des workflows d'agence.
---
FAQ
L'ingénierie des prompts est-elle vraiment une compétence transférable ou juste spécifique à chaque modèle ?
Largement transférable. Les principes fondamentaux — spécificité, contextualisation, chaînage, boucles de critique — s'appliquent d'un bout à l'autre, que ce soit GPT-4, Claude 3.5 Sonnet, Gemini ou ce qui viendra après. La syntaxe varie un peu et certains modèles répondent mieux à certains cadrages, mais la logique sous-jacente tient bon. J'ai constaté que Claude réagit bien aux contraintes explicites ; GPT-4 réagit bien aux exemples. Des différences mineures, des fondamentaux identiques.
Comment gères-tu le code généré par l'IA lors de la révision de code ?
Comme n'importe quel autre code. S'il va en production, il est examiné. Point final. J'ai arrêté de signaler « ceci a été généré par l'IA » dans les PRs chez Seahawk parce que c'est devenu une fausse piste ; les relecteurs l'scrutaient différemment, parfois injustement, parfois pas assez. Le code tient ou tombe sur ses propres mérites. Ce que je signale : toute section où la logique n'est pas évidente et où je n'ai pas ajouté de commentaires en ligne expliquant le raisonnement.
Utilises-tu des system prompts ou seulement des chat prompts ?
Les deux. Dans Cursor, je m'appuie sur le fichier .cursorrules pour les instructions persistantes au niveau du projet, des choses que je coller autrement à chaque fois. Pour les tâches ponctuelles dans l'interface web ChatGPT ou Claude, tout est dans le chat. L'approche .cursorrules a sensiblement réduit la répétition et le modèle reste plus cohérent sur une longue session.
Honnêtement, qu'en penses-tu : l'IA remplacera-t-elle les développeurs ?
Cela remplace certaines tâches, pas les développeurs. Les appels de jugement, ce qu'il faut construire, comment l'architecturer, quel compromis convient à la situation réelle de ce client, ce n'est nulle part automatisé. Si quelque chose, les développeurs qui sont serrés sont ceux qui étaient purement orientés exécution, pas orientation design ou architecture. Affûtez la couche de jugement. C'est la partie défendable.
---
Neuf ans à construire des choses sur le web, et la leçon fondamentale ne cesse de se répéter : la qualité de votre output est déterminée par la qualité de vos inputs. C'était vrai quand il s'agissait de briefs clients. C'est vrai maintenant avec les prompts.
Le modèle est un développeur junior rapide, occasionnellement brillant, mais souvent surconfiant. Gérez-le en conséquence.
Lectures connexes : Building a Real-Time Auction Site with Next.js & Supabase, How to Cost Custom Software in 2026: A Working Estimator for, et développement web sur mesure.