Comment rendre une IA fiable en production : prompts, règles métier, tests et contrôle qualité

Une IA fiable n’est pas une IA qui répond correctement à quelques démonstrations choisies. C’est un système dont le comportement utile est défini, testé sur des cas représentatifs et limites, surveillé après déploiement et interrompu lorsqu’une règle critique échoue.

Cette définition ne promet pas l’absence d’erreur. Elle rend l’erreur détectable, attribuable et traitable. Elle distingue aussi quatre propriétés souvent confondues : la conformité du format, la justesse factuelle, le respect métier et l’autorisation d’agir.

Le prompt oriente le modèle, mais reste interprété par un système probabiliste. Il ne remplace pas une autorisation serveur, un contrôle de schéma, une règle de calcul, une liste de sources permises ou un test de non-régression. Il ne doit pas non plus contenir toutes les règles de l’entreprise : leur duplication dans un long texte les rend difficiles à versionner, à tester et à faire relire par les responsables métier.

La documentation d’Anthropic sur les évaluations place la définition de critères de réussite mesurables avant l’optimisation du prompt. OpenAI documente de la même manière les jeux de données, critères et exécutions d’évaluation. Le prompt est un composant de la boucle ; il n’est pas la preuve finale.

Les 8 piliers pour construire une IA fiable présentés dans l’édition initiale — cadrer, structurer, tester, surveiller et maîtriser les sources, formats, règles et usages — deviennent ici une architecture exploitable. Chaque couche possède un responsable, un artefact et une condition d’échec.

Ce qu’un projet IA fiable doit produire ne se limite donc pas à un prompt système : il faut au minimum des règles métier, un jeu de tests, un tableau de suivi, des seuils et une procédure de reprise. La méthode simple pour produire des réponses IA fiables consiste à relier demande, contexte, règles et validation sans fusionner ces responsabilités.

« Répondre avec prudence » n’est pas une règle testable. « Si aucune source autorisée ne soutient le prix, ne produire aucun montant et transférer la demande à un humain » l’est. La formulation réduit l’espace d’interprétation et permet d’écrire un cas de test avant de voir la réponse du modèle.

L’assistant reçoit une demande de prospect, extrait les informations explicitement présentes et prépare une synthèse. Il peut poser une question de clarification. Il ne promet aucun délai, ne calcule aucun prix et n’envoie aucune proposition. La direction commerciale garde l’acceptation finale.

Un test utile relie une entrée, un comportement attendu, une méthode de notation et une règle de blocage. Un cas « réussi » parce que la réponse paraît bonne ne suffit pas. Le jeu doit refléter les demandes réelles, les cas limites et les abus plausibles.

Le fichier JSONL des douze cas d’évaluation reprend cette structure dans un format réutilisable. Il constitue une base de départ, pas un benchmark universel : chaque équipe doit l’adapter à sa tâche et ajouter ses incidents réels.

Les champs, vocabulaires, permissions et conditions critiques se vérifient mieux par du code. Un modèle-juge peut compléter l’évaluation pour la pertinence ou le ton, mais sa grille doit être testée sur un échantillon humain. Anthropic recommande de choisir la méthode la plus rapide, fiable et scalable, avec une préférence pour le code lorsque la règle est déterministe.

Ce validateur ne contrôle pas tout : il ne juge ni la qualité de formulation ni la fidélité sémantique à une source. Il démontre une frontière essentielle : les décisions critiques peuvent être refusées sans demander au modèle s’il pense avoir respecté la règle.

Une injection de prompt survient lorsqu’une entrée modifie le comportement du système de manière imprévue. L’OWASP classe la prompt injection au premier rang de son Top 10 2025 pour les applications LLM et rappelle qu’aucune prévention infaillible n’est connue. La réduction du risque combine limitation des capacités, séparation instructions/données, sorties validées, moindre privilège, confirmation humaine et surveillance.

Pour les données personnelles, la CNIL rappelle que l’utilisateur ne doit fournir que des informations qu’il est autorisé à partager. En production, ce principe doit devenir une politique : minimisation des données, filtrage avant envoi, information des utilisateurs, habilitations, durée de conservation et procédure d’incident.

Les métriques doivent suivre le risque réel de l’application. Un taux global de 94 % peut masquer une violation critique sur toutes les demandes sensibles. Les critères bloquants restent donc séparés des métriques d’amélioration.

Le NIST AI RMF recommande des processus de test, évaluation, vérification et validation documentés, puis une surveillance en production. Il insiste également sur des conditions proches du contexte réel de déploiement et sur la documentation des jeux de tests, métriques et outils.

Le comportement peut changer lorsque le modèle, ses paramètres, les outils, les sources, le prompt ou les règles changent. OpenAI précise que les sorties sont variables et recommande des versions de modèle épinglées avec des évaluations pour suivre la cohérence. La version testée doit être identifiable sans supposer qu’un même nom commercial produit toujours le même comportement.

Les signes qu’une IA manque de fiabilité apparaissent rarement dans la démonstration nominale. Ils se voient dans les règles impossibles à isoler, les refus incohérents, les sources introuvables, les droits excessifs et les changements de comportement non expliqués.

Les deux ressources sont publiées sous licence Creative Commons Attribution 4.0. Elles peuvent être adaptées, citées et redistribuées avec attribution à Edikka et lien vers cet article.

Edikka conçoit des intégrations IA et n’est pas un organisme indépendant de certification. Cette méthode décrit les contrôles que nous jugeons nécessaires pour rendre un système plus observable et gouvernable. Elle ne remplace ni une analyse de risques adaptée, ni un audit de sécurité, ni l’avis juridique requis par le contexte.

Le jeu public comporte douze cas de référence. Il ne produit ici aucun résultat comparatif entre modèles, aucun taux de gain et aucune promesse de « zéro hallucination ». Une preuve de performance exige l’exécution sur une tâche définie, un échantillon représentatif, des seuils décidés avant observation et la publication des versions testées.

• Anthropic · Définir les critères de réussite et construire des évaluations.
• OpenAI Developers · Working with evals.
• OpenAI Developers · Structured Outputs.
• OpenAI API · Backward compatibility et versions de modèles.
• OWASP GenAI · LLM01 :2025 Prompt Injection.
• NIST · AI RMF Core, fonction Measure.
• NIST · AI Risk Management Framework.
• CNIL · Questions-réponses sur l’utilisation d’un système d’IA générative.

Le passage d’une IA qui répond à une IA qui respecte un cadre ne vient pas d’une formule magique. Il vient d’une architecture où le prompt, les règles métier, les données, les formats, les tests et les responsabilités restent distincts. Le modèle conserve sa capacité d’interprétation ; le système conserve le pouvoir de vérifier, refuser, escalader et revenir en arrière.