IA industrielle : les pièges du POC qui ne passe pas en production

Pourquoi le POC convaincant ne passe pas en production

Le scénario est courant : un prototype IA atteint 92 % de précision sur les données de test, la direction donne le feu vert pour la mise en production, et 6 mois plus tard le système est toujours en phase de test ou n'a jamais fonctionné correctement en conditions réelles.

Les causes récurrentes :

• Le modèle a été entraîné et validé sur des données non représentatives. En vision industrielle : images collectées en conditions de laboratoire, sans les variations d'éclairage, de température et de vibrations du plancher d'usine. En maintenance prédictive : données filtrées manuellement, périodes de panne trop "propres".
• L'intégration SI n'a pas été conçue dès le départ. La connexion OPC-UA à l'automate, l'API vers le MES, le pont vers le CMMS — tout ça arrive en fin de projet comme une réflexion. La découverte des contraintes réseau, sécurité industrielle et versions de protocoles se fait trop tard.
• Il n'y a pas de monitoring. Un modèle déployé sans surveillance de ses métriques de performance dérive silencieusement. La distribution des données de production change (nouveau fournisseur, changement de matière, usure de l'outillage), le modèle continue à fonctionner sans erreur technique, mais ses prédictions deviennent progressivement fausses.
• Le critère de succès du POC n'était pas le bon. La précision sur données de test n'est pas le critère de mise en production. Les bons critères sont : taux de détection / taux de faux positifs sur flux de production réel, latence dans les conditions réelles, disponibilité sur 30 jours, intégration SI opérationnelle.

Définir un MVP viable : les critères non négociables

Un MVP de système IA industriel n'est pas un modèle avec de bonnes métriques de test. C'est un système qui peut tourner en production pendant 30 jours sans intervention manuelle et dont les performances sont mesurées en conditions réelles.

Les critères non négociables d'un MVP production :

• Données d'entraînement représentatives : collectées dans les conditions réelles, sur la plage de variation effective (matières, conditions ambiantes, shifts différents). Pas de données de démonstration.
• Intégration SI opérationnelle : la décision du modèle est transmise au bon système (automate, CMMS, ERP) sans intervention manuelle. Pas d'export de fichier intermédiaire.
• Monitoring des métriques de performance actif : au moins une métrique de performance mesurée automatiquement en production (taux de conformité, nombre d'alertes, taux de faux positifs). Avec une alerte si la métrique sort de sa plage nominale.
• Gestion des cas limites documentée : que se passe-t-il quand le modèle ne peut pas décider (score de confiance trop bas) ? Que se passe-t-il si le système IA est indisponible ? Ces scenarios doivent être traités avant la mise en production, pas après.

L'infrastructure MLOps minimale pour démarrer

Vous n'avez pas besoin d'un stack MLOps complet pour un premier déploiement. Mais certaines briques sont indispensables dès le départ — les ajouter après coup coûte 3 à 5 fois plus cher.

Versioning des modèles : obligatoire dès le jour 1

MLflow ou DVC, quelques lignes de configuration. Chaque modèle en production doit avoir un identifiant de version, les métriques de validation associées, et les données d'entraînement versionnées. Sans ça, quand le modèle doit être réentraîné 6 mois plus tard, vous partez de zéro.

Monitoring de la distribution des entrées

Le data drift est le principal ennemi des modèles en production industrielle. Un changement de fournisseur de matière première, une usure de l'outillage, un réglage machine modifié — autant de changements qui font dériver la distribution des données d'entrée sans que personne ne le signale explicitement.

Evidently (open-source) permet de surveiller la dérive des distributions d'entrée avec une configuration minimale. Même une simple alerte par email quand la distribution de votre feature principale sort de 2 sigma de sa valeur d'entraînement est infiniment mieux que rien.

Pipeline de réentraînement documenté

Pas forcément automatisé — mais documenté et testable. Quand le responsable qualité vous signale que le modèle fait plus d'erreurs, vous devez pouvoir réentraîner le modèle sur des données mises à jour en moins d'une journée, pas en 2 semaines.

Le pipeline minimal : script de collecte des nouvelles données labellisées + script d'entraînement reproductible + tests de non-régression + déploiement en un seul script. Pas besoin d'Airflow pour ça — un Makefile bien documenté suffit pour commencer.

Le facteur d'adoption : souvent plus limitant que la technique

Un système IA techniquement performant mais non adopté par les opérateurs ou les techniciens de maintenance est un échec projet. Les facteurs d'adoption à adresser dès la conception :

• L'interface opérateur doit être dans l'outil habituel. Les alertes dans Teams ou dans SAP PM — pas dans une nouvelle interface web que personne ne consulte. Le chemin de l'alerte à l'action doit être le plus court possible.
• Le modèle doit être explicable sur ses erreurs. Quand le système génère un faux positif (un opérateur est convaincu que la pièce est bonne), vous devez pouvoir montrer ce qui a déclenché la décision. Les heatmaps et les scores par zone sont essentiels pour maintenir la confiance.
• Le feedback des opérateurs doit alimenter le modèle. Un opérateur qui invalide une décision du système doit pouvoir le faire facilement — et cette correction doit entrer dans le dataset de réentraînement. Sinon le modèle ne s'améliore pas et les opérateurs apprennent à l'ignorer.