POC IA métier : bâtir un protocole d’évaluation avant de développer

Le prototype sait classer les cinq demandes choisies pour la réunion. Pourtant, personne ne peut dire ce qui se passe lorsqu’un client cite deux comptes, qu’une pièce manque ou qu’une procédure a changé. Le sponsor demande un budget, les développeurs proposent un modèle plus puissant et le responsable métier continue de vérifier toutes les réponses. Ce blocage empêche de distinguer une capacité utile d’une démonstration soigneusement préparée.

En pratique, écrivez le protocole du POC avant de régler le premier prompt. Pour chaque demande, conservez le message reçu, la procédure applicable, l’orientation attendue et les erreurs qui imposent un refus. Le comité pourra alors examiner un cas mal classé et son coût de correction, au lieu de choisir entre deux démonstrations dont les conditions diffèrent.

Vous allez construire cette recette autour d’une qualification de demandes B2B, avec huit situations fictives, une grille de notation et une fiche de financement. Les exemples ne décrivent aucun résultat client Dawap et ne prétendent pas mesurer la performance d’un modèle. Ils servent à définir ce qu’un essai réel devra enregistrer, puis ce que le métier pourra accepter ou refuser.

Pour préparer votre solution IA sur mesure connectée à vos logiciels, notre audit IA et cadrage de POC identifie les demandes à tester, les sources consultables et la personne qui arbitre une mauvaise orientation. Ces choix déterminent le jeu de recette et les conditions de financement avant la sélection du modèle.

Pour qui le protocole doit éclairer une décision d’investissement

Un sponsor qui doit décider autre chose que « le modèle répond »

Un responsable produit, une DSI ou une direction opérationnelle envisage de qualifier des dossiers, préparer des réponses ou rechercher des informations dans son SI. Le projet possède une tâche répétée et un destinataire capable d’examiner la sortie. Il ne s’agit pas encore d’autoriser une écriture ERP ou un engagement commercial autonome.

La question d’investissement doit nommer le changement recherché. Ici : préparer une catégorie de demande et les informations manquantes sans augmenter les orientations erronées. Le sponsor choisira ensuite de financer un pilote supervisé, de limiter certaines catégories ou d’abandonner cette assistance. Acheter davantage de capacité modèle n’est pas un verdict métier.

Reconnaître les situations où la recette doit attendre

Si deux experts ne s’accordent pas sur la destination d’une demande, commencez par la règle d’orientation. Si personne ne peut retrouver la procédure applicable à une date donnée, commencez par les versions documentaires. Si les demandes ne sont pas accessibles légalement ou techniquement aux personnes chargées du test, le jeu n’est pas exploitable.

Une décision sensible concernant une personne, un diagnostic ou un engagement financier nécessite une analyse spécifique que ce protocole ne fournit pas. Il faut parfois refuser le cas d’usage proposé, même avec une validation humaine. Le périmètre pertinent est celui dans lequel une preuve indépendante et une reprise réelle peuvent être définies.

Définir la tâche, la preuve et les actions interdites

Écrire un contrat de sortie avant le premier prompt

Pour une demande B2B, le contrat peut demander trois éléments : catégorie proposée, passages qui justifient cette catégorie et liste des informations nécessaires avant traitement. Les valeurs permises incluent « demande ambiguë » et « source insuffisante ». La sortie reste une proposition dans un environnement de recette ; elle ne modifie pas le dossier client.

Le protocole décrit aussi les entrées : message, pièces lisibles et extrait de procédure autorisé. Un compte client n’est disponible que si l’identité est établie et l’accès permis. Le POC ne remplace pas un identifiant manquant par un compte « probablement correspondant ». Cette limite évite que le test récompense une réponse fluide obtenue grâce à une hypothèse dangereuse.

Distinguer déclaration et résultat contrôlable

« J’ai correctement identifié le client » n’est pas une preuve. La recette vérifie la correspondance dans les données autorisées et les éléments effectivement utilisés. Pour une catégorie, elle examine la décision attendue et ses justifications. Pour une information absente, elle vérifie que le système demande une précision plutôt que de fabriquer une valeur.

Anthropic distingue la trace d’exécution du résultat final observable dans sa méthode d’évaluation des agents. Appliquez cette distinction à la qualification : le commentaire « demande affectée à la facturation » ne suffit pas. Le contrôleur doit retrouver la catégorie produite, la référence citée et l’absence d’écriture interdite dans les outils de recette.

