IA et Machine Learning

Un modèle n'apprend que ce qu'on lui montre. Toute la difficulté tient en une phrase : construire un jeu de données qui reflète le problème réel.

Trois familles

• Supervisé : chaque exemple est étiqueté. Le modèle apprend une fonction d'entrées vers étiquettes. Cas typiques : classer un e-mail, estimer un prix, détecter une fraude.
• Non supervisé : aucune étiquette. Le modèle cherche une structure. Cas typiques : segmenter une base de clients, réduire une dimension, détecter des anomalies.
• Par renforcement : un agent agit dans un environnement et reçoit une récompense. Cas typiques : pilotage, logistique, recommandation avec boucle.

Données, caractéristiques, étiquettes

Une caractéristique (feature, variable explicative) est une colonne mesurable. Une étiquette (label, target, variable expliquée) est ce qu'on cherche à prédire. Un modèle n'apprend que des corrélations : il ne comprend ni le métier, ni le contexte, ni les causes.

Apprentissage, validation, test

Trois jeux de données, trois rôles, et l'ordre compte :

1. entraînement : le modèle ajuste ses paramètres sur ces exemples ;
2. validation : sert à choisir entre des variantes et à régler les hyperparamètres ;
3. test : le seul jeu qui n'a jamais servi à décider quoi que ce soit. Il est consulté une fois, à la fin.

Réutiliser le jeu de test pour ajuster un modèle, c'est l'annuler. À force de regarder ses résultats, on l'a fait devenir un jeu de validation sous un autre nom : le score affiché est alors optimiste et ne reflète plus rien de la production.

Surapprentissage et sous-apprentissage

• Surapprentissage : score excellent en entraînement, médiocore en test. Le modèle a mémorisé le bruit du jeu au lieu d'apprendre la règle.
• Sous-apprentissage : score médiocre partout. Le modèle est trop simple, ou les variables retenues ne portent pas le signal.

Fuite de données

Une fuite, c'est quand une caractéristique du test apparaît dans les données d'entraînement. Exemple : prédire si un client résilie et utiliser la variable « a résilié le mois dernier ». Le modèle obtient un score parfait et ne sert à rien, parce que l'information n'existait pas au moment de la prédiction.

C'est l'erreur la plus coûteuse du domaine : elle produit un score flatteur et un modèle inutilisable. On la détecte en se demandant, pour chaque variable : étais-ce réellement disponible au moment de la décision ?

Une métrique mal choisie est un objectif mal placé. L'exactitude (accuracy) est le premier réflexe, et c'est presque toujours le mauvais.

Classification

• Matrice de confusion : quatre cases — vrais positifs (VP), faux positifs (FP), faux négatifs (FN), vrais négatifs (VN). Tout le reste s'en dérive.
• Précision : parmi les positifs annoncés, quelle part est correcte ? VP / (VP + FP). À privilégier quand un faux positif coûte cher.
• Rappel : parmi les vrais positifs, combien ont été trouvés ? VP / (VP + FN). À privilégier quand un faux négatif coûte cher.
• Score F1 : moyenne harmonique des deux. Utile quand on ne peut pas trancher.
• Exactitude : (VP + VN) / total. Trompeuse sur classes déséquilibrées : un détecteur de panne qui répond toujours « rien » obtient 99 % d'exactitude sur une base sans panne.

Aucune métrique n'est universelle : le bon choix dépend du coût réel de chaque erreur, qui est une décision métier et jamais une décision technique.

Régression

• Erreur absolue moyenne (MAE) : moyenne des écarts en valeur absolue. Exprimée dans l'unité de la cible, donc lisible.
• Erreur quadratique moyenne (RMSE) : penalise fortement les grosses erreurs, utile si les valeurs aberrantes comptent.
• R² : part de variance expliquée. Proche de 1, le modèle suit bien ; négatif, il est moins bon qu'une simple moyenne.

Au-delà d'une métrique

• Courbe précision-rappel : compromis selon le seuil de décision retenu.
• Courbe ROC et aire sous la courbe (AUC) : capacité à séparer les classes, quel que soit le seuil. À manier avec prudence sur données déséquilibrées.
• Matrice de confusion : elle reste la seule façon de comprendre quelles erreurs le modèle commet.

Le pipeline n'est pas une question de style : c'est ce qui garantit que le prétraitement appris sur les données d'entraînement s'applique ensuite exactement de la même façon à la production.

