Prompt Engineering pour la génération de code : bonnes pratiques et anti‑patterns
Découvrez comment structurer des prompts efficaces pour générer du code fiable, et évitez les pièges qui sabotent la productivité des équipes IA.
Pourquoi le prompt engineering est crucial
Dans les pipelines d’industrialisation du développement assisté par IA, le prompt est le point d’entrée de la chaîne de valeur. Un prompt mal formulé entraîne :
- Des réponses non compilables ou hors‑contexte, augmentant le temps de revue.
- Une consommation inutile de crédits d’API, ce qui pénalise le budget projet.
- Des risques de sécurité lorsque le modèle génère du code contenant des vulnérabilités connues.
En intégrant le prompt engineering comme discipline, les équipes peuvent transformer un modèle de langage en un véritable code generator fiable, comparable à un composant réutilisable dans un système CI/CD.
Principes de conception de prompts pour le code
-
Définir clairement le contrat d’entrée/sortie
- Spécifiez le langage, la version du compilateur et les dépendances attendues.
- Exemple : « Génère une fonction Python 3.11 qui calcule la moyenne pondérée d’une liste de tuples (valeur, poids). »
-
Utiliser le format few‑shot
- Présentez un ou deux exemples de fonction correctement commentée, puis demandez la variante souhaitée.
- Cela ancre le style et réduit les variations de style de code.
-
Encadrer les contraintes de sécurité
- Ajoutez explicitement : « N’utilise aucune bibliothèque externe non‑standard. »
- « Ne génère aucun appel réseau ou accès fichier. »
-
Limiter la portée
- Un prompt doit demander une tâche atomique : une fonction, une classe ou un fragment, jamais un module complet.
- Cela simplifie la validation automatique (lint, tests unitaires).
-
Décrire les tests attendus
- Incluez le cas d’usage sous forme de test pytest ou de scénario d’appel, afin que le modèle produce du code déjà couvert.
Anti‑patterns courants et comment les éviter
| Anti‑pattern | Conséquence | Remède |
|---|---|---|
| Prompt vague (« Écris du code ») | Sortie trop générique, souvent non compilable. | Spécifier le langage, la signature de fonction, les contraintes environnementales. |
| Demande de « optimiser à tout prix » | Le modèle peut proposer des constructions obscures, difficiles à maintenir. | Privilégier la lisibilité ; demander explicitement « prioriser la clarté du code ». |
| Omission de tests | Aucun cadre de validation, augmentation du temps de revue. | Ajouter un snippet de test attendu ou demander le code accompagné d’un test unitaire. |
| Référence à des bibliothèques propriétaires | Le modèle ne les connaît pas, génère des alternatives inadéquates. | Limiter aux bibliothèques standard ou fournir la signature de l’API personnalisée. |
| Prompt trop long | Dilution du signal principal, pertes de contexte. | Utiliser le principe KISS : un prompt, un exemple, un test – pas plus de 150 tokens. |
Exemple de pipeline intégré dans un workflow CI/CD
# .github/workflows/codegen.yml
name: Code Generation
on:
workflow_dispatch:
inputs:
feature:
description: 'Nom de la fonctionnalité à implémenter'
required: true
jobs:
generate:
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v3
- name: Build prompt
id: prompt
run: |
cat <<EOF > prompt.txt
# Language: Python 3.11
# Feature: ${{ github.event.inputs.feature }}
# Requirements: no external dependencies, include a pytest test.
# Example:
def add(a: int, b: int) -> int:
"""Return the sum of a and b."""
return a + b
# Write the requested function below.
EOF
- name: Call OpenAI API
env:
OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
run: |
response=$(curl https://api.openai.com/v1/chat/completions \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-H "Content-Type: application/json" \
-d '{"model":"gpt-4o-mini","messages":[{"role":"user","content":"$(cat prompt.txt)"}]}'
)
echo "$response" | jq -r '.choices[0].message.content' > generated.py
- name: Lint & Test
run: |
python -m pip install flake8 pytest
flake8 generated.py
pytest generated.py
- name: Commit generated code
if: success()
run: |
git config user.name 'github-actions'
git config user.email 'actions@github.com'
git add generated.py
git commit -m "feat: add generated code for ${{ github.event.inputs.feature }}"
git push
Ce workflow illustre :
- La construction d’un prompt programmatique à partir d’une variable d’entrée.
- L’appel à l’API d’un grand modèle (GPT‑4o‑mini) via
curl. - La validation automatisée (lint + tests) avant d’intégrer le code dans la base.
- La traçabilité grâce à un commit dédié.
En appliquant les bonnes pratiques décrites précédemment, le même pipeline peut être généralisé à d’autres langages (Java, TypeScript) en adaptant le bloc few‑shot et les contraintes de sécurité. Le résultat est un développement assisté par IA qui s’intègre de façon transparente aux processus existants, tout en conservant la rigueur requise par les équipes produit.
Envie d’aller plus loin avec WORKFLOW v6 ?
Découvrir WORKFLOW v6