Défis organisationnels et d’infrastructure

Qui fait quoi autour d’un modèle en production : le data scientist métier comme point de contact, et une plateforme de qualification identique à la production.
Auteurs
Affiliation

Nathan Randriamanana

Insee

Hugo Simon

Insee

AvertissementBrouillon

Ce chapitre est un brouillon, à compléter et à valider par ses auteurs.

Maintenir un modèle en production, la difficulté est surtout ailleurs que dans la technique. Les enquêtes auprès des praticiens et les retours d’expérience de déploiements de machine learning vont dans le même sens : les problèmes les plus durs se situent à la frontière entre équipes, qu’il s’agisse de s’entendre sur les besoins, de négocier la qualité des données ou d’intégrer le modèle dans un système existant (Amershi et al. 2019; Nahar et al. 2022; Paleyes et al. 2022). La codification APE ne fait pas exception. Ce chapitre décrit deux réponses qui ont fait la différence : un data scientist métier, point de contact pour le modèle, et une plateforme de qualification identique à la production.

Amershi, Saleema, Andrew Begel, Christian Bird, et al. 2019. « Software Engineering for Machine Learning: A Case Study ». Proceedings of the 41st International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP), 291‑300.
Nahar, Nadia, Shurui Zhou, Grace Lewis, et Christian Kästner. 2022. « Collaboration Challenges in Building ML-Enabled Systems: Communication, Documentation, Engineering, and Process ». Proceedings of the 44th International Conference on Software Engineering (ICSE). https://arxiv.org/abs/2110.10234.
Paleyes, Andrei, Raoul-Gabriel Urma, et Neil D. Lawrence. 2022. « Challenges in Deploying Machine Learning: A Survey of Case Studies ». ACM Computing Surveys 55 (6). https://doi.org/10.1145/3533378.

1 Trois équipes autour d’un modèle

Trois équipes se partagent la responsabilité du modèle, chacune avec ses propres contraintes :

Table 1: Équipes impliquées dans la codification APE.
Équipe Responsable de Préoccupation principale
Équipe métier (répertoire Sirene) La nomenclature, les règles de codification, les équipes de reprise manuelle Qualité du code APE et charge des gestionnaires
Équipes informatiques de production Le système d’information du répertoire et l’infrastructure de production Disponibilité, sécurité, maîtrise des changements
Équipe de data science (SSP Lab) Le pipeline d’entraînement, les librairies, la plateforme de développement Méthodes, outils, qualité du modèle

Sans quelqu’un qui soit côté métier et comprenne le modèle, chaque question doit passer d’une équipe à l’autre. Une baisse du taux de codification automatique, c’est du drift ou un effet saisonnier ? Cette erreur signalée est-elle isolée ou récurrente ? Un nouveau modèle peut-il partir en production ? Ces questions restent en suspens, ou sont tranchées par la personne la plus proche plutôt que par celle qui devrait décider.

2 Le data scientist métier comme point de contact

2.1 Pourquoi un rôle dédié

La littérature sur le machine learning dans les organisations décrit les rôles et responsabilités autour d’un modèle en production (Kreuzberger et al. 2023). Elle montre aussi l’intérêt de placer les data scientists dans les équipes métier qu’ils servent, au plus près du domaine et des décisions (Stelmaszak et Kline 2023). Le cadre AIML4OS, écrit pour la statistique publique, en fait une recommandation : tout modèle en production doit avoir un responsable clairement identifié (Tayebjee et al. 2025, ch. 3).

Kreuzberger, Dominik, Niklas Kühl, et Sebastian Hirschl. 2023. « Machine Learning Operations (MLOps): Overview, Definition, and Architecture ». IEEE Access 11: 31866‑79. https://doi.org/10.1109/ACCESS.2023.3262138.
Stelmaszak, Marta, et Kelsey Kline. 2023. « Managing Embedded Data Science Teams for Success: How Managers Can Navigate the Advantages and Challenges of Distributed Data Science ». Harvard Data Science Review 5 (2). https://hdsr.mitpress.mit.edu/pub/wfr9k3vq.
Tayebjee, Meilame, Nina Niederhametner, Bogdan Levagin, et Ariane Lestrade. 2025. From text to code (WP10.4) – MLOps tutorial. AIML4OS project, Work Package 10. https://aiml4os.github.io/WP10_Cluster4_MLOps/.

Pour la codification APE, ce responsable est un data scientist placé dans l’équipe métier. Il est distinct de l’équipe d’innovation qui a construit les premiers modèles. Il est à l’aise des deux côtés : il connaît la nomenclature et le travail des gestionnaires, et il sait lire une courbe risque–couverture, lancer un entraînement et relire une pull request.

2.2 Responsabilités

