Le prompt n’est pas le système.

Nous avons pris une instruction pour un modèle opérationnel.

La première vague d’IA au travail a appris le même rituel à tout le monde. Ouvrir une case vide. Expliquer ce qu’on veut. Examiner la réponse. Ajouter trois adjectifs. Répéter jusqu’à ce que le résultat paraisse plausible ou que la réunion commence.

C’est utile pour les tâches personnelles. C’est une mauvaise fondation pour un travail commercial qui se répète entre personnes, systèmes et clients. Un prompt décrit un résultat. Il définit rarement qui porte la décision, quelles données font autorité, ce que l’IA peut modifier, comment la qualité est jugée ou ce qui se passe lorsque la situation sort du parcours idéal.

Le résultat est un folklore de prompts. Un collègue possède un paragraphe magique. Un autre a dix-sept exemples dans un document intitulé FINAL_v6. L’organisation a de l’activité, mais aucun système partagé qu’elle puisse examiner ou améliorer.

Un prompt peut lancer le travail. Il ne peut pas le gouverner.

La spécification devient le livrable précieux.

Les équipes logicielles redécouvrent les spécifications parce que l’IA peut générer l’implémentation plus vite que les humains n’expliquent leur intention. Dans le développement piloté par les spécifications, le travail important se déplace en amont : définir ce que le système doit faire, le transformer en plan, décomposer le travail, puis laisser un agent implémenter selon des contraintes explicites.

La même inversion compte pour les équipes responsables du chiffre d’affaires. Si un système d’IA prépare des recherches sur les comptes, la spécification ne devrait pas commencer par le ton rédactionnel. Elle devrait commencer par la décision que la recherche soutient. Que doit savoir le commercial avant l’appel ? Quelles sources sont autorisées ? À quel point un signal doit-il être récent ? Quelles affirmations exigent une citation ? Que faut-il omettre lorsque le niveau de confiance est faible ?

Une fois la spécification explicite, les prompts deviennent des détails d’implémentation. Les modèles peuvent changer. Les outils peuvent changer. L’intention commerciale reste lisible.

Spécifiez le système de revenus en cinq parties.

Une spécification utile n’est pas un cahier des charges de 90 pages. C’est un contrat compact entre l’entreprise, les personnes qui font le travail et le système qui agit en leur nom.

« Étudie ce compte » est une demande. Pas un système.

Supposons qu’une équipe commerciale souhaite des synthèses avant appel générées par l’IA. La demande semble simple. Les décisions cachées ne le sont pas. Quelle entreprise correspond au compte lorsque les noms se confondent ? Une offre d’emploi constitue-t-elle une preuve de priorité stratégique ? De combien peut dater une annonce de financement avant de devenir anecdotique ? Le système devrait-il déduire une difficulté d’un choix technologique ?

Une spécification système rend ces questions visibles avant qu’elles ne deviennent des résultats incohérents. Elle peut exiger deux sources pour les affirmations importantes, distinguer observation et déduction, ignorer les signaux de plus de six mois, montrer l’incertitude et demander une validation avant toute entrée dans le CRM.

La synthèse générée peut encore varier. Le processus qui l’entoure ne devrait pas. Les entrées, les autorisations, les règles de décision, les contrôles et les responsabilités peuvent rester explicites même lorsque le langage est probabiliste.

• Définissez la décision avant le livrable.
• Nommez les sources faisant autorité avant de connecter les outils.
• Écrivez l’exception avant de peaufiner le parcours idéal.
• Choisissez le point de validation avant d’accorder l’autonomie.
• Décidez quelles preuves modifient la spécification après le lancement.

Une spécification devrait apprendre sans redevenir du folklore.

La première spécification sera erronée. Les vrais clients produisent des exceptions que les ateliers ne font pas émerger. L’objectif n’est pas de prévoir tous les cas particuliers. C’est de donner un endroit où intégrer les nouvelles connaissances.

Lorsqu’une synthèse confond régulièrement filiales et maisons mères, actualisez la règle d’entité. Lorsque les commerciaux ignorent une section, examinez si l’information est faible ou seulement mal placée. Lorsqu’un réviseur conformité rejette une affirmation, changez le seuil de preuve. Le système s’améliore parce que les retours opérationnels modifient un document explicite, et non parce que quelqu’un ajoute discrètement une phrase à un prompt privé.

C’est le passage de l’utilisation de l’IA à son exploitation. Le prompt cesse d’être le produit. La boucle gérée devient le produit.