Pourquoi l'ordre des étapes change tout

Un scaler standardization doit calculer sa moyenne et son écart-type sur le jeu d'entraînement seulement. S'il voit aussi le test, il a laissé une information du test s'infiltrer dans l'apprentissage, et le score_final est faux. Enpipeline, chaque transformation est ajustée puis gelée : impossible d'oublier une étape.

Entraînement complet, en une fois

Le geste à prendre :

from sklearn.pipeline import Pipeline
from sklearn.preprocessing import StandardScaler
from sklearn.linear_model import LogisticRegression

pipeline = Pipeline([
    ("scaler", StandardScaler()),
    ("model", LogisticRegression(max_iter=1000)),
])
pipeline.fit(X_train, y_train)

On n'appelle fit_transform que dans fit. En validation croisée, cross_val_score réajuste le scaler sur chaque pli : c'est exactement le comportement voulu.

Données mixtes

Un vrai jeu de données mélange des colonnes numériques et des colonnes textuelles. ColumnTransformer applique une branche de traitement à chaque type et les recolle :

from sklearn.compose import ColumnTransformer

pre = ColumnTransformer([
    ("num", StandardScaler(), ["age", "revenu"]),
    ("cat", OneHotEncoder(handle_unknown="ignore"), ["ville"]),
])

handle_unknown="ignore" n'est pas facultatif : sans lui, une ville inconnue vue à la production provoque une erreur, alors qu'elle ne peut pas faire échouer la production.

Validation croisée

Couper un jeu de données en deux en gaspille une ressource Précieuse : l'échantillon ne sera pas repris. La validation croisée en k plis répète l'entraînement k fois : chaque pli sert une fois de test, les autres d'entraînement. On obtient une estimation plus stable qu'un découpage unique.

from sklearn.model_selection import cross_val_score, StratifiedKFold
from sklearn.model_selection import GridSearchCV

cv = StratifiedKFold(n_splits=5, shuffle=True, random_state=42)
scores = cross_val_score(pipeline, X, y, cv=cv, scoring="f1")

StratifiedKFold plutôt que KFold en classification : il conserve la proportion de classes dans chaque pli, ce qui évite un pli sans aucun positif. random_state fixe le hasard : sans lui, deux exécutions ne donnent pas le même score et l'expérimentation devient ininterprétable.

Recherche d'hyperparamètres

Les hyperparamètres ne sont pas appris : ils sont choisis. On les nomme avec une double barre pour que la grille s'écrive dans l'espace des étapes du pipeline :

grille = {
    "model__C": [0.01, 0.1, 1, 10],
    "model__class_weight": [None, "balanced"],
}

rech = GridSearchCV(pipeline, grille, cv=cv, scoring="f1", n_jobs=-1)
rech.fit(X_train, y_train)
print(rech.best_params_, rech.best_score_)

Ce que la recherche ne pardonne pas

• Chercher sur le test : le score final n'a plus de valeur.
• Comparer avec des métriques différentes : on choisit la configuration qui gagne sur une métrique et on l'évalue sur une autre. Ce n'est pas une sélection, c'est du bruit.
• Faire tourner un GridSearchCV sur l'ensemble X_train/y_train puis regarder best_score_ et le prendre pour une performance : best_score_ est déjà optimiste, car il retient le maximum d'une série d'essais. Il faut évaluer le modèle choisi sur un jeu test qui n'a jamais servi.

Un modèle reproduit les biais de ses données

Un jeu d'entraînement hérité d'un historique discriminatoire produit un modèle qui reproduit cette discrimination, avec un score excellent. La performance mesurée ne dit rien de l'équité.

On ne « corrige » pas un biais en changeant d'algorithme. On agit en amont et à l'aval :

• mesurer les écarts de performance par groupe (sexe, âge, situation, territoire) ;
• rééquilibrer les données ou pondérer les erreurs ;
• revoir la formulation du problème : certains critères sont eux-mêmes le biais ;
• documenter la limite connue plutôt que la cacher.

Le seuil de décision est un arbitrage

Baisser le seuil de décision détecte plus de vrais positifs et produit plus de faux positifs. Ce n'est ni un bug ni un réglage technique : c'est une décision sur le coût relative de chaque erreur, à prendre avec le métier, et à écrire.

Le coût, pas seulement le score

