Bibliothèque de prompts en entreprise : la méthode d’Ayoub Kahouadji pour créer, tester et maintenir des prompts utiles

1. Passer d’une liste de prompts à un actif de travail

La valeur ne vient pas du nombre de formulations stockées, mais de la capacité à comprendre, tester et retirer chacune d’elles.

Une liste de prompts peut sembler productive dès le premier atelier. Chacun ajoute sa meilleure formule, le document grandit et l’équipe gagne quelques minutes. Le problème apparaît plus tard : personne ne sait quelle version utiliser, pour quelle tâche, avec quelles données, dans quel outil ni avec quel niveau de relecture.

Le même texte peut produire des résultats différents selon le modèle, le mode, les réglages, le contexte déjà présent dans la conversation et les fichiers ajoutés. La documentation OpenAI rappelle ce caractère non déterministe et recommande des tests et des évaluations lorsque les prompts évoluent ou qu’une version de modèle change. Cette observation produit ne doit pas être généralisée mot pour mot à tous les fournisseurs, mais elle illustre un principe durable : le texte seul n’est pas le système.

Traitez donc chaque prompt comme un actif de travail. Il possède une identité, un propriétaire, une tâche, une version, un statut, des conditions d’emploi et une date de revue. Il peut être corrigé, suspendu ou retiré. Les personnes savent où trouver la version active et à qui signaler un défaut.

La bibliothèque ne doit pas devenir une collection de recettes universelles. Un prompt de synthèse de réunion, un prompt de classement de demandes et un prompt de préparation d’une réponse commerciale n’ont ni les mêmes données, ni les mêmes conséquences, ni les mêmes critères de qualité. Ils méritent trois fiches séparées.

Commencez petit : trois à cinq tâches réellement répétées. Une bibliothèque courte, comprise et testée apporte davantage qu’un catalogue de cent formulations récupérées sur Internet. L’objectif initial est de rendre un usage reproductible et contestable, pas d’impressionner avec un volume.

• Une entrée canonique par tâche et par niveau de conséquence.
• Une version active clairement identifiable.
• Un propriétaire capable d’expliquer et de retirer la fiche.
• Des conditions d’usage visibles avant le texte du prompt.
• Une preuve de test conservée sans recopier de données sensibles.

2. Définir la tâche et le propriétaire avant d’écrire le prompt

Une formulation ne peut pas être évaluée si le résultat professionnel attendu reste flou.

Écrivez d’abord la tâche en une phrase observable : « préparer un brouillon de compte rendu à partir de notes validées », « classer une demande dans une taxonomie interne » ou « proposer trois titres à partir d’un brief public ». Évitez les objectifs vagues comme « améliorer la communication » ou « gagner du temps avec l’IA ».

La tâche précise le début et la fin. Qu’est-ce qui déclenche l’usage ? Qui choisit les entrées ? Quelle sortie est produite ? Qui la relit ? Quelle action peut suivre ? Un brouillon qui reste dans un espace interne n’a pas la même conséquence qu’un message envoyé, qu’une décision sur une personne ou qu’une écriture dans un CRM.

Nommez ensuite le propriétaire de la fiche. Ce rôle ne doit pas forcément être un spécialiste technique. Il doit connaître le processus métier, pouvoir réunir les exemples, arbitrer les critères d’acceptation et déclencher une suspension. Un suppléant évite qu’une fiche reste active alors que son propriétaire n’est plus disponible.

Les utilisateurs autorisés sont également définis. Une fiche testée pour l’équipe support ne doit pas être présentée comme un modèle général pour le recrutement, la finance ou la direction. Les mots se ressemblent parfois, mais les sources, les droits, le vocabulaire, les risques et la relecture changent.

Le canvas DÉCIDE pour cadrer un premier cas d’usage IA aide à trancher ces questions en amont. La bibliothèque ne remplace pas ce cadrage. Elle reçoit uniquement les tâches dont le périmètre et la conséquence sont assez clairs pour être testés.

3. Séparer instructions stables, variables, contexte et sortie

Une fiche lisible distingue les règles durables de ce qui change à chaque exécution.

