Arrêtez d'instruire votre IA, interrogez-la : le prompt engineering par l'investigation

Vous écrivez un prompt soigné, vous lancez votre agent IA, et le résultat est… à côté. Pas radicalement faux, mais pas tout à fait juste non plus. Le réflexe habituel : affiner le prompt, ajouter des précisions, reformuler. Et si le vrai problème n'était pas dans ce que vous écrivez, mais dans ce que vous ne savez pas encore que vous ignorez ?

C'est le constat que partage Thariq Shihipar, développeur chez Anthropic, à propos de Claude Fable 5 — et sa réflexion s'applique directement à tout projet PHP/Symfony piloté par des agents IA. (Source : The Decoder)

Le vrai goulot d'étranglement : vos angles morts

Shihipar introduit un cadre simple mais éclairant, emprunté à la théorie de la connaissance :

• Known Knowns : ce que vous savez déjà et mettez dans le prompt.
• Known Unknowns : les questions que vous savez ne pas avoir résolues.
• Unknown Unknowns : ce que vous ignorez ignorer — vos angles morts.

Avec les modèles précédents, on pouvait imputer une partie des résultats décevants aux limites du modèle lui-même. Avec Fable 5, Shihipar affirme que c'est désormais la capacité de l'utilisateur à clarifier ses unknown unknowns qui détermine la qualité des sorties.

Concrètement, dans un projet Symfony : vous savez que vous voulez un service de traitement de commandes. Vous savez que vous n'avez pas encore décidé du driver de queue. Mais vous ignorez peut-être que votre stratégie de retry va entrer en conflit avec l'idempotence de votre handler — et vous ne le formulez donc jamais dans votre prompt.

Résultat : l'IA génère un code fonctionnel en apparence, mais architecturalement fragile.

Passer du mode instruction au mode investigation

La recommandation centrale de Shihipar est un changement de posture : avant d'écrire un prompt directif, engagez d'abord un dialogue structuré avec le modèle pour faire émerger ce que vous n'avez pas encore pensé.

1. Le brainstorming ciblé avant la spécification

Plutôt que de décrire ce que vous voulez construire, décrivez le problème et demandez au modèle de lister les questions qu'un architecte expérimenté poserait avant de commencer.

Exemple de prompt d'investigation pour un projet Symfony :

Je veux construire un système de traitement de commandes e-commerce avec Symfony 7.
Avant de proposer une architecture, liste les 10 questions les plus importantes
qu'un architecte senior devrait se poser — notamment celles que je risque d'oublier.

Ce type de prompt retourne souvent des angles que vous n'aviez pas anticipés : gestion des transactions distribuées, stratégie d'audit log, comportement en cas de timeout partiel, compatibilité avec un futur microservice…

2. L'interview structurée en back-and-forth

Shihipar recommande de laisser le modèle mener une mini-interview avant de passer à l'implémentation. Dans la pratique, cela ressemble à :

Tu vas m'aider à concevoir un bundle Symfony de gestion d'abonnements.
Pose-moi UNE question à la fois pour comprendre mes contraintes,
jusqu'à ce que tu estimes avoir assez d'informations pour proposer une architecture solide.

Ce format itératif force à expliciter des décisions qu'on aurait sinon prises implicitement — et souvent mal.

3. Les notes d'implémentation comme mémoire vivante

Pour les sessions de coding longues, Shihipar suggère de tenir un fichier de notes en temps réel : décisions prises, hypothèses formulées, questions encore ouvertes. Ce fichier devient un contexte à injecter en début de chaque prompt, évitant que l'agent IA parte dans une direction incompatible avec ce qui a déjà été décidé.

Dans un workflow Symfony, cela peut prendre la forme d'un simple ARCHITECTURE.md versionné, passé en contexte à chaque interaction avec l'agent.

Le piège de la spécificité : ni trop, ni trop peu

Shihipar identifie un équilibre délicat que tout développeur utilisant des agents a rencontré :

• Trop de détails : vous enfermez le modèle dans une approche potentiellement erronée. Si votre prompt décrit précisément une solution technique avant que le problème soit bien cerné, l'IA optimise cette solution — même si elle est mal orientée.
• Trop vague : le modèle produit une réponse générique, inutilisable en production.

Le bon niveau de spécificité, c'est décrire précisément le problème et ses contraintes, pas la solution envisagée. Laissez la solution émerger du dialogue.

Anti-pattern fréquent en contexte Symfony :

❌ "Crée un EventSubscriber qui écoute l'événement OrderPlaced
    et envoie un email via Mailer avec ce template..."

Approche investigative :

✅ "Dans mon application Symfony, quand une commande est validée,
    plusieurs systèmes doivent être notifiés (email client, stock, ERP).
    Quelles architectures event-driven me conseilles-tu d'évaluer,
    et quelles questions dois-je trancher avant de choisir ?"

La première approche fige une décision. La seconde ouvre un espace où vos angles morts peuvent être détectés avant d'écrire la moindre ligne.

Ce que ça change concrètement dans un projet PHP/Symfony

Adopter cette posture investigative avant chaque session de développement assisté par IA, c'est :

• Réduire le rewrite coûteux : les failles architecturales détectées en phase de dialogue coûtent beaucoup moins cher que celles découvertes après implémentation.
• Mieux documenter les décisions : le dialogue lui-même constitue une trace des arbitrages effectués, utile pour l'équipe et pour les futures sessions IA.
• Améliorer la qualité du contexte : un agent IA performant en phase de génération nécessite un contexte dense et cohérent — que l'investigation préalable permet de construire.

Les équipes qui traitent encore l'IA comme un "autocompleteur sophistiqué" obtiendront des résultats en proportion. Celles qui l'utilisent comme un interlocuteur critique pour tester leur propre raisonnement avant d'implémenter auront un avantage structurel.

Conclusion

Le vrai progrès apporté par les modèles de dernière génération n'est pas seulement une meilleure génération de code — c'est la possibilité d'un véritable partenariat intellectuel en amont du code. Mais ce partenariat ne s'active pas avec un prompt directif : il s'active avec des questions.

Avant votre prochain chantier Symfony, essayez une session d'investigation de 15 minutes avec votre agent IA, avant toute spécification. Demandez-lui ce que vous n'avez probablement pas encore pensé. La réponse risque de réorienter tout ce qui suit — pour le mieux.