Le vrai travail commence avant le prompt.
L'atelier de prompts qui avait commencé trop tard
L'atelier avait été réservé pour améliorer les prompts. C'était le titre dans le calendrier, avec une petite icône de baguette magique que quelqu'un regrettait par la suite. Un groupe de managers, d'analystes, d'opérateurs et d'ingénieurs était assis autour d'une table avec un document partagé. Le prompt actuel était à l'écran. Il demandait à un modèle de langage d'examiner les demandes des clients, d'identifier la bonne politique, de rédiger une réponse et de signaler les risques. Il était poli, structuré et bien plus long que quiconque ne voulait l'admettre. Ce n'était pas non plus le problème principal.
Le premier cas de test concernait un client demandant une exception après une livraison retardée. Le modèle avait produit une réponse correcte. Puis quelqu'un des opérations a dit que la politique source à l'écran n'était plus celle que l'équipe utilisait le vendredi, car une règle temporaire du transporteur avait été prolongée deux fois sans jamais être fusionnée dans la page principale de la politique. Quelqu'un du juridique a dit que les exceptions au-dessus d'un certain montant nécessitaient une approbation, mais que le seuil dépendait de la catégorie de produit. Les finances ont demandé où étaient enregistrés les crédits de bonne volonté. Le support a dit que le ton du modèle était correct, mais que le client rappellerait parce que la réponse ne mentionnait pas l'événement de suivi manquant. Le prompt restait là, semblant innocent.
Aucun de ces problèmes ne serait résolu par un meilleur paragraphe d'instructions. Le modèle ne pouvait pas déduire quelle page de politique faisait autorité. Il ne pouvait pas savoir qu'une règle temporaire était devenue une réalité opérationnelle. Il ne pouvait pas décider qui avait l'autorité d'approbation. Il ne pouvait pas voir que l'événement de suivi manquant était la véritable cause du prochain contact. On demandait au prompt de compenser un travail peu clair. C'est une erreur courante. Les gens arrivent au prompt avec un panier d'ambiguïtés de processus et demandent au modèle d'être élégant à ce sujet.
Le vrai travail se fait avant le prompt. C'est le travail de nommer la tâche, de définir les limites, de sélectionner les sources, de régler l'autorité, de préparer des exemples, de décider des chemins d'échec, de façonner la sortie, de mesurer la qualité et de rendre la correction possible. Le prompting compte. Un mauvais prompt peut rendre une bonne configuration maladroite. Mais un beau prompt sur une opération peu claire n'est que de la confusion bien écrite. Le modèle peut sembler meilleur. Le travail ne sera pas plus sûr, moins cher ou plus compréhensible par accident.
Un prompt n'est pas une cartographie de processus
Un prompt peut indiquer à un modèle comment se comporter dans un contexte. Il ne peut pas créer le contexte si l'organisation ne l'a pas fait. Il peut demander de la concision, de la structure, de l'humilité et des citations. Il peut décrire un rôle. Il peut spécifier un format. Il peut avertir le modèle de ne pas deviner. Tout cela est utile. Mais cela reste peu de chose face aux questions de processus qui déterminent si un système d'IA aide réellement ou se contente de parler avec assurance à proximité du travail.
Quelle est la tâche. Est-ce de la classification, de l'extraction, de la synthèse, de la rédaction, de l'orientation, de la recommandation, de la vérification ou de l'action. Quelle partie est automatisée. Quelle partie reste humaine. Quel état change si le résultat est accepté. Qui est concerné. Quels enregistrements sont touchés. Quelle politique s'applique. Quelles preuves sont obligatoires. Que se passe-t-il lorsque les preuves manquent. Quelles erreurs sont tolérées. Quelles erreurs causent du tort. Ces questions déterminent la forme du système. Un prompt qui ne repose pas sur des réponses claires devient une supposition polie portant un badge.
De nombreux projets pilotes d'IA échoués commencent par un prompt parce que le prompt est la poignée la plus visible. Il semble créatif et immédiat. On peut le modifier en réunion. On peut essayer une nouvelle version avant que le café ne refroidisse. La conception des processus est plus lente. Le nettoyage des données est plus lent. La cartographie des autorités est plus lente. La construction des ensembles d'évaluation est plus lente. Malheureusement, lent ne signifie pas facultatif. Les parties sautées avant le prompt reviennent plus tard sous forme d'hallucinations, de retouches, de méfiance, d'exceptions politiques et d'un grand tableur appelé problèmes.
La meilleure séquence n'est pas glamour. Écrivez le travail. Parcourez des cas réels. Identifiez les systèmes sources. Marquez quels champs déterminent les résultats. Séparez les règles du jugement. Décidez où les humains interviennent. Définissez des contrats de sortie. Construisez des exemples. Convenez du refus. Testez avec les personnes qui vivront avec le résultat. Ce n'est qu'alors que le prompt devient un levier utile. Avant cela, c'est un volant décoratif posé sur un bureau.
La tâche a besoin d'une limite assez nette pour être testée
Le travail lié à l'IA commence souvent par des verbes trop larges. Aider au service client. Soutenir la revue juridique. Améliorer la planification. Assister les achats. Rendre les rapports plus intelligents. Ce sont des ambitions, pas des tâches. Un modèle ne peut pas être évalué par rapport à une ambition. Il peut être évalué par rapport à une tâche avec des entrées, des sorties, des contraintes, des critères de réussite et des chemins d'échec. La description plus étroite peut sembler moins excitante. C'est aussi le premier moment où le travail devient constructible.
Une limite de tâche nette indique ce que le système peut voir et ce qu'il peut modifier. Elle indique si le modèle lit des documents sources, génère un brouillon, extrait des champs structurés, recommande une action ou appelle un outil. Elle indique quelles sorties sont définitives, lesquelles sont consultatives et lesquelles doivent être revues. Elle indique ce que le système refuse. Elle indique quand le modèle doit demander plus de preuves plutôt que de compléter la réponse. Elle indique ce qui est hors du périmètre, car c'est là que les projets pilotes ambitieux deviennent des rapports d'incident.
Les limites rendent l'évaluation possible. Si la tâche est de rédiger une réponse en utilisant ces sources et cette politique, la qualité peut être testée. Si la tâche est d'améliorer la qualité du service avec l'IA, chaque résultat peut être présenté comme un progrès par quelqu'un avec suffisamment de diapositives. Une limite protège également les utilisateurs d'une escalade accidentelle. Un outil qui commence par rédiger peut acquérir un bouton qui envoie. Un classificateur peut devenir un routeur. Un routeur peut devenir une décision. Sans limite nommée, cette dérive ressemble à une adoption. Avec une limite, elle devient une demande de changement.
La limite doit être formulée dans un langage opérationnel, et pas seulement technique. Le responsable du support doit pouvoir la comprendre. Le service juridique aussi. Le propriétaire des données également. L'ingénieur doit pouvoir la tester. Si la limite n'existe que dans le prompt, elle est fragile. Les prompts sont importants, mais ils ne constituent pas des documents de politique générale porteurs. Ils ressemblent plutôt à des instructions données à un employé temporaire très compétent qui n'a jamais vu l'organigramme.
Les sources ne sont pas un tas de documents
De nombreuses équipes découvrent, au moment de rédiger les prompts, qu'elles ne savent pas quelles sources sont fiables. Elles ont des pages de politique, des PDF, des instructions par courriel, du matériel de formation, des manuels hérités, des messages de discussion, des macros de tickets, des feuilles de calcul de suivi, et la mémoire d'une opératrice que tout le monde appelle parce qu'elle sait comment cela fonctionne vraiment. On demande ensuite au modèle de répondre à partir de la base de connaissances. Quelle connaissance. Quelle base. L'expression peut dissimuler une quantité héroïque de flou.
La préparation des sources n'a rien de prestigieux, c'est pourquoi elle est souvent faite en retard. Elle implique de décider quel document prévaut lorsque les sources se contredisent, comment la fraîcheur est vérifiée, comment les règles temporaires expirent, comment les exceptions sont représentées, comment le contenu confidentiel est exclu, comment les versions des sources sont conservées, et comment les identifiants de citation survivent à la réponse du modèle. Ce n'est pas de la paperasse. C'est la différence entre la récupération et la fouille.
L'IA rend la discipline des sources plus importante parce que le modèle peut faire passer de mauvaises pratiques pour acceptables. Il peut assembler des fragments en une prose fluide. Il peut lisser les contradictions. Il peut produire une réponse plausible à partir de documents obsolètes. Un résultat de recherche avec des lacunes visibles semble incomplet. Une réponse générée avec les mêmes lacunes peut sembler complète. Plus la prose est bonne, plus la provenance est importante. La confiance ne devrait pas servir à blanchir une chaîne de sources faible.
Une bonne préparation des sources réduit aussi la complexité du prompt. Un prompt rempli d'avertissements sur des politiques contradictoires, des documents obsolètes, des champs manquants et des exceptions particulières est souvent le symptôme d'une négligence en amont. Si la couche de récupération filtre déjà par autorité et fraîcheur, le prompt peut être plus court. Si la source porte des métadonnées structurées, le modèle n'a pas besoin de les déduire des titres de paragraphes. Si les exceptions sont représentées comme des règles, le modèle n'a pas à devenir un détective avec des limites de jetons. La meilleure amélioration d'un prompt est parfois un meilleur index.
Les exemples sont de petites pièces de gouvernance
Les exemples sont généralement considérés comme des outils de formation, mais ils relèvent aussi de la gouvernance. Un bon exemple définit ce que signifie la qualité dans une situation donnée. Il montre comment l'organisation gère l'incertitude, les preuves manquantes, les politiques contradictoires, le ton sensible, l'escalade et le refus. Il indique au modèle et à l'équipe à quoi ressemble une bonne réponse, mais aussi à quoi ressemble un bon non-refus. Cela importe car de nombreux systèmes sérieux échouent en répondant alors qu'ils devraient marquer une pause.
Construire des exemples impose des décisions que la discussion abstraite évite. Prenez vingt cas réels. Marquez le résultat correct. Marquez les alternatives acceptables. Marquez les raccourcis inacceptables. Expliquez pourquoi. Incluez des cas limites qui ont fait hésiter du personnel expérimenté. Incluez aussi des cas ordinaires, car les systèmes qui ne s'entraînent que sur le dramatique apprennent de mauvaises manières. Demandez à des experts du domaine d'être en désaccord et consignez ce désaccord. C'est plus lent que de demander au modèle d'être prudent. Cela produit aussi un langage commun pour la prudence.
Les exemples doivent inclure des cas négatifs. Aucune source trouvée. Conflit de sources. L'utilisateur n'a pas l'autorité. Demande hors du cadre prévu. Le client demande quelque chose qui semble simple mais qui déclenche une politique. Le modèle doit apprendre quand refuser, escalader, demander ou renvoyer une incertitude structurée. Si les exemples ne montrent que des réponses réussies, l'invite penchera vers l'achèvement. L'achèvement n'est pas toujours un succès. Parfois, la meilleure réponse est un manque de preuves, ce qui est difficile à célébrer dans une démonstration mais utile dans un système en fonctionnement.
Les exemples sont aussi le début de l'évaluation. Ils peuvent devenir des cas de test, des cas de régression, des supports de formation pour les évaluateurs et des échantillons de surveillance. Lorsqu'un incident survient, un cas corrigé peut devenir un nouvel exemple. Cela donne une mémoire au système. Sans exemples, les modifications d'invite deviennent des changements d'humeur. Quelqu'un dit que la réponse semble meilleure. Quelqu'un d'autre dit qu'elle semble pire. Le modèle sourit au milieu, imperturbable face aux preuves.
La forme de la sortie est une décision opérationnelle
Les discussions sur les invites passent souvent trop de temps sur le ton et pas assez sur la forme de la sortie. Le ton compte, surtout dans la communication client ou publique. Mais la forme de la sortie détermine si la réponse peut être vérifiée, routée, stockée, approuvée, contestée ou utilisée par un autre système. Un paragraphe peut être agréable. Une sortie structurée peut être exploitable. Un travail sérieux sur l'IA nécessite souvent les deux : une prose lisible pour les humains et des champs que les machines peuvent vérifier.
La forme de sortie comprend les champs obligatoires, les références aux sources, la confiance ou l'incertitude, les motifs de refus, les indicateurs d'escalade, les enregistrements concernés, les actions proposées et l'état d'approbation humaine. Elle précise si le modèle peut laisser un champ vide. Elle précise s'il doit citer un identifiant de politique. Elle précise s'il peut inventer des catégories ou doit choisir dans une liste contrôlée. Elle précise ce qui se passe lorsque l'entrée est ambiguë. Ces choix ne relèvent pas du simple vernis du prompt. Ils relèvent de la conception du flux de travail.
La sortie structurée maintient également le modèle dans son rôle. Si le système exige un champ séparé pour les preuves, les affirmations non étayées deviennent visibles. S'il exige un type d'action issu d'une liste autorisée, l'utilisation créative des outils devient plus difficile. S'il exige que l'incertitude soit explicite, les réviseurs peuvent trier. S'il exige un motif de refus, les cas bloqués peuvent être analysés. Le prompt peut demander ces éléments, mais le système environnant doit les valider. Demander poliment n'est pas un contrôle. C'est une suggestion avec mise en forme.
Il y a un aspect humain. Les personnes ont besoin d'une sortie qui correspond à leur rythme de travail. Un avocat peut avoir besoin de clauses sources et de notes de risque. Un agent de support peut avoir besoin d'un brouillon prêt pour le client ainsi que de codes de raison internes. Un planificateur peut avoir besoin d'une recommandation d'itinéraire et de la contrainte qui l'a motivée. Un gestionnaire peut avoir besoin de raisons agrégées, et non de prose individuelle. Si la forme de sortie ignore l'utilisateur, le prompt peut être techniquement correct et opérationnellement irritant. C'est un exploit courant, mais pas un exploit utile.
L'autorité ne peut pas être implicite par la serviabilité
Un modèle serviable invite à la confiance. C'est bien, jusqu'à ce que la serviabilité soit confondue avec l'autorité. Si le modèle rédige une réponse, qui peut l'envoyer. S'il recommande un remboursement, qui peut l'approuver. S'il classe le risque, qui peut agir sur cette classification. S'il extrait un champ, qui le corrige. S'il ne trouve pas de preuve, qui décide de poursuivre. Ces questions doivent être répondues avant le prompt, car le prompt ne peut pas accorder d'autorité institutionnelle.
La conception de l'autorité comprend les rôles, les seuils, les files de révision, les droits de dérogation, les chemins d'escalade et les registres d'audit. Elle distingue la suggestion de la décision. Elle distingue la décision automatisée de la décision humaine soutenue par l'automatisation. Elle précise quand un humain doit voir le matériel source plutôt que seulement la prose du modèle. Elle précise quand un appel d'outil est autorisé et quand il est bloqué. Elle précise qui est responsable des dommages, des retards, des corrections et de la communication. Le modèle peut aider dans le cadre de cette conception. Il ne devrait pas être la conception.
C'est particulièrement important lorsque l'IA est ajoutée à des flux de travail existants. L'autorité existante peut être informelle. Une personne senior approuve les exceptions parce que tout le monde sait qu'il faut lui demander. Une chef d'équipe interprète la politique parce qu'elle a vu les cas limites. Une feuille de calcul porte une règle temporaire parce que le système ne le peut pas. Lorsque l'IA entre en jeu, l'autorité informelle devient fragile. Le modèle peut amplifier l'ancienne ambiguïté plus vite que les gens ne peuvent la rattraper. Le travail préalable au prompt consiste à rendre l'autorité suffisamment explicite pour que la mise à l'échelle ne fasse pas simplement passer à l'échelle la confusion.
Il vaut la peine de dire que l'autorité n'est pas l'ennemie de la vitesse. Une autorité claire rend souvent le travail plus rapide parce que les gens savent ce qui peut avancer sans débat, ce qui doit faire une pause et qui peut décider. Une autorité vague semble flexible jusqu'à ce qu'elle rencontre le volume. Alors chaque cas difficile devient une petite crise constitutionnelle, avec des fils de discussion comme jurisprudence. Ce n'est pas un système juridique recommandé.
L'évaluation n'est pas un contrôle d'ambiance
De nombreuses itérations de prompts sont jugées au ressenti. Cette version sonne mieux. Celle-là est plus concise. Celle-ci est moins directive. Ces jugements peuvent être utiles, mais ils ne suffisent pas. Les opérations d'IA ont besoin d'une évaluation qui suit la tâche. Le modèle a-t-il utilisé la bonne source. A-t-il manqué des champs obligatoires. A-t-il refusé lorsque les preuves étaient absentes. A-t-il fait remonter les cas à haut risque. A-t-il préservé les identifiants de politique. Les humains l'ont-ils contourné. Les clients ont-ils posé moins de questions de suivi. Les équipes en aval ont-elles vu moins de reprises.
L'évaluation devrait inclure des cas ordinaires, des cas limites, des cas adverses, des sources obsolètes, des données manquantes, des politiques contradictoires et des exemples de refus acceptables. Elle devrait être reproductible. Elle devrait distinguer une défaillance du modèle d'une défaillance de la source, d'une défaillance du prompt, d'une défaillance de l'interface et d'une défaillance du processus. Sinon, chaque problème devient un problème de prompt, car le prompt est la partie que tout le monde peut voir. La partie visible n'est pas toujours la partie coupable. Cela est vrai dans les logiciels comme dans les réunions.
L'évaluation décide aussi du moment où l'on s'arrête. Sans jeu de tests ni critères de mise en production, le travail sur les prompts peut continuer indéfiniment, car la langue peut toujours être améliorée. Il y aura toujours un autre adjectif, une autre instruction, un autre exemple, un autre ajustement de formatage. La question n'est pas de savoir si le prompt est parfait. La question est de savoir si le système accomplit la tâche dans les limites convenues de risque, de coût et de qualité. La perfection est un mauvais gestionnaire de mise en production. Elle ne porte pas de téléavertisseur.
Le travail après le prompt commence avant la mise en production
Les chemins de correction devraient être conçus avant que le premier utilisateur en production ne signale un problème. Comment un utilisateur signale-t-il une réponse erronée. Où va ce signalement. Qui l'examine. La source change-t-elle. La banque d'exemples change-t-elle. Le prompt change-t-il. Une règle change-t-elle. Un seuil change-t-il. Un humain reçoit-il un retour. Le cas corrigé devient-il un test de régression. Si la correction n'est pas conçue, le retour devient un tas. Les tas sont l'endroit où l'apprentissage va faire une longue sieste.
La surveillance devrait aussi être décidée avant la mise en production. Suivre non seulement la latence et le coût, mais aussi les taux de refus, les taux de source manquante, les raisons de contournement, la charge de remontée, les reprises en aval, les thèmes de réclamation, les citations obsolètes et la dérive dans la répartition des tâches. La qualité des réponses du modèle n'est qu'une partie de la qualité opérationnelle. Un système peut bien répondre et pourtant orienter trop de travail vers les humains. Il peut répondre rapidement et pourtant augmenter les corrections. Il peut réduire les tickets et pourtant créer des tickets plus difficiles. La surveillance devrait voir le travail, pas seulement les jetons.
Le travail préparatoire ne s'arrête jamais vraiment. De nouvelles politiques apparaissent. Les systèmes sources changent. Les utilisateurs trouvent des raccourcis. Le modèle change. L'entreprise change. Une consigne qui fonctionnait en mai peut être erronée en septembre parce que le travail s'est déplacé en dessous. Cela ne signifie pas que tout est fragile. Cela signifie que les opérations d'IA ont besoin d'une prise en charge. Quelqu'un doit maintenir la définition de la tâche, les sources, les exemples, l'évaluation, l'autorité et la réparation. Sinon, la consigne devient un fossile avec une excellente grammaire.
La leçon
Le vrai travail se fait avant la consigne, car la consigne n'est que la partie visible d'un système d'exploitation plus vaste. Le modèle a besoin d'une tâche qu'il peut accomplir, de sources auxquelles il peut se fier, de limites qu'il ne peut pas franchir, de résultats qui peuvent être vérifiés, d'exemples qui incarnent le jugement, d'une autorité qui indique aux humains et aux outils ce qu'ils ont le droit de faire, et d'une évaluation qui peut distinguer l'amélioration d'une simple prose plus agréable. Sans cela, la consigne porte des responsabilités qu'elle ne peut pas assumer.
Cette vision ne diminue pas l'importance de la consigne. Elle la rend plus précieuse. Une consigne intégrée à une opération préparée peut être courte, claire, testable et maintenable. Elle peut orienter le modèle au lieu de compenser l'ambiguïté. Elle peut évoluer avec des exemples et des preuves. Elle peut être modifiée en toute confiance parce que l'équipe sait ce que signifie un bon résultat. C'est mieux que le mysticisme de la consigne, qui produit surtout des consignes plus longues et des doutes plus discrets.
Avant de demander comment orienter le modèle, demandez-vous quel travail l'organisation a déjà fait pour le modèle. La tâche est-elle nommée. Les sources sont-elles autoritaires. Les exemples sont-ils marqués. La sortie est-elle structurée. L'autorité est-elle explicite. L'échec est-il sûr. L'évaluation est-elle réelle. La réparation est-elle conçue. Si ces réponses sont faibles, commencez par là. La consigne la plus utile de la pièce pourrait être celle qui amène tout le monde à admettre que la consigne n'est pas là où le travail commence.