Un prompt réutilisable devient plus facile à maintenir lorsqu’il est découpé. Les instructions stables décrivent le rôle de l’assistant, l’objectif, les limites, les étapes de contrôle et ce qu’il ne doit pas faire. Les variables accueillent les informations qui changent : date, type de document, public, produit, langue ou longueur.

Le contexte fournit les sources nécessaires à l’exécution. Il peut s’agir de notes autorisées, d’une nomenclature interne, d’un extrait de procédure ou d’un document public. La fiche indique qui sélectionne ces sources, comment vérifier leur date et comment éviter d’ajouter un fichier entier lorsque quelques éléments suffisent.

La sortie attendue possède un format observable. Une consigne comme « réponds bien » ne permet aucune recette. Demandez plutôt un tableau avec des colonnes définies, une synthèse en cinq points, un brouillon contenant des mentions obligatoires ou un objet structuré qui respecte un schéma. Le format ne prouve pas l’exactitude, mais il rend le contrôle possible.

Les exemples peuvent montrer une bonne entrée et une bonne sortie, puis un cas à refuser. Ils servent de référence pédagogique et de test. Ils doivent rester synthétiques ou dûment autorisés. Ne transformez pas un ancien dossier client en exemple partagé simplement parce qu’il a déjà été utilisé dans une conversation.

La documentation officielle OpenAI distingue notamment les instructions de plus haute autorité, l’entrée utilisateur, les exemples et le contexte. D’autres outils emploient des noms différents. La bibliothèque doit conserver ses concepts métiers sans dépendre d’un libellé d’interface qui peut changer.

4. Placer les données et les droits avant la zone de copie

L’utilisateur doit voir les conditions de partage avant de coller un texte ou d’ajouter un fichier.

Une bibliothèque de prompts peut réduire certains écarts en rappelant les données admises. Elle peut aussi les amplifier si le modèle invite à coller un compte rendu, un fichier de prospects ou un contrat sans distinguer les droits. La fiche commence donc par les catégories d’entrées, pas par une zone vide.

La CNIL recommande que les utilisateurs ne soumettent que des informations qu’ils sont autorisés à partager et qu’ils vérifient les données d’entrée comme la qualité des sorties. La fiche pratique France Num, CPME et CNIL cite les prompts types comme un moyen d’harmoniser les pratiques, tout en rappelant la confidentialité et la décision humaine.

Créez quatre statuts adaptés à l’organisation : autorisé, préparé, soumis à revue et interdit. Une source publique validée peut être autorisée. Un document interne peut demander suppression d’identifiants et extraction limitée. Une donnée de salarié, un secret d’accès ou une information couverte par une obligation spécifique peut être interdit ou soumis à l’expertise compétente.

Le statut dépend aussi du service, de l’offre, du compte, des réglages, du contrat et du mode de déploiement. La même donnée ne devient pas automatiquement partageable parce que le prompt est approuvé. L’outil et le cas d’usage doivent déjà figurer dans le registre prévu par la charte.

Ne conservez pas les vraies entrées dans un journal général pour prouver que le prompt fonctionne. Stockez plutôt l’identifiant du test, la catégorie de données, la version, le verdict et une référence protégée lorsque la conservation est nécessaire et autorisée. Les secrets, données personnelles et documents privés restent hors de la bibliothèque publique ou largement partagée.

• Source publique validée : utilisable dans le périmètre prévu.
• Document interne ordinaire : extraction minimale et règles de partage vérifiées.
• Donnée personnelle ou stratégique : revue selon le traitement, le contrat et les rôles.
• Secret, identifiant ou information interdite : jamais copié dans le prompt, l’exemple ou le journal.
• Doute sur le droit ou le contexte : arrêt et escalade avant envoi.

5. Écrire les critères d’acceptation avant d’optimiser la formulation

Le prompt n’est améliorable que si l’équipe sait reconnaître une sortie acceptable, à corriger ou à refuser.

Commencez par les défauts qui cassent le travail. Une synthèse peut être inutilisable si elle invente un engagement, omet une décision, attribue une phrase à la mauvaise personne ou masque une incertitude. Un classement peut échouer s’il utilise une catégorie inexistante ou s’il force un cas ambigu.

Transformez ces défauts en critères. Certains sont binaires : aucune source inventée, aucune donnée interdite, toutes les rubriques obligatoires présentes. D’autres demandent une échelle : fidélité au document, clarté, exhaustivité, ton ou niveau de détail. Écrivez ce que signifient les niveaux pour réduire les jugements arbitraires.