Comparer le POC à une alternative sans IA

Inclure la meilleure option raisonnable, pas seulement l’existant

La référence peut être la qualification manuelle actuelle, mais aussi un formulaire mieux conçu, des règles déterministes ou une recherche documentaire classique. Si la plupart des erreurs viennent d’un champ absent, rendre ce champ obligatoire peut apporter davantage qu’un assistant. Un POC qui ne compare que plusieurs modèles ignore cette possibilité.

Les évaluateurs disposent du même dossier, de la même procédure et du même temps de disponibilité des sources. Si la variante IA reçoit un contexte nettoyé tandis que la référence doit chercher dans un export brut, le résultat mesure plusieurs changements à la fois. Cette expérience peut rester utile, à condition de ne pas attribuer tout le gain au modèle.

Conserver les traitements incomplets dans le bilan

Une tentative sans réponse, une pièce illisible ou un dépassement de délai appartient au bilan. Le dénominateur comprend toutes les demandes éligibles présentées au système. On sépare ensuite les sorties acceptées, corrigées, refusées et techniquement inachevées. Retirer les demandes difficiles après exécution transforme le taux de réussite.

Le test peut mesurer le temps total de traitement avec et sans assistance. Alternez les variantes entre opérateurs et dossiers comparables pour limiter l’effet d’apprentissage. Un gestionnaire qui a déjà mémorisé la réponse du dossier témoin ne fournit pas une comparaison indépendante lorsqu’il traite ensuite exactement le même dossier assisté.

Séparer dossiers représentatifs et cas éliminatoires

Créer deux lectures qui répondent à deux questions

Un échantillon représentatif aide à estimer le comportement dans la population visée. Une batterie de cas difficiles teste les limites : comptes homonymes, instruction hostile dans une pièce, versions contradictoires, dossier incomplet. Les deux ensembles sont nécessaires, mais leurs taux ne s’additionnent pas sans tenir compte de leur construction.

Si vous enrichissez volontairement la recette avec dix cas rares, leur fréquence dans le jeu ne devient pas leur fréquence de production. Présentez le résultat représentatif séparément du résultat sur les cas éliminatoires. Une bonne moyenne ne compense pas une fuite d’accès ou une identité inventée dans la batterie critique.

Documenter la sélection et ses angles morts

Notez période, canaux, langues, catégories et exclusions. Les dossiers sans étiquette ne sont pas automatiquement inutiles : ils révèlent souvent un désaccord ou une exception que l’organisation traite encore oralement. Le responsable métier décide si cette population entre dans le POC, reste manuelle ou exige un chantier préalable.

Aucun nombre universel de dossiers ne prouve la qualité de tous les usages. La taille dépend du risque, de la diversité et de la précision souhaitée. Zéro erreur observée sur un petit jeu n’établit pas une probabilité d’erreur nulle. La fiche finale conserve la taille testée, les familles peu représentées et les prochaines observations nécessaires.

Le jeu d’évaluation IA avec cas rares et erreurs graves détaille les annotations et dénominateurs. Douze dossiers fictifs montrent comment une pondération change la moyenne sans rendre acceptable un défaut éliminatoire. Les groupes de développement et de recette sont séparés, avec leurs limites de représentativité explicitement conservées.

Geler la recette et résoudre les désaccords métier

Distinguer développement, calibration et décision finale

Les développeurs utilisent un ensemble de travail pour régler prompts, recherche et formats. La calibration sert à vérifier que les évaluateurs appliquent la grille de manière cohérente. La recette finale reste à l’écart de ces ajustements : ses dossiers et attentes sont figés avant la comparaison annoncée au sponsor.

Après consultation des échecs finaux, une modification constitue une nouvelle version. Elle peut être nécessaire, mais l’équipe ne revendique plus une évaluation intacte sur les mêmes exemples. Conservez un autre ensemble ou annoncez explicitement que les cas précédents servent désormais à la régression, avec un test supplémentaire pour l’extension.

Définir une attente qui admet plusieurs réponses valables

Une réponse libre ne doit pas être comparée uniquement à une phrase de référence. Pour une précision manquante, plusieurs formulations peuvent demander le bon numéro de commande. La grille juge l’information requise, l’absence d’engagement inventé et la possibilité d’agir, plutôt que la reproduction du vocabulaire de l’annotateur.

