Comment écrire de meilleurs prompts d’IA : le contexte manquant qui rend les suggestions d’IA réellement utiles

De meilleurs prompts d’IA ne sont pas nécessairement plus longs. Ils contiennent le contexte dont un assistant a besoin pour prendre la bonne décision au lieu de se contenter de produire une modification plausible. Pour le travail d’ingénierie, cela signifie généralement indiquer le périmètre, l’hypothèse, le résultat souhaité, les contraintes et la raison pour laquelle la modification est importante.

C’est la différence entre une réponse qui compile et une modification qui aide le produit.

Un assistant peut écrire du code valide à partir d’une instruction courte, mais une instruction courte masque souvent la décision produit. « Supprime la barre latérale sur mobile » indique à l’assistant quoi modifier. Elle ne lui dit pas si le comportement sur ordinateur doit rester intact, pourquoi le comportement actuel nuit aux utilisateurs ni comment juger la réussite.

Lorsque ce contexte manque, l’assistant doit deviner. Il peut effectuer une modification techniquement soignée qui supprime un flux de travail utile sur ordinateur, modifie une mise en page sans rapport ou traite un symptôme plutôt que le problème.

Utilisez un prompt comme un bref cahier des charges d’ingénierie, et non comme une commande.

Commencez par ces six informations :

1. Périmètre : quel écran, quels fichiers, quel flux ou quel comportement sont concernés ?
2. Problème : qu’est-ce qui est difficile, cassé, lent ou déroutant pour une personne qui utilise le produit ?
3. Hypothèse : quelle est, selon vous, la cause du problème ?
4. Résultat souhaité : qu’est-ce qui doit être vrai une fois le travail terminé ?
5. Contraintes : qu’est-ce qui doit rester inchangé et quelles approches sont exclues ?
6. Demande de preuves : demandez à l’assistant de remettre en question l’hypothèse et d’expliquer ce qu’il vérifierait d’abord.

Vous n’avez pas besoin de tous ces éléments pour une question d’une ligne. Vous en avez besoin lorsque l’assistant pourrait prendre à votre place une décision de produit ou d’architecture.

Voici un prompt faible :

Rends la navigation mobile plus cohérente et supprime la barre latérale.

Il donne une action, mais aucune limite de décision. L’assistant pourrait supprimer la barre latérale partout, car il ne sait pas que les utilisateurs sur ordinateur en dépendent.

Voici un meilleur prompt :

Problème : la barre latérale de bureau est difficile à utiliser sur mobile, car elle
prend trop d’espace horizontal et entre en concurrence avec le contenu de la leçon.

Hypothèse : un modèle de navigation propre au mobile faciliterait le passage d’une
leçon à l’autre sans modifier le flux de travail sur ordinateur.

Résultat : sur les petits écrans, les apprenants peuvent changer de leçon et revenir
à l’exercice en cours sans perdre le contexte. Les utilisateurs sur ordinateur
conservent la barre latérale existante et le flux de travail au clavier.

Contraintes : ne supprimez pas la barre latérale sur ordinateur. Préservez le
comportement de routage existant, les libellés d’accessibilité et l’état de
progression. Évitez d’ajouter une deuxième source de vérité pour la leçon sélectionnée.

Avant d’implémenter, inspectez la responsabilité actuelle de la navigation et remettez
en question l’hypothèse si une modification de mise en page plus restreinte résoudrait le problème.

Le meilleur prompt donne à l’assistant la latitude d’enquêter, mais rend explicites les limites importantes : le mobile est le périmètre, le comportement sur ordinateur est protégé et un seul propriétaire d’état n’est pas négociable.

Une demande de positionnement peut présenter le même problème :

Déplace le bouton de sujet dans la barre latérale et fais en sorte qu’il s’intègre.

Cette instruction traite la mise en page existante comme de la décoration. Elle n’explique pas pourquoi le changement de sujet doit se trouver ailleurs ni comment les utilisateurs doivent le trouver après le déplacement.

Essayez plutôt ceci :

Problème : le sélecteur de sujet dans la barre de navigation entre en concurrence avec
la navigation globale, alors que les utilisateurs l’emploient pour comparer des leçons
au sein du cours actuel.