Le NIST recommande de documenter les tâches, les sources, les transformations et les critères de décision, puis d’évaluer exactitude, qualité, fiabilité et authenticité par rapport à des références connues, avec des méthodes humaines et automatisées selon le besoin. Le profil est volontaire et transversal ; il ne fournit pas une note universelle pour un prompt de PME.

Le valideur doit pouvoir refuser. Il compare la sortie aux sources, signale l’erreur, corrige si le processus le permet et classe le résultat. Une simple case « relu » ne montre ni la méthode ni la raison d’une acceptation. Conservez les motifs récurrents pour améliorer la fiche et la formation.

Ne cherchez pas à remplacer toute appréciation humaine par un second modèle. Une évaluation automatique peut vérifier un format, une catégorie ou certaines règles. Les dimensions subjectives et les conséquences métier demandent des critères clairs, des exemples de référence et une calibration entre personnes.

6. Construire un corpus de tests qui cherche les faiblesses

Un bon test ne montre pas seulement que le prompt fonctionne sur le cas qui a servi à l’écrire.

Préparez d’abord deux ou trois cas normaux représentatifs. Ils servent de référence et permettent de vérifier le chemin attendu. Ajoutez ensuite un cas incomplet, un cas ambigu, un cas contradictoire, une source obsolète et une entrée qui contient une instruction parasite.

Un test de données vérifie que l’utilisateur ou le système repère une information non admise avant l’envoi. Un test de refus présente une demande hors périmètre. Un test de source demande une réponse alors qu’aucune preuve suffisante n’est disponible. Le résultat attendu peut être une question, un signalement ou un arrêt, pas nécessairement un texte complet.

Les cas doivent rester comparables entre les versions. Conservez l’entrée synthétique, la référence attendue, les critères, le verdict et la personne qui a revu le test. Si l’environnement change, notez l’outil, le modèle ou mode affiché, les fonctions actives et les paramètres utiles.

Évitez les pourcentages impressionnants sur de très petits dénominateurs. Si huit cas sur dix passent, écrivez « 8/10 » et décrivez les deux échecs. Le volume doit être proportionné à la conséquence. Un prompt de faible enjeu peut commencer avec une dizaine de cas ; une décision sensible demande une méthode d’évaluation spécialisée.

Tout échec réel qui révèle une nouvelle famille de problème peut devenir un test de régression, après anonymisation ou reconstruction synthétique. Cette pratique empêche le même défaut de revenir silencieusement lors de la prochaine modification.

1. Cas normauxVérifier les variantes les plus fréquentes et le format attendu.
2. Cas incompletsObserver si le système demande ce qui manque au lieu de l’inventer.
3. Cas contradictoiresExiger que la divergence soit signalée et conservée.
4. Cas non autorisésTester la détection, le refus et l’escalade.
5. Cas de régressionAjouter les défauts réels sous une forme synthétique et reproductible.

7. Versionner la fiche et publier un statut explicite

Une équipe doit pouvoir retrouver la version active, comprendre ce qui a changé et revenir au processus manuel.

Attribuez un identifiant stable à la fiche, par exemple `SYN-REUNION-01`. La version change lorsque les instructions, les variables, les critères, les données ou le format évoluent. L’historique résume le changement, sa raison, les tests rejoués, le valideur et la date d’entrée en vigueur.

Utilisez cinq statuts simples. Brouillon signifie non utilisable hors conception. Pilote autorise un groupe et un volume limités. Approuvé ouvre le périmètre documenté. Suspendu bloque temporairement l’usage pendant l’analyse. Retiré désigne une fiche remplacée ou devenue inutile.

Le statut doit apparaître avant le texte à copier. Dans un wiki, affichez un bandeau. Dans un tableur, protégez les colonnes d’autorité. Dans une application, servez uniquement la version approuvée et conservez une procédure de retour. Les anciennes versions restent traçables sans être proposées comme modèles actifs.

Pour une utilisation manuelle et bornée, un document partagé contrôlé peut suffire. Pour une application API, la documentation OpenAI consultée le 30 juillet 2026 recommande de conserver les prompts de production dans le code, avec entrées typées, revue, tests et déploiement normal. Elle annonce la fin programmée de ses objets de prompts réutilisables au 30 novembre 2026. Cette échéance produit doit être revérifiée avant une migration.