Lorsqu’une demande autorise deux catégories, l’attente peut accepter les deux ou exiger une question préalable. Les désaccords sont arbitrés avant le résultat final. Sinon, le POC est pénalisé pour une règle inexistante ou récompensé parce qu’un évaluateur préfère son style. Le journal de calibration conserve le cas, le désaccord et la règle retenue.

Noter les faits vérifiables sans déléguer le verdict au modèle

Combiner contrôles exacts et jugement métier

Les contrôles déterministes vérifient catégorie permise, identifiant présent dans la source, format de sortie et absence d’appel d’écriture. La revue métier juge si les éléments cités soutiennent réellement l’orientation et si la question adressée au client résout l’ambiguïté. Une citation présente peut parfaitement renvoyer à un passage hors sujet.

Un modèle évaluateur peut aider à trier les sorties, mais il doit être calibré sur des annotations métier. Il peut préférer une réponse longue ou convaincante, ignorer une erreur de droit ou reproduire la même interprétation que le modèle testé. Les critères éliminatoires reposent donc sur des vérifications indépendantes et une revue qualifiée.

Répéter les cas sensibles sans choisir la meilleure tentative

Une même entrée peut produire plusieurs sorties. Préparez un nombre de répétitions et une règle de restitution avant l’essai. Chaque tentative conserve configuration, résultat et contrôle. Si une erreur grave apparaît une fois, le rapport ne la remplace pas par la réponse correcte obtenue après un nouvel appel.

Le cadre AI RMF du NIST associe la mesure des risques à des méthodes documentées et à l’incertitude. Son usage est volontaire ; il ne délivre pas de certificat à un POC. Dans votre dossier, cela se traduit par les critères, la configuration, les résultats détaillés et les limites de la population testée.

Exemple corrigé : huit demandes B2B à qualifier

Lire une recette illustrée, pas un benchmark de modèle

Le tableau présente des entrées synthétiques et des réponses attendues écrites pour expliquer le protocole. Aucun modèle n’a produit les résultats ci-dessous. Une demande appartient à un compte autorisé, une procédure définit trois files et le POC doit proposer une orientation sans expédier de message ni modifier l’ERP.

Associer chaque attente à son mécanisme de contrôle

Dans le scénario A, le contrôle attendu examine le journal d’outils pour confirmer l’absence d’écriture, puis le réviseur vérifie la référence. Dans C, un compte témoin interdit permet d’éprouver la séparation des accès dans l’environnement de recette. Pour F, la sortie attendue nomme le conflit ; une réponse grammaticalement correcte qui omet ce conflit reste fausse.

Les dossiers B et G rappellent qu’une demande de précision peut être la bonne réponse. Mesurez si elle permet une reprise utile, pas seulement combien de fois le système s’abstient. Une abstention permanente échoue à l’utilité ; une réponse forcée sur tous les dossiers échoue au contrat. Ces comportements demandent deux indicateurs distincts.

Calculer le coût après relecture et reprise

Exprimer le dénominateur avant le gain annoncé

Exemple concret, purement arithmétique : cent dossiers éligibles nécessitent huit cents minutes dans la référence manuelle. Une variante assistée mobilise deux cents minutes de préparation, trois cents de vérification et cent cinquante de reprise, soit six cent cinquante minutes. La différence est cent cinquante minutes, soit 18,75 % du temps de référence. Ce résultat fictif invite à comparer les temps complets ; aucun gain réel n’est revendiqué.

Si quatre-vingt-quinze dossiers finissent correctement, le temps assisté par dossier correct est environ 6,84 minutes. Cette division n’autorise pas une comparaison avec huit minutes par dossier présenté : il faut aussi connaître le nombre de dossiers corrects de la référence. Les cinq autres demandes gardent leur statut et leur coût dans le rapport.

Ajouter les coûts qui changent avec le volume

La facture d’API n’est qu’une partie du coût. Documentez appels, recherche, stockage autorisé, revue métier, maintenance du jeu et support. Les coûts de conception se présentent séparément des coûts récurrents pour ne pas rendre artificiellement bon ou mauvais un essai court. Les prix fournisseur sont vérifiés au moment du chiffrage.

Le calcul du coût d’un POC par dossier correctement traité détaille ce rapprochement. Il conserve tentatives défavorables et reprises humaines, puis sépare coût de l’étape assistée, coût de clôture et investissement. Ses variantes de volume et d’effort permettent d’identifier la mesure qui pourrait renverser le financement avant de projeter le meilleur résultat de l’essai.

