Les équipes des finances ont adopté l’IA générative comme elles avaient adopté les tableurs : une personne à la fois. Un analyste trouve une formulation qui produit un bon résumé des écarts, l’enregistre dans un fichier de notes et la transmet à un collègue, qui change quelques mots. Quelques mois plus tard, l’équipe compte de nombreuses versions de la même demande, et le chef des finances reçoit deux explications différentes du même mouvement de marge de la part de deux personnes qui ont toutes deux utilisé l’IA.
Le problème vient rarement du modèle. Il vient du fait que la demande, les données qu’elle consulte et la réponse attendue n’ont jamais été mises par écrit. Une bibliothèque d’invites règle ce problème : un ensemble partagé et testé d’invites pour les questions auxquelles les finances répondent chaque mois, chacune avec un responsable désigné.
Pourquoi les invites improvisées dérivent
Les modèles de langage réagissent à la formulation et au contexte. Demandez « les revenus par rapport au plan » un jour et « les ventes par rapport au budget » le lendemain, et l’assistant peut choisir des définitions, des périodes et des arrondis différents. Collez un extrait plus ancien d’un jour que le dossier, ou laissez le fournisseur mettre à jour le modèle sous-jacent, et la même question donne une réponse différente, avec la même assurance.
Rien de cela n’est visible pour le lecteur. La réponse arrive bien rédigée et formulée avec aplomb, sans trace des choix faits en chemin. En finance, une réponse impossible à reproduire ne peut pas être vérifiée, et une réponse impossible à vérifier ne devrait pas se rendre jusqu’à un dirigeant.
Ce que contient une entrée de la bibliothèque
Une entrée est plus que le texte d’une invite. C’est un petit produit documenté, en cinq parties.
- La question à laquelle elle répond, dans les mots que les gens emploient réellement, avec les variantes habituelles : pourquoi la marge a bougé, le pont de marge, ce qui a fait varier la marge brute.
- Les données qu’elle consulte : le modèle certifié, les mesures, la période et les règles d’accès. Une invite de la bibliothèque ne dépend jamais de ce qui a été collé dans la conversation.
- Le format attendu : la longueur, l’ordre, les unités, les conventions de signe et l’arrondi, pour que chaque réponse ait la même forme et puisse entrer dans un dossier sans retouche.
- Des questions tests avec les réponses attendues, vérifiées par rapport aux chiffres certifiés et conservées avec l’entrée.
- Un responsable et une version. Une personne répond de l’entrée, approuve les changements et décide de son retrait.
Rédiger une entrée est un petit travail, pas un projet. L’essentiel de l’effort va aux questions tests et à leurs réponses attendues, et c’est aussi là que se trouve l’essentiel de la valeur : elles transforment une bonne formulation en un outil sur lequel l’équipe peut compter.
Commencer par les questions auxquelles les finances répondent chaque mois
Les meilleures premières entrées sont les questions récurrentes : les revenus et la marge par rapport au plan, les charges d’exploitation par centre de coûts, la trésorerie et le fonds de roulement, les effectifs et le coût de la main-d’œuvre. Elles reviennent à chaque clôture, leurs bonnes réponses sont connues, et leurs définitions existent déjà dans le modèle de rapports. Une poignée d’entrées bien construites couvre une bonne part de ce que demandent les dirigeants, et les questions qui sortent de la bibliothèque montrent où bâtir ensuite.
Résistez à l’envie de cataloguer toutes les invites jamais écrites. Une bibliothèque a de la valeur parce que chaque entrée a été testée et a un responsable; une longue liste de formulations non testées n’est qu’un plus gros fichier de notes.
Tester les invites comme on teste les rapports
Une invite est du code écrit en langage courant, et elle mérite la même discipline. Chaque entrée porte ses questions tests, et toute la bibliothèque est réexécutée chaque fois qu’une invite, le modèle de données ou le modèle d’IA change. Une entrée qui échoue retourne à son responsable avant que quiconque s’y fie. Avec le temps, les résultats des tests deviennent la preuve que la bibliothèque est fiable, et le registre que les auditeurs et les contrôleurs demanderont à voir.
Les tests doivent vérifier plus que le chiffre principal. Une bonne réponse utilise la bonne période, la bonne comparaison et la bonne convention de signe, et le dit; une réponse avec le bon total et la mauvaise période reste fausse.
Rendre chaque réponse vérifiable
Être reproductible ne suffit pas; une réponse doit aussi montrer comment elle a été obtenue. Les invites de la bibliothèque devraient exiger que l’assistant précise les mesures, les filtres et la période utilisés ainsi que la date de la dernière actualisation des données, pour qu’un réviseur puisse rattacher chaque chiffre au modèle certifié. Les réponses qui sortent de l’équipe des finances, comme le commentaire du dossier du conseil, sont révisées par une personne et conservées avec la version de l’invite qui les a produites.
Un ordre fixe aide le réviseur : d’abord la conclusion, puis les chiffres qui la soutiennent, puis la source et son heure d’actualisation. Quand toutes les réponses suivent le même ordre, un élément manquant saute aux yeux.
Mettre la bibliothèque là où les gens travaillent déjà
Une entrée qu’il faut copier d’un document vers une fenêtre de clavardage sera modifiée en chemin, et ces modifications ne seront pas testées. Rendez la bibliothèque accessible dans les outils que l’équipe utilise déjà, comme l’assistant de l’outil de rapports ou un agent conçu pour l’équipe des finances dans Copilot Studio, afin que les gens choisissent une entrée testée plutôt que de la retaper. Plus le chemin testé est facile, moins les invites improvisées survivent.
Gérer la bibliothèque comme un produit
Quelqu’un doit être responsable de la bibliothèque, habituellement la personne qui dirige la planification financière ou les rapports, avec un petit groupe de contributeurs. Les nouvelles entrées viennent des questions auxquelles les analystes répondent encore et encore. Un changement à une entrée suit une version allégée de la gestion des changements : une proposition, un essai, l’approbation du responsable et un nouveau numéro de version. Les entrées retirées sont conservées, avec la raison, pour que les réponses passées restent explicables. Faites le suivi de la bibliothèque comme de n’importe quel produit : quelles entrées servent le plus, lesquelles échouent à leurs tests, et quelles questions arrivent auxquelles elle ne sait pas encore répondre. L’accès suit les mêmes règles que les données, de sorte qu’une invite ne peut pas révéler ce que son utilisateur n’a pas le droit de voir; les règles qui protègent les données s’appliquent à chaque requête d’IA faite par la bibliothèque.
Le bénéfice est plus discret que le lancement d’un nouvel outil, et plus durable. La même question obtient la même réponse, peu importe qui la pose et quand, et lorsqu’une réponse change, la raison est consignée.