Un modèle à 94 % d'exactitude peut coûter plus cher qu'un modèle à 88 % : inférence coûteuse, maintenance, explication obligatoire, reprise d'une mauvaise décision. Un projet se juge sur un ensemble de critères, dont le score n'est qu'un.

Confortable, exact, et faux

La vraie question n'est pas « le modèle est-il exact ? » mais « quand il se trompe, a-t-il tort avec confiance ? ». On mesure cela par la calibration : des prédictions annoncées à 80 % doivent être correctes environ 80 % du temps. Un modèle non calibré inspire une confiance injustifiée, et c'est ainsi que naissent les mauvaises décisions automatiques.

Un réseau de neurones est une composition de fonctions simples. Chaque couche transforme sa sortie, et l'ensemble compose une fonction plus riche.

Le perceptron

Une couche calcule une somme pondérée puis lui applique une activation non linéaire. C'est tout. L'astuce est là : sans fonction d'activation non linéaire, empiler des couches ne donnerait qu'une seule transformation linéaire, donc l'équivalent d'une seule couche.

Le rôle de l'activation

• ReLU : max(0, x) — simple, efficace, la valeur par défaut en vision.
• Sigmoïde : borne entre 0 et 1, sortie naturelle pour une probabilité, mais les gradients disparaissent aux extrémités.
• Softmax : transforme un vecteur en distribution de probabilité, utilisé en classification multiclass.

Propagation avant et arrière

1. propagation avant : on traverse les couches de l'entrée vers la sortie et on calcule la prédiction ;
2. calcul de la perte : on compare la prédiction à la vérité, par exemple avec l'entropie croisée ;
3. propagation arrière : on remonte les couches et on calcule le gradient de la perte par rapport à chaque poids ;
4. mise à jour : les poids sont ajustés dans la direction qui réduit la perte.

Le gradient est la pente locale de la perte : il indique dans quelle direction augmenter ou réduire un poids. La descente de gradient suit cette pente, par petits pas, jusqu'à un minimum.

Pourquoi c'est long, et comment on y remédie

En profondeur, le gradient peut s'annuler en remontant les couches (gradient qui disparaît) ou devenir gigantesque (gradient qui explose). Quatre réponses :

• normalisation (BatchNorm, LayerNorm) : garde les activations à une échelle stable ;
• fonctions d'activation qui saturent moins (ReLU) ;
• couches de normalisation et architecture à résiduelles, qui laissent un chemin direct pour le gradient ;
• contrôle de la taille de lot et du taux d'apprentissage.

Un réseau profond a beaucoup plus de paramètres que de données. Sans contrainte, il apprend le bruit.

Les quatre outils

• Régularisation L2 : on penalise les poids importants, ce qui répartit l'information sur plusieurs variables au lieu de la concentrer sur une.
• Régularisation L1 : elle pousse certains poids à zéro et sélectionne donc les variables inutiles.
• Arrêt précoce : on s'arrête quand la perte de validation cesse de diminuer, alors que la perte d'entraînement continue.
• abandon (dropout) : pendant l'entraînement, on met au hasard une fraction des neurones à zéro, ce qui empêche le réseau de trop compter sur un chemin unique.

Convolution et vision

Une convolution applique un petit filtre glissant sur l'image et détecte un motif local, quelles que soit sa position. Empiler des couches compose des motifs simples (bords) en motifs complexes (textures, parties, objets). Deux propriétés expliquent son succès : la réutilisation des poids — un même filtre sert partout, donc bien moins de paramètres — et l'invariance par translation.

Apprentissage par transfert

Entraîner un grand réseau de zéro exige beaucoup de données. On part plutôt d'un modèle préentraîné sur un grand jeu (ImageNet, un corpus de textes) et on l'adapte :

• gel : on n'entraîne que les dernières couches ; solution la plus économique ;
• déblocage partiel : on débloque les dernières couches ; plus de gain, un peu plus de calcul ;
• ajustement fin : tout le réseau est réentraîné ; réservé aux gros volumes de données.

Quand on n'a que quelques centaines d'exemples, cette démarche est la différence entre un modèle qui fonctionne et un modèle qui surapprend.

Un modèle ne manipule pas du texte : il manipule des nombres. Tout commence donc par une conversion.

Découpage

Le tokenizer découpe le texte en unités, appelées jetons. Un mot peut être un jeton, une partie de mot, ou plusieurs mots réunis selon la ponctuation et la langue.

