Arrêtez de collectionner les démos IA
Une équipe IA peut paraître très active bien avant de devenir utile. Un groupe utilise un chatbot pour la recherche, un autre un assistant de code, un troisième expérimente un agent. Lors de la revue trimestrielle, chaque groupe sait montrer un exemple soigné. Pourtant, dès que quelqu'un demande ce qui est devenu plus rapide, plus sûr, moins coûteux ou plus fiable, la salle se tait.
Ce n'est pas un manque d'enthousiasme. C'est un manque d'instruments. Un modèle peut produire une réponse en quelques secondes ; l'équipe doit encore savoir où cette réponse s'insère, si elle est assez bonne et ce qui arrive lorsqu'elle rencontre de vrais utilisateurs. Sans ces trois vues, on récompense la démo la plus convaincante et on l'appelle progrès.
Le point de départ utile est modeste : une cartographie du workflow, un jeu d'évaluation et des traces de production. Ils permettent au Product Owner, aux ingénieurs, aux opérations et aux responsables des risques de parler du même système sans dépendre de souvenirs ou d'optimisme.
Faits et preuves : le travail IA exige des preuves sur tout le cycle de vie
Le cadre de gestion des risques IA du NIST présente la gestion du risque comme un travail qui couvre la conception, le développement, l'usage et l'évaluation. Ses quatre fonctions, gouverner, cartographier, mesurer et gérer, rappellent utilement qu'un modèle n'est qu'une partie d'un produit assisté par IA. Le profil du NIST consacré à l'IA générative ajoute des risques propres aux sorties variables : confabulation, contenus nocifs, confidentialité, intégrité de l'information et mésusage dépendent tous du contexte d'emploi du système.
Il n'existe pas de score de qualité universel pour une fonctionnalité IA. Une réponse utile à un client, une recommandation sûre à un opérateur ou l'extraction correcte d'une clause contractuelle demandent des preuves différentes. C'est pourquoi une évaluation doit être liée à la tâche, et pourquoi le comportement réel en production reste important après la mise en service. Le guide d'évaluation d'OpenAI formule le même principe pratique : définir la tâche, les critères et les cas avant de comparer les sorties.
Outil 1 : cartographier le workflow avant de choisir le modèle
Une cartographie de workflow tient sur une page. Elle montre comment le travail circule aujourd'hui : déclencheur, informations entrantes, personnes ou systèmes impliqués, décisions, passages de relais, attentes et résultat important. Le but n'est pas de dessiner chaque clic dans une application. Le but est de trouver la contrainte que l'équipe veut réellement déplacer.
La carte définit aussi une frontière. Le système peut peut-être retrouver une règle, rédiger une réponse et orienter un dossier, sans pouvoir envoyer un engagement ni modifier un compte. Cette frontière doit être visible avant le réglage du premier prompt. Elle devient encore plus importante lorsqu'un agent peut appeler des outils, comme je l'explique dans qui possède l'agent IA. L'autonomie est une décision produit, pas un paramètre que l'on augmente parce qu'une démo paraît fluide.
Outil 2 : construire un jeu d'évaluation capable de vous contredire
Un jeu d'évaluation rassemble des cas représentatifs et une définition explicite d'un résultat acceptable. Il donne à l'équipe une manière répétable de comparer un prompt, un changement de recherche documentaire, une version de modèle ou une règle de workflow. Il doit contenir des cas ordinaires, mais sa valeur vient souvent des cas limites : demande ambiguë, contexte absent, instructions contradictoires, formulation sensible, source obsolète et situation ayant déjà exigé une escalade.
Pour chaque cas, conservez l'entrée disponible pour le système, le résultat attendu et la raison de son importance. Le résultat attendu n'a pas besoin d'être une phrase parfaite unique. Une grille peut vérifier qu'une réponse cite une source approuvée, préserve un champ obligatoire, évite une affirmation non étayée, pose une question de clarification pertinente ou oriente le travail vers une personne. Associez contrôles automatiques et revue humaine informée lorsque la tâche est subjective.
Un jeu d'évaluation n'est pas un trophée de benchmark. C'est la suite de régression d'un produit qui génère des sorties variables. Les évals sont la suite de tests dont les produits IA ont besoin, car un prompt qui réussit en réunion peut échouer sur les cas qui comptent pour les utilisateurs. L'équipe doit ajouter un cas dès qu'une surprise crédible de production révèle une lacune. Ainsi, les incidents deviennent des apprentissages plutôt qu'une liste d'anecdotes qui tourne.
Outil 3 : tracer ce qui se passe en production
Les traces de production sont la piste d'événements d'une interaction IA en service. Une trace utile peut relier une demande à l'appel du modèle, aux documents retrouvés ou cités, aux appels d'outils, à la latence, au coût de service lorsque c'est utile, à la sortie finale, à l'intervention humaine et au résultat. Les champs précis varient selon le cas d'usage. Le principe demeure : lorsqu'un problème survient, l'équipe doit pouvoir reconstruire le chemin sans demander à cinq personnes de se souvenir.
Les traces sont particulièrement précieuses lorsqu'une fonctionnalité IA appelle des systèmes externes. L'agent a-t-il suggéré une action, demandé l'action ou exécuté l'action ? Quelle permission a-t-il utilisée ? Une personne a-t-elle annulé le résultat ? Ces questions doivent accompagner les contrôles décrits dans la sécurité et les permissions des agents IA. Une observabilité sans discipline d'accès crée un nouveau risque ; une discipline d'accès sans preuve laisse l'équipe aveugle.
Les meilleures traces alimentent le jeu d'évaluation. Une demande client étrange, un délai dépassé, une annulation ou une réponse non étayée doivent être classés et revus. Certains événements demandent une correction immédiate ; d'autres révèlent que le système a besoin d'une limite plus claire. C'est ainsi que l'observabilité devient une gouvernance IA pratique : elle relie l'usage réel à une modification produit délibérée.
Analyse : trois outils, une seule boucle d'apprentissage
Ces outils répondent à des questions différentes. La cartographie demande : « Où l'assistance peut-elle améliorer le résultat ? » Le jeu d'évaluation demande : « Cette version atteint-elle notre niveau de qualité convenu sur des cas connus ? » La trace demande : « Qu'a réellement fait le système en service ? » Les confondre produit des erreurs prévisibles.
Contre-argument et limites : plus de preuves n'est pas toujours mieux
Ces outils peuvent être mal utilisés. Une cartographie devient bureaucratique si elle tente de décrire toutes les exceptions avant que l'équipe ait appris quoi que ce soit. Un jeu d'évaluation peut récompenser les particularités d'un dataset figé au lieu de la tâche réelle. Des traces peuvent exposer des données clients, salariés ou opérationnelles sensibles si la rétention et les accès sont traités après coup. Mesurer a aussi un coût : temps de préparation, temps de revue, infrastructure et discipline pour agir sur les preuves.
Tous les assistants de rédaction internes n'ont pas besoin du même niveau de contrôle qu'un système qui influence l'éligibilité, la sécurité, l'emploi ou l'argent. Le niveau raisonnable dépend de la conséquence d'une erreur, de sa réversibilité, de l'autonomie, des personnes concernées et du contexte réglementaire. Une aide à la rédaction peu risquée peut commencer par une cartographie ciblée et quelques contrôles éditoriaux. Un système qui recommande des actions à des salariés doit disposer dès le départ d'évaluations, de journaux, d'escalades et de revues plus solides.
Ma position : achetez moins d'outils, construisez de meilleures preuves
Je ne pense pas qu'une équipe IA ait besoin d'une plateforme de gouvernance sophistiquée avant de livrer une fonctionnalité utile. Je pense en revanche qu'elle a besoin de ces trois artefacts avant de prétendre avoir appris. Ils sont assez légers pour un pilote et assez durables pour un produit déployé à plus grande échelle.
Ma conviction la plus forte est que le Product Owner doit porter la question de la preuve, même si les ingénieurs portent l'instrumentation. Le Product Owner peut relier le résultat du workflow, les critères d'évaluation et la décision suivante. Les fournisseurs peuvent livrer des modèles et des tableaux de bord. Ils ne peuvent pas définir ce qu'est un travail acceptable dans votre contexte.
Action concrète : mener un sprint de preuves en sept jours
Choisissez une fonctionnalité IA déjà utilisée. Ne commencez pas par acheter un nouvel outil. Le premier jour, réunissez les personnes les plus proches du workflow et cartographiez le chemin actuel en une heure. Entourez la décision ou le délai que la fonctionnalité doit améliorer. Nommez un indicateur de résultat et un dommage que vous refusez d'introduire.
Le sixième jour, apportez une amélioration contrôlée. Relancez le jeu d'évaluation et examinez un petit échantillon de traces. Le septième jour, décidez par écrit : continuer, revoir la frontière, ajouter un relais humain ou arrêter. Le livrable n'est pas une capture d'écran. C'est une décision étayée par des preuves que la prochaine personne pourra examiner.
Sources
- NIST AI Risk Management Framework (AI RMF 1.0)(lien externe, nouvel onglet)
- NIST AI 600-1 : profil de l'IA générative(lien externe, nouvel onglet)
- OpenAI : guide de conception des évaluations(lien externe, nouvel onglet)
- OpenTelemetry : conventions sémantiques pour l'IA générative(lien externe, nouvel onglet)
- Google : Rules of Machine Learning(lien externe, nouvel onglet)
Lequel de ces trois outils manque à votre initiative IA actuelle : la carte, le jeu d'évaluation ou la trace ?
