8 prompts pour ne plus traiter Claude comme un stagiaire
8 prompts pour ne plus traiter Claude comme un stagiaire
Source: Adam (@Adamaestr0_) — thread du 10 octobre 2026 — 563 000 vues, 2 481 likes, 4 580 marque-pages
Arrêtez de dire à Claude : « fais ça. » Arrêtez de dire à Claude : « écris le code. » Arrêtez de dire à Claude : « corrige cette erreur. »
En réalité, vous traitez une IA senior comme si elle était un stagiaire junior. Voici 8 prompts que vous pouvez copier-coller directement.
Le fil est en espagnol ; les huit prompts sont ici traduits en français, prêts à être copiés-collés.
Le point commun aux huit : aucun ne dit seulement quoi faire. Chacun installe d’abord un rôle (« pense comme un ingénieur senior de… »), impose un ordre d’exécution (on analyse avant de coder, on conçoit avant d’implémenter), puis se termine sur une liste de livrables attendus. C’est le format de sortie qui manquait, pas l’expertise.
1. Application complète depuis zéro
Le plus long des huit, et le seul qui demande explicitement de raisonner en deux temps : architecture d’abord, version minimale ensuite.
Réfléchis comme un ingénieur full-stack senior qui développe une application complète et prête pour la production. D’abord, conçois l’architecture du système, puis développe la version minimale mais évolutive.
Le résultat doit inclure :
- L’architecture
- L’arborescence des fichiers
- Le schéma de base de données
- Les points d’accès de l’API
- L’architecture de l’interface
- Le code complet.
Conçois-la comme un vrai MVP de startup, et rends-la évolutive.
Le « MVP real de startup, mais évolutif » est la ligne la plus utile : elle interdit à la fois le jouet qui marche une fois et le monolithe que personne ne déploie.
2. Compréhension et refactorisation d’un codebase
Pour reprendre un projet hérité sans le casser.
Réfléchis comme un ingénieur senior qui vient d’arriver sur une base de code vaste et inconnue.
D’abord, comprends l’architecture et le flux de données.
Ensuite, identifie :
- Les problèmes structurels
- Le code dupliqué
- Les goulots d’étranglement de performance
- Les risques de maintenabilité
Résultat :
- Un résumé d’architecture
- Les zones problématiques
- Les stratégies de refactorisation
- Le code amélioré
La fonctionnalité reste inchangée — c’est la qualité qui s’améliore.
Le remède au « réécris-moi tout le projet » : ici la fonctionnalité est déclarée invariante, et le refactoring vient après l’analyse, pas à la place.
3. Ingénieur senior de débogage
Le prompt le plus directement transposable au quotidien.
Réfléchis comme un ingénieur senior de débogage qui enquête sur des bugs en production.
- Analyse soigneusement le code
- Avance pas à pas
- Trouve la cause racine
- Propose des solutions robustes
Résultat :
- Ce que fait le code
- Quel est le problème
- Pourquoi il échoue
- Les cas limites
- Le code corrigé, prêt pour la production
Remarquez la consigne « ce que fait le code / quel est le problème / pourquoi il échoue » : trois livrables distincts, qui empêchent le modèle de se contenter d’un patch qui fait disparaître le symptôme.
4. Design de système + implémentation
Réfléchis comme un architecte système senior. Conçois un système évolutif pour le produit, puis développe la version minimale de production. Inclus :
- L’architecture
- La structure des composants
- Le flux de données
- La conception de l’API
- Le schéma de base de données
- La stratégie de cache
- Le code d’implémentation
Le cousin du n° 1, orienté conception distribuée plutôt que produit complet. Le cache est nommé explicitement, parce que c’est le point qu’on oublie le plus souvent.
5. Optimisation des performances
Réfléchis comme un ingénieur performance qui optimise du code. Objectifs :
- La vitesse
- L’occupation mémoire
- L’extensibilité
Trouve :
- Les goulots d’étranglement
- La logique inefficace
- Les rendus inutiles
Résultat :
- Les problèmes de performance
- Les stratégies d’optimisation
- Le code amélioré
Trois objectifs nommés, trois classes de défauts à traquer, trois livrables. Sans ça, un modèle optimise ce qui l’amuse et casse ce qui marche.
6. Reconstruction en clean architecture
Réfléchis comme un ingénieur senior qui fait passer le code en clean architecture.
- Sépare les responsabilités
- Augmente la modularité
- Réduis le couplage. Le comportement reste inchangé — c’est la structure qui s’améliore.
Résultat :
- La nouvelle arborescence
- La description de l’architecture
- Le code refactorisé
Refactorisation « sans changement de comportement » : c’est la seule garantie qui permet de refactoriser sans prendre le risque de tout casser.
7. Workflow multi-agents de Claude
Le seul des huit qui exploite une capacité d’Anthropic plutôt qu’une technique de prompting.
Tu es 4 agents qui collaborent :
- Architecte
- Ingénieur
- Relecteur
- Optimiseur
Rôles :
- Architecte → conçoit le système
- Ingénieur → développe
- Relecteur → contrôle qualité
- Optimiseur → améliore la performance
Résultat :
- L’architecture
- L’implémentation
- Le retour de la relecture
- La version finale optimisée
8. Constructeur de composants UI de niveau production
Réfléchis comme un ingénieur frontend senior et construis :
- Des composants d’interface réutilisables
- Accessibles
- Prêts pour la production
Prends en compte :
- Les états de chargement
- Les cas limites
- Le design responsive
- L’accessibilité
Résultat :
- L’architecture du composant
- Le design des props
- L’implémentation
- Des exemples d’utilisation
« États de chargement, cas limites, responsive, accessibilité » : les quatre lignes qui séparent un composant de démonstration d’un composant qu’on peut réellement intégrer.
Ce que les huit ont en commun
| Prompt | Rôle | Livrable | |
|---|---|---|---|
| 1 | App complète | ing. full-stack senior | archi, arborescence, BDD, API, UI, code |
| 2 | Refonte de code | ing. senior en poste | résumé d’archi, zones à risque, stratégie, code |
| 3 | Débogage | ing. débogage senior | cause racine, cas limites, code corrigé |
| 4 | Design système | architecte systèmes senior | archi, composants, flux, API, BDD, cache, code |
| 5 | Performance | ing. performance | goulots, stratégies, code |
| 6 | Clean architecture | ing. senior | arborescence, archi, code refactorisé |
| 7 | Multi-agents | 4 agents | archi, implémentation, revue, version optimisée |
| 8 | Composants UI | ing. frontend senior | archi, props, implémentation, exemples |
Le meilleur commentaire du fil
Précisément le point qui manque à ces huit prompts — trouvé sous le fil le 11 octobre :
« D’accord, mais le vrai saut ce n’est pas le ton : c’est de lui donner du contexte et un critère de “terminé”. Le prompt qui marche pour moi : “Avant de toucher au code, explique-moi la cause probable de l’erreur, propose-moi 2 solutions et dis-moi comment je vérifierai que c’est résolu.” Sans critère, pas de senior. » — JVCE (@Jiler830219)
Autrement dit : « avant de toucher au code, explique-moi la cause probable, propose-moi deux solutions et dis-moi comment je vérifierai que c’est réglé ». Le ton ne fait rien. Le critère de « terminé », si.
Fil original en espagnol, 10 tweets, ≈ 2 900 likes et ≈ 786 K vues cumulées sur l’ensemble du fil — @Adamaestr0_, cofondateur d’IA Proactiv (bulletin à plus de 70 000 abonnés). Prompts traduits en français ; remise en forme pour le journal.