Votre IA improvise votre produit

Pourquoi le résultat varie autant

Voici le même prompt, envoyé au même modèle, à soixante secondes d'intervalle.

Prompt : « Écris des critères d'acceptation pour un ticket : l'utilisateur peut configurer les paramètres du fournisseur d'IA. »

Premier essai — sans contexte : le résultat est une checklist générique. « L'utilisateur peut sélectionner un fournisseur d'IA dans une liste déroulante. L'utilisateur peut sauvegarder les paramètres. L'utilisateur voit un message de confirmation. » Ça pourrait être n'importe quel produit, n'importe quelle plateforme, n'importe quelle époque. Il n'y a rien de faux là-dedans. Il n'y a rien d'utile non plus.

Deuxième essai — avec contexte produit : le résultat fait référence aux pages d'administration Jira Cloud, aux permissions du Forge resolver, à la validation des clés API par fournisseur (OpenAI, Anthropic, Google, Mistral, xAI), au comportement du scope de données au niveau organisation versus projet, et aux actions d'écriture conditionnées par la licence. Il précise que les paramètres sont persistés via @forge/sql et que l'interface utilise des composants Atlaskit avec des tokens xcss. Ça ressemble à quelqu'un qui a vraiment travaillé dans cette codebase.

Le modèle n'a pas changé. La température n'a pas changé. L'entrée a changé. Cet écart — entre générique et ancré dans la réalité — est tout le sujet de cet article.

Quand les résultats d'IA semblent incohérents, le réflexe est de blâmer le modèle : changer de fournisseur, monter en gamme, ajuster la température. Presque toujours, c'est le mauvais levier.

Chaque prompt repart de zéro. Le modèle n'a aucune mémoire de votre produit, de vos utilisateurs, de vos contraintes ou de votre dernière conversation, sauf si vous fournissez explicitement ces informations. « Écris des critères d'acceptation » veut dire quelque chose de complètement différent pour une app Forge native à Jira servant des équipes d'ingénierie de dix à cent personnes et pour une app mobile fitness grand public.

Le modèle répond au monde que vous lui décrivez. Si vous ne décrivez rien, il en invente un — et c'est rarement le vôtre.

C'est pourquoi deux personnes de la même équipe peuvent utiliser le même modèle et obtenir des résultats radicalement différents. Ce n'est pas une question de compétence. Ce n'est pas la structure du prompt. C'est si le modèle a reçu assez de réalité produit pour travailler avec.

Pour le cadre plus large sur pourquoi cela provoque des erreurs si coûteuses dans Jira, commencez par : L'IA ne répare pas les équipes mal alignées. Elle les dissimule.

La solution n'est pas une meilleure technique de prompting. C'est construire une couche de contexte réutilisable — une description compacte et honnête du monde de votre produit — et la joindre avant chaque prompt. Vous l'écrivez une fois. Vous la réutilisez partout. Le modèle arrête de deviner et commence à travailler avec les mêmes contraintes que votre équipe.

Une fois que le contexte produit alimente le modèle, le résultat cesse de flotter dans l'abstraction et commence à converger vers quelque chose de plus concret.

Les quatre couches

Le contexte produit n'est pas un seul bloc de texte. Il se décompose naturellement en quatre couches, chacune faisant un travail différent.

Résumé produit couvre ce que fait le produit, pour qui et quels résultats comptent — une vérité opérationnelle, pas du copy marketing. La différence est importante. « Un outil de gestion de projet pour les équipes » pourrait décrire n'importe quoi. « Just est un copilote IA natif à Jira pour les équipes produit et ingénierie sur Jira Cloud. Mission principale : transformer des issues Jira ambiguës en plans d'exécution structurés — clarifications, plans étape par étape et écriture dans les champs Jira — sans quitter le panneau d'issue. Pas un chatbot. Pas un outil autonome. Construit sur Atlassian Forge. » décrit exactement un produit.
Audience couvre qui sont les utilisateurs, ce dont ils ont besoin, ce qu'ils attendent et ce qu'ils ne savent pas.
Langage design couvre les patterns visuels, la bibliothèque de composants, les habitudes d'interaction et les choses qu'on ne fait jamais.
Stack et contraintes couvre les frameworks réels, les limites de runtime, les intégrations et les choix explicitement hors limites.

La mauvaise version de chaque champ correspond à des milliers de produits. La bonne correspond à exactement un. C'est le test.

Le contexte produit fonctionne mieux comme quatre blocs explicites : résumé produit, audience, langage design et stack technique.

L'audience est là où le contexte générique se casse

