11 - Applications au developpement
Six situations de travail reelles, et pour chacune le prompt exact a copier-coller pour gagner du temps sans perdre la maitrise de ton code.
Temps de lecture : 8 min | Niveau : Debutant a Intermediaire
Ce que tu sauras faire apres
- Choisir le bon fichier de cette section selon la situation ou tu es bloque.
- Reutiliser les templates sans avoir a inventer une seule formulation.
- Appliquer la regle de base de cette section : toujours donner au modele un moyen de verifier son travail.
- Enchainer les fichiers dans l ordre d une vraie journee de dev ou de data engineering.
Comment utiliser cette section
Cette section n est pas un cours a lire d une traite. Chaque fichier = une situation de travail.
Tu es devant ton ecran, tu es bloque, tu ouvres le fichier qui correspond, tu copies le template, tu remplis les [CHAMPS_A_REMPLIR], tu envoies.
| Tu es dans cette situation | Ouvre ce fichier |
|---|---|
| On vient de me donner acces a un repo que je ne connais pas | 01-comprendre-du-code-inconnu.md |
| Mon code marche mais il n a aucun test | 02-ecrire-et-corriger-des-tests.md |
| Je dois changer une techno, une version, ou nettoyer du vieux code | 03-refactoring-et-migration.md |
| Ca plante et je ne comprends pas pourquoi | 04-debug-et-analyse-derreur.md |
| Je veux qu on relise mon code avant de le pousser | 05-revue-de-code.md |
| Je dois ecrire un commit, une PR, une doc, une note | 06-documentation-commits-et-ecrit.md |
Le contenu de la section
01 - Comprendre du code inconnu
Comment explorer un repo qu on ne connait pas : partir du large, puis resserrer. Cartographier l architecture, comprendre une fonction precise, retracer un flux de donnees de bout en bout. Exemple deroule sur un projet Python + Airflow.
02 - Ecrire et corriger des tests
Faire generer des tests qui servent vraiment a quelque chose : cas limites, test de regression apres un bug, fixtures pytest, et le cas particulier des tests de pipeline de donnees (dbt, Airflow, pandas).
03 - Refactoring et migration
La methode par lots : filet de securite d abord, petits lots ensuite, verification apres chaque lot. Deux exemples concrets : passer un script pandas en PySpark, et migrer du SQL Oracle vers BigQuery.
04 - Debug et analyse d erreur
Le template de debug en quatre blocs (contexte / ce que j attends / ce que j obtiens / ce que j ai deja essaye). Lire une stack trace, traiter des logs trop volumineux, attaquer un bug intermittent.
05 - Revue de code
Une grille de revue en six dimensions, un prompt par dimension, et la technique la plus importante de la section : demander au modele de refuter ton code, pas de le valider.
06 - Documentation, commits et ecrit
Docstrings, README, messages de commit, description de pull request, note technique. Et surtout : le template qui transforme des notes brouillonnes en texte professionnel clair.
La regle qui traverse toute la section
Une seule idee revient dans les six fichiers, et elle vient directement de la documentation officielle de Claude Code :
"Claude stops when the work looks done. Without a check it can run, 'looks done' is the only signal available, and you become the verification loop." -- Best practices for Claude Code
Traduction pratique pour toi : ne demande jamais seulement "fais X". Demande "fais X, puis lance [COMMANDE_DE_VERIFICATION] et corrige jusqu a ce que ca passe."
Le check peut etre :
- une suite de tests (
pytest -q), - un build ou un lint (
ruff check .,mypy src/), - une requete SQL de controle qui compare l ancien et le nouveau resultat,
- un
dbt build --select mon_modele, - un simple
python mon_dag.pypour verifier qu un DAG Airflow se charge sans erreur.
Sans check, tu redeviens toi-meme le controleur, et tu perds le temps que tu croyais gagner.
Ordre de lecture conseille
Si tu veux lire la section en entier plutot que d y piocher :
- 01 (comprendre) - c est la base, tout le reste en depend.
- 04 (debug) - c est le gain de temps le plus immediat au quotidien.
- 02 (tests) - c est ce qui rend les fichiers 03 et 05 possibles.
- 03 (refactoring) - a ne faire que quand 02 est en place.
- 05 (revue) - le garde-fou avant de pousser.
- 06 (ecrit) - le fichier a garder ouvert en permanence si l ecrit te coute.
Convention des templates
Dans tous les fichiers, un template ressemble a ca :
Contexte : [DECRIS_LE_PROJET_EN_UNE_PHRASE]
Fichier concerne : @[CHEMIN/DU/FICHIER.py]
Ce que je veux : [OBJECTIF_PRECIS]
Verification : lance [COMMANDE] et corrige jusqu a ce que ca passe.- Tout ce qui est entre crochets et en MAJUSCULES est a remplacer.
- Le reste se copie tel quel, tu n as rien a reformuler.
- Le
@devant un chemin est une syntaxe Claude Code : elle injecte le contenu du fichier dans la conversation (reference files and directories). Dans un autre outil (ChatGPT, Copilot Chat, Gemini), remplace-le par un copier-coller du fichier.
A retenir
- Un fichier = une situation de travail. Tu ouvres celui dont tu as besoin, tu ne lis pas tout.
- Les templates sont a trous : tu remplis les
[CHAMPS], tu n inventes aucune formulation. - La regle unique de la section : toujours fournir un moyen de verifier (test, build, requete de controle).
- Commence large, puis resserre. Jamais l inverse.
- Ce que tu ne sais pas verifier, tu ne le livres pas.
Depots GitHub a explorer
Ces depots servent a voir sur du vrai code ce que les six situations de la section donnent en pratique : des bugs reels avec leurs tests, des agents qui explorent un depot etape par etape, des prompts de revue deja ecrits et utilises en production.
| Depot | Ce qu'on y trouve | Par ou commencer |
|---|---|---|
| SWE-bench/SWE-bench | Des bugs reels tires de vrais projets Python open source, chacun livre avec les tests qui doivent passer une fois le correctif applique | le dossier swebench/harness/ : c est lui qui rejoue les tests et decide si un correctif tient vraiment |
| SWE-agent/SWE-agent | Un agent qui prend une issue GitHub et tente de la corriger seul, avec ses traces de travail enregistrees | le dossier trajectories/demonstrations/ : tu lis pas a pas comment il explore un depot qu il ne connait pas |
| Aider-AI/aider | Un assistant de codage en ligne de commande, branche directement sur ton depot git | le dossier benchmark/ et son README.md, puis benchmark/refactor_tools.py pour le banc d essai de refactoring |
| github/awesome-copilot | Une collection communautaire d instructions, de regles et de configurations pretes a poser dans un depot | le dossier instructions/, et dedans code-review-generic.instructions.md |
| The-PR-Agent/pr-agent | Un outil de revue de code automatisee sur pull request : /review, /describe, /improve | le dossier pr_agent/tools/, fichier pr_reviewer.py : le prompt de revue en clair |
| anthropics/claude-code-security-review | Une GitHub Action officielle qui passe une revue de securite sur chaque pull request | le fichier claudecode/prompts.py : le prompt d audit, a recopier dans tes propres revues |
Clone The-PR-Agent/pr-agent en premier. Tu ouvres pr_agent/tools/pr_reviewer.py et tu vois comment un outil de revue serieux formule sa demande, dimension par dimension. C est le chemin le plus court entre cette section et un gain visible des ta prochaine pull request : tu reprends ces formulations telles quelles dans le fichier 05.