Prompt Dev Avancé

1 Architecture API RESTful complète

Concevoir une API moderne, évolutive, et production-ready nécessite de la structure. Voici comment demander à Copilot de générer une API complète sans compromis.

Le prompt complet

Prompt Agent
Concevoir une API REST v1 pour [domaine : e-commerce / CRM / IoT...].

Spécification détaillée :
- Ressources principales : [list avec relations]
- Authentification : JWT + refresh token (expiration 24h/7j)
- Autorisation : Role-based (User, Admin, SuperAdmin)
- Rate limiting : 100 req/min par user, 1000 req/min global
- Pagination : cursor-based ou offset (specify)
- Versioning : URL-based (/api/v1/...)
- HATEOAS : inclure _links dans les réponses

Schéma de réponse normalisé :
```json
{
  "success": true|false,
  "data": {...|[...]},
  "errors": [
    { "code": "RESOURCE_NOT_FOUND", "message": "...", "field": "id" }
  ],
  "meta": {
    "timestamp": "2026-03-01T10:30:00Z",
    "pagination": { "page": 1, "perPage": 20, "total": 100, "hasNext": true }
  }
}
```

Codes HTTP requis : 200, 201, 204, 400, 401, 403, 404, 409, 422, 429, 500

Génère :
1. OpenAPI 3.0.0 complet (Swagger)
2. Implémentation en [Express/NestJS/FastAPI] avec TypeScript
3. Schemas de validation (Zod/Pydantic)
4. Middleware d'auth, rate limiting, error handling
5. Tests d'intégration pour chaque endpoint (Happy path + edge cases)
6. Documentation en markdown avec exemples cURL

Cas avancés à couvrir

• Soft deletes : les ressources supprimées restent en BD, juste marquées
• Audit logging : tracer qui a modifié quoi quand
• Webhooks : l'API notifie les clients d'événements
• Batch operations : créer/modifier 100 items en 1 request
• Partial updates (PATCH) : vs PUT (replace)

2 Architectures Micro-services & Event-driven

Décomposer un monolithe en services indépendants est complexe. Voici comment structurer le prompt pour que Copilot génère une architecture cohérente.

Stratégie de décomposition

Prompt Chat
Aide-moi à décomposer cette monolith [Shopp app] en micro-services.

Architecture actuelle :
[décrire le monolithe ou coller le code]

Critères de split obligatoires :
1. Domain-Driven Design (bounded contexts)
2. Chaque service = 1 équipe de 1-3 devs
3. Pas de dépendances circulaires
4. Chaque service a sa propre BD (CQRS si nécessaire)

Services candidates identifiés :
- UserService (auth, profile)
- ProductCatalogService (inventory, pricing)
- OrderService (order management)
- PaymentService (Stripe integration)
- NotificationService (emails, SMS, push)
- ShippingService (logistics, tracking)

Pour chaque service :
1. Responsabilités exactes
2. Données qu'il propriétaire
3. APIs qu'il expose
4. Événements qu'il émet/consomme
5. Dépendances externes
6. Schéma BD initial
7. Points critiques de résilience

Fournir :
- Diagramme Mermaid C4 (Context, Container, Component)
- Event catalog (JSON)
- Service mesh config (Istio ou Linkerd)

Event streaming & async messaging

Prompt Agent
Implémente le pattern SAGA pour les commandes multi-services.

Cas d'usage : User crée une commande
→ OrderService crée la commande
→ PaymentService charge la carte (peut échouer)
→ InventoryService décrémente le stock (peut échouer)
→ ShippingService crée un shipment
→ NotificationService envoie confirmation email

Avec compensation :
Si PaymentService rejette → annuler InventoryService + OrderService

Technologie : [Kafka / RabbitMQ / AWS SNS/SQS]

Génère :
1. Event definitions (TypeScript interfaces)
2. Saga orchestrator (idempotent, resilient)
3. Dead letter queue handling
4. Sagas replay & rollback logic
5. Tests intégrés avec testcontainers