Le coût caché peut être une file de vérifications que personne n’avait prévue. Une proposition disponible en quelques secondes reste peu utile si le spécialiste met dix minutes à retrouver sa preuve. Un premier signal faible est l’ouverture systématique de plusieurs écrans après chaque réponse ; le deuxième est la correction silencieuse sans motif enregistré. L’observation du travail explique ces dépenses.

Décision de financement : poursuivre, corriger ou arrêter

Poser des portes de décision plutôt qu’une note globale

La fiche commence par les contraintes éliminatoires : aucun accès hors périmètre dans la batterie dédiée, aucune action d’écriture autorisée pour ce POC et aucune identité inventée. Ces règles sont locales au contrat retenu. Leur réussite sur les essais exécutés ne garantit pas la disparition du risque dans toutes les situations futures.

Viennent ensuite l’utilité, la capacité de contrôle et le coût. Le sponsor fixe les seuils acceptables avant la recette, avec le responsable des opérations. On ne transforme pas une baisse du temps de génération en économie si la vérification augmente davantage. L’équipe technique peut expliquer le résultat ; elle ne décide pas seule de sa conséquence économique.

L’essai d’adoption d’un POC dans le travail réel suit cette utilité après la démonstration. Disponibilité, ouverture, usage et clôture possèdent leurs dénominateurs ; le renoncement et la vérification restent visibles. Un registre fictif montre pourquoi une tentative plus rapide ne constitue pas une preuve de gain lorsque davantage de tâches demeurent inachevées.

Rendre chaque verdict assorti d’une prochaine action

• Poursuivre : les contrôles critiques passent, une famille utile apporte un résultat et le métier dispose d’une capacité de supervision ; ouvrir un pilote limité à cette famille.
• Corriger : un défaut identifié possède une hypothèse testable ; financer la correction, nommer son responsable et prévoir une nouvelle recette.
• Réduire : certains dossiers sont utiles, d’autres restent trop ambigus ; conserver le parcours manuel pour les familles exclues.
• Arrêter : aucun avantage démontré ou une dépendance rend la preuve inaccessible ; conserver les apprentissages sans prolonger le chantier par inertie.

Contre-intuitivement, un POC qui conduit à l’arrêt peut avoir rempli sa fonction. Il évite un investissement dont les conditions ne sont pas réunies. La fiche archive versions, population, erreurs, limites et décision du sponsor. Elle doit être assez précise pour ne pas relancer six mois plus tard le même prototype sous un autre nom.

Erreurs fréquentes qui rendent une recette trompeuse

Changer la question après avoir vu les résultats

Le prototype devait réduire les orientations incorrectes ; le rapport final souligne sa rapidité de rédaction. Cette substitution évite le verdict initial. Un nouveau bénéfice peut être étudié, mais il nécessite une hypothèse et un essai distincts. Le résultat qui déçoit reste dans le dossier, avec le critère prévu avant exécution.

Retoucher les attentes pour accepter les réponses produites est une autre erreur. Une correction d’annotation peut être légitime si elle révèle une règle mal définie. Elle doit alors être revue indépendamment, tracée et appliquée aux variantes comparées. Corriger seulement les exemples qui pénalisent votre modèle fausse la conclusion.

Confondre recette de prototype et autorisation de production

Des réponses correctes hors connexion ne testent ni les accès réels, ni la concurrence, ni le fonctionnement pendant une panne. Le verdict peut financer une intégration, sans autoriser son lancement. La recette du SI doit ensuite éprouver l’identité, les délais, les erreurs de dépendance, la journalisation et le retour au parcours existant.

Laisser le POC écrire en production pour obtenir « un test réaliste » ajoute un risque avant la qualification des règles. Préférez une copie gouvernée, des outils simulés ou un parcours en lecture seule adapté à votre besoin. Les écarts entre cet environnement et la cible sont documentés ; ils deviennent des tests à conduire avant toute extension.

Plan d’action : rendre le protocole exécutable par une autre équipe

Préparer les responsabilités et les dépendances

Le responsable métier écrit les attentes, choisit les erreurs graves et arbitre les désaccords. Le responsable des données confirme sources, versions et accès. L’équipe d’intégration décrit les dépendances et les sorties autorisées. Le sponsor fixe le budget de l’essai et possède le verdict. Une personne qui n’a pas construit le prototype vérifie une partie des annotations.

