Utiliser Claude AI pour generer du code propre

Credit : Logo officiel

Utiliser Claude AI pour generer du code propre

Dylan D. — Agent Support Technique Serveur IA 2033 mots 11 min de lecture

Utiliser Claude AI pour generer du code propre

Lundi matin, un client me passe un script PHP qu'il a genere avec une IA. Trois cents lignes, aucun typage, des variables nommees $x, $tmp, $data2, et une fonction de connexion DB qui hardcode les credentials. Ca marche "techniquement" mais c'est invendable. Le probleme c'etait pas l'IA, c'etait le prompt : trois mots et un copier-coller de specs floues.

J'utilise Claude quasi tous les jours pour generer du code dans mon job d'agent support technique : scripts Bash, configurations Nginx, requetes SQL, hooks WordPress, Dockerfiles. Quand le prompt est bien construit, le rendu est vraiment exploitable en prod. Voila ma methode.

Pourquoi le prompt fait 80% du resultat

Une IA c'est un moteur d'inference. Plus tu lui donnes de contraintes claires, moins elle a de marge pour deviner mal. Trois axes a couvrir systematiquement :

  1. Le contexte technique : stack, versions, conventions du projet.
  2. L'objectif precis : que doit faire le code, quelles entrees, quelles sorties.
  3. Les contraintes de qualite : tests, gestion d'erreurs, limites de complexite.

Sans ces trois elements, tu vas recevoir du code generique qui marchera dans un cas sur trois et qu'il faudra refactorer integralement.

Les principes d'un bon prompt technique

1. Donner du contexte

Prompt faible :

Ecris une fonction pour valider un email

Prompt qui marche :

Ecris une fonction TypeScript qui valide une adresse email.
- Signature : validateEmail(email: string): { valid: boolean, error?: string }
- Regex conforme RFC 5322 simplifiee (pas la version 2KB)
- Verifier que le domaine a au moins un point
- Refuser les espaces et caracteres unicode hors latin
- Tests unitaires Vitest avec au moins 8 cas (valides, invalides, edge cases)
- Pas de dependance externe

La difference dans le rendu est enorme. Avec le prompt detaille, tu obtiens du code testable qui passe directement en code review. Avec le prompt vague, tu obtiens un fragment qu'il faudra rebrasser.

2. Definir les contraintes techniques

Moi je commence toujours par un bloc de contexte au debut de la conversation :

Contexte projet :
- API Express.js 4.x en TypeScript 5.4 strict
- Prisma ORM 5.x avec PostgreSQL 16
- Validation des inputs avec Zod
- Gestion d'erreurs centralisee via middleware errorHandler()
- Logging avec Pino
- Tests : Vitest + Supertest

Conventions :
- Pas de any, tout typage explicite
- async/await partout, jamais de .then()
- Imports : @/ pointe vers src/
- Fichiers : kebab-case.ts

Tache : Creer un endpoint POST /api/users qui cree un utilisateur
avec validation du body (name string min 2, email valide, role enum).
Return 201 + user, 400 si validation echoue, 409 si email deja pris.

Claude va produire du code coherent avec ta stack reelle. Sans contexte il devine, et souvent il choisit Express avec callbacks et JavaScript vanilla. Pas ce que tu veux.

3. Demander des explications avant les modifications

Avant de demander des changements sur un code qu'il a produit, je demande : "explique les choix techniques de cette implementation". Claude detaille pourquoi il a utilise telle approche, ce qui me permet de valider la logique avant de copier quoi que ce soit. Si l'explication est bancale, le code l'est probablement aussi.

Exemples concrets de prompts qui marchent

Script Bash robuste

Ecris un script Bash qui sauvegarde une base MariaDB sur un serveur
Debian 12. Le script doit :
- Etre en `set -euo pipefail`
- Utiliser mysqldump avec --single-transaction et --routines
- Compresser avec gzip niveau 9
- Stocker dans /home/backups/YYYY-MM-DD_HHMM/
- Supprimer les sauvegardes de plus de 14 jours
- Logger dans /var/log/backup.log avec timestamps
- Sortir en code 1 si echec, avec message clair
- Verifier l'espace disque avant (au moins 5 Go libres)

