Leçon 5 — L'organisation
Les quatre leçons précédentes portaient sur la technique. Celle-ci porte sur ce qui détermine réellement la survie d'un modèle : qui fait quoi, et qui répond de quoi.
Les rôles, sans le jargon des offres d'emploi
Les intitulés varient énormément d'une organisation à l'autre. Ce qui compte est la liste des compétences qui doivent être couvertes, quel que soit le nombre de personnes.
Comprendre le métier. Traduire un besoin en problème formulable, savoir ce qu'une erreur coûte, juger si une prédiction est plausible. Sans cette compétence, on construit des modèles techniquement bons et inutiles.
Préparer les données. Trouver les sources, comprendre leur signification réelle, détecter les anomalies, construire les variables. C'est le poste de travail le plus lourd et le plus déterminant sur la performance finale.
Modéliser. Choisir une approche, entraîner, évaluer honnêtement, éviter la fuite de données. C'est la compétence la plus visible et rarement le goulot d'étranglement.
Industrialiser. Conteneuriser, exposer, intégrer, automatiser, surveiller. C'est du génie logiciel classique appliqué à un objet qui a des propriétés inhabituelles.
Exploiter. Suivre les indicateurs, intervenir en cas d'incident, décider d'un réentraînement, arbitrer un retour arrière.
Dans une petite structure, une ou deux personnes couvrent tout, et c'est très bien. Ce qui est fatal, c'est qu'un de ces cinq domaines ne soit couvert par personne — et c'est presque toujours le dernier.
Le point critique : la propriété
Rappelé de la leçon 1 parce que c'est le facteur qui explique le plus d'abandons.
Un modèle en production a besoin d'un propriétaire nommé. Pas une équipe : un nom. Quelqu'un qui, si le modèle se dégrade, a la responsabilité de s'en apercevoir et de décider quoi faire.
Ce que le propriétaire doit avoir concrètement :
- Un indicateur métier qu'il suit, et sur lequel il rend compte.
- Une revue périodique inscrite dans son agenda, mensuelle ou trimestrielle.
- L'autorité de décider d'un réentraînement, d'un retour arrière ou d'un retrait.
- L'accès aux moyens pour agir, ce qui suppose un budget de maintenance prévu.
Le schéma qui fonctionne le mieux : le modèle appartient à l'équipe produit qui en tire la valeur, avec le soutien d'une équipe plateforme qui fournit l'outillage. L'équipe produit répond de la performance métier ; l'équipe plateforme répond de la fiabilité de l'infrastructure.
Le schéma qui échoue : une équipe centrale de data science qui livre des modèles à des équipes métier qui n'en veulent pas particulièrement. Personne ne se sent responsable, et le modèle meurt de désintérêt.
Les trois niveaux de maturité
Cette échelle est utile pour situer votre organisation et savoir quelle est la prochaine étape — plutôt que de viser directement le sommet.
Niveau 0 — Manuel
Tout se fait à la main. Un notebook entraîne, quelqu'un exporte un fichier de modèle, quelqu'un le copie sur un serveur. Il n'y a ni versionnement des données, ni surveillance.
C'est acceptable pour un premier modèle, pour valider qu'une idée a de la valeur. Beaucoup d'organisations restent ici bien trop longtemps.
La prochaine étape : figer les données avec une empreinte, sortir le code du notebook, et mettre en place un tableau de bord minimal.
Niveau 1 — Automatisé
L'entraînement est un pipeline reproductible déclenché par commande. Les expériences sont suivies. Le déploiement passe par une chaîne d'intégration continue. La surveillance couvre les entrées et les sorties.
C'est le niveau visé par la plupart des organisations, et c'est suffisant pour la grande majorité des cas. Un modèle réentraîné manuellement chaque mois, avec des indicateurs suivis et un retour arrière testé, est un système sain.
La prochaine étape, seulement si le besoin existe : automatiser le déclenchement.
Niveau 2 — Continu
Le réentraînement se déclenche automatiquement sur dérive ou sur calendrier, avec validation automatique du nouveau modèle, déploiement en canari et retour arrière automatique en cas de régression.
Ce n'est justifié que lorsque les données évoluent vite et que le volume de modèles rend le manuel impraticable. Y accéder sans les prérequis de la leçon 4 — tests de qualité des données, validation, canari, retour arrière testé — produit un système qui propage des erreurs plus vite qu'un humain ne les détecte.
N'installez pas l'outillage du niveau 2 quand vous êtes au niveau 0. L'ordre qui fonctionne est de résoudre les problèmes que vous avez réellement, dans l'ordre où ils vous gênent. Une plateforme MLOps complète installée avant le premier modèle en production est un investissement qui ne sera jamais amorti.
La documentation qui sert réellement
La plupart de la documentation de modèle ne sert à rien parce qu'elle décrit le code. Ce qui sert, c'est ce qui répond aux questions qu'on se posera dans six mois, quand la personne qui a construit le modèle sera partie.
La fiche de modèle — model card — est le format le plus utile. Une page, pas plus, contenant :
- À quoi sert ce modèle et quelle décision il alimente.
- Sur quelles données il a été entraîné : source, période, volume, et quelles populations sont sous-représentées.
- Ce qu'il ne faut pas en faire : les usages hors périmètre. C'est la section la plus utile et la plus souvent absente.
- Ses performances, globales et par sous-groupe pertinent.
- Ses limites connues et ses modes d'échec observés.
- Qui en est propriétaire et comment le contacter.
- Quand il a été entraîné et quand il devra être réexaminé.
Cette fiche n'est pas un exercice bureaucratique. En Europe, la documentation technique est une obligation pour les systèmes classés à haut risque par le règlement sur l'intelligence artificielle, et le cours sur l'éthique détaille ce cadre. Autant l'écrire au moment où l'on connaît les réponses.
À documenter aussi, et cela vaut son pesant d'or : le journal des décisions. Pourquoi cette approche plutôt qu'une autre, pourquoi cette variable a été écartée, quelle piste a été essayée et abandonnée. Sans cela, votre successeur refera les mêmes essais infructueux.
La dette technique, et comment ne pas la laisser filer
Reprise de la leçon 1, avec les remèdes.
Les dépendances de données invisibles. Personne ne sait qu'une table alimente trois modèles, et quelqu'un la modifie. Remède : documenter les dépendances et, si possible, contrôler les schémas de données automatiquement pour que la rupture soit détectée plutôt que subie.
Les variables mortes. Des variables calculées, coûteuses, qui n'influencent plus le modèle depuis deux versions. Remède : mesurer périodiquement l'importance des variables et retirer celles qui ne servent plus. Chaque variable retirée est une source de panne en moins.
Les modèles en cascade. La sortie du modèle A alimente le modèle B. Une amélioration de A peut dégrader B, et personne ne comprend pourquoi. Remède : éviter autant que possible, et si nécessaire, versionner et tester la chaîne complète.
Le code de configuration mort. Des paramètres dont personne ne connaît plus l'effet, qu'on n'ose plus retirer. Remède : retirer par petits pas, avec le jeu de référence figé pour vérifier que rien ne change.
Les modèles zombies. Des modèles en production que plus personne n'utilise, qui consomment de l'infrastructure et de l'attention. Remède : un inventaire annuel, et le courage de retirer. Décommissionner proprement est un travail de professionnel, pas un aveu d'échec.
La liste de contrôle avant une mise en production
À faire valider par le propriétaire du modèle, et à conserver.
- Un propriétaire est nommé, avec un indicateur métier et une revue périodique planifiée.
- Le modèle est reproductible : données figées, code versionné, environnement conteneurisé, graines fixées.
- Un jeu de référence figé existe et le modèle y produit les prédictions attendues.
- La chaîne de préparation des données est partagée entre entraînement et production.
- Le tableau de bord couvre les entrées, les sorties et un échantillon annoté.
- Les alertes sont peu nombreuses et chacune a une action écrite.
- Le retour arrière a été testé, pas seulement documenté.
- Une fiche de modèle existe, avec la section « ce qu'il ne faut pas en faire ».
- Le comportement en cas d'indisponibilité du modèle est défini.
- La métrique métier est instrumentée, avec un groupe témoin si possible.
Aucune de ces lignes ne concerne la précision du modèle. C'est délibéré : la précision est le seul point dont l'équipe se préoccupe spontanément.
À retenir
- Cinq compétences doivent être couvertes : métier, données, modélisation, industrialisation, exploitation. Peu importe le nombre de personnes ; ce qui tue, c'est qu'une soit absente.
- Un modèle en production exige un propriétaire nommé, avec un indicateur, une revue planifiée, l'autorité et le budget.
- Le schéma qui marche : propriété par l'équipe produit, outillage par une équipe plateforme.
- Trois niveaux de maturité : manuel, automatisé, continu. Le niveau 1 suffit à la plupart des organisations.
- N'installez pas l'outillage du niveau 2 quand vous êtes au niveau 0.
- La fiche de modèle est la documentation qui sert, et sa section la plus utile est « ce qu'il ne faut pas en faire ».
- La dette propre au machine learning : dépendances invisibles, variables mortes, cascades, configuration morte, modèles zombies. Retirer est un travail de professionnel.
Leçon suivante — Récapitulatif, glossaire et FAQ →