GenAI industrielle : testez le contexte, pas seulement le modèle

Un assistant répond correctement à vingt questions d’un technicien pendant la démonstration. Le lundi suivant, il confond deux versions d’une procédure de consignation. La qualité du modèle n’a pas changé. Le contexte, lui, vient de montrer ce que le test avait oublié.

Sirris et Flanders Make présenteront le 8 septembre 2026 les résultats du projet TrustGenAI, mené dans le programme Flanders AI Research. Le webinaire annoncé porte sur un Trustworthiness Playbook pour les applications industrielles de GenAI. Deux cas serviront d’exemple : la prévision de la puissance d’un réseau et l’assistance multimodale aux opérateurs.

Le programme promet neuf dimensions de confiance et une distinction entre critères indispensables et souhaitables selon le cas d’usage. La liste détaillée et la méthode complète ne sont pas encore publiées sur la page de l’événement. Il serait donc prématuré de les inventer ou de présenter ce futur playbook comme une certification.

Une conclusion est déjà exploitable : la confiance ne se mesure pas une fois pour toutes au niveau du modèle. Elle se construit autour d’une tâche, de données, d’une interface, d’une conséquence et d’une possibilité de reprise.

Sirris, programme du webinaire Trustworthy GenAI et sustAIn.brussels, vérifiés le 10 août 2026.

Deux applications, deux définitions de l’erreur

Une prévision de charge électrique produit une valeur numérique pour une période donnée. On peut comparer cette valeur au résultat observé, mesurer l’écart, regarder les pointes ratées et décider à partir de quel seuil le système ne doit plus piloter une action.

Une assistance multimodale aux opérateurs reçoit des éléments plus hétérogènes : question orale, photo, code d’alarme, extrait de manuel ou état d’une machine. Sa réponse peut être juste, incomplète, périmée ou dangereusement plausible. Le test ne porte plus seulement sur une précision moyenne. Il doit vérifier la bonne procédure, sa version, les préconditions, l’incertitude et le moment où l’assistant doit renvoyer vers un humain.

Question d’acceptation	Prévision de charge	Assistance opérateur
Sortie attendue	Valeur et horizon définis	Réponse liée à une source et une version
Erreur grave	Pointe manquée ou action inadaptée	Instruction dangereuse ou procédure périmée
Incertitude	Intervalle ou seuil mesurable	Refus, question de clarification ou escalade
Reprise	Retour à une règle de calcul connue	Accès direct à la procédure et au responsable
Surveillance	Écart entre prévu et observé	Cas refusés, corrections et sources utilisées

Sirris, les deux cas d'usage industriels annoncés, vérifié le 10 août 2026.

Tester les deux applications avec le même questionnaire fournisseur produirait donc une illusion de rigueur. Un score global peut aider à comparer des versions, mais il ne dit pas si une erreur précise reste acceptable sur votre poste de travail.

Le système à tester dépasse le modèle

Le cadre de gestion des risques IA du NIST sépare quatre fonctions : gouverner, cartographier, mesurer et gérer. Son playbook précise qu’il ne s’agit pas d’une checklist universelle à appliquer intégralement. Les organisations choisissent les actions adaptées à leur secteur et à leur cas d’usage.

Cette logique évite une erreur fréquente dans les pilotes GenAI : mesurer le modèle alors que l’application ajoute plusieurs couches qui peuvent chacune créer ou corriger un échec.

Le périmètre d’essai devrait inclure au minimum :

1. l’entrée réelle, avec ses scans imparfaits, photos sombres, accents, abréviations et champs manquants ;
2. la récupération des connaissances, avec les droits d’accès, doublons et anciennes versions ;
3. la consigne et les règles métier, qui orientent ou limitent la génération ;
4. le modèle et sa version, car un changement amont peut modifier le comportement ;
5. l’interface, qui doit montrer une source, une incertitude ou une interdiction sans ambiguïté ;
6. l’action humaine, notamment qui contrôle, corrige, arrête et reprend le travail ;
7. le journal, qui permet de retrouver l’entrée, la version, la sortie et la décision.

NIST AI Risk Management Framework et NIST AI RMF Playbook, vérifiés le 10 août 2026.

