Accueil › Bibliothèque de prompts › Prompt ChatGPT pour programmer

Prompt ChatGPT pour programmer

Un prompt de programmation précis qui produit du code propre et fonctionnel avec le contexte et les contraintes dont l’IA a besoin.

Code · Fonctionne très bien avec ChatGPT

Prompt prêt à copier

Tu es un ingénieur senior en [langage]. Écris du code pour [tâche].
Contexte : [framework/version, environnement, contraintes].
Entrées : [décris]. Sortie attendue : [décris].
Exigences :
- Code propre, lisible et idiomatique en [langage].
- Gère les cas limites et les erreurs avec élégance.
- Ajoute de brefs commentaires expliquant les parties non évidentes.
- Inclus un bref exemple d’utilisation.
- Indique toute hypothèse que tu as faite.

Tu veux une version sur mesure ?

Réponds à quelques questions rapides et le Générateur de prompts de code créera un prompt personnalisé avec tes données exactes.

💻 Ouvrir le Générateur de prompts de code

Pourquoi la plupart des prompts de programmation avec IA te font perdre du temps

Demande à ChatGPT d’"écrire une fonction pour téléverser un fichier" et tu obtiendras du code qui compile, s’exécute dans un environnement imaginaire et ne colle pas au tien. Il pourra supposer Python 3.12 alors que tu es en 3.8, choisir une bibliothèque que tu n’as pas installée ou gérer un format de fichier que tu n’as jamais mentionné. Le modèle ne devine pas au hasard : il comble les vides que tu as laissés ouverts avec les valeurs par défaut statistiquement les plus courantes. Chaque ambiguïté dans ta demande devient une décision que le modèle prend à ta place, et plus il prend de décisions, plus tu hérites de reprises. Le prompt ci-dessus fonctionne en comblant ces vides avant que le modèle n’écrive une seule ligne, ce qui transforme un brouillon grossier en code que tu peux souvent coller directement.

Le contexte est ce qui fait que le code colle à ta stack

La ligne de contexte — framework, version, environnement, contraintes — est le champ qui fait gagner le plus de temps. "Node 18 avec Express et TypeScript, sans bibliothèques HTTP externes, s’exécutant sur AWS Lambda" indique au modèle exactement quoi viser, et il évitera de suggérer un paquet que tu ne peux pas utiliser ou une syntaxe que ton runtime rejette. La version compte plus qu’on ne l’imagine : les patterns asynchrones, les fonctions de la bibliothèque standard et la syntaxe des types diffèrent d’une version à l’autre, et le code écrit pour la mauvaise version échoue de façons déroutantes. Indiquer les contraintes d’entrée ("doit être sans dépendances", "ne peut pas utiliser la récursion", "doit s’exécuter en moins de 100 ms sur une liste de 10 000 éléments") guide aussi le choix de l’algorithme, pas seulement la syntaxe. Sans cette ligne, le modèle optimise pour paraître correct isolément plutôt que pour fonctionner dans ton projet.

Entrées, sorties et cas limites

Décrire les entrées exactes et la sortie attendue élimine une autre classe entière de décalages. "Reçoit une liste de dictionnaires de commandes avec les clés id, total et statut ; renvoie la somme de total des commandes dont le statut est 'payé'" donne au modèle un contrat précis à satisfaire, et il façonnera la signature de la fonction et le type de retour en conséquence. L’exigence de gérer les cas limites et les erreurs avec élégance est ce qui sépare les extraits jetables du code prêt pour la production. Sans le lui indiquer, ChatGPT écrit pour le chemin heureux et ignore les entrées vides, les valeurs nulles, les données malformées et les échecs réseau. Nommer cette exigence l’oblige à ajouter les protections que tu découvrirais autrement en production. Quand tu peux, décris les cas limites concrets qui comptent pour tes données — une liste vide, une clé manquante, un timeout — pour que le modèle gère ceux que tu affrontes vraiment.

Les hypothèses et la vérification bouclent la boucle

La dernière exigence, "indique toute hypothèse que tu as faite", est la plus sous-utilisée et la plus précieuse. Le modèle fait toujours des hypothèses ; la seule question est de savoir si tu peux les voir. Quand il les écrit — "j’ai supposé que les horodatages sont en UTC", "j’ai supposé que l’entrée est déjà validée" — tu peux repérer une hypothèse erronée en quelques secondes au lieu de la déboguer pendant une heure. L’exemple d’utilisation remplit le même rôle de vérification : il te montre comment le code est censé être appelé et te permet de contrôler l’interface avant de l’intégrer. Même avec un bon prompt, traite le résultat comme le premier brouillon d’un ingénieur senior, pas comme un commit terminé. Lis-le, exécute-le contre un cas limite réel et, pour tout ce qui est important, enchaîne avec "écris des tests unitaires couvrant les cas d’entrée vide et d’erreur" pour te fier aux tests plutôt qu’au modèle.

Pourquoi ce prompt fonctionne

Les prompts de programmation vagues produisent du code qui ne colle pas à ta stack. Ce prompt fournit langage, framework, entrées et sorties d’emblée, pour que l’IA écrive du code idiomatique qui s’exécute vraiment dans ton environnement, et fait apparaître ses hypothèses pour que tu repères tôt les décalages.

Comment le personnaliser

Indique toujours la version du langage et le framework pour éviter le code incompatible.
Décris les entrées et les sorties attendues avec précision.
Demande des tests si la logique est importante.

Exemple de résultat

Juste un exemple

Prompt complété : langage = Python 3.9, tâche = "analyser un CSV de transactions et renvoyer le total d’une catégorie donnée", contraintes = "bibliothèque standard uniquement".

