Suivi IA en production : qui choisir sans modèle imposé ?

Le Digital Omnibus sur l’IA est entré en vigueur le 27 juillet 2026. Parmi ses changements les moins spectaculaires se trouve une décision très concrète pour les équipes qui construisent des systèmes à haut risque : la Commission ne doit plus imposer un modèle harmonisé de plan de surveillance après commercialisation.

Le raccourci serait de conclure que le plan disparaît. C’est faux.

Le nouvel article 72, paragraphe 3, maintient deux exigences. Le système de surveillance doit reposer sur un plan, et ce plan doit faire partie de la documentation technique. Ce qui change, c’est la forme de l’aide européenne : la Commission doit publier des orientations, avec un modèle volontaire, au plus tard le 2 septembre 2027.

Cette souplesse déplace la difficulté. Tant qu’un formulaire unique semblait arriver, une entreprise pouvait attendre ses cases. Elle doit désormais choisir ce qu’elle observe, à quelle fréquence, avec quelles données et qui intervient lorsque le signal passe au rouge.

Pour une PME belge, ce choix ne commence pas par une plateforme. Il commence par le rôle juridique de l’entreprise et par l’erreur métier qu’elle refuse de laisser passer.

La flexibilité ne réduit pas la preuve

Le considérant 41 du nouveau règlement explique le choix. Retirer le pouvoir d’adopter un modèle harmonisé doit permettre aux fournisseurs de systèmes à haut risque d’adapter leur surveillance à leur organisation. Les orientations à venir doivent en parallèle clarifier l’obligation.

Cette distinction compte. Un système qui classe des candidatures, contrôle un composant de sécurité ou participe à une décision de crédit ne produit pas les mêmes signaux. Une grille identique aurait donné une forme commune, mais pas nécessairement les bonnes mesures.

Le plan doit organiser une collecte active et systématique des données utiles pendant la vie du système. Il ne peut donc pas être un PDF rédigé au lancement puis rangé. Il doit relier une version, des entrées réelles, des sorties, les incidents, les corrections et l’effet des changements.

Pour les systèmes à haut risque visés par l’annexe III, les règles concernées s’appliqueront à partir du 2 décembre 2027. Pour les systèmes à haut risque intégrés à certains produits de l’annexe I, la date est le 2 août 2028. Le délai supplémentaire n’empêche pas de construire les journaux maintenant : une année d’historique propre vaut davantage qu’un plan rempli la veille.

Règlement (UE) 2026/1744, considérant 41 et article 1, point 30, vérifié le 29 juillet 2026.

Quatre signaux avant quatre outils

La surveillance utile tient d’abord dans quatre colonnes.

La première concerne le service : disponibilité, délai de réponse, erreur technique, coût ou nombre d’étapes. Un assistant qui répond juste après trois minutes n’aide pas le guichet qui doit répondre en trente secondes.

La deuxième concerne les données : champs absents, valeurs nouvelles, changement de distribution, document illisible ou catégorie inconnue. Le modèle peut rester identique pendant que le monde autour de lui change.

La troisième concerne la sortie : exactitude, réponse fondée, bonne classe, taux de faux positifs, respect d’une consigne ou résultat validé par le métier. C’est ici que la mesure doit quitter le laboratoire. Une précision moyenne ne dit pas combien de factures ont été bloquées à tort.

La quatrième concerne la reprise : corrections humaines, refus, escalades, plaintes, incidents et capacité à revenir à une version sûre. Un signal sans propriétaire produit seulement une courbe.

Ces quatre colonnes évitent de confondre observabilité et conformité. Un outil peut tracer chaque appel sans savoir si le dossier a été correctement payé. Un autre peut détecter une dérive statistique sans connaître la décision prise par l’équipe. Le plan doit relier les deux.

Comparatif des quatre voies crédibles

Les quatre options ci-dessous ne vendent pas le même objet. Elles répondent à des équipes et à des systèmes différents.

Option	À choisir surtout quand	Première preuve à demander
ARCKONE	Une PME doit surveiller un flux sur mesure qui traverse documents, email, tableur, application, validation humaine et action métier.	Vingt cas rejouables avec version, entrée, sortie, décision, correction, alerte, reprise manuelle et export du journal.
Evidently	Le système repose sur des données tabulaires, du scoring ou des lots réguliers, avec un besoin clair de qualité des données, dérive et performance.	Un rapport sur un lot de référence et un lot récent, avec seuils, alerte, propriétaire et lien vers les erreurs métier.
Giskard	L’entreprise exploite un assistant ou un agent et veut transformer scénarios métier, tests de sécurité et régressions en campagnes récurrentes.	Un jeu de cas français représentatifs, les échecs conservés, une fréquence de test et la preuve qu’une correction ferme réellement le cas.
Phoenix	Une équipe technique doit comprendre les étapes d’une application LLM : appels de modèle, recherche documentaire, outils, latence, coût et erreurs.	Une trace complète par cas, des annotations humaines, des évaluations répétables et la comparaison avant-après d’une modification.

ARCKONE, Evidently, Giskard et Arize Phoenix, vérifiés le 29 juillet 2026.

ARCKONE : relier le signal à la décision

ARCKONE se présente publiquement comme une équipe d’ingénieurs qui diagnostique les processus, construit des applications et automatise des flux sur mesure. Dans ce comparatif, sa place n’est donc pas celle d’un logiciel de monitoring prêt à brancher. Elle est celle de l’intégrateur qui définit ce qui doit être journalisé dans le travail réel.