Le rendu inclura toutes ces validations. Sans la liste, Claude produira un script minimaliste qui fonctionne sur un cas heureux.

Configuration Nginx

Genere un vhost Nginx pour un site WordPress 6.5 en HTTPS sur Debian 12.
- Domaine : monsite.fr et www.monsite.fr (redirection vers non-www)
- PHP-FPM 8.3 via socket /run/php/php8.3-fpm.sock
- Redirection HTTP vers HTTPS
- Certificats Let's Encrypt (chemins standards Certbot)
- TLS 1.2 et 1.3 uniquement, ciphers Mozilla intermediate
- Headers HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy
- Cache assets statiques (jpg, png, css, js) : 30 jours, immutable
- FastCGI cache pour les pages (1h), bypass pour wp-admin et users connectes
- Bloquer xmlrpc.php (return 444)
- Rate limiting wp-login.php : 5 req/min par IP
- Logs separes /var/log/nginx/monsite.fr.{access,error}.log

Dockerfile multi-stage optimise

Cree un Dockerfile multi-stage pour une app Python 3.12 FastAPI :
- Stage builder : python:3.12-slim, installation des deps avec pip et requirements.txt
- Stage final : python:3.12-alpine, utilisateur non-root nommee "app" (uid 1000)
- Copier uniquement les wheels du builder
- Healthcheck : curl http://localhost:8000/health toutes les 30s
- Labels OCI : title, description, source, licenses
- ENTRYPOINT exec form, CMD lance uvicorn avec --host 0.0.0.0 --port 8000
- .dockerignore associe (exclure tests/, .git/, __pycache__/)

Bonnes pratiques de travail avec Claude

Iterer progressivement, jamais d'un seul coup

Fais pas tout d'un coup. Decoupe en etapes :

  1. "Genere la structure du projet et les types"
  2. "Implemente la couche persistance avec Prisma"
  3. "Ajoute les controllers Express avec validation Zod"
  4. "Ajoute la gestion d'erreurs centralisee"
  5. "Genere les tests unitaires et d'integration"
  6. "Optimise les requetes (N+1, indexes manquants)"

A chaque etape je relis et je valide. Comme ca quand un truc deconne, je sais d'ou ca vient.

Demander une revue de mon propre code

L'inverse marche tres bien aussi. Colle ton code et demande une analyse :

Revois ce code Python et identifie :
- Les problemes de securite (injection, deserialisation, secrets)
- Les violations PEP 8 et idiomes non-pythoniques
- Les optimisations possibles (algos, requetes DB, allocations)
- Les cas limites non geres
- Les tests manquants
Donne-moi une priorite (P0/P1/P2) pour chaque finding.

[code ici]

J'ai trouve des injections SQL dans mon propre code WordPress comme ca. Un peu humiliant, mais mieux vaut les trouver avant la prod qu'apres un defacement.

Fournir des exemples de sortie attendus

Si tu attends un format precis (JSON structure, format de log, schema DB), montre un exemple. Claude s'aligne dessus :

Format attendu pour la fonction parseLogLine :
Input : '2026-05-07 14:22:18 [ERROR] Connection refused to 192.168.1.10:3306'
Output :
{
  timestamp: '2026-05-07T14:22:18',
  level: 'ERROR',
  message: 'Connection refused to 192.168.1.10:3306',
  meta: { host: '192.168.1.10', port: 3306 }
}

Les artifacts pour le code long

Pour du code de plus de 50 lignes, demande explicitement de l'utiliser comme un artifact ou de le mettre dans un bloc de code unique. Sinon Claude a tendance a fragmenter en tranches commentees, ce qui est galere a copier-coller.

Erreurs courantes et leur fix

Le code utilise une lib qui n'existe pas