L'audience est généralement le premier champ que les équipes simplifient à l'excès. « Product managers et développeurs » semble raisonnable. C'est aussi trop vague pour aider le modèle à prendre de meilleures décisions.

Un champ audience utile est précis sur la composition de l'équipe, la familiarité avec l'IA, les attentes en matière de confiance et ce que les utilisateurs ne veulent pas. Pour Just, cela signifie des PMs et des ingénieurs seniors dans des équipes Jira Cloud de 10 à 100 personnes, avec une familiarité modérée avec l'IA, qui gèrent leurs propres clés API et se soucient davantage d'une sortie fiable que d'une sortie impressionnante.

La ligne « Pas pour » est tout aussi importante. Préciser que ce n'est pas pour des équipes hors Jira Cloud ou pour des utilisateurs qui veulent des agents entièrement autonomes élimine des catégories entières de mauvaises hypothèses avant qu'elles n'apparaissent.

C'est ce qui rend le contexte ancré plutôt que décoratif. Le modèle n'est pas seulement informé de qui est l'utilisateur. Il lui est aussi expliqué dans quel monde cet utilisateur évolue et quels types de workflows sembleraient incorrects.

Extraire ce qui existe déjà

La plupart des équipes ont déjà les quatre couches de contexte — elles sont simplement dispersées entre les codebases, les fichiers de design, la documentation et la mémoire de l'équipe, plutôt que dans une forme que l'IA peut utiliser.

Depuis votre dépôt : pointez un agent de code — Claude Code, Codex ou équivalent — sur votre codebase et demandez un résumé markdown couvrant l'objectif du produit, le stack, les limites d'implémentation et les contraintes connues. Un dépôt bien structuré produit un premier jet utilisable en quelques minutes.

Depuis vos fichiers design : identifiez le nom de la bibliothèque de composants, trois à cinq patterns d'interaction clés sur lesquels votre produit s'appuie, et trois choses que l'UI ne fait jamais. Les anti-patterns comptent autant que les patterns.

Depuis la documentation existante : les notes d'onboarding, les fichiers README, les briefs internes ou le contexte marketing peuvent tous contribuer des fragments de résumé produit et de définition d'audience. Ils n'ont pas besoin d'être parfaits pour être utiles.

Depuis votre propre tête : si rien de tout ça n'existe encore, ouvrez un document vierge et écrivez maintenant un paragraphe par champ. Ce sera imparfait. Un contexte imparfait surpasse largement l'absence de contexte.

Vous n'avez pas besoin d'une documentation parfaite. Vous avez besoin d'une description compacte et honnête du monde dans lequel vit votre produit.

Stockez-le une fois, réutilisez-le partout

Le contexte ne devient rentable que s'il est réutilisable. L'écrire une fois et le coller dans une seule session aide cette session. Le rendre persistant aide chaque session.

Dans Just, le panneau d'administration dispose d'une section dédiée pour chacun de ces quatre champs de contexte — Résumé Produit, Audience, Langage Design et Stack. Collez votre contenu dans chaque champ une fois par projet. Chaque insight futur, chaque clarification, chaque plan et chaque étape d'exécution dans ce projet sera automatiquement ancré dans ce contexte.
Si vous n'utilisez pas Just, créez un seul fichier context.md à la racine de votre dépôt ou dans la documentation partagée. Structurez-le avec les mêmes quatre sections. Collez-le au début de chaque session IA — assistants de code, outils de chat, générateurs de documents. Le format importe moins que l'habitude : le contexte d'abord, avant le prompt.

Traitez votre couche de contexte comme un document vivant, pas comme un artefact du jour de lancement. Révisez-la quand le produit change significativement — une nouvelle intégration, un changement d'audience majeur, une migration de système de design. Ne la révisez pas à chaque sprint. Si votre résumé produit change toutes les deux semaines, ce n'est pas un résumé produit — ce sont des notes de réunion.

Le contexte partagé rend le résultat plus cohérent entre les personnes, les rôles et les sessions, plutôt que de laisser chacun réinventer le même prompt seul.

Le contexte n'est pas du prompt engineering

Le contexte produit n'est pas du prompt engineering. Ce n'est pas un truc, un template ou un hack ingénieux. C'est donner au modèle le même briefing que vous donneriez à un nouveau prestataire le premier jour : voici ce que nous construisons, pour qui, comment ça doit ressembler et sur quoi ça tourne.

Les équipes qui font ça une fois — et le réutilisent de manière cohérente — obtiennent des résultats qui donnent l'impression de venir de quelqu'un qui comprend vraiment le produit. Parce que dans tous les sens fonctionnels du terme, c'est le cas. Le modèle n'est pas devenu plus intelligent. Vous avez simplement arrêté de lui demander de deviner.