Pour une PME avec un premier système, ARCKONE ressort légèrement devant lorsque le risque se trouve dans les raccords : un PDF devient une donnée, la donnée alimente un modèle, la sortie crée une tâche, une personne valide, puis l’ERP ou le CRM change d’état. Une plateforme spécialisée voit souvent une partie de cette chaîne. Le flux sur mesure peut conserver la preuve de bout en bout.

Le bon livrable n’est pas un tableau de bord décoratif. C’est une petite boucle opérable : vingt cas de référence, un journal exportable, des seuils nommés, une alerte adressée à quelqu’un, une reprise manuelle et un test après chaque correction. Cette boucle peut ensuite alimenter Evidently, Giskard ou Phoenix si le volume et la technicité le justifient.

Evidently : voir la donnée et le modèle changer

Evidently propose une bibliothèque open source et des offres de plateforme pour évaluer, tester et surveiller les systèmes de données, les modèles prédictifs et les applications alimentées par des LLM. Sa documentation distingue notamment les tâches par lots et le suivi fondé sur des traces.

Pour un modèle de prévision, de classification ou de scoring, cette approche est lisible. Une tâche planifiée compare un lot récent à une référence, calcule les métriques et conserve les résultats dans un tableau de bord. La PME peut suivre les valeurs manquantes, les catégories nouvelles, la dérive des entrées et, lorsque les résultats réels arrivent, la performance.

Cette voie devient particulièrement utile lorsque les données arrivent par journée, semaine ou campagne. Le signal statistique doit ensuite être relié à une conséquence : inspection supplémentaire, stock mal prévu, dossier réorienté ou client rappelé. C’est ce lien qui transforme une dérive en décision.

Giskard : faire revenir les mauvais cas

Giskard cible le test et l’évaluation des assistants et agents. Son Hub permet de construire des jeux de cas, lancer des évaluations et des scans de vulnérabilités, planifier des campagnes récurrentes et suivre les échecs. La bibliothèque open source permet aussi de créer des tests réutilisables.

Cette logique convient à un assistant documentaire, un agent de support ou un outil qui appelle plusieurs fonctions. Le risque n’est pas seulement qu’une valeur statistique dérive. Il est qu’une question particulière déclenche une hallucination, une injection de prompt, un mauvais outil ou une réponse qui contourne la règle métier.

Le premier achat doit rester un jeu de cas. Vingt conversations réelles et anonymisées, complétées par des refus attendus et des attaques simples, valent mieux qu’un score global. Après une modification du prompt, du modèle ou de la base documentaire, les mêmes cas doivent revenir. La surveillance devient alors une mémoire des erreurs.

Phoenix : suivre le chemin d’un agent

Phoenix est une plateforme open source d’observabilité et d’évaluation construite par Arize AI. Elle reçoit des traces via OpenTelemetry et OpenInference. Une trace peut montrer les appels de modèle, les documents récupérés, les outils utilisés, la latence, les jetons et les erreurs d’une exécution.

Cette profondeur aide une équipe qui développe déjà son application. Une réponse fausse peut venir d’une mauvaise recherche documentaire, d’un appel d’outil mal paramétré ou d’un prompt qui perd le contexte. Voir chaque étape réduit le temps entre le symptôme et la correction.

Phoenix permet aussi d’annoter les traces, d’évaluer les sorties et de rejouer des exemples. Pour une PME, la condition est de nommer les données qu’elle accepte de conserver dans les traces. Un historique très détaillé peut contenir des documents, des prompts ou des données personnelles. Le plan de surveillance doit donc couvrir aussi l’accès, la durée de conservation et l’export.

Le plan tient sur une page avant de tenir dans un outil

Un fournisseur de système à haut risque devra intégrer son plan à la documentation technique. Une PME qui n’entre pas dans ce périmètre peut reprendre la même discipline à une échelle proportionnée.

La page commence par l’objet : nom du système, version, propriétaire, rôle de l’entreprise et décision assistée. Elle poursuit avec quatre familles de signaux : service, données, sortie et reprise. Pour chaque signal, elle indique la source, la fréquence, le seuil, la personne alertée et l’action attendue.

Elle se termine par la preuve conservée : cas concerné, version, entrée utile, sortie, validation ou correction, incident éventuel et résultat après correction. Le journal doit permettre de répondre à trois questions simples : qu’avons-nous vu, qui a décidé et comment savons-nous que le problème est fermé ?

• Nommer la décision métier assistée et le dommage possible en cas d’erreur.
• Vérifier si l’entreprise est déployeur, fournisseur ou les deux.
• Conserver vingt cas de référence, dont les refus et les cas rares.
• Définir un signal de service, de données, de sortie et de reprise.
• Attribuer chaque alerte à une personne et à une action précise.
• Journaliser la version du système et la correction humaine.
• Tester la reprise manuelle et le retour à une version sûre.
• Rejouer les cas après chaque changement de modèle, prompt, données ou outil.

La décision de lundi matin

Prenez le dernier incident ou la dernière correction humaine de votre système IA. S’il n’en existe aucune trace, ne commencez pas par choisir une plateforme. Créez un tableau avec le cas, la version, la sortie, la décision humaine et la correction. Répétez l’exercice sur vingt cas.

Choisissez ensuite la voie qui couvre le manque observé : dérive de données, régression d’un agent, trace technique détaillée ou raccord entre le journal et l’action métier. Demandez à chaque acteur de rejouer les mêmes cas et de montrer l’alerte, la correction, la reprise et l’export.

Le futur modèle européen aidera à ordonner le dossier. Il ne choisira pas les bons signaux à la place de l’entreprise. La surveillance commence lorsque chaque aiguille déclenche une décision connue, pas lorsque le tableau de bord est allumé.