# À quoi ressemble un bon prompt pour un développeur?

Date: 2023-09-11 · Author: Robert Scales · https://guidetoartificialintelligence.com/fr/apprendre/bon-prompt-developpeur/

**Answer:** Un bon prompt de programmation se lit comme un petit billet de travail : le langage et sa version, le code qui l’entoure, l’interface exacte, les contraintes, les cas de test qui définissent ce qui est « terminé », et une demande d’expliquer les choix et d’énumérer les hypothèses. Plus vous y mettez de la réalité de votre projet, moins le code que vous recevez est générique.

« Écris une fonction qui analyse des durées » vous donnera une fonction. Elle sera peut-être dans la mauvaise version du langage, fera appel à une bibliothèque que vous n’utilisez pas, gérera des formats que vous ne voyez jamais et ratera ceux que vous voyez. Le modèle n’est pas négligent; il remplit simplement chaque vide que vous laissez avec le choix le plus courant qu’il a vu. Un bon prompt de développeur comble ces vides comme le fait un billet de travail bien rédigé.

*ChatGPT : Le Guide Pour Débutant* illustre l’idée par une progression simple. « Aide-moi à corriger ce code » n’apporte pas grand-chose d’utile. Nommer le langage et le type de problème donne une réponse ciblée. Demander une révision de qualités précises, avec le raisonnement derrière chaque suggestion, donne la réponse la plus utile. La même progression s’applique à l’écriture de nouveau code.

## Ce que doit contenir un prompt de développeur

1. **L’environnement.** Le langage, la version, l’environnement d’exécution et le cadriciel : « Node.js 18, JavaScript simple, modules ES. »
2. **Le contexte.** Le code autour de la modification, ou au moins les types et les signatures de fonctions avec lesquels elle doit s’intégrer.
3. **L’interface.** Le nom de la fonction, les paramètres, la valeur de retour et la façon de signaler les erreurs.
4. **Les contraintes.** Aucune nouvelle dépendance, des limites de performance, la prise en charge des navigateurs, le style maison.
5. **Les tests d’acceptation.** Des entrées concrètes et les sorties attendues, que vous écrivez vous-même.
6. **L’explication.** Demandez une courte note sur les choix de conception et une liste des hypothèses.

Les deux dernières parties font le plus gros du travail. Vos cas de test transforment un objectif vague en objectif précis, et une liste d’hypothèses vous montre où le modèle a deviné.

## Un exemple complet : un analyseur de durées

Supposons que votre application permet aux utilisateurs de taper des durées de vidéo comme `1h30m` et que vous avez besoin de secondes.

```prompt
Tu es un développeur JavaScript principal qui révise et écrit du code de production.

Environnement : Node.js 18, JavaScript simple (pas de TypeScript), modules ES. Aucune nouvelle dépendance npm.

Tâche : écris une fonction exportée parseDuration(text) dans un fichier duration.js.
- Elle accepte des chaînes composées d’heures, de minutes et de secondes dans cet ordre, chacune facultative, mais au moins une présente : "2h", "45m", "1h30m", "1h5m20s". Accepte les espaces autour ainsi que les majuscules ou les minuscules.
- Elle renvoie le nombre total de secondes sous forme d’entier.
- Elle lève une RangeError avec un message clair pour tout le reste, y compris "", "1.5h", "30m1h" et "-5m".

Tests d’acceptation (ils doivent réussir) :
parseDuration("1h30m") === 5400
parseDuration(" 45M ") === 2700
parseDuration("1h5m20s") === 3920
parseDuration("30m1h") lève une RangeError

Après le code, écris les mêmes tests avec l’exécuteur de tests intégré de Node (`node:test` et `node:assert`). Énumère ensuite les hypothèses que tu as faites et explique ton approche d’analyse en trois phrases.
```

Remarquez ce que le prompt exclut. Nommer Node 18 et son exécuteur de tests intégré évite une réponse qui installe un cadriciel de test que vous n’utilisez pas. Énumérer les entrées invalides force une décision sur les décimales et l’ordre au lieu de laisser faire le hasard. Et demander les hypothèses peut faire ressortir une chose que vous n’aviez pas tranchée, par exemple si `0h` est valide.

## Deux autres tâches de développeur, deux autres prompts

**Remanier sans changer le comportement.** Collez la fonction et ses tests, puis ajoutez : « Remanie ce code pour le rendre plus lisible. Garde l’interface publique et fais en sorte que tous les tests réussissent encore. Ne change pas le comportement, même pour les cas limites. Montre le diff et explique chaque changement en une ligne. » Les tests servent de verrou sur le comportement.

**Réviser votre propre code.** Collez une fonction et demandez des vérifications précises plutôt que des conseils généraux : « Révise ce code pour la validation des entrées, la gestion des erreurs et la performance sur des listes de 100 000 éléments. Pour chaque problème, cite la ligne, explique le risque et suggère une correction. Écris “aucun problème trouvé” pour toute catégorie qui est correcte. » Nommer les catégories garde la révision centrée sur ce qui compte pour vous.

> **À essayer :** prenez une petite fonction que vous avez écrite récemment. Écrivez le prompt comme si vous la demandiez à partir de zéro, avec l’environnement, l’interface, les contraintes et quatre cas de test. Comparez la version du modèle avec la vôtre, et notez lesquelles de ses hypothèses vous auriez tranchées autrement.

## Comment obtenir du code fiable?

Traitez chaque réponse comme une demande de fusion (*pull request*) d’un collègue que vous venez de rencontrer : utile, souvent bonne, et jamais fusionnée sans révision. L’article précédent sur la question de savoir si ChatGPT peut écrire du code fiable décrit la boucle de test et de correction; les habitudes ci-dessous viennent avant et après cette boucle.

**Soyez maître des tests.** Écrivez vous-même les tests d’acceptation, à partir de vos exigences, avant de lire le code généré. Les tests que le modèle écrit pour son propre code peuvent simplement confirmer ce qu’il a déjà fait, erreurs comprises.

**Exécutez le code dans un vrai environnement.** Les abonnés à ChatGPT Plus peuvent utiliser *Code Interpreter*, qu’OpenAI a déployé en juillet et qu’elle appelle maintenant *Advanced Data Analysis* (analyse de données avancée). Il permet à ChatGPT d’exécuter réellement du code et d’en montrer le résultat, ce qui attrape certaines erreurs tôt. C’est toutefois un bac à sable, pas votre projet : pour tout ce qui dépend de vos versions et de votre configuration, exécutez les tests dans votre propre environnement.

**Vérifiez chaque nom dans la documentation.** Des méthodes, des options et des paquets peuvent avoir l’air corrects et ne pas exister, ou n’exister que dans une autre version. Cherchez tout ce qui vous est inconnu dans la documentation officielle de la version que vous avez nommée.

**Gardez les changements petits.** Demandez une fonction ou un changement à la fois, pour que chaque diff soit assez court pour être lu ligne par ligne.

**Faites attention à ce que vous collez.** Retirez les clés d’API, les mots de passe, les données de clients et tout ce que votre employeur considère comme confidentiel avant de partager du code. Lisez la politique de votre entreprise sur les outils d’IA; certaines équipes utilisent des forfaits d’affaires aux conditions différentes pour les données, et d’autres ne permettent pas du tout de coller du code.

## Sources

- A Beginner's Guide to ChatGPT: https://www.amazon.com/dp/B0BZRRPXZW
- ChatGPT — Release Notes: https://help.openai.com/en/articles/6825453-chatgpt-release-notes
- Introducing ChatGPT Enterprise: https://openai.com/index/introducing-chatgpt-enterprise/