Une démonstration réussie ne signifie pas qu’une intelligence artificielle est prête à être utilisée quotidiennement par vos collaborateurs ou vos clients. Pendant un prototype, les conditions sont généralement favorables : quelques documents bien choisis sont transmis à l’IA, les questions sont préparées à l’avance et les personnes qui connaissent déjà le projet réalisent les premiers essais.
Lorsque la solution arrive dans les conditions réelles de l’entreprise, la situation change rapidement. Les utilisateurs posent des questions imprévues, fournissent des informations incomplètes, utilisent un vocabulaire différent de celui prévu par les concepteurs ou demandent à l’IA de traiter des situations qu’elle n’a jamais rencontrées.
Une IA capable de produire une excellente démonstration n’est donc pas nécessairement capable de réaliser de manière fiable une tâche métier en production.
Avant de déployer un chatbot, un assistant documentaire, un système RAG, un agent IA ou une automatisation basée sur un modèle de langage, il devient essentiel de construire une véritable recette métier IA. L’objectif consiste à confronter la solution à des situations représentatives du travail réel afin de déterminer précisément ce qu’elle sait faire, les erreurs qu’elle peut commettre et les situations dans lesquelles une intervention humaine reste nécessaire.
Qu’est-ce qu’une recette métier IA ?
Dans un projet informatique traditionnel, la phase de recette permet de vérifier qu’une application correspond bien aux besoins définis avant sa mise en production.
Le principe peut être appliqué à l’intelligence artificielle, mais avec une difficulté supplémentaire : une IA générative ne produit pas nécessairement exactement la même réponse à chaque exécution.
Il ne suffit donc plus de vérifier qu’un bouton fonctionne ou qu’un calcul retourne une valeur exacte. Il faut déterminer si la réponse générée est suffisamment correcte, complète et fiable pour le processus dans lequel elle sera utilisée.
Une recette métier IA regroupe ainsi plusieurs scénarios permettant de tester la solution dans différentes conditions. Elle doit naturellement contenir des situations courantes, mais aussi des cas ambigus, des informations manquantes, des demandes hors périmètre, des erreurs dans les documents ou encore des situations nécessitant une validation humaine.
L’objectif n’est pas de démontrer que l’intelligence artificielle est parfaite. Il s’agit plutôt de déterminer dans quelles conditions l’entreprise peut lui faire confiance et quelles limites doivent être conservées autour de son utilisation.
Un benchmark IA ne remplace pas vos propres tests métier
Lorsqu’un nouveau modèle est lancé, ses performances sont généralement présentées à travers différents benchmarks permettant d’évaluer ses capacités de raisonnement, de programmation, de compréhension documentaire ou encore d’utilisation d’outils.
Ces informations permettent de comparer les capacités générales de plusieurs modèles, mais elles ne répondent pas à la question la plus importante pour une entreprise : le système fonctionne-t-il correctement avec mes données, mes règles et mes processus ?
Un modèle peut être excellent en raisonnement général tout en interprétant mal le vocabulaire spécifique de votre secteur. De la même manière, un système RAG peut utiliser un modèle particulièrement performant et fournir malgré tout de mauvaises réponses si les documents récupérés ne sont pas les bons.
Un agent IA peut également réussir des tests génériques d’utilisation d’outils et rencontrer des difficultés lorsqu’il doit travailler avec votre CRM ou respecter précisément vos règles commerciales.
Les benchmarks répondent principalement à une question :
« De quoi ce modèle est-il capable dans un environnement de test ? »
La recette métier doit répondre à une autre :
« Cette solution est-elle suffisamment fiable pour réaliser cette tâche dans notre entreprise ? »
1. Définir précisément ce que l’IA doit faire
La première étape consiste à décrire la mission de l’intelligence artificielle de manière suffisamment précise pour pouvoir ensuite vérifier son comportement.
Dire qu’un assistant doit « répondre aux clients » reste beaucoup trop vague. Une définition plus exploitable pourrait préciser que l’assistant doit répondre aux questions concernant les horaires, les conditions de livraison, les retours et les caractéristiques des produits en utilisant uniquement la documentation officielle de l’entreprise.
Elle peut également préciser que les demandes relatives à un litige, une remise exceptionnelle ou une situation non couverte doivent être transférées à un collaborateur.
Cette distinction est essentielle, car une IA ne doit pas uniquement savoir quand répondre. Elle doit également savoir quand elle ne doit pas répondre.
Plus l’intelligence artificielle peut agir sur le système d’information, plus ce périmètre doit être rigoureux. Cette question devient particulièrement importante avec les connecteurs ChatGPT et l’automatisation des outils métier, car l’IA peut désormais interagir avec un CRM, une messagerie, des documents ou d’autres applications au lieu de simplement produire du texte.
2. Construire les tests à partir de vrais cas métier
Les meilleurs scénarios de recette ne sont généralement pas imaginés uniquement par le développeur ou le fournisseur de la solution. Ils doivent être construits avec les personnes qui réalisent réellement le travail concerné.
Si l’objectif consiste à automatiser une partie du traitement des prospects, les commerciaux disposent probablement de dizaines d’exemples intéressants. Pour un assistant documentaire, les collaborateurs connaissent les questions difficiles qui reviennent régulièrement. Dans le service client, l’historique des demandes permet de retrouver des situations fréquentes, mais également des dossiers beaucoup plus complexes.
La recette doit donc partir autant que possible de cas réels et représentatifs.
Une première version peut contenir quelques dizaines de scénarios regroupant des demandes fréquentes, des cas moins courants mais importants, des situations ambiguës et plusieurs exemples pour lesquels l’IA doit volontairement demander une intervention humaine.
Une TPE ou une PME n’a pas besoin de constituer immédiatement une base de plusieurs milliers de tests. Quelques dizaines de cas soigneusement sélectionnés permettent déjà de révéler de nombreux problèmes qu’une démonstration classique ne ferait jamais apparaître.
3. Définir le résultat attendu avant d’interroger l’IA
Chaque scénario doit être associé à un résultat attendu défini avant l’exécution du test.
Lorsque l’IA effectue une extraction de données, cette opération est relativement simple. Si elle doit récupérer la date, le montant TTC et le nom du fournisseur d’une facture, les valeurs correctes sont connues à l’avance.
L’évaluation devient plus subtile lorsque le résultat attendu est une réponse rédigée.
Il est alors possible de définir plusieurs critères, par exemple :
| Critère | Question à poser |
|---|---|
| Exactitude | Les informations communiquées sont-elles correctes ? |
| Complétude | Les informations indispensables sont-elles présentes ? |
| Sources | La réponse repose-t-elle sur les données autorisées ? |
| Ton | La formulation correspond-elle à l’entreprise ? |
| Décision | L’IA répond-elle ou transfère-t-elle correctement le dossier ? |
Cette étape permet d’éviter un piège fréquent : accepter une réponse simplement parce qu’elle paraît convaincante.
Les modèles d’intelligence artificielle savent produire des textes très crédibles, y compris lorsque certaines informations sont incorrectes. Une réponse agréable à lire ne doit donc jamais remplacer une véritable validation métier.
4. Tester volontairement les situations difficiles
Une recette contenant uniquement des situations faciles donnera presque toujours une image trop favorable du système.
La réalité opérationnelle est beaucoup moins propre. Les documents peuvent être incomplets, les utilisateurs font des fautes, certaines informations sont contradictoires et les demandes dépassent régulièrement le périmètre prévu.
Il faut donc volontairement introduire des situations difficiles dans la recette.
Que fait l’IA lorsque l’information n’existe pas ?
Un assistant documentaire doit être capable de reconnaître que la réponse ne se trouve pas dans les documents disponibles plutôt que d’essayer de compléter les informations manquantes.
Que fait-elle lorsque deux sources se contredisent ?
L’entreprise doit définir quelle source possède la priorité ou demander à l’IA de transférer la décision à un collaborateur lorsqu’aucune règle claire ne permet de choisir.
Comment réagit-elle face à une demande ambiguë ?
Dans certaines situations, demander une précision à l’utilisateur constitue une bien meilleure réponse que de sélectionner arbitrairement une interprétation.
Que se passe-t-il lorsqu’une demande sort de son périmètre ?
Un assistant spécialisé dans le support client ne devrait pas improviser une réponse juridique, comptable ou médicale simplement parce qu’un utilisateur lui pose la question.
Que fait-elle lorsqu’un utilisateur tente de contourner ses règles ?
Cette question devient particulièrement importante pour les agents capables de lire des données internes ou d’agir sur différentes applications.
Plus l’IA possède de droits, plus les conséquences d’une mauvaise décision peuvent être importantes. Il faut donc tester non seulement ce qu’elle sait faire, mais également ce qu’elle refuse correctement de faire.
5. Distinguer les erreurs mineures des erreurs critiques
Toutes les erreurs produites par une intelligence artificielle n’ont pas la même importance.
Une réponse légèrement trop longue ou une formulation maladroite peut parfaitement rester exploitable, tandis qu’un mauvais montant ajouté automatiquement dans un devis peut entraîner des conséquences beaucoup plus importantes.
La recette peut donc distinguer plusieurs catégories.
Une erreur mineure correspond à un résultat imparfait qui reste exploitable sans risque significatif.
Une erreur importante nécessite une correction avant que le résultat puisse être utilisé.
Une erreur critique correspond à un comportement que le système ne devrait jamais produire, par exemple communiquer une donnée confidentielle, inventer un tarif, créer une commande incorrecte ou réaliser automatiquement une action nécessitant normalement une validation humaine.
Cette classification permet d’éviter de regarder uniquement le taux de réussite global.
Une IA peut afficher 95 % de réponses considérées comme correctes et rester impossible à déployer si les 5 % d’erreurs restantes concernent précisément les situations les plus sensibles.
Le bon indicateur n’est donc pas seulement combien de tests ont réussi, mais également quels tests ont échoué et quelles seraient les conséquences de ces échecs en production.
6. Construire une matrice de recette métier
Prenons l’exemple d’une intelligence artificielle chargée de qualifier automatiquement les demandes commerciales reçues par une PME.
Une première matrice pourrait ressembler à celle-ci :
| Scénario | Résultat attendu | Criticité | Résultat |
|---|---|---|---|
| Demande de devis complète | Extraire les coordonnées et qualifier le prospect | Haute | ✅ |
| Numéro de téléphone absent | Demander l’information manquante | Moyenne | ✅ |
| Demande hors zone géographique | Détecter l’inéligibilité | Haute | ✅ |
| Message commercial indésirable | Ne pas créer d’opportunité | Moyenne | ❌ |
| Client déjà existant | Rattacher la demande au bon compte | Haute | ✅ |
| Informations contradictoires | Demander une validation humaine | Haute | ❌ |
| Tentative de contournement des règles | Refuser la demande | Critique | ✅ |
| Demande d’accès à une donnée confidentielle | Refuser et signaler le cas | Critique | ✅ |
Une telle matrice rend immédiatement la discussion plus objective.
Au lieu de demander aux utilisateurs s’ils trouvent que « l’IA fonctionne bien », l’entreprise peut constater que 47 scénarios sur 50 sont correctement traités, mais que deux échecs concernent des règles métier importantes et doivent être corrigés avant le lancement.
7. Définir les critères de Go / No Go avant les résultats
La décision de mise en production doit idéalement reposer sur des critères déterminés avant le début de la recette.
Ces seuils dépendent naturellement du métier et du niveau de risque associé à l’automatisation. Une IA utilisée pour trouver des idées de publication peut tolérer davantage d’imperfections qu’un système manipulant des informations financières ou modifiant automatiquement des données clients.
À titre d’exemple, une entreprise pourrait décider que la mise en production nécessite l’absence totale d’échec sur les scénarios critiques, un taux de réussite supérieur à 95 % sur les cas prioritaires et la détection correcte de toutes les situations nécessitant une intervention humaine.
Ces chiffres ne constituent pas des seuils universels. Ils doivent être adaptés à chaque cas d’usage.
L’élément essentiel est de fixer les règles avant de connaître les résultats, afin d’éviter d’abaisser progressivement les exigences simplement parce que le projet est déjà très avancé.
La validation humaine doit elle aussi être testée
Il est fréquent de voir apparaître la mention « validation humaine » dans les projets d’intelligence artificielle, mais cette étape est rarement testée aussi sérieusement que le modèle lui-même.
Lorsqu’une IA transmet un dossier à un collaborateur, plusieurs questions doivent pourtant être vérifiées.
La personne comprend-elle pourquoi le système demande une validation ? Dispose-t-elle des informations nécessaires pour prendre une décision ? Peut-elle corriger facilement le résultat proposé ? Sait-elle dans quels cas elle doit remettre en question la recommandation de l’IA ?
Une validation humaine mal conçue peut devenir une simple formalité dans laquelle le collaborateur clique systématiquement sur « Valider » parce qu’il fait confiance au système ou parce qu’il ne dispose pas du temps nécessaire pour contrôler réellement le résultat.
La recette métier doit donc évaluer l’ensemble du processus, et pas uniquement le modèle.
Tester également les performances et les coûts
Une IA peut être très précise tout en restant difficilement exploitable parce qu’elle répond trop lentement ou coûte trop cher lorsque le nombre de traitements augmente.
La recette peut donc également mesurer le temps moyen nécessaire pour réaliser une tâche, les appels effectués au modèle, la consommation de tokens, le nombre de tentatives nécessaires et le temps consacré au contrôle humain.
Cette approche permet de déterminer si le système est non seulement fiable, mais également économiquement viable.
L’intérêt est de passer d’une impression générale à des indicateurs comparables : coût par dossier correctement traité, temps gagné par collaborateur ou pourcentage de tâches réellement automatisées.
Pour les entreprises qui commencent seulement à structurer leurs projets, cette logique rejoint celle présentée dans notre dossier sur le plan Osez l’IA pour les TPE et PME, qui met l’accent sur l’identification des usages pertinents et le déploiement progressif de solutions adaptées à l’activité.
Utiliser la même recette pour comparer plusieurs modèles
Une fois construite, la recette métier devient également un excellent outil de comparaison entre différentes solutions.
L’entreprise peut exécuter exactement les mêmes scénarios avec GPT, Claude, Gemini, Mistral ou un modèle open source puis mesurer le taux de réussite, les erreurs critiques, le temps de traitement et le coût de chaque solution.
Cette approche est beaucoup plus pertinente que de chercher quel est « le meilleur modèle » dans l’absolu.
Un modèle moins performant sur certains benchmarks publics peut parfaitement être le meilleur choix pour votre processus s’il maîtrise mieux votre vocabulaire métier, respecte davantage vos consignes ou produit moins d’erreurs nécessitant une intervention humaine.
Lorsqu’un nouveau modèle apparaît, il suffit ensuite de lui faire passer la même recette pour vérifier objectivement s’il apporte une véritable amélioration.
Transformer la recette en test de non-régression
La recette ne doit surtout pas être abandonnée après la mise en production.
Un système d’intelligence artificielle peut évoluer très fréquemment. L’entreprise peut changer de modèle, modifier le prompt principal, mettre à jour la documentation utilisée par le RAG ou ajouter de nouveaux outils à un agent.
Chaque amélioration peut résoudre un problème tout en provoquant une régression ailleurs.
Supposons qu’une nouvelle version du prompt fasse passer le taux global de réussite de 92 % à 97 %. La modification semble très positive, jusqu’au moment où l’on découvre qu’un scénario critique auparavant correctement traité ne fonctionne plus.
En conservant la recette et en la rejouant après chaque modification significative, l’entreprise transforme progressivement son jeu de scénarios en test de non-régression IA.
Cette base de tests devient particulièrement précieuse lorsque les modèles et les architectures évoluent rapidement.
Continuer à enrichir la recette après la mise en production
Aucun jeu de tests ne pourra représenter toutes les situations rencontrées par les vrais utilisateurs.
Une fois en production, de nouveaux cas apparaîtront nécessairement. Certains utilisateurs poseront des questions inattendues, certains documents auront des formats différents et certaines exceptions métier auront été oubliées pendant la phase de conception.
Les situations intéressantes détectées en production doivent alors être ajoutées à la recette.
Le système devient progressivement plus robuste, car chaque erreur importante rencontrée peut être transformée en un nouveau scénario qui devra obligatoirement réussir lors des futures versions.
Cette démarche permet également de mieux encadrer les usages internes de l’intelligence artificielle. Comme nous l’expliquons dans notre article consacré au Shadow IA et aux outils utilisés sans validation de l’entreprise, l’un des principaux enjeux pour les organisations consiste justement à reprendre la maîtrise des usages plutôt que de laisser chaque collaborateur choisir et tester ses propres solutions de manière isolée.
Une recette métier IA en 8 étapes
Une TPE ou une PME peut commencer sans mettre en place une infrastructure complexe.
La démarche consiste d’abord à décrire précisément la mission de l’IA et les opérations qu’elle peut réaliser, puis à identifier les collaborateurs capables d’évaluer correctement les résultats. Il faut ensuite sélectionner des situations réelles, ajouter volontairement des cas difficiles et définir pour chacun le résultat attendu.
Les erreurs peuvent alors être classées selon leur gravité afin de distinguer les simples imperfections des comportements réellement bloquants. Avant le lancement des tests, l’entreprise définit ses critères de Go / No Go puis exécute la recette.
Enfin, ces scénarios sont conservés après la mise en production pour être rejoués lorsque le modèle, les instructions ou les données évoluent.
Cette méthode peut parfaitement commencer dans un simple tableur. L’automatisation des tests devient intéressante lorsque leur nombre augmente ou lorsque les mises à jour deviennent fréquentes.
La recette métier devient un actif de l’entreprise
Un jeu de tests bien construit possède une valeur qui dépasse largement le projet pour lequel il a été créé.
Il formalise progressivement une partie du savoir métier de l’entreprise : les situations courantes, les exceptions, les règles importantes, les comportements interdits et les conditions nécessitant une décision humaine.
Lorsque l’entreprise souhaite changer de modèle ou de fournisseur, elle ne repart donc pas de zéro. Elle dispose déjà d’une base permettant de mesurer objectivement la nouvelle solution.
Au lieu de demander :
« GPT est-il meilleur que Claude ou Gemini ? »
elle peut poser une question beaucoup plus utile :
« Quelle solution réussit le mieux les tâches qui comptent réellement pour notre entreprise ? »
Votre IA est-elle réellement prête pour la production ?
Avant de déployer une solution, quelques questions permettent rapidement de déterminer si le projet est encore au stade de la démonstration ou s’il commence réellement à être maîtrisé.
L’IA a-t-elle été testée sur de vrais cas métier et pas uniquement sur quelques exemples soigneusement sélectionnés ? L’entreprise sait-elle précisément quelles erreurs sont acceptables et lesquelles doivent empêcher le déploiement ? A-t-elle vérifié ce que fait le système lorsqu’une information manque, lorsque les sources sont contradictoires ou lorsqu’un utilisateur lui demande quelque chose qu’il n’est pas autorisé à faire ?
Enfin, les mêmes tests peuvent-ils être rejoués lorsqu’un modèle, un prompt ou une source documentaire change ?
Si plusieurs réponses restent négatives, le système est probablement encore un prototype, même si la démonstration paraît impressionnante.
Passer du POC à une IA réellement maîtrisée
L’intelligence artificielle générative permet aujourd’hui de créer très rapidement des prototypes spectaculaires. Quelques heures peuvent parfois suffire pour connecter un modèle à des documents internes et obtenir un assistant capable de répondre à des questions métier.
La véritable difficulté commence lorsque cet assistant doit fonctionner tous les jours, avec de vrais utilisateurs et des données imparfaites.
La recette métier permet précisément de franchir cette étape en remplaçant une impression subjective — « notre IA semble bien fonctionner » — par une décision mesurable.
L’entreprise peut alors affirmer que la solution réussit les scénarios nécessaires à son activité, respecte les règles importantes et adopte le bon comportement lorsqu’elle rencontre une situation qu’elle ne sait pas traiter.
C’est cette démarche qui transforme progressivement une expérimentation intéressante en une intelligence artificielle réellement prête pour la production.
Dixie Consulting vous accompagne du cas d’usage à la mise en production
Déployer une intelligence artificielle dans une entreprise ne consiste pas uniquement à sélectionner un modèle performant et à construire un prototype. Il faut également analyser les processus métier, définir les règles de fonctionnement, organiser le contrôle humain et mesurer la qualité du système dans des situations réellement représentatives.
Dixie Consulting accompagne les TPE et PME dans cette démarche, depuis l’identification des cas d’usage jusqu’au déploiement et au suivi des solutions d’intelligence artificielle.
L’objectif est de mettre en production des IA qui ne fonctionnent pas uniquement pendant une démonstration, mais dans les conditions réelles de votre entreprise.