Quel que soit le support, ne mélangez pas autorité et facilité de copie. Une personne peut proposer une amélioration sans pouvoir remplacer la version active. Le propriétaire publie après recette et conserve la décision. En cas de doute, le statut revient à pilote ou suspendu.

8. Former les utilisateurs à appliquer, corriger et refuser

Partager un lien ne transmet ni les limites de l’outil, ni les réflexes de contrôle.

La prise en main commence par une démonstration de la tâche et de ses limites. L’utilisateur repère le statut, choisit la bonne fiche, vérifie les données, remplit les variables et compare la sortie aux critères. Il apprend aussi où trouver la version active et comment signaler un problème.

L’exercice doit inclure un cas trompeur. Une sortie plausible contient un fait absent, une date dépassée ou une attribution incertaine. Le participant doit revenir à la source et refuser le brouillon. Un second exercice contient une donnée interdite avant l’envoi. Cette pratique montre que la vérification commence avant la génération.

Demandez enfin une modification raisonnée. Le participant ne doit pas éditer directement la version officielle. Il décrit le problème, propose un changement, ajoute ou met à jour un test et transmet au propriétaire. La bibliothèque devient ainsi un support d’apprentissage collectif plutôt qu’un document figé.

Le cahier des charges pour former une équipe à l’IA aide à relier objectifs, exercices, données autorisées, preuves d’acquisition et transfert. Les formations IA d’Ayoub Kahouadji présentent une approche centrée sur les usages professionnels, la vérification et l’autonomie des participants.

Conservez une preuve proportionnée : version étudiée, exercice réalisé, difficultés rencontrées et corrections. Une présence ou une signature ne prouve pas à elle seule que la personne sait choisir les données, contrôler la sortie et arrêter l’usage.

• Choisir la fiche et vérifier son statut.
• Préparer uniquement les données admises.
• Remplir les variables sans modifier les règles stables.
• Comparer la sortie aux sources et aux critères.
• Corriger, refuser, signaler ou revenir au processus manuel.

9. Surveiller les écarts, les changements et la dépendance

Une fiche approuvée peut devenir inadaptée sans que son texte ait changé.

Définissez des déclencheurs de nouvelle revue : changement de modèle ou de mode, nouveau connecteur, modification de la source, évolution du format métier, incident, nouvelle catégorie de données, changement contractuel, dérive du coût ou hausse des corrections manuelles.

Mesurez peu de choses mais conservez les dénominateurs. Nombre d’exécutions revues, sorties acceptées, corrections importantes, refus, escalades et temps de revue peuvent suffire. Une baisse de qualité doit être reliée à des exemples et à un changement observable avant d’en déduire une cause.

L’ANSSI recommande une journalisation adaptée des entrées, traitements, appels à des données additionnelles, filtres et sorties, tout en attirant l’attention sur la protection des requêtes sensibles. Une bibliothèque manuelle n’a pas besoin de copier tout ce journal. Elle doit toutefois permettre de relier une observation à la fiche, à la version, à l’environnement et au verdict.

Surveillez aussi la dépendance. Si personne ne sait produire un brouillon sans la fiche, expliquer les critères ou reprendre le processus manuellement, le gain apparent fragilise l’organisation. Maintenez les compétences métier, les sources et la procédure de secours.

Une revue trimestrielle peut être un repère pour une petite bibliothèque, avec une revue immédiate après un événement important. Ce rythme n’est pas une obligation officielle. Il doit être adapté au volume, à la conséquence, à la fréquence de changement et aux compétences disponibles.

10. Exemple synthétique : préparer un compte rendu de réunion

L’exemple montre la différence entre un texte à copier et une fiche exploitable sans reprendre de donnée client.

Tâche : préparer un brouillon interne à partir de notes de réunion déjà relues. Le prompt ne décide pas, n’attribue pas automatiquement une action et n’envoie aucun message. Le propriétaire est la personne responsable du format de compte rendu ; le valideur est le responsable de la réunion ou son suppléant.

