Décomposer, itérer, choisir le bon prompt

8.8 Décomposer une tâche complexe 🪜

Définition

Décomposer une tâche complexe signifie transformer une grosse demande risquée en plusieurs petites étapes contrôlables.

Au lieu de demander :

Rewrite the whole app.

Tu demandes :

1. Explain the current architecture.
2. Create a migration plan.
3. Identify affected files.
4. Modify one module.
5. Add tests.
6. Review the diff.

GitHub recommande de découper les tâches complexes en tâches plus simples et d’itérer avec Copilot pour obtenir de meilleurs résultats. (docs.github.com)

Mauvais prompt ❌

Migrate this application from REST to GraphQL.

Problèmes :

• trop large ;
• trop risqué ;
• manque de stratégie ;
• risque de modifier trop de fichiers ;
• tests oubliés ;
• impact sécurité non évalué.

Bon découpage ✅

Étape 1 — Comprendre

Explain the current REST API structure.
Identify controllers, services, authentication logic, and response formats.
Do not modify code.

Étape 2 — Planifier

Create a migration plan from REST to GraphQL.
Include affected files, schema design, resolver strategy, auth impact, tests, and rollout risks.
Do not modify code yet.

Étape 3 — Implémenter une partie

Implement only the GraphQL query for fetching a user by ID.
Reuse the existing UserService.
Do not change REST endpoints.
Add tests.

Étape 4 — Valider

Review the changes for backward compatibility, security, and missing tests.

Exemple sécurité

Mauvais prompt :

Secure this service.

Bon découpage :

First, review this service for security risks.
Do not modify code.
Focus on auth, authorization, input validation, injection, and secrets.

Puis :

Create a prioritized remediation plan.

Puis :

Apply only the input validation fixes.
Preserve public behavior.
Add tests.

Exemple legacy

Mauvais prompt :

Refactor this legacy module.

Bon prompt :

Analyze this legacy module and identify:
- responsibilities
- dependencies
- side effects
- hard-to-test areas
- risky code paths

Do not modify code.

Ensuite :

Create a safe refactoring plan that preserves behavior and adds tests before changing logic.

8.9 Itérer sur une réponse Copilot 🔁

Définition

Itérer signifie ne pas s’arrêter à la première réponse de Copilot.

Tu peux améliorer progressivement la réponse :

• ajouter des contraintes
• demander une explication
• demander une alternative
• corriger une erreur
• demander des tests
• réduire le scope
• demander une solution plus sûre

GitHub conseille d’expérimenter et de reformuler les prompts si la réponse initiale n’est pas satisfaisante. (github.blog)

Exemple d’itération

Prompt initial :

Generate a function to validate passwords.

Réponse trop simple.

Tu continues :

Update the function to require:
- at least 12 characters
- one uppercase letter
- one lowercase letter
- one number
- one special character
Return a list of validation errors instead of a boolean.

Puis :

Add Jest tests for valid password, missing uppercase, missing number, too short, and multiple errors.

Puis :

Review the implementation for readability and edge cases.

Exemple avec bug

Copilot propose :

def average(numbers):
    if not numbers:
        return 0
    return sum(numbers) / len(numbers)

Tu n’es pas d’accord avec return 0.

Tu réponds :

Do not return 0 for an empty list.
Raise ValueError instead because empty input is invalid in this domain.
Update the tests accordingly.

Exemple avec sécurité

Copilot propose une requête SQL en string interpolation.

Tu réponds :

Rewrite this using parameterized queries.
Explain why the previous version was vulnerable to SQL injection.

Bonnes questions à poser après une réponse

Après une réponse Copilot, tu peux demander :

• Quelle hypothèse as-tu faite ?
• Quels fichiers seraient impactés ?
• Quels tests faut-il ajouter ?
• Quels risques de régression existent ?
• Quelle alternative plus simple existe ?
• Quelle alternative plus sûre existe ?
• Est-ce que cette solution respecte les contraintes ?
• Quels edge cases ne sont pas couverts ?

À retenir :

La première réponse est souvent un brouillon.
L’itération sert à rendre la réponse plus précise, plus sûre et plus testable.

8.10 Gérer l’historique de chat 🧹

Définition

L’historique de chat peut aider Copilot à comprendre une conversation, mais il peut aussi polluer le contexte.

Il devient problématique quand :

• le sujet a changé ;
• une ancienne contrainte n’est plus valable ;
• un ancien framework a été mentionné ;
• une mauvaise hypothèse a été acceptée ;
• des fichiers ou exemples obsolètes ont influencé la réponse.

Exemple

Tu as d’abord demandé :

Generate a MongoDB repository.

Puis tu veux maintenant :

Generate a PostgreSQL repository using Prisma.

Risque :

Copilot peut rester influencé par le contexte MongoDB.

Bon prompt :

Ignore the previous MongoDB-related context.
For this task, use PostgreSQL with Prisma only.
Generate a repository method to find active users by email domain.
Follow the existing UserRepository.ts style.

Bonne pratique

Si le contexte est pollué :

• commence une nouvelle conversation ;
• précise ce qu’il faut ignorer ;
• rappelle la nouvelle source de vérité ;
• reformule les contraintes importantes ;
• garde uniquement les fichiers pertinents ouverts.

Exercice 5 — Historique pollué

Situation :

Dans la conversation, tu as d’abord demandé une solution MongoDB. Maintenant, tu veux une solution PostgreSQL avec Prisma.

Bon prompt :

Ignore the previous MongoDB-related context.
For this task, use PostgreSQL with Prisma only.
Generate a repository method to find active users by email domain.
Follow the existing UserRepository.ts style.