Table 2: Responsabilités du data scientist métier.
Domaine Le data scientist métier…
Besoins Traduit les besoins métier en exigences pour le modèle : accuracy cible \(p^*\), charge de reprise acceptable, codes qui ne doivent jamais être faux
Annotation Organise les campagnes d’annotation et le golden set : échantillonnage, consignes, calendrier des équipes d’experts
Retours métier Recueille les erreurs signalées, distingue les erreurs isolées des erreurs récurrentes, et transforme ces dernières en règles validées par les experts
Réentraînement Pilote le protocole de réentraînement et valide les quality gates
Monitoring Fait une première analyse des alertes du monitoring et décide s’il faut agir
Mise en production Est l’interlocuteur des équipes informatiques de production pour chaque version du modèle, de la qualification au rollback
Communication Rend compte de la qualité à la hiérarchie et aux utilisateurs du code APE

L’équipe de data science reste responsable des outils : librairies, pipelines, plateforme de développement. Le data scientist métier est responsable du modèle en tant que service rendu au métier. Ce partage permet à l’équipe d’innovation de passer à d’autres projets sans laisser le modèle orphelin.

2.3 Les conditions du rôle

Le rôle ne marche que si quelques conditions sont réunies :

  • du temps : réentraînement, annotation et monitoring sont des tâches récurrentes, pas une activité annexe ;
  • des accès : la même plateforme de développement et les mêmes dépôts que l’équipe de data science ;
  • des compétences : Python, Git, stats, et connaissance de la nomenclature ;
  • un mandat : le pouvoir de décider des mises en production, dans des règles convenues avec le métier et l’informatique.

3 Une plateforme de qualification identique à la production

3.1 L’écart entre développement et production

Le modèle est développé et entraîné sur le SSP Cloud, une plateforme de data science ouverte, avec des GPU et un accès à internet (voir Architecture). Il tourne en production sur l’infrastructure interne de l’Insee : CPU uniquement, pas d’accès à internet, limites de ressources strictes et changements très encadrés. Toute différence entre les deux environnements peut faire échouer une mise en production, ou changer le comportement du modèle sans que personne ne s’en rende compte :

  • une version de librairie différente, qui change le prétraitement ou les résultats numériques ;
  • une ressource que le modèle télécharge au démarrage, inaccessible dans un réseau fermé ;
  • une latence ou une empreinte mémoire mesurée sur une machine de développement, pas sur le CPU de production ;
  • une différence de configuration dans la façon dont l’API est exposée au répertoire.

3.2 Ce que signifie « iso-production »

La plateforme de qualification comble cet écart en reproduisant la production aussi fidèlement que possible :

  • le même environnement d’exécution : image de base, versions de Python et des librairies, builds CPU uniquement ;
  • les mêmes ressources : limites de CPU et de mémoire, nombre de réplicas ;
  • les mêmes contraintes réseau : pas d’accès à internet, dépendances servies par le gestionnaire de dépôts interne ;
  • le même mécanisme de déploiement et la même configuration qu’en production.

3.3 Ce qu’on y mesure

Chaque modèle candidat passe la même batterie de tests avant sa mise en production (voir Protocole de réentraînement) :

  • la latence des appels unitaires (médiane, p95, p99) et le débit en batch, sous une charge réaliste ;
  • l’empreinte mémoire et le temps de démarrage ;
  • la cohérence online / offline : le modèle servi doit reproduire exactement les prédictions hors ligne sur le golden set de test ;
  • la robustesse : des entrées mal formées ou inattendues doivent être rejetées proprement, sans faire tomber le service.

Ce sont les métriques non fonctionnelles de l’évaluation, qui n’ont de sens qu’ici.

flowchart LR
  DEV["Développement et entraînement<br/>(SSP Cloud : GPU, internet)"] --> REG[("Model registry<br/>MLflow")]
  REG --> QUAL["Plateforme de qualification<br/>(iso-production : CPU, réseau fermé)"]
  QUAL -->|"latence, mémoire,<br/>cohérence, robustesse"| GO{"Go / no-go"}
  GO -->|"non"| DEV
  GO -->|"oui"| PROD["Production<br/>(infrastructure interne)"]
Figure 1: Du développement à la production.

3.4 Qui fait quoi

Table 3: Partage des responsabilités autour de la qualification.
Étape Équipe de data science Data scientist métier Production informatique / architectes
Artefact du modèle et suite de tests Fournit Relit —
Plateforme de qualification Utilise Utilise Fournit et maintient
Go / no-go Conseille Décide Vérifie les critères d’exploitation
Mise en production et rollback — Demande Exécute

4 Défis ouverts

  • Pérenniser l’annotation. Le golden set demande aux experts métier un effort d’annotation modeste mais continu, qui entre en concurrence avec leur travail quotidien de codification.
  • Compétences et continuité. Un seul data scientist métier, c’est un single point of failure : il faut un suppléant et de la documentation.
  • Garder les plateformes alignées. Chaque changement en production (image de base, limites de ressources, règles réseau) doit être répercuté sur la plateforme de qualification, sinon la qualification perd son sens.
Retour au sommet