Modèle 8 : fiche système et fiche modèle
Couvre : A.6.2.2 à A.6.2.8 (cycle de vie : exigences, conception, vérification, déploiement, surveillance, documentation technique, journaux), et le retrait du système. La norme n'impose ni un fichier par exigence ni ces intitulés : une fiche par système suffit. Inspiré des « model cards » (Mitchell et al., 2019). Les données ont leur propre fiche (modèle 9).
Une fiche par système, une fiche modèle par version du modèle. La fiche système vit aussi longtemps que le système ; la fiche modèle est figée à la mise en production.
fiche système finalité, exigences, déploiement, surveillance, journaux, retrait
fiche modèle conception, données utilisées, métriques, limites, approbation
renvois risques (modèle 3), impact (modèle 4), données (modèle 9)
Modèle vide
Système nom, propriétaire métier, propriétaire technique
Version version du système, version du modèle, date, prochaine revue
Classe AI Act reprise du modèle 1, avec l'article ou l'annexe cité
Exigences et spécification (A.6.2.2)
Finalité ce que le système décide ou recommande, en une phrase
Usage prévu utilisateurs, processus, supervision humaine
Usages exclus ce qu'il ne doit pas servir à faire
Exigences fonctionnelles, performance, équité, robustesse, sécurité, explicabilité
Critères seuil chiffré par exigence ; c'est lui qu'on vérifie en A.6.2.4
Conception (A.6.2.3)
Architecture composants, entrées, sorties, intégration dans le SI
Modèle famille d'algorithme, bibliothèque et version, hyperparamètres retenus
Variables liste, variables exclues et pourquoi (variables sensibles, proxies)
Données renvoi à la fiche jeu de données (modèle 9), version
Choix écartés alternatives testées, raison du rejet
Vérification et validation (A.6.2.4)
Jeu de test version, période, taille, indépendant de l'entraînement
Performance métrique, valeur, seuil, résultat
Équité métrique par groupe, écart, seuil, résultat
Robustesse données manquantes, valeurs extrêmes, dérive simulée
Sécurité attaques testées, résultat
Limites connues cas où le modèle se trompe le plus
Déploiement (A.6.2.5)
Environnements écarts entre développement et production (données, matériel, intégrations)
Critères critères de mise en production de A.6.2.4 : tous atteints ? sinon, dérogation
Tests utilisateurs qui, combien, résultats
Approbation instance, signataires, date, conditions
Plan mise en production progressive ou directe, date
Retour arrière version précédente ou procédure de repli, délai de bascule
Surveillance (A.6.2.6)
Indicateur définition, fréquence, seuil d'alerte, destinataire, action
Documentation technique par public (A.6.2.7)
Public document, contenu, lieu, version
Publics usuels : utilisateurs internes, personnes concernées, exploitants, auditeurs, autorité de contrôle (AI Act art. 13, instructions d'utilisation, pour un haut risque).
Journaux (A.6.2.8)
Contenu entrées, sorties, version du modèle, intervention humaine
Conservation durée, lieu, accès ; AI Act art. 19 et 26 § 6 : voir les conditions ci-dessous
Usage qui les consulte, pour quoi
Retrait
Déclencheurs conditions qui imposent l'arrêt ou le remplacement
Procédure repli, information des utilisateurs, archivage
Conservation journaux, fiche, modèle archivé, durée
Exemple rempli : mutuelle fictive
Système tri automatique des sinistres ; métier : directeur des prestations ;
technique : responsable data
Version système 2.3, modèle tri-sinistres-2.3, novembre 2026, revue mai 2027
Classe AI Act à confirmer, traité comme haut risque par prudence (modèle 1)
Exigences :
Finalité orienter chaque dossier de soins vers gestion rapide ou approfondie
Usage prévu tous les dossiers de soins, environ 2 400 par jour ; le gestionnaire
peut réorienter tout dossier
Usages exclus refuser un dossier, tarifer, évaluer un gestionnaire
Exigences E1 rappel des dossiers à examiner >= 95 %
E2 part en gestion rapide 65 à 75 %
E3 écart rural sur le taux d'approfondi < 5 points (modèle 4)
E4 écart ALD sur le taux d'approfondi < 10 points (modèle 4)
E5 motif lisible pour chaque orientation 3 variables principales
E6 temps de réponse < 2 s par dossier
Conception :
Architecture service interne appelé par l'outil de gestion à la saisie du dossier ;
sortie : orientation, score, 3 motifs
Modèle gradient boosting (LightGBM 4.3), 400 arbres, profondeur 6
Variables nature de l'acte, montant, historique 24 mois, type de prestataire,
zone de résidence ; exclus : âge, sexe, code postal complet (proxy)
Données jeu 2019-2023 v3.1 (modèle 9), repondéré sur les agences rurales
Choix écartés réseau de neurones : +0,4 point de rappel, motifs illisibles
Vérification, jeu de test 2024 v1.0 (180 000 dossiers, non vus à l'entraînement) :
E1 rappel 96,2 % seuil 95 % conforme
E2 gestion rapide 70,4 % seuil 65 à 75 % conforme
E3 écart rural 4,1 points seuil 5 conforme (v2.2 en production : +18 %)
E4 écart ALD 8,3 points seuil 10 conforme, à surveiller
E6 temps de réponse 0,3 s seuil 2 s conforme
robustesse 20 % de valeurs manquantes : rappel 94,8 %, non conforme ;
règle ajoutée : dossier incomplet = approfondi d'office
sécurité pas d'exposition externe ; accès au service par compte technique
limites actes rares (moins de 50 cas par an) : orientés en approfondi
Déploiement :
Approbation comité de mise en production, 18 novembre 2026 ; signé par le directeur
des prestations, le responsable data, le RSSI ; avis DPO joint
Conditions revue à 6 mois (modèle 4) ; E3 recalculé chaque mois en production
Plan 2 semaines en parallèle de la v2.2 sans effet, puis bascule
Retour arrière v2.2 conservée pour une panne technique (biais rural connu) ;
repli ultime : tout dossier en approfondi ; bascule < 1 h
Suivi du tri des sinistres
Surveillance, tableau de bord de l'équipe data :
part en gestion rapide quotidien hors 65 à 75 % sur 7 jours responsable data analyse
écart rural mensuel > 5 points comité IA revue humaine
écart ALD mensuel > 10 points comité IA règle ALD
dérive des variables hebdo PSI > 0,2 sur une variable responsable data analyse
réorientations manuelles hebdo > 8 % des dossiers prestations revue
réclamations liées au tri mensuel > 30 par mois relation adhérents revue
Documentation par public :
gestionnaires notice d'utilisation, sens du score et des motifs intranet v2.3
adhérents courrier type et page « examen détaillé » espace adhérent
exploitants runbook, procédure de repli wiki data v2.3
auditeurs, ACPR cette fiche, rapport de tests, journaux GED qualité v2.3
Journaux :
Contenu identifiant dossier, entrées, orientation, score, motifs, version du
modèle, réorientation et identifiant du gestionnaire, horodatage
Conservation 12 mois (politique IA, au-delà des 6 mois de l'AI Act), base dédiée,
accès équipe data et audit
Usage calcul des indicateurs, traitement des réclamations, audits
Retrait :
Déclencheurs écart rural > 5 points 2 mois de suite ; nouvelle version approuvée ;
abandon décidé par le comité IA
Procédure repli (tout en approfondi), information des gestionnaires sous 24 h
Conservation modèle, fiche et rapport de tests archivés 5 ans ; journaux 12 mois
Conservation : portée de la règle AI Act
Pour les systèmes à haut risque, les articles 19 (fournisseur) et 26 § 6 (déployeur) visent les journaux générés automatiquement qui sont sous leur contrôle. La durée doit être adaptée à la finalité : au moins six mois, sauf disposition contraire du droit applicable, notamment de la protection des données. Des règles sectorielles financières sont également prévues. L’article 12 décrit les capacités de journalisation ; il ne fixe pas lui-même cette durée.
La conservation de douze mois dans l’exemple est un choix interne à justifier, pas une obligation générale de conserver toutes les entrées et sorties de toute IA. Pour S1, la qualification haut risque reste à confirmer : le niveau de précaution choisi par l’organisation ne rend pas ces obligations légales automatiquement applicables.
Sources : article 19, article 26.