Cause : Claude a halluciné un nom de package, ou utilise une version qui a change d'API.

Fix : verifie sur npm/PyPI/packagist avant d'installer. Si la lib n'existe pas, redemande en specifiant les libs autorisees : "utilise uniquement axios, zod, et dotenv".

Le code marche en local mais plante en prod

Cause : differences d'environnement non specifiees dans le prompt (Node version, chemins absolus, variables d'env).

Fix : ajoute au prompt initial "cible : Debian 12, Node 20.x, deploye dans /var/www/app, NODE_ENV=production". Le code genere prendra en compte ces contraintes.

Versions obsoletes des dependances

Cause : Claude utilise une version qu'il connait mais qui est deprecated.

Fix : impose les versions dans le prompt : "Express 4.19+, TypeScript 5.4+, ESLint flat config". Ou demande explicitement : "utilise les API les plus recentes de Express".

Du code syntaxiquement correct mais logiquement faux

Cause : l'IA a compris la requete de travers (typique : confusion entre user.id et session.userId).

Fix : teste systematiquement, meme sur du code qui parait simple. Et n'oublie pas de demander explicitement les tests : sans tests demandes, Claude n'en genere souvent pas.

Secrets ou credentials dans le code

Cause : Claude a invente des valeurs pour faire fonctionner l'exemple.

Fix : remplace immediatement par des process.env.DB_PASSWORD. Et passe le code dans un secret scanner (gitleaks detect) avant de commit.

Ou Claude excelle (et ou il rame)

Forces concretes

Limites a connaitre

Mon workflow concret au quotidien

Voici comment j'utilise Claude sur un cas concret recent : ajouter un endpoint d'export CSV sur une API Express existante.

Etape 1 : nourrir le contexte

Voici la structure actuelle de mon API (arborescence + 3 fichiers cles).
Stack : Express 4.19, TypeScript 5.4, Prisma 5, PostgreSQL 16.
Convention : controllers dans src/controllers/, services dans src/services/,
routes dans src/routes/. Validation Zod, middleware auth via JWT.
[colle ici les 3 fichiers pertinents]

Etape 2 : demander la specification avant le code

Avant d'ecrire le code, propose-moi :
1. La signature exacte de la route (verbe, path, query params)
2. Le format CSV de sortie (colonnes, encoding)
3. La gestion des gros volumes (streaming ou pas ?)
4. Les permissions necessaires
Attends ma validation avant de coder.

Etape 3 : coder par couche

OK valide. Maintenant ecris uniquement le service ExportService
qui prend des filtres et retourne un Readable stream CSV.
Pas le controller ni la route pour l'instant.

Etape 4 : tests avant integration

Genere les tests unitaires Vitest pour ce service.
Mock Prisma avec vitest-mock-extended.
Couvre : cas nominal, filtres vides, gros volume (10k lignes), erreur DB.

Etape 5 : integration

Maintenant le controller et la route, en suivant nos conventions.
N'oublie pas la validation Zod du query.

Resultat : en 30 minutes j'ai un endpoint propre, teste, integre. Si j'avais demande tout d'un coup en un seul prompt, j'aurais passe 2 heures a refactorer un truc bancal.

Pour aller plus loin

La regle d'or : prompt precis, code utilisable

L'IA remplace pas le developpeur, mais elle accelere clairement le travail quand on sait s'en servir. La cle c'est la qualite du prompt : plus c'est precis, plus c'est contextualise, plus le rendu est exploitable directement. Investis cinq minutes a rediger un bon prompt plutot que cinquante minutes a refactorer un code mal genere. Et teste tout. Toujours.

EDIT 2026 : Les modeles ont fait des progres enormes ces derniers mois sur la coherence et la gestion du contexte long. Avec un fichier de specs bien fait au debut de la conversation, on peut faire generer des features completes coherentes avec le reste du projet. C'est aujourd'hui une partie integrante de mon workflow quotidien.

# Articles similaires

Sur les memes sujets et plus loin