Prompt engineering : comment notre équipe a multiplié sa productivité par 3

On utilisait l’IA comme un moteur de recherche amélioré. On avait tout faux.

En début 2025, toute l’équipe utilisait des LLM. Claude, ChatGPT, Copilot — tout le monde avait ses outils. Mais quand j’ai regardé de plus près, j’ai réalisé que 90% des interactions ressemblaient à ça :

“Écris-moi une fonction qui fait X.”

“Explique-moi ce code.”

“Corrige ce bug.”

Des prompts d’une ligne. Pas de contexte. Pas de contraintes. Et des résultats… moyens. L’IA produisait du code qui marchait, mais qui n’était pas à nos standards. Résultat : les développeurs passaient autant de temps à corriger la sortie de l’IA qu’à l’écrire eux-mêmes.

Nous avons décidé de structurer notre approche. 6 mois plus tard, la productivité mesurée de l’équipe avait triplé. Voici exactement comment.

Le framework CRAFT : notre méthode en 5 étapes

Nous avons formalisé un framework interne que nous appelons CRAFT. Chaque prompt important suit cette structure :

C — Contexte

Donnez à l’IA le contexte complet. Pas juste “écris une fonction”, mais :

• Le projet : “Nous développons une API e-commerce en Node.js avec TypeScript strict, utilisant Express et Prisma.”
• Les contraintes : “Le code doit respecter notre linter ESLint strict, utiliser les types Prisma générés, et gérer les erreurs avec notre système custom d’error handling.”
• L’existant : “Voici le fichier existant dans lequel cette fonction doit s’intégrer : [code]”

Différence mesurée : un prompt avec contexte produit du code utilisable en l’état 3 fois plus souvent qu’un prompt sans contexte.

R — Rôle

Assignez un rôle précis à l’IA. Ce n’est pas du théâtre : ça cadre le registre de la réponse.

Exemples de rôles efficaces :

• “Tu es un architecte senior spécialisé en systèmes distribués avec 15 ans d’expérience.”
• “Tu es un expert en sécurité applicative qui fait un audit de ce code.”
• “Tu es un tech lead qui doit expliquer cette décision d’architecture au COMEX.”

Le rôle change fondamentalement la nature de la réponse. Un “développeur” vous donne du code. Un “architecte” vous donne des patterns et des compromis. Un “auditeur sécurité” vous donne des vulnérabilités.

A — Action

Soyez précis sur ce que vous attendez. Pas “aide-moi avec cette feature”, mais :

• “Génère les types TypeScript pour ce schéma de base de données”
• “Analyse ce code et liste les 5 problèmes de performance les plus critiques”
• “Propose 3 architectures alternatives pour ce service, avec les avantages et inconvénients de chacune”

La règle : si votre prompt peut être interprété de 3 façons différentes, il sera interprété de la mauvaise façon. Soyez univoque.

F — Format

Spécifiez le format de sortie attendu :

• “Réponds sous forme de tableau comparatif”
• “Structure ta réponse en : 1) Analyse du problème, 2) Solutions proposées, 3) Recommandation”
• “Donne-moi uniquement le code, sans explication, dans un bloc TypeScript”
• “Réponds en bullet points, maximum 5 lignes par point”

Le format réduit le bruit et accélère la lecture. Un tableau de comparaison est plus utile que 3 pages de prose.

T — Tests

Demandez à l’IA de valider sa propre sortie :

• “Après avoir généré le code, vérifie qu’il compile en TypeScript strict”
• “Identifie les cas limites que ta solution ne gère pas”
• “Donne-moi 3 scénarios de test qui valideraient cette implémentation”

Cette étape réduit considérablement les erreurs. L’IA est meilleure pour trouver des problèmes dans du code que pour écrire du code sans problème du premier coup.

Les 6 techniques qui ont le plus d’impact

1. Le chain-of-thought forcé

Au lieu de : “Quel est le meilleur pattern pour ce service ?”

Demandez : “Analyse étape par étape : 1) Quels sont les besoins non-fonctionnels de ce service ? 2) Quels patterns répondent à ces besoins ? 3) Compare-les sur les critères de complexité, performance et maintenabilité. 4) Recommande le meilleur choix avec justification.”

Impact mesuré : les réponses architecturales sont 2x plus pertinentes avec le chain-of-thought.

2. Le few-shot avec nos propres exemples

