Vous y êtes allé. Vous confiez à une IA une tâche complexe : "analyser cette base de code", "écrire un modèle de menace", "concevoir la surface de l'API" - et vous obtenez quelque chose d'utile. Cela fonctionne pour le dépôt que vous consultez. Mais essayez-le sur une base de code différente et la qualité est aléatoire. Le résultat est sensible à la structure du projet, aux conventions de dénomination et à tout ce que le modèle accrochera ce jour-là.
Le résultat n'est pas mauvais. Ce n'est tout simplement pas fiable. Et pour tout ce que vous souhaitez répéter sur plusieurs projets ou confier à une équipe, la fiabilité est ce qui compte.
Cet article explique comment utiliser une sortie d'IA qui fonctionne une seule fois et la faire fonctionner de manière cohérente : structurée, fondée sur des preuves et reproductible quel que soit le référentiel cible.
Nous passerons en revue dix techniques d'incitation, chacune étant un concept autonome que vous pourrez utiliser demain sur tout ce sur quoi vous travaillez. Pour garder les choses concrètes, nous utiliserons un exemple concret : nous avons utilisé l'IA pour générer des diagrammes d'architecture C4 pour OpenCode, un assistant de codage d'IA open source construit avec TypeScript, Bun et le Model Context Protocol. Au cours de cinq itérations, nous avons amélioré les invites jusqu'à ce que le résultat soit structuré, étayé par des preuves et reproductible. Mais les techniques elles-mêmes s'appliquent à toute tâche complexe : modèles de menaces, audits de dépendances, documents API, plans de migration, etc.
Commençons par là où les choses ont commencé.
Voici plus ou moins l'invite avec laquelle nous avons commencé :
Produisez un diagramme de conteneur C4 pour ce référentiel.Et voici ce que nous avons obtenu :
Un diagramme valide avec des noms de conteneurs raisonnables, une syntaxe correcte et... une boîte géante intitulée "Integration Gateway" qui rassemble trois sous-systèmes complètement différents (un adaptateur de fournisseur LLM, une couche de transport MCP et un système de plugins).
Les notes d’analyse comptaient 31 lignes. Aucun score. Aucune alternative envisagée. Aucune preuve que l’IA ait réellement réfléchi aux compromis. Cela avait produit l’équivalent architectural de « cette réunion aurait pu être un courrier électronique ».
Le problème n'était pas l'IA. Le problème, c'était nous. Nous lui avions confié une tâche vague et obtenu une réponse vague. Ce n'est pas un bug, c'est une cause et un effet.
L'idée centrale sur laquelle nous revenons sans cesse : pour les tâches analytiques complexes, l'invite n'est pas seulement une entrée. C'est la méthodologie. Si vous donnez à l’IA un processus rigoureux à suivre, elle produit un résultat rigoureux. Si vous lui donnez une seule ligne, il l'envole.
Au cours de cinq itérations, nous avons ajouté des techniques une par une et avons observé que le résultat s'améliorait de manière mesurable à chaque tour. Voici ce que nous avons appris.
Lorsque vous expliquez une tâche à un nouveau membre de l'équipe, vous ne passez pas dix minutes à décrire la base de code et à dire ensuite « oh, au fait, j'ai besoin que vous rédigiez des documents d'architecture ». Vous dirigez avec ce dont vous avez besoin, puis remplissez le contexte.
L'IA fonctionne de la même manière. Les modèles linguistiques traitent votre invite de manière séquentielle : ils suscitent l'attention et les attentes au fur et à mesure qu'ils lisent. Si vous mettez 500 mots de contexte avant la tâche elle-même, le modèle s'est déjà fait une opinion sur ce qui compte avant même de savoir ce que vous demandez.
La solution est très simple : placez la tâche en premier.
Tâche : [Ce que vous voulez – une phrase] Contraintes : [Ce qu'il ne faut PAS faire – limites strictes] Contexte : [Contexte, chemins de fichiers, travaux préalables] Résultat : [Format exact attendu]L’ordre compte. La tâche définit le cadre. Les contraintes empêchent les modes de défaillance courants. Le contexte remplit les détails. Le format de sortie indique au modèle à quoi ressemble « terminé ».
Voici à quoi ressemble une invite contextuelle :
Voici un monorepo TypeScript avec des packages pour les fonctions CLI, de bureau, Web et cloud. La CLI utilise des yargs, le serveur utilise Hono sur Bun, les sessions utilisent une boucle d'invite avec l'exécution de l'outil... [500 mots supplémentaires] ... veuillez produire un diagramme C4.Et voici les instructions en premier :
Vous êtes agent d'analyse d'architecture. Analysez une base de code et produisez des résultats C4 fondés sur des preuves. Conservez l’abstraction au niveau du conteneur, sauf demande contraire explicite.Trois lignes. Le modèle connaît immédiatement son rôle, ce qu'il produit et à quel niveau d'abstraction rester. Tout ce qui suit est interprété à travers ce cadre : lorsqu'il lit plus tard des informations sur les adaptateurs de fournisseur et les transports MCP, il se demande "comment cela est-il mappé à un conteneur ?" plutôt que "laissez-moi résumer ce projet TypeScript".
Dans notre projet : le passage à l'instruction d'abord a été le premier changement que nous avons apporté (voir l'invite du protocole), et cela a immédiatement affiné le résultat. Le modèle a cessé de produire des résumés génériques et a commencé à produire des analyses d'architecture. Petit changement, grande différence.
Pensez aux révisions de code. Qu'est-ce qui est le plus facile à réviser : un PR avec un modèle de description clair (## Quoi, ## Pourquoi, ## Comment, ## Test), ou un PR avec un paragraphe de forme libre qui peut ou non tout couvrir ?
Le même principe s’applique à la sortie AI. Lorsque le modèle peut choisir sa propre structure, il se tourne vers une prose qui se lit bien mais qui est difficile à vérifier ou à comparer. Il écrira des paragraphes fluides qui semblent réfléchis et ignorera les parties pour lesquelles il a peu de confiance - et vous ne le remarquerez pas, car il n'y a pas de liste de contrôle vous indiquant ce qui manque.
Définissez les sections exactes souhaitées, dans l'ordre :
Renvoyez exactement ces sections dans cet ordre : 1) Portée et non-objectifs 2) Principales conclusions 3) Tableau des preuves 4) Alternatives envisagées 5) Recommandation avec justification 6) Hypothèses et mises en garde N'ajoutez pas de sections supplémentaires. N'omettez pas de sections. Marquez les sections vides comme « N/A — [raison] ».Deux contraintes clés : "Ne pas ajouter de sections supplémentaires" empêche le modèle de créer sa propre structure qui pourrait cacher des éléments. "Ne pas omettre de sections" l'empêche de sauter discrètement les zones où il est incertain. La clause « N/A avec raison » est particulièrement utile : elle oblige le modèle à reconnaître ce qu'il n'a pas trouvé plutôt que de simplement... ne pas le mentionner.
La sortie de forme libre comporte trois modes de défaillance :
Vous ne pouvez pas le différencier. Lorsque deux itérations ne partagent pas la même structure, les comparer revient à comparer deux essais. Avec les sections fixes, vous pouvez procéder section par section.
Le modèle cache ses lacunes. Faible confiance sur un sujet ? N'écrivez simplement pas ce...
[Courte citation de 8% de l'article original]