Une étude McKinsey régulièrement citée estime que 70 à 80% des projets IoT industriels n'atteignent jamais la production ou sont abandonnés dans les deux ans suivant le pilote. Le chiffre est probablement gonflé — il englobe beaucoup de POC marketing — mais l'ordre de grandeur tient quand on regarde nos propres engagements. Plus intéressant que le taux d'échec : les causes ne sont presque jamais celles que les commerciaux mettent en avant (capteurs, connectivité, cloud). Cinq pièges récurrents expliquent l'essentiel des abandons, et tous sont gérables — encore faut-il les nommer. Le premier piège est le modèle ML générique. La tentation est forte : entraîner un Isolation Forest ou un XGBoost sur la concaténation des données de toutes les machines, parce que cela donne un dataset plus large et un modèle plus « robuste ». En pratique, c'est précisément ce qu'il ne faut pas faire. Chaque machine a sa propre signature vibratoire, son régime de fonctionnement, son historique d'usure et de réparations. Un modèle générique apprend la moyenne et rate les transitions qui annoncent une panne sur une machine spécifique. La règle qui paie : un modèle par machine, entraîné sur 6 à 12 mois de données historiques de cette machine après stabilisation post-calibration. Si l'historique manque, on commence par un modèle naïf (seuils statiques, contrôle 3σ) et on bascule sur le modèle ML quand les données s'accumulent. Le deuxième piège est l'alerte non-actionnable. Un algorithme mal calibré qui produit 30 à 50 alertes par jour, dont 90% de faux positifs, est pire qu'absence d'alertes : les techniciens cessent de regarder, l'astreinte ignore les notifications, et la vraie alerte critique passe inaperçue dans le bruit. La parade est une boucle de retour supervisée : chaque alerte doit être clôturée dans la GMAO (CMMS) avec une annotation obligatoire — « vraie dégradation », « faux positif », « maintenance préventive avancée ». Cette annotation alimente un job nocturne qui réajuste les seuils par machine et réentraîne mensuellement le modèle. Sans cette boucle, le projet meurt par érosion de l'attention. Troisième piège : l'absence de buffer côté edge. Les capteurs IoT en environnement industriel utilisent typiquement LoRaWAN, NB-IoT ou Wi-Fi industriel. Tous ces transports perdent des messages — un orage, un mur déplacé, une saturation locale. Si l'edge gateway envoie en mode fire-and-forget vers le cloud, les pertes créent des trous dans les séries temporelles qui invalident les détections d'anomalie (le modèle voit une « anomalie » qui est en réalité une absence de donnée). La règle est de bufferiser au moins 24 heures localement sur le gateway, avec retry exponentiel et identifiants uniques pour permettre la déduplication côté backend. Un Raspberry Pi CM4 avec une carte SD industrielle suffit largement pour des dizaines de capteurs. Quatrième piège : pas d'intégration avec la GMAO. Une alerte qui arrive par email dans une boîte partagée ne sera pas traitée. Une alerte qui crée automatiquement un ordre de travail dans SAP PM, Maximo ou Carl Source, avec criticité et délai de traitement calculés selon la machine et le type de défaut, devient un événement opérationnel. L'intégration est rarement triviale — les API GMAO sont vieilles, souvent SOAP, parfois inexistantes et remplacées par un export CSV nocturne — mais c'est ce qui transforme un projet « cool tech » en outil de production. Compter 15 à 30% du budget projet pour cette seule intégration ; les projets qui n'allouent rien à ce poste sont structurellement à risque. Le cinquième piège est culturel et le plus mortel : la perte de confiance humaine. Le technicien qui a trente ans de métier sent les machines comme un médecin sent ses patients. Si l'algorithme prédit une panne, qu'on lance une intervention coûteuse, et qu'au démontage rien n'est trouvé, la confiance s'effondre — souvent définitivement. Deux protections pratiques : ne jamais déclencher une intervention non-préventive sur la seule base d'une alerte (toujours croiser avec une inspection visuelle ou une mesure terrain), et publier mensuellement les métriques de qualité du modèle (précision, rappel, vraies positives confirmées) accessibles à toute l'équipe maintenance. Quand le technicien voit que l'algorithme s'est trompé deux fois et a eu raison vingt fois sur les douze derniers mois, il regarde l'alerte suivante. Il y a un sixième facteur qu'on omet souvent parce qu'il est négatif : ne pas commencer par la prédiction. Beaucoup d'usines découvrent en faisant l'instrumentation qu'elles n'ont même pas de visibilité descriptive correcte — combien de temps la machine tourne réellement, à quelle charge, quels arrêts ont eu lieu et pourquoi. Avant d'investir en prédictif, fournir un dashboard descriptif honnête (OEE, MTBF, MTTR par machine) apporte souvent 60 à 70% du ROI promis par le prédictif, pour 20% de l'effort. Le prédictif n'a de sens que par-dessus une base descriptive solide. Quand les cinq pièges sont neutralisés, les ordres de grandeur réalistes sont -25% à -45% d'arrêts imprévus, -15% à -30% de coûts maintenance corrective, +5 à +12 points d'OEE, et un ROI atteint en 9 à 14 mois. Sur nos projets, le déterminant numéro un n'est jamais le choix du modèle ML — c'est la qualité de la boucle de retour humaine et l'intégration GMAO. Le reste est de l'ingénierie qui s'apprend.