Au lieu de décrire notre style de code, nous fournissons des exemples de notre codebase :

“Voici comment nous écrivons un service dans notre projet : [exemple réel de 30 lignes]. Maintenant, écris le service UserNotification en suivant exactement le même pattern.”

Impact mesuré : le code généré respecte nos conventions dans 85% des cas, contre 30% sans exemple.

3. Le prompt itératif

Ne demandez pas tout en une fois. Découpez :

1. “Propose l’interface TypeScript de ce service”
2. “Maintenant, implémente la méthode createOrder”
3. “Ajoute la gestion d’erreurs et le logging”
4. “Génère les tests unitaires”

Chaque étape valide la précédente avant d’avancer. Résultat : moins de reprises et un code plus cohérent.

4. Le prompt adversarial

Après avoir obtenu une solution, demandez à l’IA de la critiquer :

“Maintenant, mets-toi dans la peau d’un reviewer senior exigeant. Quels sont les problèmes de ce code ? Quels cas limites ne sont pas gérés ? Où est-ce que ça va casser en production ?”

C’est la technique qui nous a le plus surpris par son efficacité. L’IA trouve systématiquement des problèmes dans son propre code quand on lui demande de le critiquer.

5. Les templates de prompts partagés

Nous avons créé une bibliothèque de 30 templates de prompts partagés dans l’équipe :

• Template “nouveau endpoint API”
• Template “migration de base de données”
• Template “revue de code sécurité”
• Template “rédaction de documentation technique”
• Template “analyse de performance”

Chaque template est une structure CRAFT pré-remplie avec le contexte de notre projet. Un développeur n’a plus qu’à remplir les blancs.

6. Le contexte persistant via fichiers

Au lieu de répéter le contexte à chaque conversation, nous maintenons des fichiers de contexte :

• project-context.md : stack technique, conventions, architecture
• coding-standards.md : règles de style, patterns à utiliser/éviter
• api-conventions.md : format des réponses, gestion d’erreurs, versioning

Ces fichiers sont fournis à l’IA en début de session. C’est comme onboarder un nouveau développeur à chaque conversation.

Les résultats chiffrés après 6 mois

Nous avons mesuré avant/après sur un trimestre :

Le facteur x3 en productivité vient de la combinaison des gains : développement plus rapide, moins de bugs, tests automatisés, documentation générée.

Les pièges à éviter

Le copier-coller aveugle

L’IA génère du code plausible, pas nécessairement correct. Chaque ligne doit être revue par un humain qui comprend ce qu’elle fait. On a vu des bugs subtils passer en production parce qu’un développeur a fait confiance aveuglément.

Le prompt trop long

Un prompt de 2000 mots n’est pas meilleur qu’un prompt de 200 mots bien structuré. La concision et la clarté battent la verbosité. Si votre prompt est trop long, découpez-le en étapes.

L’IA comme excuse pour ne pas réfléchir

L’IA accélère l’exécution, pas la réflexion. Si vous ne savez pas ce que vous voulez construire, l’IA ne le saura pas non plus. Réfléchissez d’abord, promptez ensuite.

La dépendance

Si un développeur ne peut plus travailler sans l’IA, c’est un red flag. L’IA est un outil, pas une béquille. Les compétences fondamentales doivent rester affûtées.

FAQ

Quel LLM utiliser pour le développement ?

En 2026, Claude excelle pour l’architecture et le raisonnement complexe, Copilot/Cursor pour la complétion en temps réel dans l’IDE. La plupart des équipes utilisent les deux. Le choix du modèle compte moins que la qualité du prompt.

Combien de temps faut-il pour former une équipe au prompt engineering ?

Une journée de formation initiale, puis 2-3 semaines de pratique encadrée. Le vrai gain arrive après environ 1 mois, quand les réflexes sont installés et que la bibliothèque de templates est constituée.

Le prompt engineering est-il un métier à part entière ?

Non, en 2026 c’est une compétence intégrée au métier de développeur, comme savoir utiliser Git ou un debugger. Les postes de “prompt engineer” purs disparaissent, la compétence se diffuse dans tous les rôles tech.

Comment mesurer le gain de productivité du prompt engineering ?

Mesurez les métriques DORA (fréquence de déploiement, lead time) avant et après adoption. Complétez avec le nombre de features livrées par sprint et le taux de bugs en production. Attention : le gain n’est pas immédiat, comptez 4 à 6 semaines d’adaptation.