Techniques avancées

L’anatomie vue dans la page précédente est le fondement. Ici, on ajoute des patterns qui s’appliquent quand la tâche est plus complexe. Ce ne sont pas de nouveaux composants — c’est la façon de les agencer différemment selon la situation.

Patterns qui marchent

Role prompting

Donner un rôle précis change l’angle d’attaque de Claude sur le problème — il adopte un cadre de référence différent.

Quand l’utiliser	Expertise métier précise, ton spécialisé

Avant : "Explique-moi les injections SQL"

Après : "Tu es un expert en sécurité web spécialisé en pentesting. Explique les injections SQL comme si tu briefais un dev junior avant son premier audit."

→ Le rôle oriente le niveau de détail, le vocabulaire et les priorités de la réponse.

Few-shot

Montrer des exemples du résultat attendu avant de poser la question — Claude déduit le pattern et l’applique.

Quand l’utiliser	Format de sortie précis, style à reproduire

Avant : "Génère des noms de variables pour ces 3 cas"

Après :

Voici le pattern de nommage qu'on utilise :
- compteur d'erreurs → errorCount
- état de chargement → isLoading
- liste d'utilisateurs → userList

En suivant ce pattern, génère les noms pour : timestamp de création, flag de validation, tableau de permissions.

→ Zéro ambiguïté sur le format attendu — Claude extrapole directement depuis les exemples.

Chain of thought

Demander à Claude de raisonner étape par étape avant de conclure — réduit les erreurs sur les problèmes complexes.

Quand l’utiliser	Raisonnement multi-étapes, logique à expliciter

Avant : "Quelle architecture choisir pour ce service de notifications ?"

Après : "Analyse les contraintes du service de notifications ci-dessous. Réfléchis étape par étape : charge estimée, latence acceptable, coût de maintenance. Puis propose une architecture en justifiant chaque choix."

→ Le “étape par étape” force Claude à ne pas sauter aux conclusions — les réponses sont plus fiables et auditables.

Contraintes négatives

Dire explicitement ce qu’il ne faut PAS faire — plus efficace que de l’espérer implicitement.

Quand l’utiliser	Éviter un comportement par défaut indésirable

Avant : "Refactorise ce module"

Après : "Refactorise ce module pour réduire la duplication. Ne change pas l'interface publique. N'ajoute pas de dépendances externes. Ne touche pas aux fichiers de test."

→ Claude a des comportements par défaut (ajouter des abstractions, suggérer des bibliothèques). Les contraintes négatives les désactivent explicitement.

Persona + audience

Combiner qui est Claude et à qui il parle — double levier pour calibrer le niveau et le ton.

Quand l’utiliser	Adapter le niveau d’explication à un public précis

Avant : "Explique les microservices"

Après : "Tu es un architecte senior. Explique les microservices à un dev backend Java qui n'a travaillé qu'en monolithique — utilise des analogies avec ce qu'il connaît déjà, évite le jargon cloud-native."

→ Le public cible dans la demande évite des allers-retours pour ajuster le niveau.

Format imposé

Spécifier la structure exacte de la réponse — évite de devoir reformater ou re-demander.

Quand l’utiliser	Sortie structurée, intégration dans un process

Avant : "Liste les risques de ce changement"

Après : "Liste les risques de ce changement. Format : JSON avec les clés 'risque', 'probabilité' (faible/moyen/élevé), 'impact' (faible/moyen/élevé), 'mitigation'. Maximum 5 risques."

→ Une réponse bien structurée au premier essai évite un aller-retour correctif.

Règles d’or

Contexte > longueur — un prompt court avec le bon contexte bat un long prompt vague
Une tâche à la fois — découpe les demandes complexes
Itère — le premier prompt est rarement le meilleur, affine avec Claude
Montre l’attendu — si tu as un format précis en tête, donne un exemple