import csv
from decimal import Decimal, InvalidOperation

def total_for_category(csv_path, category):
    """Renvoie la somme de 'amount' des lignes correspondant à 'category'.

    Suppose que le CSV a les en-têtes 'category' et 'amount'.
    Ignore les lignes avec un amount manquant ou non numérique.
    """
    total = Decimal("0")
    with open(csv_path, newline="", encoding="utf-8") as f:
        reader = csv.DictReader(f)
        if reader.fieldnames is None or "amount" not in reader.fieldnames:
            raise ValueError("Le CSV doit avoir une colonne 'amount'")
        for row in reader:
            if row.get("category") != category:
                continue
            try:
                total += Decimal(row["amount"])
            except (InvalidOperation, TypeError):
                # Ignore les amounts malformes au lieu de casser toute l execution.
                continue
    return total

# Exemple d'utilisation :
# print(total_for_category("transactions.csv", "groceries"))

Hypothèses : les montants sont des chaînes décimales ; le fichier est en UTF-8 ; les lignes malformées doivent être ignorées, pas faire échouer toute l’analyse. On utilise Decimal plutôt que float pour éviter les erreurs d’arrondi avec l’argent.

Variantes de prompt à essayer

Expliquer l’approche avant de coder

Tu es un ingénieur senior en [langage]. J’ai besoin de [tâche], avec ces contraintes : [framework/version, environnement]. Avant d’écrire du code, explique brièvement l’approche que tu comptes suivre, les principaux compromis et toute décision où plus d’une option raisonnable existe. Attends que je confirme l’approche puis écris du code propre et idiomatique en [langage] avec gestion des erreurs et un exemple d’utilisation.

Refactoriser du code existant

Tu es un ingénieur senior en [langage]. Refactorise le code ci-dessous pour qu’il soit plus propre, lisible et idiomatique pour [framework/version], sans changer son comportement. Signale tout bug ou cas limite qu’il gère mal actuellement et ajoute la gestion des erreurs là où elle manque. Garde l’interface publique identique. Explique brièvement chaque changement significatif. Code : [colle le code].

Code et tests en même temps

Tu es un ingénieur senior en [langage]. Écris du code pour [tâche] en [framework/version], entrées [décris], sortie attendue [décris]. Puis écris un ensemble de tests unitaires avec [framework de tests] couvrant le chemin heureux, les entrées vides et nulles, les valeurs limites et au moins une condition d’erreur. Indique toute hypothèse. Garde le code comme les tests idiomatiques et lisibles.

Erreurs courantes à éviter

Omettre la version du langage. La syntaxe asynchrone, les fonctions de la bibliothèque standard et les annotations de types diffèrent d’une version à l’autre, donc le code pour la mauvaise version échoue bizarrement. Indique-la toujours : Python 3.9, Node 18, Java 17.
Ne pas décrire les entrées et sorties avec précision. "Traite les données" ne donne au modèle aucun contrat à satisfaire. Spécifie la forme exacte de l’entrée et ce que la fonction doit renvoyer.
Oublier de nommer les contraintes. Si tu ne peux pas ajouter de dépendances ou dois atteindre un objectif de performance, dis-le d’emblée ; sinon, le modèle choisit une bibliothèque que tu n’as pas ou un algorithme trop lent.
Sauter la gestion des erreurs dans la demande. Sans le lui indiquer, ChatGPT n’écrit que le chemin heureux. Demande-lui explicitement de gérer les entrées vides, les nuls et les échecs, en nommant idéalement ceux que tes données produisent vraiment.
Se fier au code sans l’exécuter. Même un brouillon bien construit peut traîner une hypothèse erronée. Exécute-le contre un cas limite réel et demande des tests unitaires avant de dépendre de quoi que ce soit d’important : traite le résultat comme un premier brouillon, pas comme un commit.

Questions fréquentes

Pourquoi ChatGPT me donne-t-il du code qui ne fonctionne pas dans mon projet ?

Presque toujours parce que le prompt a laissé l’environnement non spécifié. Le modèle se rabat sur la version du langage et les bibliothèques les plus courantes, qui peuvent ne pas correspondre aux tiennes. Remplir le champ de contexte — framework, version et contraintes — résout la plupart de ces décalages avant que le code ne soit écrit.

Devrais-je demander des tests en plus du code ?

Pour tout ce dont tu vas vraiment dépendre, oui. Les tests sont le moyen le plus fiable de vérifier le code écrit par IA, car ils attrapent les hypothèses erronées et les bugs de cas limites que le modèle a manqués. Ajoute "inclus des tests unitaires pour l’entrée vide et les cas d’erreur" au prompt, ou utilise la variation code et tests ci-dessus.

Comment éviter que l’IA fasse des hypothèses silencieuses ?

Garde l’exigence "indique toute hypothèse que tu as faite" dans chaque prompt de programmation. Le modèle suppose toujours quelque chose ; cela rend ces hypothèses visibles pour que tu puisses en repérer une erronée en quelques secondes. Quand une hypothèse listée est fausse, corrige-la simplement et demande une révision.

Est-il sûr de coller ce code directement en production ?

Traite-le comme le premier brouillon d’un ingénieur senior, pas comme un commit terminé. Lis-le, exécute-le contre des entrées réelles et de cas limites, revois les hypothèses indiquées et ajoute des tests pour tout ce qui est important. Un bon prompt te rapproche beaucoup, mais la revue humaine reste la dernière ligne de défense.

Astuce : remplace les parties entre [crochets] par tes propres informations avant d’envoyer. Plus tu es précis — public, ton, objectif, contraintes — meilleur sera le résultat de l’IA.