Les jetons. Chaque identifiant de jeton est associé à un vecteur de nombres que le réseau apprend l'est. Un mot n'a pas de sens isolé : « bank » désigne une banque ou une rive selon la phrase, et seul le contexte permet de le trancher.

Des vecteurs statiques aux vecteurs contextuels

• word2vec et analogues : un vecteur unique par mot. Problème : « banque » a un seul vecteur pour deux sens.
• embeddings contextuels : le vecteur dépend de la phrase. Le mot « banque » de la phrase sur la Seine et celui de la phrase sur le taux de change n'ont plus le même vecteur.

La distance entre vecteurs reflète une similarité de sens, et c'est ce qui permet des usages comme le rapprochement automatique d'une question avec un document.

Tâches classiques

• classification : étiqueter un document ;
• analyse d'opinion : détecter le sentiment ;
• reconnaissance d'entités : extraire les noms, montants, dates ;
• résumé et traduction : produire un texte.

Les réseaux récurrents lisaient le texte mot à mot, ce qui rendait l'entraînement lent et la mémorisation longue difficile. Le transformer change la donne : il lit toute la séquence en une fois, en parallèle, grâce à l'attention.

Le mécanisme d'attention

L'attention répond à une question simple : quels mots de la phrase doivent regarder quels autres mots ? En « l'animal n'a pas croisé le rue parce qu'il était fatigué », « il » doit se rattacher à « l'animal », et non à « rue ».

Pour chaque mot, le mécanisme calcule trois vecteurs :

• requête (query) : ce que le mot cherche ;
• clé (key) : ce que le mot offre ;
• valeur (value) : l'information réellement transmise.

Le mécanisme compare chaque requête à toutes les clés pour obtenir des poids d'attention, puis fait une moyenne pondérée des valeurs. C'est ce qui permet à « il » de récupérer l'information de « l'animal » quelle que soit la distance entre les deux mots.

Encodeur et décodeur

• encodeur : lit et comprend. Base de la classification, de l'extraction d'entités et des vecteurs de recherche.
• décodeur : produit du texte, jeton après jeton. Base de la génération.
• encodeur-décodeur : lit d'un côté, écrit de l'autre. Base de la traduction et de la synthèse.

Un modèle de langage prédit le jeton suivant à partir des précédents. C'est tout. Cette unique idée suffit à produire de la traduction, du résumé, du code et des réponses.

Le prix à payer

Chaque jeton compare sa requête à tous les autres : le coût est quadratique en longueur de séquence. D'où les fenêtres d'attention tronquées, les versions à contexte long, et le fait qu'un contexte gigantesque n'est pas gratuit, ni en calcul, ni en mémoire, ni en latence.

Un grand modèle de langage est un prédicteur de texte. Il n'accède pas à une base de connaissances vérifiée, il ne raisonne pas sur des faits, et il ne « sait » pas ce qu'il ne sait pas.

L'hallucination

Le modèle produit la suite la plus plausible, pas la suite vraie. Une citation d'article, une API ou un résumé inexistants sont donc parfaitement idiomatiques — et totalement faux. Il est essentiel d'écrire du contenu génératif dans l'ordre, de garder cette limite à l'esprit : sur un sujet qu'on ne maîtrise pas, la phrase produite est un indice, pas une preuve.

Trois parades

• Donner du contexte vérifiable au lieu de compter sur la mémoire du modèle : c'est le principe du RAG, où l'on retrieve des documents fiables avant de générer la réponse ;
• Exiger des sources et les contrôler une par une ;
• Restreindre les tâches à ce que le modèle fait bien : reformuler, classer, extraire, synthétiser un document fourni.

L'affinage consiste à réentraîner un modèle déjà entraîné sur vos données. Le RAG, lui, ne change aucune requête : il enrichit la requête avec des documents trouvés au moment de l'appel. En pratique, on commence par le RAG, car il est réversible : on retire les documents et le système revient à son état précédent, alors qu'un affinage est difficile à défaire.

Évaluer avant de déployer

On n'évalue pas un grand modèle à l'œil. Trois niveaux :

1. évaluation de base : un jeu de questions représentatives, notées sur un barème écrit à l'avance ;
2. évaluation adversariale : chercher activement les cas où le modèle se trompe ;
3. évaluation en production : taux d'abandon, reprises de la réponse, signalements, coût par requête.

Un point de vigilance : fuite de données par la requête. Un modèle qui reçoit une question contenant une donnée personnelle peut la mémoriser. Aucune donnée personnelle ne part dans un modèle tiers sans base légale et information de la personne.

