Mon verdict d'emblée : quand une IA de vision d'entrepôt perd en précision après le déploiement, le modèle n'est presque jamais le vrai problème. Le vrai problème, c'est tout ce qui entoure le modèle — la lumière, les caméras, les données, et la façon dont vous déployez les nouvelles versions.
J'ai vu cette scène trop de fois. Un fournisseur fait une démo sur un portable : 99% de précision sur le jeu d'entraînement, de jolis graphiques sur un projecteur, toute la salle applaudit. Deux mois après le lancement, la précision sur le terrain a glissé vers le bas des 90%, les opérateurs recontrôlent manuellement chaque commande, et le patron veut savoir où est passé l'argent. Le fournisseur hausse les épaules : "Vos conditions de site ont changé."
La précision sur le jeu d'entraînement, c'est un examen sans documents. La production, c'est un examen avec documents où quelqu'un ne cesse d'allumer et d'éteindre la lumière.
Passons en revue les causes profondes, une par une. Premièrement : la lumière. La lumière d'un entrepôt ne tient jamais en place. Une porte de quai s'ouvre et le soleil frappe le convoyeur. L'équipe de nuit travaille sous un éclairage différent de l'équipe de jour. En automne, le soleil est à un angle différent et une station qui marchait bien en juin est soudain pleine de reflets. Je me souviens bien d'un cas publié : un système d'inspection visuelle monté sur du matériel Jetson Orin affichait 99.8% au labo, puis les faux positifs ont grimpé à 15–20% après le déploiement — la cause était le soleil entrant par une fenêtre, qui faisait passer les reflets sur les pièces métalliques pour des défauts. Carton, ruban adhésif, film étirable — les surfaces d'un entrepôt sont des miroirs. Personne n'y échappe.
Deuxièmement : les caméras bougent. Un chariot élévateur heurte un support et l'angle change de quelques degrés. La poussière s'accumule sur l'objectif pendant trois mois. Les vibrations du convoyeur floutent l'image. Quelques degrés, ça semble trivial, mais pour un modèle qui positionne ou compte, un nouvel angle est effectivement un nouveau jeu de données.
Troisièmement : les marchandises changent. De nouveaux SKU arrivent, une marque change la couleur de sa boîte, un logo est redessiné, le film étirable passe de transparent à noir — rien de tout ça n'était dans les données d'entraînement. Quatrièmement, plus sournois : le prétraitement en production ne correspond pas à celui de l'entraînement. Le modèle a été entraîné sur des images normalisées ; un ingénieur a sauté l'étape de normalisation pour gagner quelques millisecondes de latence. Un biais entraînement-serving (training-serving skew) comme celui-ci ne lève aucune erreur. Il mange juste votre précision en silence.
La cinquième est une que même beaucoup d'équipes d'algorithmes ratent : les étiquettes elles-mêmes dérivent. La même équipe de contrôle qualité juge différemment "est-ce que cette rayure compte comme un défaut" en janvier et en juillet. Le modèle apprend d'une cible mouvante.
Donc voici le résumé en une phrase : le modèle n'a pas empiré. Le monde a changé. Et la plupart des déploiements de vision en entrepôt sont totalement impréparés pour un monde qui change.
Versionnez vos modèles comme vous versionnez votre slotting
Commencez par une vilaine habitude. Dans trop de projets, la gestion des modèles est un dossier contenant model_final_v2_real_final.pth. Quel jeu de données l'a entraîné ? Quels hyperparamètres ? Le prétraitement a-t-il changé ? Personne ne peut le dire. Quelque chose casse et vous voulez revenir en arrière — revenir en arrière vers quoi, exactement ?
La gestion des versions a une règle non négociable : tout modèle qui a un jour été en production doit être entièrement reproductible. Un numéro de version doit lier trois choses — la version du jeu de données, la version du code, et les hyperparamètres plus les graines aléatoires. Les données d'entraînement sont figées en instantané comme un artefact immuable que personne ne touche ensuite. S'il manque un maillon, le jour où quelque chose casse, vous en serez réduit à deviner quel maillon a changé.
Comment prendre un instantané d'un jeu de données sans sur-ingénierie ? Simple : chaque entraînement stocke la liste des fichiers plus les valeurs de hachage du jeu d'entraînement, avec les ratios d'échantillonnage et les méthodes d'augmentation écrits dans le journal d'entraînement. Si quelqu'un demande "sur quoi cette version a été entraînée exactement" et que vous pouvez répondre en trois minutes, vous avez réussi. Les équipes qui ne peuvent pas répondre finissent par déboguer avec de la superstition.
Le deuxième élément de survie, c'est le retour en arrière (rollback). Le standard pour l'itération des modèles de vision, c'est le rollback en un clic : une mauvaise nouvelle version est remplacée par la dernière version stable en quelques minutes — pas de réentraînement, pas de changement de code. Si vous ne pouvez pas faire ça, ne parlez pas d'itération. Regardez les histoires d'horreur où la précision s'est effondrée : souvent, le désastre n'était pas que la nouvelle version était mauvaise, c'était que la nouvelle version était mauvaise et qu'il n'y avait aucun moyen de revenir en arrière, si bien que le site a tourné sur un modèle cassé pendant des semaines.
Vient ensuite la décision sur la stratégie de déploiement, et je vous donne mon verdict directement. Trois patterns standards de l'industrie : le mode shadow, le déploiement canary, le déploiement blue-green. Le mode shadow fait tourner le nouveau modèle sur le trafic réel aux côtés de l'ancien — les sorties du nouveau modèle sont journalisées mais jamais utilisées. Risque zéro, conçu pour répondre à "comment ce modèle se comporte-t-il sur du trafic réel". Le déploiement canary laisse le nouveau modèle servir une petite part du trafic réel — disons 5% pendant une semaine — puis monte par paliers comme 20%, 50%, 100% si tout tient, en gardant le rayon d'impact réduit. Le déploiement blue-green est une bascule instantanée entre deux environnements complets, adapté aux moments "il faut basculer" comme changer de modèle de caméra ou refondre le prétraitement.
Mon choix pour la vision en entrepôt : la voie standard, c'est deux semaines en shadow, puis une montée en canary. Ne sautez jamais le shadow pour aller directement au canary — chaque commande servie par un canary est une vraie affaire, et un mauvais contrôle qualité, c'est une mauvaise expédition. Une mauvaise prédiction en shadow n'est qu'une ligne dans un journal. L'ordre compte.
Ces deux semaines de shadow ne sont pas non plus du temps perdu. Surveillez trois chiffres : le taux de désaccord entre le nouveau et l'ancien modèle, les SKU sur lesquels les désaccords se concentrent, et si le nouveau modèle est clairement plus stable sur les échantillons à haute confiance. Si le désaccord reste élevé et que vous passez au canary quand même, vous volez à l'aveugle. Pendant le canary, surveillez les métriques business, pas seulement les techniques : les heures de recontrôle manuel ont-elles baissé, le taux d'erreurs d'expédition a-t-il bougé. Une mise à niveau avec de bonnes métriques techniques et des métriques business plates n'est pas une mise à niveau. C'est du brassage.
Trop d'alertes, c'est comme pas d'alertes
Après le lancement vient le deuxième champ de bataille : la surveillance. Beaucoup de projets culminent le jour du lancement parce que personne ne remarque quand le modèle commence à pourrir. Quand l'équipe d'exploitation sent que quelque chose cloche, le modèle se dégrade depuis deux mois.
D'abord, surveillez les bonnes métriques. Le taux de faux positifs et le taux de faux négatifs doivent être suivis séparément, parce qu'ils brûlent deux sortes d'argent différentes. Les faux positifs brûlent de la main-d'œuvre : le modèle signale un problème qui n'existe pas, et chaque commande signalée force quelqu'un à s'arrêter et à recontrôler. Poussez le taux de faux positifs assez haut et les opérateurs commencent à ignorer le système — votre investissement IA est mort-né. Les faux négatifs brûlent du vrai cash : les marchandises défectueuses passent et sont expédiées aux clients, se transformant en retours et en chargebacks. Un tableau de bord qui ne montre que la "précision globale" est de l'auto-tromperie — un modèle à 95% de précision pourrait être 2.5% de faux positifs plus 2.5% de faux négatifs, ou 4.5% et 0.5%. Ce sont deux business complètement différents.
Il faut aussi distinguer quatre sortes de "cassé" différentes : la dérive des données (les entrées ont changé — éclairage, nouveaux emballages), la dérive des prédictions (la distribution des sorties du modèle a changé), la dérive de concept (la relation entrée-réponse elle-même a changé, par ex. les standards de contrôle qualité ont été durcis), et les simples bugs d'ingénierie (un pipeline de features est tombé). Causes différentes, remèdes différents. Recourir à "ajouter des données et réentraîner" dès que la précision baisse traite la mauvaise maladie neuf fois sur dix — si la caméra est de travers, cent réentraînements n'y changeront rien.
Enfin, la fatigue d'alertes, que je souligne parce que c'est la façon la plus courante dont ces systèmes meurent. Des seuils trop lâches et un modèle qui pourrit n'alerte personne. Des seuils trop serrés et la personne d'astreinte reçoit des dizaines d'alertes par jour et commence à les balayer en masse sans les lire. Mon expérience : deux niveaux d'alerte, pas plus. Niveau un : la précision est passée sous la ligne de base, traitez-le aujourd'hui. Niveau deux : la tendance se dégrade, regardez-le cette semaine. Tout schéma d'alertes à plus de deux niveaux est effectivement l'absence de schéma d'alertes.
Pas de grandes théories pour finir. Juste une chose que vous pouvez faire demain.
À partir d'aujourd'hui, faites sauvegarder au système ses images de production, tirez-en 100 au hasard chaque jour, faites-les recontrôler par un humain, et consignez combien étaient des faux positifs et des faux négatifs. Tenez le rythme pendant deux semaines. Ce que vous obtiendrez, c'est l'actif le plus précieux de tout ce projet : une vraie courbe de précision venue du terrain. Tout ce qui précède — versionnage, déploiement canary, seuils d'alerte — ne fonctionne qu'une fois cette courbe existante. Sans elle, chaque paramètre que vous réglez est une supposition.
Dans ce métier, le gagnant n'est jamais l'équipe qui a le modèle le plus précis. C'est l'équipe qui découvre en premier quand le sien cesse d'être précis.
Traduit de l'anglais. En cas de divergence, la version anglaise fait foi.