Une PME n’a pas besoin d’une plateforme d’évaluation gigantesque pour commencer. Elle a besoin d’un dossier rejouable. Cinquante cas bien choisis, conservés avec leur résultat attendu et leur conséquence, valent davantage que cinq cents questions génériques téléchargées sur internet.

Écrivez l’échec avant la métrique

« Le système doit être fiable à 95 % » ne suffit pas. Cette phrase mélange les questions faciles et difficiles, les erreurs sans effet et celles qui arrêtent une production.

Commencez plutôt par nommer les échecs interdits. Pour un assistant de maintenance, ce peut être recommander une intervention sans consignation, citer une pièce incompatible ou utiliser un manuel obsolète. Pour une prévision, ce peut être dépasser un écart défini pendant une pointe ou continuer à produire une recommandation lorsque les capteurs sont incomplets.

Chaque échec interdit reçoit ensuite quatre éléments :

• un cas de test ou une famille de cas ;
• un résultat attendu, y compris le refus de répondre ;
• la personne qui décide si le résultat est acceptable ;
• l’action de reprise lorsque le test échoue.

Les métriques viennent après. Certaines seront numériques : taux d’erreur, écart absolu, temps de réponse, proportion de réponses avec une source valide. D’autres seront des portes fermées : aucun accès à une procédure non autorisée, aucune action automatique au-delà d’un seuil, aucun conseil de sécurité sans référence valide.

Le règlement ne classe pas toute l’usine à haut risque

La présence d’une IA dans un atelier ne suffit pas à rendre automatiquement l’application « à haut risque » au sens de l’AI Act. La qualification dépend notamment de la finalité prévue, du rôle du système et des catégories définies par le règlement.

Cette analyse doit néanmoins être faite avant le pilote. Lorsqu’un système entre dans le régime à haut risque, le règlement prévoit des exigences spécifiques, notamment en matière de gestion des risques, de données, de documentation, de journaux, de contrôle humain, d’exactitude, de robustesse et de cybersécurité. Pour les autres applications, ces éléments restent de bonnes disciplines d’achat et d’exploitation, mais il ne faut pas leur attribuer automatiquement le même statut juridique.

Règlement (UE) 2024/1689, version actuelle consolidée au 27 juillet 2026, vérifié le 10 août 2026.

Le dossier de test sert donc deux décisions distinctes. La première est juridique : quel régime s’applique à l’usage prévu ? La seconde est opérationnelle : quelles preuves faut-il avant de laisser l’application entrer dans le flux ? Une conclusion juridique ne remplace pas un essai métier, et un bon essai ne tranche pas seul la qualification réglementaire.

Le protocole d’acceptation d’une page

Avant de comparer des fournisseurs ou des modèles, rédigez une page avec l’équipe métier, l’IT et la personne qui porte la sécurité du poste.

• Nommer une tâche précise et la décision que l'application peut influencer.
• Choisir les documents, capteurs et versions autorisés comme entrées.
• Recenser les cas fréquents, limites, incomplets et contradictoires.
• Écrire les erreurs interdites avant de fixer un score moyen.
• Définir quand l'application doit refuser, demander une précision ou escalader.
• Conserver la source, la version du modèle, la sortie et la correction humaine.
• Prévoir une reprise sans IA pour les tâches qui ne peuvent pas attendre.
• Nommer la personne qui accepte le pilote et celle qui peut le suspendre.

Ce document devient le point de départ de la démonstration. Donnez au fournisseur vos cas, pas seulement les siens. Demandez les résultats bruts, les refus et les erreurs. Si une mise à jour du modèle ou de la base documentaire intervient, rejouez le même lot avant de remettre l’application en service.

La décision de lundi matin

Prenez le pilote GenAI industriel le plus avancé de l’entreprise. Écrivez trois situations normales, trois cas incomplets et trois erreurs dont la conséquence serait grave. Pour chacune, notez la sortie attendue, le droit de refuser et la personne appelée en cas d’échec.

Si l’équipe ne sait pas remplir ces neuf lignes, elle n’a pas encore besoin d’un meilleur modèle. Elle doit préciser la tâche et la reprise.

Le futur playbook TrustGenAI apportera un cadre supplémentaire en septembre. La PME peut déjà préparer le terrain : une application digne de confiance n’est pas celle qui répond toujours. C’est celle dont les bonnes réponses, les refus et les limites ont été définis avant la mise en production.