Un modèle non reproductible est un modèle qu'on ne peut ni corriger, ni auditer, ni migrer. La reproductibilité n'est pas pas une élégance technique : c'est la condition d'exploitation.

Ce qu'il faut consigner à chaque entraînement

1. la version des données : le jeu d'entraînement, avec une empreinte de contrôle (checksum) pour garantir qu'il n'a pas bougé ;
2. le code : la version exacte du dépôt, pas « la branche principale » ;
3. l'environnement : versions de Python et des bibliothèques, idéalement via un fichier verrouillé ;
4. les hyperparamètres et la configuration ;
5. les métriques sur chaque jeu ;
6. l'empreinte du modèle produit.

Geler les dépendances

Une version non épinglée est une source d'irreproductibilité silencieuse. On verrouille les versions dans un fichier dédié et on s'appuie dessus.

Le résultat obtenu par un tiers ne dépend plus du jour où il a tourné, mais de la version déclarée. C'est aussi ce qui permet de diagnostiquer : sans trace figée, un score qui change n'a aucune explication possible.

Un modèle en production n'est pas fini. Il dérive, parce que le monde dérive.

La dérive des données

La distribution des données d'entrée change : nouvelle campagne, nouveau matériel, nouvelle saisonnalité, changement d'habitude de consommation. Le modèle reçoit alors des entrées qu'il n'a jamais vues, et son exactitude réelle baisse sans qu'aucune alerte ne se déclenche, parce que tout continue de fonctionner techniquement.

La dérive de la performance est plus grave : elle vient du lien entre les entrées et la cible, qui se dégrade.

Ce qu'on surveille

• entrées : distribution, valeurs manquantes, valeurs inattendues ;
• sorties : répartition des prédictions, taux de refus, latence ;
• performance : quand les étiquettes réelles arrivent, on peut mesurer l'exactitude réelle, la seule qui compte ;
• dépendances : changement de version d'un composant en amont.

Alerte et retour arrière

Une surveillance sans procédure n'est pas une surveillance. Le dispositif se résume à trois questions auxquelles il faut pouvoir répondre :

1. quelle métrique surveille-t-on, et quel seuil déclenche une alerte ?
2. que fait-on à l'alerte — on alerte qui ?
3. combien de temps faut-il pour revenir à la version précédente ?

Sans réponse à la troisième question, la reprise d'activité peut prendre des jours. Le retour arrière doit être aussi immédiat que le déploiement.

Décider de la mise en production

Avant de publier, on statue sur ce qui doit rester vrai et donc être testé : un niveau de performance minimal, un comportement correct sur des cas limites, une latence maximale, un coût par requête, un seuil de disponibilité. Ces critères deviennent des tests automatiques : c'est la seule manière de les tenir dans la durée.

Le coût total d'un projet

Le modèle n'est qu'une ligne :

• acquisition et nettoyage des données : la ligne la plus sous-estimée ;
• annotation, si un humain doit étiqueter : elle détermine le plafond de qualité ;
• inférence : le coût se répète à chaque appel, il est donc cumulatif ;
• maintenance : surveillance, réentraînement, mise à jour des dépendances ;
• explication et audit, exigés de plus en plus par les textes en vigueur.

Par quoi commencer

Le premier projet qui réussit n'est pas le plus ambitieux, c'est celui qui répond à une question précise, avec une donnée disponible et un coût d'erreur connu. Trois critères de choix :

1. la donnée existe-t-elle déjà, et quelqu'un l'a-t-il vue ?
2. connaissez-vous le coût d'une erreur ?
3. pouvez-vous mesurer l'effet sur une décision réelle ?

Et la question la plus rentable du début : une règle explicite suffit-elle ? Si un expert sait formuler la règle, un modèle est rarement nécessaire — il sera plus coûteux, moins lisible et moins maintenable qu'un tableau.

Le règlement européen sur l'intelligence artificielle est entré en vigueur le 1^er août 2024. Il ne s'applique pas uniformément : il entre en vigueur par étapes, et un même système peut relever de plusieurs régimes à la fois.

Le calendrier, tel qu'il est aujourd'hui

Date	Ce qui s'applique
2 février 2025	pratiques interdites et obligation de compétence IA
2 août 2025	modèles à usage général, gouvernance, sanctions
2 août 2026	application générale
2 décembre 2026	transparence : contenu de synthèse
2 décembre 2027	systèmes à haut risque de l'annexe III
2 août 2028	systèmes à haut risque intégrés à des produits réglementés