Résultat souhaité : placez le changement de sujet à côté de la navigation du cours afin
que son objectif soit clair et qu’il reste facile à atteindre lors de la consultation
d’une leçon.

Contraintes : laissez les actions globales de la barre de navigation inchangées,
préservez le sujet sélectionné pendant la navigation et ne faites pas de la barre latérale
l’unique moyen de changer de sujet sur les écrans étroits.

Inspectez d’abord le modèle actuel de route et d’état. Expliquez si la barre latérale
est la bonne destination avant de modifier la mise en page.

Le changement essentiel n’est pas « plus de détails ». C’est une meilleure définition de la réussite.

L’IA est particulièrement utile lorsqu’elle peut signaler une mauvaise prémisse avant d’écrire un correctif. Ajoutez une question directe :

Quelles preuves infirmeraient cette hypothèse et quelle modification plus petite
devrions-nous envisager en premier ?

Pour un bug, demandez des étapes de reproduction et des hypothèses concurrentes. Pour un refactor, demandez quel comportement pourrait régresser. Pour une modification d’architecture, demandez quel propriétaire, quelle limite ou quel contrat existant serait dupliqué.

Cela fait passer le travail de « produire du code maintenant » à « prendre une décision défendable, puis l’implémenter ».

Utilisez ce modèle lorsqu’une tâche nécessite du contexte produit et technique :

Tâche : [Décrivez la modification en une phrase.]

Problème : [Qui est touché et qu’est-ce qui ne va pas ?]
Périmètre : [Fichiers, écrans, flux de travail ou sous-système concernés.]
Hypothèse : [Ce qui, selon vous, cause le problème ou quelle solution pourrait aider.]
Résultat souhaité : [Résultat observable pour l’utilisateur et le système.]
Contraintes : [Comportement à préserver, compatibilité, performances, accessibilité,
sécurité, déploiement et éléments hors périmètre.]
Contexte pertinent : [Architecture, flux de données, modifications récentes, journaux ou exemples.]
Critères d’acceptation : [Comment savoir que le travail est terminé.]
Validation : [Tests, vérifications manuelles ou mesures à exécuter.]

Avant de modifier le code, inspectez la zone concernée. Remettez l’hypothèse en question
si les éléments de preuve suggèrent une solution plus sûre ou plus restreinte.

Le modèle facilite aussi la revue : un coéquipier peut voir le résultat attendu et décider si l’implémentation proposée le satisfait.

Un contexte pertinent est sélectif. Incluez un test défaillant, un message d’erreur, la limite actuelle d’un composant, une charge utile de requête ou un court parcours utilisateur. Ne collez pas des milliers de lignes sans rapport en espérant que l’assistant trouve la partie importante.

Pour un flux de travail de programmation ciblé, consultez comment formuler des prompts à ChatGPT pour le code. Pour des modèles réutilisables concernant l’implémentation, le débogage et la revue, lisez l’ingénierie des prompts pour les développeurs.

Utilisez un guide spécifique à l’outil lorsque le contexte du dépôt modifie le prompt : formuler des prompts pour Cursor AI, bonnes pratiques de prompting avec GitHub Copilot ou obtenir de meilleurs résultats avec Claude Code.

Utilisez un guide spécifique à la tâche lorsque vous avez besoin de formulations prêtes à adapter : exemples d’ingénierie des prompts pour les ingénieurs logiciels, modèles de prompts pour refactoriser du code ou modèles de prompts pour déboguer des problèmes en production.

Utilisez un guide de décision lorsque le risque concerne le processus plutôt que la syntaxe : les erreurs des assistants de programmation IA et comment les éviter et comment les développeurs chevronnés utilisent l’IA différemment.

Les mêmes habitudes qui rendent les prompts d’IA utiles rendent aussi les tickets, les pull requests et les notes d’incident plus clairs : expliquez le problème, définissez le résultat, préservez les comportements importants et validez le résultat.

Lorsqu’une tâche implique une commande shell ou une sortie de terminal, rendez le comportement concret avant de demander à un assistant de le modifier. Exercez-vous aux flux de travail en ligne de commande dans le navigateur afin de reconnaître l’entrée, la sortie et le mode d’échec que vous souhaitez voir l’implémentation gérer.