Retours d’expérience
1 Côté technique
Mieux vaut un petit modèle bien intégré qu’un gros modèle impossible à déployer. Les transformers pré-entraînés ne faisaient guère mieux qu’un modèle de type fastText, et ils ne tenaient pas dans le budget de latence et de CPU. On a mis l’effort là où il payait : qualité des données, calibration et pipeline de déploiement.
Les dépendances sont un risque à gérer. Le dépôt de fastText a été archivé par ses auteurs à peine plus d’un an après la mise en production. Le passage à PyTorch a demandé du temps et du soin, « mais le jeu en vaut la chandelle » : le modèle est désormais maintenu en interne, calibré, explicable, et il peut évoluer. En contrepartie, PyTorch impose une gestion stricte des versions entre l’entraînement, le serving et la production.
Livrer le prétraitement avec le modèle. Au début, l’équipe informatique métier avait recodé en Java le prétraitement du texte, et cette duplication causait des erreurs. Packager le modèle avec son prétraitement et son contrat (pyfunc MLflow, modèles Pydantic), et le servir via une API Python, a réglé le problème.
Le GitOps rend le déploiement banal, et c’est le but. Quand déployer un modèle se résume à un commit d’une ligne, relu, et qu’un rollback se résume à un revert, un déploiement n’est plus un événement.
La calibration est un sujet métier. Le seuil sur l’indice de confiance fixe la charge de reprise manuelle : c’est une décision méthodologique, pas un réglage d’exploitation. On ne peut le fixer que sur un modèle calibré et un échantillon représentatif, et il faut le revoir à chaque nouveau modèle.
2 Côté données
La qualité des labels est le principal levier. Les codes historiques mélangent les sorties d’un moteur de règles, de modèles précédents et d’une codification humaine faite dans l’urgence. Un moteur de règles auditable, où chaque recodage est loggé, a fait plus pour l’accuracy que la plupart des changements d’architecture. Mais les règles ont des effets de bord sur les codes voisins : elles doivent rester ciblées.
Pas d’évaluation sans golden set aléatoire annoté à l’aveugle. Les corrections manuelles sont sélectionnées sur les échecs du modèle, et les annotateurs qui voient la prédiction se laissent influencer. Sans échantillon aléatoire, alimenté en continu et annoté à l’aveugle, on ne peut ni mesurer l’accuracy de la codification automatique, ni fixer le seuil, ni comparer deux modèles. Le monitoring doit être un processus continu, pas une suite de campagnes ponctuelles.
Les experts comme référence, les LLM pour le volume. Pour la révision NAF 2025, quelques dizaines de milliers d’annotations d’experts ont suffi pour choisir et valider le recodage par LLM de millions d’observations. La confiance déclarée par les LLM eux-mêmes n’était pas un filtre exploitable ; l’accord entre modèles, si.
Connaître le plafond. Même des annotateurs expérimentés sont souvent en désaccord au niveau le plus fin de la nomenclature. L’accord inter-annotateurs donne une borne supérieure réaliste de ce qu’un modèle peut atteindre, et permet de cadrer les attentes.
3 Côté organisation
Le MLOps, c’est une organisation autant qu’une stack technique. Le projet associe :
- l’équipe métier, responsable du répertoire et de la nomenclature ;
- les équipes informatiques qui exploitent la production ;
- l’équipe de data science (SSP Lab).
Le tournant a été de nommer, dans l’équipe métier, un responsable du modèle, chargé du réentraînement, de la qualification et de l’exploitation, distinct de l’équipe d’innovation. Cela rejoint la recommandation d’AIML4OS : tout modèle en production doit avoir un responsable clairement identifié (Tayebjee et al. 2025, ch. 3). Ce rôle est décrit dans Défis organisationnels et d’infrastructure.
La confiance se construit avec des outils. Les experts métier font confiance au modèle quand ils peuvent voir pourquoi il a décidé (explicabilité), vérifier ce qui a changé entre deux versions (rapports de comparaison, changelogs) et transformer leurs retours en corrections durables (règles).
L’open source, ça paie. Tout le code est public, ce qui a permis des échanges avec d’autres instituts statistiques : Statistique Canada, le Statec, Statistics Austria, Destatis, les instituts nationaux de statistique d’Afrique subsaharienne et l’OCDE. Les outils ont aussi été réutilisés pour d’autres nomenclatures.
4 Une perspective européenne
Le pipeline a servi d’implémentation de référence, avec ceux de Statistics Austria et de Destatis, pour le tutoriel MLOps rédigé dans le cadre du projet européen AIML4OS (Work Package 10, cluster 4 « From text to code ») (Tayebjee et al. 2025). Le tutoriel découpe le cycle de vie en quatre étapes, chacune avec sa checklist :
- Données : stockage, validation, versionnage ;
- Modèle : entraînement reproductible, validation au-delà de l’accuracy, packaging, model registry ;
- Serving : API, conteneurs, GitOps, passage du développement à la production ;
- Monitoring : types de drift, niveaux de monitoring, réentraînement et mise en production.
Cette note peut se lire comme une étude de cas détaillée de ce cadre.
5 Questions ouvertes
Certaines questions méthodologiques restent ouvertes, et se posent sans doute pour tous les pipelines de codification :
- Biais d’ancrage. Si les gestionnaires voient la proposition du modèle, leurs codes ne sont plus indépendants du modèle. Comment en tenir compte quand ces codes servent à l’entraînement ?
- Taille du golden set. Avec environ 750 classes, impossible d’avoir des métriques par classe sur un seul trimestre. Sur quelle fenêtre cumuler le golden set ?
- Accuracy cible. Qui fixe \(p^*\) ? C’est un arbitrage métier entre accuracy et charge de reprise manuelle.
- Historique. À quel rythme faire perdre du poids aux anciens codes ? Que faire des observations historiques dont le code NAF 2025 est ambigu : les réannoter, les exclure, ou garder les codes des moteurs avec un faible poids ?