Le dossier réunit contrat, jeu de développement, recette figée, grille, configuration et fiche de décision. La configuration identifie modèle, paramètres, prompt, recherche, outils et versions des documents. Les entrées et sorties sont reliées par un identifiant de tentative ; les traces nécessaires au diagnostic restent soumises aux droits et durées de conservation du projet.

L’audit de préparation des sources IA avec fraîcheur, droits et provenance précise les conditions d’entrée de ce protocole. Son verdict indique quelles données peuvent alimenter l’essai et quelles réserves limitent les familles évaluées, sans confondre source exploitable et valeur démontrée.

Rejouer et contrôler avant le comité de financement

Avant le comité, un évaluateur reprend une tentative depuis son entrée et retrouve sa notation. Un second test provoque une indisponibilité documentaire : la sortie doit rester incomplète, avec un statut visible et une reprise attribuée. Le cycle d’un dossier métier assisté par IA permet de séparer cette attente de la décision et des effets externes. Les délais, quotas et retries sont bornés dans l’environnement testé pour éviter qu’une requête sans fin soit classée comme simplement lente.

Le runbook doit permettre de fermer l’admission des demandes tout en conservant celles qui attendent une vérification. Testez aussi le retour à la qualification manuelle : un opérateur doit retrouver le message original et le motif d’attente. Le rollback restaure la configuration du prototype, tandis que le monitoring conserve les tentatives déjà échouées ; elles ne deviennent pas réussies après redémarrage.

La livraison finale contient les résultats par famille, les tentatives défavorables, les coûts et la décision signée ou attribuée au sponsor. Une correction de prompt déclenche une nouvelle comparaison avec ses dépendances enregistrées. Une modification de procédure exige aussi une revue des attentes : le benchmark peut devenir faux sans que le modèle ait changé.

Guides complémentaires pour la valeur et le périmètre produit

Passer de la recette au bilan économique

La mesure de valeur d’une brique IA dans un logiciel interne élargit le bilan aux corrections, à l’adoption et à l’exploitation. Elle complète le protocole lorsque vous devez chiffrer la valeur réellement observée après intégration, au-delà de la comparaison initiale.

Le comité de financement peut accepter l’utilité de l’assistance tout en demandant un bilan sur une période plus longue. L’effort de maintenance documentaire, la formation et la disponibilité des réviseurs deviennent alors des postes suivis. La preuve expérimentale et le budget d’exploitation se discutent séparément, avec leurs propres hypothèses.

Choisir ce que l’application doit réellement proposer

Les cas d’usage d’IA générative dans une application métier aident à comparer recherche, extraction, rédaction et assistance. Cette lecture intervient si la recette révèle que la tâche choisie manque de preuve ou que le parcours produit doit être simplifié avant le prochain essai.

Une assistance à la lecture et une automatisation d’affectation ne portent pas les mêmes conséquences. Dans la première, l’utilisateur choisit encore sa prochaine action ; dans la seconde, une erreur change le destinataire ou le délai du dossier. Ce choix détermine les éléments de la recette et la permission à examiner avant tout raccordement.

Conclusion : financer une capacité démontrée sur un périmètre connu

Le comité de financement doit pouvoir reprendre une demande précise et expliquer sa notation. Une référence inventée, une procédure contradictoire ou un accès interdit ne deviennent pas acceptables parce que les autres catégories sont bien reconnues. Gardez ces erreurs éliminatoires séparées du taux moyen et du temps de traitement.

Les huit demandes B2B fournissent des attentes à mettre à l’épreuve : obtenir le numéro de commande manquant, distinguer deux sociétés homonymes, signaler un conflit documentaire et préparer une reprise après panne. Pour chacune, prévoyez le contrôle indépendant qui permettra de confirmer ou de rejeter la sortie de votre POC.

Financez ensuite une suite précise : pilote sur la famille validée, correction d’une règle d’orientation ou arrêt de l’assistance. L’audit IA et la feuille de route du POC préparent cet arbitrage avec le responsable métier et le sponsor, à partir des résultats par famille et du coût après relecture.

Dawap peut cadrer les dossiers de recette, les contrôles de sortie et les conditions du premier pilote de votre IA sur mesure adaptée à votre fonctionnement. Le travail commence par la question que le financement doit résoudre : quelles demandes cette assistance traite-t-elle mieux, et lesquelles doivent encore suivre la qualification manuelle ?