Un point de vigilance daté

Les deux dernières lignes ne figuraient pas dans le calendrier d'origine : elles ont été reculées par le « AI Omnibus », adopté à l'été 2026. Un cours, un article des études antérieures à cette adoption annoncent encore l'échéance d'août 2026 pour les systèmes à haut risque : cette information est périmée. C'est le meilleur exemple du risque que représente une formation non mise à jour.

À qui s'applique le texte

Le règlement vise le fournisseur, qui commercialise un système ou un modèle sous son nom, et le déployeur, qui l'utilise dans son activité professionnelle. Un même acteur peut être l'un ou l'autre, selon la chaîne : l'éditeur d'un modèle de vision médicale est fournisseur, l'hôpital qui s'en sert est déployeur. La question à poser en premier n'est donc jamais « est-ce que je fais de l'IA ? » mais « à quel titre ? ».

Le règlement classe les systèmes en trois grandes catégories. Cette classification précède toute question technique : elle détermine ce qu'on devra prouver.

Les pratiques interdites

Applicables depuis le 2 février 2025, elles constituent le socle le plus ancien et le plus fermement établi. On y trouve notamment les systèmes qui manipulent des personnes de manière à altérer leur comportement, comme la notation d'un visage, et ceux qui exploitent des vulnérabilités connues pour dégrader un système d'information.

Les systèmes à haut risque

Ils sont définis, pour l'essentiel, par l'usage qu'on en fait et non par la technique. L'annexe III vise notamment :

• les systèmes de reconnaissance biométrique ;
• les systèmes liés aux infrastructures critiques ;
• l'éducation, y compris l'évaluation et l'orientation ;
• l'emploi : tri de candidatures, décision de recrutement, évaluation de performance ;
• l'accès aux services essentiels : crédit, assurance, soins ;
• certaines applications par les autorités : police des frontières, justice.

Pour ces systèmes, les obligations sont lourdes : gestion des risques sur tout le cycle de vie, qualité des données, documentation technique, traçabilité, transparence envers l'utilisateur, et surveillance après mise sur le marché.

Transparence et contenu de synthèse

Depuis août 2026, une interface d'interaction avec une IA doit être signalée comme telle, et les contenus synthétiques doivent être identifiables comme tels. L'obligation spécifique visant les systèmes qui génèrent un contenu de synthèse s'applique à compter de décembre 2026.

Compétence IA

L'obligation de compétence est applicable depuis février 2025. Prise dans le cours d'un projet, elle signifie concrètement : les personnes qui manipulent un système doivent en comprendre le fonctionnement et les limites. C'est le contenu de ce cours.

Un règlement qui entre en vigueur par étapes, et dont le calendrier a déjà été modifié, ne peut pas être appris une fois pour toutes. Il se surveille.

Où regarder, dans cet ordre

1. la page officielle de la Commission européenne : elle tient le calendrier consolidé, c'est la première source à consulter ;
2. le texte au Journal officiel, qui est la seule source faisant foi ;
3. les publications de l'autorité nationale, qui traduisent les obligations en gestes concrets ;
4. les lignes directrices, qui précisent les points d'interprétation encore ouverts.

Les réflexes de méthode

• dater chaque information : une obligation annoncée sans date de vérification devient une rumeur en quelques mois ;
• distinguer le texte adopté d'une ligne directrice : l'une est contraignante, l'autre interprete ;
• vérifier le calendrier avant de s'engager sur un projet : l'échéance applicable a pu reculer, comme en 2026 ;
• consigner la référence exacte — article, annexe, date — plutôt qu'un résumé.

Ce que la conformité change dans un projet technique

Trois conséquences très concrètes, indépendantes du secteur :

1. on trace ce qui a servi à entraîner et à décider : versions des données, des modèles et des choix, cette traçabilité étant elle-même une obligation ;
2. on documente la finalité : un système de recommandation qui devient un outil d'évaluation du personnel change de régime ;
3. on teste le comportement attendu, y compris sur des cas limites, et on garde la trace de ces tests.

Retenez ceci : sur un système à haut risque, ce qui compte n'est pas la qualité du modèle, mais la capacité à démontrer la qualité du modèle. Une exigence de preuve ne se rattrape pas après coup.