7 erreurs que commettent les usines lors du déploiement de l'IoT
DBR77 Team · Publié le
Les sept erreurs les plus courantes dans les déploiements IoT en usine sont : aucune décision définie, un pilotage confié à l'IT seul, trop de lignes en même temps, aucune référence de départ, des alertes sans responsable, des codes de causes repris de l'ERP et un programme qui dépend d'un seul porteur. Aucune de ces erreurs ne concerne les capteurs ou les logiciels.
Chacune transforme l'IoT en système de reporting coûteux. Vous trouverez ci-dessous comment repérer chaque erreur et ce qu'il faut faire à la place.
La question qui montre si l'IoT fonctionne
Quand un client dit à Paweł Dera, CTO de DBR77 IIoT, « nous avons déjà de l'IoT », il pose une seule question : « Qu'avez-vous changé dans le process le mois dernier à partir des données du système ? » Souvent, personne ne peut citer quoi que ce soit.
Les tableaux de bord impressionnent, mais les décisions se prennent toujours à l'expérience. En général, personne n'a répondu au départ à trois questions : quels sont les cinq indicateurs qui comptent, qui agit sur chacun, et quel seuil déclenche une action.
Dans l'enquête de McKinsey auprès de plus de 700 experts de la fabrication, moins d'un tiers avaient fait passer des cas d'usage critiques à un déploiement à grande échelle. Le Forum économique mondial a décrit 70 % des industriels comme bloqués dans le « purgatoire des pilotes ».
Erreur 1 : aucune décision définie
Lors du panel de l'ITM Industry Europe 2026 consacré aux raisons pour lesquelles l'IA en usine s'arrête au stade du pilote, Paweł Dera a ramené la plupart des projets enlisés à la même lacune : personne n'avait écrit quelle décision le modèle devait améliorer. Les enregistrements sont disponibles en polonais.
« Nous voulons être davantage pilotés par les données » ne nomme ni déclencheur, ni responsable, ni délai, alors qu'une décision a besoin des trois. Avant la mise en service, rédigez un court contrat de décision pour la ligne :
- Cinq indicateurs qui comptent, par exemple la disponibilité, le temps de réaction, les principales causes d'arrêt, la production par poste et les rebuts.
- Un rôle qui agit sur chaque indicateur, par poste.
- Un seuil par indicateur qui déclenche une action précise de ce rôle.
Si vous ne pouvez pas remplir ce contrat, le projet n'est pas prêt à connecter des machines. Notre guide sur comment choisir le premier cas d'usage IoT montre comment trouver une décision qui vaut la peine d'être lancée.
Erreur 2 : l'IT porte seul le déploiement
L'IoT touche aux réseaux et à la sécurité, il atterrit donc souvent à l'IT. L'IT livre les machines connectées et les tableaux de bord, et personne dans l'atelier ne change sa façon de travailler.
Les travaux de McKinsey sur l'IoT montrent que de nombreux déploiements sont pilotés par l'IT plutôt que traités comme des transformations métier, et que les entreprises qui réussissent désignent un responsable clair.
Répartissez plutôt les responsabilités. La production possède le déploiement et ses résultats : un responsable de ligne décide de ce qui compte et qui agit. L'IT et l'OT assurent le réseau, les accès et la sécurité. La maintenance prend en charge la réaction aux arrêts techniques.
Voyez concrètement comment se présentent décisions, responsables et alertes
Lors d'une démonstration en ligne de 30 minutes, nous montrons comment DBR77 IIoT relie chaque arrêt à une cause, un responsable et un temps de réaction, sur une ligne en production.
Erreurs 3 et 4 : trop de lignes à la fois, et aucune référence de départ
Connecter toute l'usine d'un coup paraît efficace. En pratique, les efforts se dispersent et aucune ligne ne reçoit assez d'attention pour changer les habitudes.
La quatrième erreur accompagne souvent la troisième : il n'y a pas de référence de départ, si bien que sans chiffres « avant » le projet est jugé sur des impressions. Deux semaines de données sur une seule ligne suffisent. Mesurez le délai entre l'arrêt et la première action, la part des arrêts sans cause et les trois principales pertes en minutes.
Erreurs 5 et 6 : des alertes sans responsable, et des codes de causes issus de l'ERP
Les alertes envoyées à « la maintenance » ou à un groupe de discussion n'ont pas de destinataire précis, et au bout d'une semaine les gens les mettent en sourdine. Chaque alerte doit être attribuée à un rôle précis sur le poste en cours, avec une règle d'escalade : pas d'acquittement dans les 5 minutes, et le chef d'équipe est prévenu.
Les codes de causes repris de l'ERP ont été conçus pour la comptabilité analytique, et un opérateur devant une machine arrêtée pense avec d'autres mots. Face à des dizaines de codes au vocabulaire financier, il choisit « autre ». Gardez 10 à 15 causes par type de machine, formulées avec les mots que l'on emploie dans l'atelier. Les recommandations de Vorne sur les six grandes pertes donnent un exemple de règle claire : tout arrêt de plus de deux minutes reçoit une cause.
Sur une ligne de conditionnement de carton ondulé où les alertes sont devenues des tâches avec un responsable et où les opérateurs choisissaient la cause sur la machine en environ deux secondes, le temps de réaction moyen est passé de 24 à 9 minutes. L'application opérateur montre comment fonctionne la saisie des causes, et les données à collecter sur les machines indique les signaux par lesquels commencer.
Erreur 7 : le programme repose sur un seul porteur
Beaucoup de programmes IoT reposent sur une seule personne enthousiaste. Quand cette personne part, les revues s'arrêtent et le système devient un écran accroché au mur. Rendez le programme indépendant de toute personne :
- Des standards documentés : définitions, listes de causes, routages d'alertes et seuils, écrits et versionnés.
- Des rôles nommés : un responsable de ligne, un responsable des données et un responsable de réaction par poste, chacun avec un suppléant.
- Un rythme fixe : une revue de 10 minutes au début de chaque poste et une revue mensuelle des seuils et des causes.
Ces trois éléments transforment aussi un pilote en standard d'usine.
Les sept erreurs en un coup d'œil
| Erreur | Symptôme sur le terrain | Correction |
|---|---|---|
| Aucune décision définie | Personne ne peut citer un changement fait le mois dernier à partir des données | Contrat de décision : cinq indicateurs, un responsable chacun, seuils d'action |
| Pilotage confié à l'IT seul | Machines connectées, tableaux de bord en ligne, travail inchangé | La production possède les résultats ; l'IT et l'OT possèdent le réseau et la sécurité |
| Trop de lignes à la fois | De nombreux écrans, aucune ligne avec un résultat prouvé | Une ligne d'abord, puis un déploiement reproductible |
| Aucune référence de départ | Les résultats font débat en réunion | Deux semaines de données « avant » sur la ligne pilote |
| Alertes sans responsable | Notifications mises en sourdine en quelques semaines | Un rôle par alerte, plus une règle d'escalade |
| Codes de causes issus de l'ERP | « Autre » et « inconnu » en tête du Pareto | 10 à 15 causes formulées dans le langage de l'atelier, par type de machine |
| Un seul porteur | Le programme s'essouffle quand cette personne part | Standards documentés, rôles nommés avec suppléants, rythme de revue fixe |
Questions fréquentes
Comment savoir si notre système IoT n'est qu'un outil de reporting ?
Demandez-vous ce que vous avez changé dans le process le mois dernier grâce aux données. Si personne ne peut citer de changement, commencez par un contrat de décision pour une ligne.
Qui doit piloter un déploiement IoT en usine ?
La production doit posséder les résultats, à travers un responsable de ligne qui décide de ce qui compte et qui agit. L'IT et l'OT possèdent le réseau, les accès et la sécurité. Sans responsable côté production, le projet livre des tableaux de bord et peu de choses d'autre.
Peut-on corriger ces erreurs sur un système déjà en service ?
Oui. La plupart des corrections portent sur les décisions, les responsables et les listes de causes. Le matériel reste en général en place. Choisissez une ligne, définissez le contrat de décision, collectez une référence de deux semaines et reconstruisez la liste des causes avec les opérateurs.
Combien de lignes un premier déploiement IoT doit-il couvrir ?
Une seule. Prouvez le résultat là-bas, documentez le standard, puis déployez ligne par ligne.
Conclusion
Si l'IoT tourne déjà dans votre usine, parcourez le tableau ci-dessus pour une ligne, avec son responsable de ligne. Commencez par la première rangée : si personne ne peut citer un changement de process du mois dernier, rédigez le contrat de décision décrit à l'erreur 1 avant de modifier quoi que ce soit d'autre.
Vérifiez votre dispositif IoT face à ces sept erreurs
Réservez une démonstration de 30 minutes. Nous montrons comment DBR77 IIoT gère décisions, responsables et causes, et où votre dispositif actuel pourrait faire perdre de la valeur.
Sources
- DBR77, Enregistrements de la conférence ITM Industry Europe 2026 (en polonais), 2026
- McKinsey & Company, How digital manufacturing can escape "pilot purgatory", 2018
- McKinsey & Company, IoT value set to accelerate through 2030, 2021
- Forum économique mondial, These 10 new 'Lighthouse' factories show the future of manufacturing is here, 2020
- Vorne, The Six Big Losses, 2026
- Données pilote DBR77 IIoT, ligne de carton ondulé (client anonyme), 2026