3 GraphQL avec optimisations extrêmes

GraphQL est puissant mais peut devenir un cauchemar de performance. Voici comment demander une implémentation bulletproof.

Le prompt GraphQL avancé

Prompt Agent
Crée un schéma GraphQL production-ready pour [entités].

Optimisations obligatoires :
1. DataLoader → zéro N+1 queries
2. Batch size limits (max 1000 items par batch)
3. Query complexity scoring (prevent abuse)
4. Field-level auth (query l'email ? need IsAdmin)
5. Caching hints (@cacheControl directives)
6. Cursor-based pagination (vs offset)

Sécurité :
- Max query depth : 5 levels
- Max alias per query : 30
- Timeout : 30s per query
- Rate limiting : 10 queries/min par user

Erreurs détaillées :
- UNAUTHENTICATED
- FORBIDDEN
- RATE_LIMITED
- QUERY_TOO_COMPLEX
- TIMEOUT

Génère :
1. Schema GraphQL complet (.graphql file)
2. Resolvers TypeScript + DataLoader
3. Middleware de sécurité
4. Query complexity calculator
5. Benchmarks (show N+1 vs optimized)

Apollo Federation

Si vous avez plusieurs services avec leur propre GraphQL, utilisez Apollo Federation :

Prompt Chat
Implémente Apollo Federation pour fédérer 3 services GraphQL :
- UserGraph (users, profiles)
- ProductGraph (products, inventory)
- OrderGraph (orders, payments)

Chaque service reste indépendant mais clients voient 1 unified graph.

Génère :
1. Supergraph schema
2. Subgraph implementation pour chaque service
3. Apollo Router config
4. Tests de cross-service queries

4 Infrastructure & CI/CD avancée

Une pipeline moderne implique beaucoup de stages. Voici comment générer une infrastructure production-ready.

CI/CD 4 environnements

Prompt Agent
Crée une CI/CD GitHub Actions pour [app Node.js / Python / Go].

Environnements :
1. DEV : auto-deploy à chaque push sur develop
2. STAGING : manual trigger, environment-level approvals
3. CANARY : 5% traffic vers new version, 24h canary
4. PROD : manual approval, blue-green deployment

Stages pour chaque env :
1. Lint (ESLint + Prettier)
2. Type check (TypeScript ou mypy)
3. Test unit + integration (>80% coverage)
4. Security scan (npm audit, SNYK, SonarQube)
5. Build (slim Docker image)
6. Image scan (Trivy)
7. Deploy (Kubernetes, GitOps)
8. Smoke tests (API health check)
9. Performance benchmarks (vs baseline)
10. Rollback ready (1-click)

Pour chaque stage qui échoue : créer une issue GitHub auto

Secrets management : AWS Secrets Manager / GitHub Secrets

Génère :
1. .github/workflows/*.yml complet
2. Dockerfile optimisé multi-stage
3. Kubernetes manifests (Helm charts)
4. Monitoring alerts (Prometheus/Datadog)

Infrastructure as Code

Prompt Chat
Génère Terraform pour déployer sur [AWS / GCP / Azure].

Ressources requises :
- VPC + subnets (privé/public)
- RDS PostgreSQL (replicated, automated backups)
- Redis (cache, sessions)
- S3 buckets (versioned, encrypted)
- ALB / API Gateway
- CloudFront CDN
- CloudWatch logs + alarms
- IAM roles + policies (least privilege)

Production hardening :
- Enable encryption everywhere
- MFA required for console access
- WAF rules pour DDoS
- VPC Flow Logs enabled
- GuardDuty enabled
- Config & Compliance monitoring

Génère :
1. main.tf, variables.tf, outputs.tf
2. Terraform modules pour réusabilité
3. terraform.tfvars (example)
4. Script de destruction sûre

5 Stratégies de testing au niveau Champion

Tester à 100%, mais intelligemment. Voici la matrice optimale.

Matrice de couverture

Prompt pour une suite complète

Prompt Agent
Crée une suite de tests complète pour [UserService].

Tests requis :

**Unit tests** (>90% couverture)
- Chaque fonction / méthode
- Tous les chemins (if/else)
- Edge cases (null, empty, max values)
- Error paths
Mocks : dépendances externes

**Integration tests** (>80% couverture)
- Avec base de données réelle (PostgreSQL test container)
- Avec Redis cache
- Avec email service mock
Fixtures : dados de test réalistes

**E2E tests** (user workflows)
1. User register → verify email → login
2. User change password → session invalidated
3. User 2FA enabled → login requires code
Utiliser Playwright depuis API jusqu'au navigateur

**Property-based tests** (fuzzing)
- Generate random valid/invalid inputs
- Assert invariants hold

Format :
- Chaque test = une fonction / test case
- Naming : describe('UserService', () => { test('should...', () => {}) })
- Setup/teardown : avant/après chaque test
- Timeout : approprié (unit: 1s, integration: 10s, e2e: 60s)

Génère :
1. Fichiers de test complets
2. Test data factories (chance.js / faker)
3. Mock implementations
4. Test utilities / helpers
5. CI integration (report + coverage)

6 Migration base de données (zéro downtime)

Migrer la DB d'une appli active est un art. Comet éviter les 30 minutes d'outage.

Stratégie Expand > Migrate > Contract

Prompt Agent
Planifie une migration BD zéro-downtime.

Changement : renommer « user_phone » → « user_contact_phone »

Réalité :
1. La base est utilisée 24/7 par 10,000 users
2. L'appli litMigration BD (zéro downtime)
   les données en lecture/écriture
3. Rollback doit être fast (<1 min)

Stratégie Expand > Migrate > Contract :

**Phase 1 : Expand (migration de schéma)**
- Ajouter la nouvelle colonne « user_contact_phone » (nullable)
- Créer un partial index sur OLD column

**Phase 2 : Migrate (copie des données)**
- Batch job : copier data old → new par chunks de 10k rows
- Time : pendant off-peak hours
- Monitor : % copied, error rate
- Rollback : déleter new column

**Phase 3 : Migrate code (double write/read)**
- Déployer appli v2 qui :
  - Écrit dans BOTH OLD + NEW colonnes
  - Lit de NEW, fallback sur OLD
- Keep en place 24h (ensure no regression)
- Rollback : revert code

**Phase 4 : Contract (cleanup)**
- Supprimer l'ancienne colonne
- Supprimer le partial index
- Analyse tabelle pour mettre à jour stats

Par étape : monitorer locks, query performance, erreurs

Génère :
1. Migrations SQL (Flyway/Alembic) avec rollback
2. ORM code (avant/après)
3. Monitoring queries (check % copied, locks)
4. Rollback runbooks
5. Communication à envoyer à l'équipe

Cas spécialisés

• Changer le type d'une colonne : INT → VARCHAR requiert souvent recréer l'index
• Ajouter une contrainte NOT NULL : doit d'abord remplir les NULLs
• Renommer une table : risky, préférer créer new + rename old
• Index sur expression : sur grandes tables, peut causer de locks

7 Débogage avancé de production

Votre appli ralentit en production mais tourne bien en local. Voici comment structurer une investigation méthodique avec Copilot.

Root Cause Analysis (RCA) structuré

Prompt Chat
Aidez-moi à faire une RCA (Root Cause Analysis) sur ce problème de prod.

Symptômes observés (06:15 UTC - 06:45 UTC) :
- API latency P99 : 2s → 15s (7x increased)
- Error rate : 0% → 12% (TimeoutError)
- CPU usage : 40% → 95%
- Memory : steady à 60%
- Database query time : 10ms → 800ms pour SELECT users

Contexte :
- 3000 RPS normally, 5000 RPS durant l'incident
- Déployment 15 minutes avant : added new feature "user recommendations"
- Feature utilise une NEW table « user_preferences » (5M rows)

Hypothèses à tester (du plus au moins probable) :
1. N+1 queries : user.recommendations cherche user_preferences X fois
2. Missing index : user_preferences.user_id non-indexed
3. Memory leak : feature accumule des données en RAM, garbage collection pauses
4. Deadlock : new queries contentionent pour les locks
5. Cache miss : Redis utilisé par old features, nouveau code bypasse cache

Pour chaque hypothèse :
1. Requête pour tester
2. Commande kubectl pour vérifier
3. Logs grep à faire
4. Metrics à checker

Fix minimal proposé pour rollback rapide :
- Peut-on désactiver la feature sans redeploy ?
- Peut-on ajouter un index sans bloquant l'appli ?

Génère :
1. Query lente expliquée (EXPLAIN ANALYZE)
2. Détails de chaque hypothèse
3. Commandes diagnostics exactes
4. Plan d'action immédiat vs long-term fix
5. Monitoring dashboard pour éviter récurrence

Debugging avec logs + metrics + traces

Prompt Agent
Implémente le distributed tracing pour [microservice].

Stack : Jaeger / Datadog / New Relic

Chaque request traverse plusieurs services :
API Gateway → OrderService → PaymentService → InventoryService

Avec tracing, visualization :
- Request ID propagé partout
- Chaque service logge son latency
- Bottleneck identifié en 2 secondes

Génère :
1. Instrumentation code (OpenTelemetry)
2. Jaeger/Datadog config
3. Dashboard avec flame graphs
4. Alerts si latency > SLO

8 Performance & Optimisation

Identifier les bottlenecks, optimiser les queries, et mettre en cache intelligemment. Des prompts pour transformer une app lente en app rapide.

Profiling d'application

Prompt Agent
Mon app Node.js/Express a des problèmes de performance.

Métriques actuelles :
- p50 latency : 120ms (acceptable)
- p95 latency : 2.8s (trop lent !)
- p99 latency : 8s (catastrophique)
- Throughput : 150 req/s (objectif : 500 req/s)
- Memory : 800MB RSS (semble élevé pour cette app)

Endpoints les plus lents :
1. GET /api/dashboard (3.2s) — agrège données de 5 tables
2. GET /api/reports/export (6s) — génère un CSV de 50k lignes
3. POST /api/search (1.5s) — recherche full-text sur 2M documents

Pour chaque endpoint, fais :
1. Analyse des causes probables (N+1, missing index, compute-heavy, I/O bound)
2. Profile plan : quelles métriques mesurer et comment
3. Fix proposé avec estimation de l'amélioration
4. Code du fix optimisé
5. Benchmark avant/après (script k6)

Stratégie de caching multi-niveaux

Prompt Chat
Conçois une stratégie de cache pour mon application.

Architecture actuelle : Express → PostgreSQL (pas de cache).

Niveaux de cache à implémenter :
1. In-memory (node-cache) : pour les données quasi-statiques (config, feature flags)
   - TTL : 5 min
   - Max size : 100MB
2. Redis : pour les données partagées entre instances
   - Sessions utilisateur (TTL: 24h)
   - Résultats de queries fréquentes (TTL: 30s-5min)
   - Rate limiting counters
3. CDN (CloudFront/Vercel Edge) : pour les assets et API responses publiques
   - Cache-Control headers
   - Stale-while-revalidate

Pour chaque niveau :
- Quand invalider le cache ?
- Pattern : cache-aside, write-through, ou write-behind ?
- Code d'implémentation (Redis service avec invalidation)
- Métriques à monitorer (hit rate, miss rate, eviction rate)

Génère un CacheService TypeScript réutilisable avec :
- get/set/del avec TTL
- Cache stampede protection (singleflight)
- Graceful degradation si Redis est down

Optimisation de queries SQL

Prompt Chat
Optimise cette query qui prend 3.2 secondes :

```sql
SELECT u.*, COUNT(o.id) as order_count, SUM(o.total) as total_spent
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE u.created_at > '2025-01-01'
GROUP BY u.id
ORDER BY total_spent DESC
LIMIT 50;
```

Table users : 500k rows. Table orders : 2M rows.

Fournir :
1. EXPLAIN ANALYZE de la query actuelle (simulé)
2. Indexes manquants à créer
3. Query réécrite optimisée
4. Alternatives : materialized view ? Denormalization ?
5. Estimation du speed-up attendu

9 Sécurité applicative

Audits OWASP, threat modeling, secure code review — des prompts pour construire des applications résistantes aux attaques.

Threat Modeling (STRIDE)

Prompt Agent
Fais un threat model STRIDE pour mon application.

Architecture :
- Frontend : React SPA (Vercel)
- API : Express.js (Railway)
- Auth : JWT + refresh tokens (httpOnly cookies)
- DB : PostgreSQL (Supabase)
- Storage : S3 pour les fichiers uploadés
- Payments : Stripe Checkout

Pour chaque composant, analyse les 6 catégories STRIDE :
- Spoofing (usurpation d'identité)
- Tampering (altération des données)
- Repudiation (nier une action)
- Information Disclosure (fuite de données)
- Denial of Service (déni de service)
- Elevation of Privilege (escalade de privilèges)

Format de sortie :
| Composant | Menace | Catégorie | Probabilité | Impact | Mitigation |

Puis pour les 5 menaces les plus critiques :
- Scénario d'attaque détaillé
- Code de la mitigation
- Test de vérification

Audit OWASP automatisé

Prompt Chat
Fais un audit de sécurité OWASP Top 10 (2025) sur ces fichiers :
#file:src/auth/login.controller.ts
#file:src/middleware/auth.middleware.ts
#file:src/routes/upload.routes.ts

Pour chaque vulnérabilité OWASP :
1. Scan le code pour des patterns dangereux
2. Si trouvé : montre la ligne + l'exploit possible
3. Propose le fix avec code corrigé
4. Ajoute un test de sécurité qui vérifie le fix

Checklist spécifique :
- [ ] Injection SQL (parameterized queries ?)
- [ ] XSS (output encoding ?)
- [ ] CSRF (token anti-CSRF ?)
- [ ] IDOR (vérification d'autorisation sur chaque resource ?)
- [ ] Rate limiting (brute force protection ?)
- [ ] Secrets exposés (pas de hardcoded keys ?)
- [ ] Headers de sécurité (Helmet.js ?)
- [ ] CORS (pas de wildcard en production ?)

Secure Code Review Checklist

Prompt Chat
Revois ce code avec un focus sécurité (#file:src/services/payment.service.ts).

Vérifie systématiquement :

1. INPUT VALIDATION
   - Tous les inputs sont validés (Zod/Joi) ?
   - Types numériques : overflow possible ?
   - Strings : longueur max définie ?

2. AUTHENTIFICATION
   - Chaque endpoint vérifie le token ?
   - Tokens expirés rejetés ?
   - Refresh token rotation implémentée ?

3. AUTORISATION
   - User A ne peut pas accéder aux données de User B ?
   - Rôles vérifiés avant les actions sensibles ?
   - Endpoints admin protégés ?

4. DATA PROTECTION
   - Passwords hashés (bcrypt, rounds >= 12) ?
   - PII non loggées ?
   - Données sensibles chiffrées at-rest ?

5. ERROR HANDLING
   - Pas de stack traces en production ?
   - Messages d'erreur génériques (pas "user not found" sur login) ?
   - Pas d'information disclosure dans les 500 ?

Gravité pour chaque finding : 🔴 Critical / 🟠 High / 🟡 Medium / 🟢 Low

10 Refactoring patterns

Des prompts systématiques pour moderniser du code legacy, appliquer les principes SOLID, et transformer des codebase chaotiques en code maintenable.

Audit de dette technique

Prompt Agent
Fais un audit de dette technique de ce projet.

Scanne #codebase et identifie :

1. CODE SMELLS (par priorité)
   - God classes (> 300 lignes)
   - God functions (> 50 lignes)
   - Duplication (DRY violations)
   - Dead code (fonctions jamais appelées)
   - Magic numbers / strings

2. ARCHITECTURE SMELLS
   - Circular dependencies
   - Layer violations (controller qui accède directement à la DB)
   - Couplage fort entre modules
   - Absence de interfaces/abstractions

3. TECH DEBT
   - Dépendances obsolètes (versions majeures en retard)
   - TODO/FIXME/HACK dans le code
   - Tests manquants (modules sans tests)
   - Configuration hardcodée

Format de sortie : tableau avec Fichier | Problème | Impact | Effort de fix | Priorité
Puis : plan de refactoring en 3 sprints (quick wins → medium → long-term)

Appliquer SOLID

Prompt Chat
Refactore ce fichier (#file:src/services/order.service.ts) en appliquant SOLID.

Pour chaque principe violé, montre :

S — Single Responsibility
→ Cette classe fait X, Y et Z. Séparer en 3 classes.

O — Open/Closed
→ Les conditions switch/if pour les types de paiement. Utiliser le pattern Strategy.

L — Liskov Substitution
→ Les sous-classes qui override en cassant le contrat parent.

I — Interface Segregation
→ L'interface IOrderService a 15 méthodes. Séparer en 3-4 interfaces spécialisées.

D — Dependency Inversion
→ new ConcreteRepository() dans le service. Injecter via le constructeur.

Pour chaque violation :
1. Code actuel (la ligne problématique)
2. Pourquoi c'est un problème
3. Code refactoré
4. Test qui valide le refactoring

Migration de legacy codebase

Prompt Agent
Plan de migration pour moderniser ce projet legacy.

État actuel :
- JavaScript ES5, pas de TypeScript
- Express 3.x (EOL)
- Callbacks partout (pas de Promises)
- Pas de tests
- Mongo sans ORM (raw driver)
- Pas de linting

État cible :
- TypeScript strict
- Express 5.x (ou Fastify)
- Async/await
- Tests Jest/Vitest >80% coverage
- Mongoose ou Prisma (si migration vers PostgreSQL)
- ESLint + Prettier

Stratégie INCRÉMENTALE (pas de big-bang rewrite) :
1. Phase 1 : Ajouter TypeScript progressivement (allowJs: true)
2. Phase 2 : Convertir fichier par fichier (commencer par les plus simples)
3. Phase 3 : Remplacer callbacks par async/await
4. Phase 4 : Ajouter les tests au fur et à mesure
5. Phase 5 : Upgrade Express

Pour chaque phase : durée estimée, risques, critère de "done".
Génère le script de migration pour la phase 1 (setup TypeScript).

11 Architecture front-end

State management, design systems, SSR/SSG, et composants réutilisables. Des prompts pour architecurer une app front-end scalable.

Design System complet

Prompt Agent
Crée un design system pour mon app React + TypeScript.

Composants de base (Atomic Design) :
Atoms : Button, Input, Label, Badge, Avatar, Icon, Spinner
Molecules : FormField (Label + Input + Error), SearchBar, Card, Toast
Organisms : Navbar, Sidebar, DataTable, Modal, Form

Pour chaque composant :
1. Props interface TypeScript (avec JSDoc)
2. Variants : taille (sm/md/lg), style (primary/secondary/ghost/danger)
3. States : default, hover, focus, disabled, loading, error
4. Accessibilité : aria-labels, keyboard navigation, focus trap (modals)
5. Storybook story avec tous les variants
6. Test : render + interaction (Testing Library)

Style : Tailwind CSS avec design tokens custom :
- Colors : primary, secondary, neutral, success, warning, danger
- Spacing : basé sur 4px (1=4px, 2=8px...)
- Typography : 5 scales (xs, sm, base, lg, xl)
- Radius : sm (4px), md (8px), lg (12px), full (9999px)
- Shadows : sm, md, lg

Structure : src/components/ui/[component]/index.tsx + [component].stories.tsx + [component].test.tsx

State Management avancé

Prompt Chat
Mon app React a un problème de state management.

Situation actuelle :
- useState partout (prop drilling sur 5 niveaux)
- Quelques useContext mais ça re-render toute l'app
- Pas de cache des API calls (fetch dans useEffect)
- Pas de state global pour l'auth

Propose une architecture avec :
1. Server state : TanStack Query (React Query)
   - Queries avec cache, refetch on focus, optimistic updates
   - Mutations avec invalidation de cache
   - Infinite scroll avec useInfiniteQuery

2. Client state : Zustand (léger, pas de boilerplate)
   - Auth store (user, token, login/logout actions)
   - UI store (sidebar open, theme, modal state)
   - Pas de state client pour les données serveur !

3. Form state : React Hook Form + Zod
   - Validation côté client et serveur
   - Multi-step forms avec persistence

Pour chaque couche :
- Setup code
- 2 exemples concrets
- Pattern d'organisation des fichiers

SSR / SSG avec Next.js

Prompt Agent
Migre cette app React (CRA/Vite) vers Next.js 14 App Router.

Pages à migrer :
1. / (landing) → Static (SSG)
2. /dashboard → Dynamic (SSR + auth required)
3. /blog/[slug] → Static + ISR (revalidate: 60s)
4. /api/* → Route Handlers (API internes)

Pour chaque page, montre :
- Le fichier page.tsx avec la bonne stratégie de rendu
- Metadata (SEO : title, description, og:image)
- Loading.tsx (skeleton pendant le chargement)
- Error.tsx (error boundary)
- Les server actions pour les mutations

Configuration :
- next.config.js optimisé (images, redirects, headers)
- Middleware pour l'auth (protéger /dashboard/*)
- Layout partagé avec navigation persistante

Bonus : sitemap.xml + robots.txt auto-générés

🌐 12. Copilot par langage

Chaque langage a ses idiomes. Adaptez vos prompts pour obtenir du code réellement idiomatique, pas du « pseudo-code traduit ».

🐍 Python

Python a ses propres conventions (PEP 8, type hints, dataclasses). Soyez explicite :

Python
Crée une dataclass `UserProfile` avec :
- name: str, email: str, age: int (optionnel, défaut None)
- Méthode `is_adult` qui retourne un bool
- Utilise `__post_init__` pour valider l'email (regex basique)
- Type hints complètes, docstrings Google-style
- Compatible Python 3.10+ (utilise `|` au lieu de Optional)

📘 TypeScript

TypeScript brille quand les types sont précis. Guidez Copilot avec des contraintes de typage :

TypeScript
Crée un hook React `useDebounce<T>(value: T, delay: number): T`
- Générique avec contrainte sur T
- Cleanup du timeout dans useEffect
- Strict mode compatible (pas de any)
- Exporte aussi le type `UseDebounceOptions` pour config avancée
- Ajoute des JSDoc avec @example

🦀 Rust

Rust demande une attention particulière au ownership et aux lifetimes :

Rust
Implémente un cache LRU thread-safe en Rust :
- Struct `LruCache<K, V>` avec capacité configurable
- Utilise `Arc<Mutex<...>>` pour le thread-safety
- Méthodes : get(&self, key) -> Option<&V>, put(&mut self, key, value)
- Implémente les traits Display et Debug
- Gestion propre des lifetimes (pas de 'static si évitable)
- Inclus des tests avec #[cfg(test)]

🗄️ SQL

Précisez toujours le SGBD cible — la syntaxe varie énormément :

PostgreSQL
Écris une requête PostgreSQL 15+ qui :
- Trouve les utilisateurs inactifs depuis 90 jours
- Avec leur dernier achat et le montant total dépensé
- Utilise des CTEs (WITH) pour la lisibilité
- Inclus un index recommandé pour optimiser cette requête
- Ajoute EXPLAIN ANALYZE en commentaire pour vérifier le plan

📋 Résumé par langage