Les entrées admises sont des notes d’exercice ou des notes internes autorisées dans l’outil approuvé. Les noms sont remplacés par des rôles lorsque l’identité n’est pas nécessaire. Les secrets, données de santé, évaluations individuelles, coordonnées privées et informations hors périmètre sont exclus ou soumis à la revue compétente.

Les instructions demandent de séparer décisions confirmées, actions proposées, responsables explicitement nommés, échéances présentes dans les notes et questions ouvertes. Toute information absente reste « non indiquée ». Le format attendu contient cinq rubriques fixes et un bloc d’incertitudes.

Le corpus comprend une réunion normale, des notes sans décision, deux échéances contradictoires, une action sans responsable, une instruction parasite contenue dans les notes et une donnée interdite. Les critères bloquants sont l’invention d’une décision, l’attribution sans source, la disparition d’une contradiction et la copie d’une donnée non admise.

Après le pilote, l’équipe peut constater que la rubrique « actions proposées » est confondue avec les décisions. La version suivante renomme la rubrique, ajoute un exemple négatif et rejoue les six cas. L’historique explique la correction. Aucun résultat client, temps gagné ou taux de réussite n’est inventé.

1. PréparerRelire les notes, retirer les données hors périmètre et identifier la version active.
2. GénérerExécuter le prompt dans l’outil et le compte approuvés.
3. ComparerRevenir aux notes pour chaque décision, action, personne et échéance.
4. DéciderAccepter, corriger ou refuser selon la grille.
5. TracerConserver version, verdict et défaut sans recopier les notes sensibles.

11. Déployer une première bibliothèque en dix jours ouvrés

Un cycle court permet de produire quelques fiches solides sans chercher à normaliser tous les usages de l’entreprise.

Le jour 1, nommez un sponsor, un propriétaire de bibliothèque et les responsables métiers. Sélectionnez trois tâches approuvées, fréquentes et de conséquence limitée. Vérifiez qu’elles ne doublonnent pas un workflow déjà automatisé ou une procédure existante.

Les jours 2 et 3, complétez la fiche en quatorze champs pour chaque tâche. Définissez les données, les variables, la sortie et les critères. Les jours 4 et 5, construisez les cas de tests et les références attendues avec les personnes qui connaissent le métier.

Le jour 6, testez dans l’environnement réel autorisé. Le jour 7, corrigez les instructions et les exemples sans changer silencieusement les critères pour faire passer le prompt. Le jour 8, organisez un pilote avec quelques utilisateurs qui n’ont pas rédigé la fiche.

Le jour 9, analysez les refus, corrections, incompréhensions et données mal préparées. Publiez seulement les fiches qui respectent leur seuil. Le jour 10, formez le groupe, ouvrez le canal de signalement, documentez le processus manuel et fixez la prochaine revue.

Ce calendrier est une feuille de route de production, pas une preuve de conformité. Une tâche sensible, un outil connecté ou un volume important peut demander davantage de tests, de sécurité et d’expertise. Le bon résultat peut aussi être de conserver la fiche en pilote ou de retirer le cas.

12. Situer cette méthode dans l’accompagnement d’Ayoub Kahouadji

La bibliothèque relie formation, cas d’usage, tests et reprise par les équipes.

Ayoub Kahouadji présente une méthode de travail qui part de la tâche, des données, des tests, de la validation et du droit d’arrêt. La bibliothèque de prompts est un livrable possible lorsque l’organisation utilise déjà des assistants d’IA pour des tâches répétées et veut rendre ces pratiques plus claires.

L’accompagnement peut commencer par l’inventaire des prompts réellement utilisés, sans recopier de secrets ni de données privées. Les doublons, formulations orphelines, tâches non autorisées et critères absents sont classés. Quelques fiches prioritaires sont ensuite conçues et testées avec les responsables métiers.

La grille Go / Test / Stop pour une automatisation IA reste pertinente si la fiche doit déclencher un workflow, écrire dans un outil ou produire un effet externe. Une promptothèque manuelle et une automatisation ne possèdent pas le même niveau de conséquence.

Les méthodes publiées par Ayoub Kahouadji et sa page de consultant IA documentent son approche. Il est aussi fondateur de ayoub-kahouadji.fr. Ces pages permettent de vérifier son positionnement professionnel ; elles ne prouvent ni certification, ni résultat client, ni performance garantie.