Je termine ma maîtrise en intelligence artificielle cette année. Dans mon rôle de directeur TI, la question devient vite opérationnelle. Aux études, on veut savoir si le modèle apprend. Au travail, je dois pouvoir répondre à quelqu’un qui demande : « Pourquoi a-t-il donné cette réponse mardi à 14 h 17? »

Une inférence n’est pas seulement un score. Le service lit une demande, applique un schéma, récupère ou calcule des variables, normalise leurs valeurs, exécute une version précise du modèle, puis une règle transforme le résultat en action. Pour reproduire l’événement, chaque pièce doit avoir une identité.

demande brute → validation → features versionnées → modèle versionné
              → score → seuil/règle versionnée → recommandation → action

Je conserverais un enregistrement d’inférence comme celui-ci :

{
  "decisionId": "DEC-88421",
  "time": "2022-03-08T19:17:04Z",
  "subjectRef": "DOSSIER-4182",
  "featureSet": "retard-v12",
  "featureHash": "a914...",
  "model": "retard-xgb-37",
  "score": 0.82,
  "policy": "intervention-v5",
  "outcome": "REVUE_HUMAINE"
}

Le hash détecte une différence, mais il ne suffit pas à expliquer. Les valeurs exactes doivent être récupérables pendant la durée requise, avec accès contrôlé. Si elles contiennent des données personnelles, je ne copie pas tout dans un log général; le journal pointe vers une version protégée et applique la rétention du dossier.

Le modèle appartient à un registre avec son artefact, code d’entraînement, dépendances, hyperparamètres, métriques, jeu de référence et approbation. Une version « latest » mutable détruit la reproductibilité. Le prétraitement est livré avec le modèle; changer une catégorie, une moyenne ou l’ordre des colonnes sans version peut modifier tous les scores.

Expliquer sans inventer une histoire

Pour un modèle linéaire, les coefficients donnent une relation assez directe. Pour un ensemble d’arbres ou un réseau profond, une méthode d’interprétation peut estimer la contribution locale de variables. Ce résultat dépend d’hypothèses et de la population de référence. Il aide à enquêter; il n’est pas forcément la cause humaine réelle.

Je suivrais cette séquence pour une contestation :

1. retrouver decisionId et vérifier les versions;
2. reconstruire les features à partir de la donnée figée;
3. rejouer le modèle dans un environnement isolé;
4. comparer score, seuil et règle active;
5. vérifier les données aberrantes ou absentes;
6. produire l’interprétation avec ses limites;
7. faire revoir le cas par le responsable métier;
8. corriger donnée, règle ou modèle selon la cause confirmée.

Le système doit pouvoir s’abstenir. Un score proche du seuil, une variable obligatoire absente ou une demande loin des données d’entraînement retourne à une personne. Le workflow conserve la raison HORS_DISTRIBUTION, DONNEE_MANQUANTE ou AMBIGU, pas seulement « erreur IA ».

En production, je surveille latence, taux d’abstention, distribution des variables, distribution des scores et résultats obtenus plus tard. Une dérive déclenche une enquête; elle ne lance pas automatiquement un nouvel entraînement sur des données non validées. Un déploiement canari compare l’ancienne et la nouvelle version, et un rollback remet modèle et politique de seuil.

Un bon score de test ne répond pas à une contestation ni à une panne. Ma pratique sera de choisir un cas historique, fermer l’environnement de développement et demander à une autre personne de reproduire la décision avec le registre. Si elle retrouve les entrées, l’artefact, la règle et le chemin de recours, le modèle commence à être exploitable.