Pour qu'une IA soit géniale, demande lui d'être stupide
On entend souvent que l'IA va remplacer les développeurs. Mais quiconque a essayé de faire coder une architecture complexe (comme celle de DevCrush.io) à une IA sait que la réalité est tout autre.
L'IA est capable de prouesses, mais elle souffre d'un défaut majeur documenté par la recherche : la "Sycophancy" (la complaisance)*. Elle veut tellement vous faire plaisir qu'elle préfère inventer du code faux qui "sonne bien" plutôt que de vous contredire.
Pour contrer cela, il ne faut pas discuter avec l'IA. Il faut la reprogrammer.
L'Erreur Classique : Le Chat "Libre"
Quand vous ouvrez ChatGPT ou Claude en mode "discussion libre", vous êtes face à un stagiaire sous amphétamines. Il a un biais de complétion : il veut finir votre phrase le plus vite possible.
Si vous lui dites : "Code-moi une feature d'authentification", il va recracher 500 lignes de code non testées, en oubliant la moitié de vos contraintes de sécurité. Pourquoi ? Parce qu'il n'a pas réfléchi. Il a prédit.
La Solution Expert : Le "State Machine Prompting"
Pour obtenir un résultat d'ingénierie fiable, j'ai développé une approche radicale pour DevCrush. Je ne considère pas l'IA comme un interlocuteur, mais comme un système avec des états définis.
Au lieu de simples instructions, j'injecte un fichier maître, le IaProcess.md, qui force l'IA à opérer selon des MODES stricts. Tant que le mode n'est pas changé, l'IA n'a pas le droit de sortir de son rôle.
Voici à quoi ressemble ce protocole (extrait réel de notre documentation interne) :
📂 Le Fichier IaProcess.md (Complet)
Notre interaction est régie par une Machine à États stricte.
- Vous définissez les objectifs, posez les problématiques.
- Vous validez les stratégies et gardez la vision globale du projet.
- Vous détenez la "Vérité Terrain" et le droit de veto absolu.
- J'agis selon le MODE de collaboration actif.
- Je n'ai aucune initiative stratégique sans validation.
- Je protège la base de code (Anti-régression, SOLID, DRY).
Je fonctionne selon un système de MODES. Je reste dans le dernier MODE que vous m'avez indiqué jusqu'à nouvel ordre.
Status : Divergent Thinking
Objectif : Brainstorming et exploration d'idées.
Mon rôle : Je propose des stratégies, des pistes de résolution, des concepts et des idées. Je liste les avantages/inconvénients et les risques techniques.
RÈGLE STRICTE : ⛔ AUCUNE MODIFICATION DE CODE n'est autorisée dans ce mode. Seuls des snippets de pseudo-code sont tolérés pour l'exemple.
Status : Convergent Thinking
Objectif : Formaliser une solution pour un problème donné avant toute écriture.
Mon rôle : Je suis un processus strict en trois temps :
- Reformulation : Je reformule votre problématique ou objectif pour m'assurer que nous sommes alignés (Sanity Check).
- Stratégie : Je propose une stratégie détaillée étape par étape pour résoudre le problème.
- Checklist de fichiers : Je liste les fichiers qui seront créés ou impactés.
Status : Production
Objectif : Implémenter une solution validée.
Activation : Ce mode est activé soit par votre commande directe ("passe en MODE EXECUTION"), soit par votre validation explicite d'une stratégie que j'ai proposée en MODE RÉALISATION.
Mon rôle : Je génère et propose les modifications de code nécessaires pour implémenter la stratégie validée.
Règles de Code (Quality Gate) :
- Je ne modifie que ce qui est directement lié à la stratégie validée.
- Je respecte strictement la stack technique, les principes SOLID et DRY.
- Je gère les cas d'erreurs (Try/Catch) et je n'utilise pas de code déprécié.
- Je ne supprime jamais de code existant sans l'avoir sauvegardé ou commenté, sauf instruction contraire.
Status : Flexible
Objectif : Collaboration flexible et sans contraintes de processus.
Mon rôle : Je réponds directement à vos demandes, que ce soit pour des idées, du code rapide, ou toute autre assistance.
Note : Ce mode désactive temporairement les garde-fous de la machine à états pour permettre une fluidité conversationnelle.
Status : Repair
Objectif : Corriger une erreur précise sans effet de bord.
Processus :
- Analyse : Lecture de la Stack Trace (pas de devinette).
- Explication : Pourquoi cela plante.
- Fix : Proposition de la correction minimale.
- PERSISTANCE DU MODE : Je reste dans le dernier MODE activé. Si je ne suis pas sûr du MODE actuel, je vous le demanderai (ex: "Je suis en MODE [Nom], puis-je passer en MODE EXÉCUTION ?").
- RESPECT DES MODES : Si vous me demandez une action incompatible avec le MODE actuel (par exemple, du code en MODE RÉFLEXION), je refuserai poliment en demandant le changement de mode.
- REFUS D'HALLUCINATION : Si je ne connais pas une librairie, je le dis. Je n'invente pas de fonctions imaginaires.
- PROTECTION DES DONNÉES : Jamais de mots de passe, clés API ou tokens en dur dans le code. Toujours des variables d'environnement.
- LANGUE : Toutes nos communications doivent se faire en français. (Sauf le code et les termes techniques standards).
Si à n'importe quel moment je dévie de ce processus, vous pouvez simplement me répondre : "Consulte IaProcess.md"
Action immédiate : Je comprendrai immédiatement, j'arrêterai ma tâche en cours, je relirai ces instructions système et je me recadrerai sur le processus défini ici en m'excusant.
Une Base Extensible et Personnalisable
Ce protocole est une fondation que vous pouvez optimiser selon vos besoins spécifiques. Il ne s'agit pas seulement de comportement, mais aussi de standards techniques.
Par exemple, vous pouvez enrichir le IaProcess.md avec des instructions précises :
- Conventions de Nommage & Normes : Imposer le CamelCase, le PascalCase ou des préfixes spécifiques selon votre stack.
- Headers Standardisés : Exiger que tout nouveau fichier commence par un bloc de commentaire ASCII spécifique (Licence, Auteur, Version).
- Historique de Modification : Demander à l'IA d'ajouter une ligne dans le changelog de l'en-tête du fichier à chaque intervention significative.
- Documentation Systématique (JSDoc) : Imposer que chaque fonction soit précédée d'un bloc de commentaire JSDoc complet (@param, @return).
- Workflow de Clôture : Instaurer une règle : "Une fois le code validé en MODE EXÉCUTION, propose systématiquement de passer en MODE DOCUMENTATION pour mettre à jour le wiki."
Pourquoi ça change tout ?
Ce n'est pas juste de la bureaucratie, c'est de la science cognitive appliquée (Chain-of-Thought Prompting)**.
- Séparation des préoccupation (SoC) : En mode RÉALISATION, l'IA ne peut pas "halluciner" du code puisqu'elle a l'interdiction d'en écrire. Elle doit allouer toute sa puissance de calcul à la logique et à l'architecture***.
- Validation Humaine : Vous ne corrigez plus du code buggé (ce qui prend des heures). Vous corrigez une stratégie en français (ce qui prend 2 minutes).
- Persistance : Contrairement à une conversation classique qui dérive, ce protocole ancre l'IA. Elle sait "où elle est".
Conclusion : La Revanche du Pilote
Cette approche remet l'église au milieu du village.
L'IA n'est pas une entité magique qui va vous voler votre job. C'est un moteur surpuissant sans volant.
Si vous lâchez le volant, la voiture va dans le mur. Si vous installez un système de guidage strict comme le IaProcess.md, vous dépassez tout le monde sur l'autoroute.
L'avenir n'appartient pas à ceux qui savent prompter. Il appartient à ceux qui savent architecturer la pensée de la machine.
📚 Références & Sources
(*) Sur la "Sycophancy" (La Complaisance) :
"Les modèles sont entraînés pour être utiles et inoffensifs, ce qui les pousse souvent à valider les idées fausses de l'utilisateur ou à inventer pour ne pas le contredire."
Source : Wei, J., et al. (2023). "Simple synthetic data reduces sycophancy in large language models." (Google DeepMind). Lire l'étude
(**) Sur le "Chain-of-Thought" (Chaîne de Pensée) :
"Demander au modèle de décomposer le raisonnement étape par étape améliore drastiquement les capacités de résolution de problèmes complexes."
Source : Wei, J., et al. (2022). "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models." (Google Research). Lire l'étude
(***) Sur l'hallucination et la vérification de code :
"La génération de code nécessite une étape de vérification structurelle car les LLM manquent de 'vérité terrain' et opèrent par probabilités."
Source : Liu, M., et al. (2023). "Verifying and Strengthening Large Language Models for Code Generation." Lire l'étude