Cas terrain C'PRAG
10 autopsies techniques tirées de situations réelles rencontrées sur le terrain.
01 — Quand l'ajout d'un équipement arrête toute la collecte
Industrie manufacturière — Connectivité IIoT
Une usine disposait d'un boîtier IIoT assurant la remontée des données de production depuis plusieurs mois. Lors de l'extension du parc avec des équipements de la même série, l'ensemble du système de collecte a cessé de fonctionner correctement.
Les nouveaux équipements semblaient correctement configurés. Les adresses IP étaient distinctes. Les tests réseau classiques ne révélaient aucune anomalie. Le problème apparaissait de manière intermittente, rendant le diagnostic difficile à reproduire.
Les nouveaux boîtiers provenaient de la même série de fabrication que l'équipement déjà installé. Ils partageaient la même adresse MAC gravée en usine. Le switch réseau recevait des informations contradictoires sur la localisation physique des équipements, provoquant des collisions silencieuses.
Perte de visibilité sur la production en temps réel.
Données manquantes sur les indicateurs de performance.
Temps perdu à chercher un défaut logiciel ou réseau inexistant.
Identification du conflit au niveau Ethernet par analyse des tables ARP.
Reconfiguration des identifiants matériels sur les équipements concernés.
Vérification systématique de l'ensemble du parc pour détecter d'éventuels doublons.
Mise en place d'une procédure de contrôle lors de l'intégration de tout nouvel équipement réseau.
Retour à un fonctionnement normal de la collecte.
Zéro perte de données depuis la correction.
La procédure de contrôle a été intégrée au processus d'installation standard.
02 — Quand plus personne n'ose toucher au serveur
Industrie — Infrastructure applicative critique
Une application métier critique fonctionnait sur une infrastructure ayant évolué pendant plusieurs années. Les configurations avaient été modifiées progressivement, sans documentation centralisée. Le seul référent technique avait quitté l'entreprise.
La documentation existante ne reflétait plus la réalité du système. Une partie des composants avait été installée manuellement sans traçabilité. Certaines dépendances n'étaient connues que par habitude opérationnelle accumulée.
L'infrastructure reposait entièrement sur des opérations manuelles accumulées au fil des années. L'état réel du système n'était décrit nulle part de manière fiable. Toute intervention devenait une prise de risque non maîtrisée.
Dépendance totale à une connaissance individuelle disparue.
Impossibilité de reproduire l'environnement en cas d'incident.
Risque élevé lors de toute mise à jour ou intervention.
Temps de reprise inconnu après incident.
Audit complet de l'existant pour cartographier les composants réels.
Migration vers une infrastructure décrite intégralement de manière déclarative.
Chaque composant, service et dépendance est devenu traçable et versionné.
Les environnements peuvent être reconstruits à l'identique depuis la configuration.
Déploiements reproductibles et documentés par construction.
Retour arrière quasi immédiat en cas d'erreur.
Réduction du risque lié à la connaissance individuelle.
L'équipe peut intervenir sans craindre de casser un état fragile non documenté.
03 — Quand la base SQL ralentit la production sans raison apparente
Industrie — Base de données de production
Une base de données utilisée quotidiennement par les équipes de production et les outils métier présentait des ralentissements progressifs. Les requêtes qui s'exécutaient en quelques secondes prenaient désormais plusieurs minutes. Les utilisateurs contournaient le problème en exportant les données manuellement.
Aucune modification applicative récente n'expliquait la dégradation. Le volume de données avait augmenté progressivement. Les plans d'exécution révélaient des scans complets de tables volumineuses sur des requêtes fréquentes. Certains index n'avaient jamais été mis à jour depuis la mise en production initiale.
La base avait été conçue pour un volume de données initial. Avec la croissance des données, l'absence d'indexation adaptée et de maintenance régulière avait transformé des requêtes simples en opérations coûteuses. La fragmentation des index atteignait des niveaux critiques.
Décisions de production prises sur des données en retard.
Perte de confiance des équipes dans les outils métier.
Risque de corruption ou d'incohérence par accumulation de contournements manuels.
Analyse des plans d'exécution sur les requêtes les plus fréquentes.
Refonte de l'indexation sur les tables critiques.
Mise en place d'une maintenance régulière automatisée.
Réécriture de plusieurs requêtes présentant des jointures non optimisées.
Retour à des temps de réponse acceptables sur l'ensemble des requêtes critiques.
Les contournements manuels ont été supprimés.
Un plan de maintenance préventive a été mis en place pour éviter la récurrence.
04 — Quand l'historisation industrielle perd des données en silence
Industrie — Acquisition et historisation de données machine
Un système d'historisation collectait les données de production depuis les machines de l'atelier. Les rapports de production présentaient des lacunes inexpliquées. Certaines plages horaires apparaissaient vides alors que la production avait bien eu lieu.
Le système de collecte semblait fonctionner normalement en surface. Les logs ne signalaient aucune erreur critique. Les lacunes apparaissaient de manière aléatoire, sans corrélation évidente avec des événements réseau ou machine.
Le composant de collecte ne gérait pas correctement les micro-coupures réseau. Lors d'une interruption brève, les données tamponnées localement étaient perdues au lieu d'être rejouées. Le mécanisme de reprise après coupure n'avait jamais été testé en conditions réelles.
Indicateurs de performance faussés.
Traçabilité incomplète sur des lots de production.
Impossibilité de reconstituer l'historique en cas de litige ou d'audit qualité.
Identification du comportement défaillant par simulation de coupures contrôlées.
Mise en place d'un buffer local persistant avec mécanisme de rejeu fiable.
Ajout de contrôles d'intégrité sur les séquences temporelles collectées.
Tests de reprise systématiques intégrés à la procédure de validation.
Zéro perte de données depuis la correction, y compris lors des coupures réseau.
La traçabilité est désormais complète et exploitable pour les audits qualité.
05 — Quand l'automate S7 remonte des valeurs qui n'ont aucun sens
Industrie — Connectivité automate / supervision
Un automate Siemens S7 remontait des valeurs de température et de compteurs complètement incohérentes sur la nouvelle supervision : températures négatives impossibles, compteurs qui repartaient à zéro aléatoirement, états binaires inversés. Les opérateurs avaient pris l'habitude d'ignorer certaines alarmes.
L'automate fonctionnait correctement en local : l'IHM TIA Portal affichait les bonnes valeurs. Le problème apparaissait uniquement après la migration vers le nouveau serveur d'acquisition. Les données arrivaient bien sur le serveur, mais avec des valeurs aberrantes. Aucune modification du réseau ni de l'automate.
Un problème de byte swapping (endianness) dans le nouveau driver d'acquisition. L'automate Siemens S7 stocke les mots (WORD, DWORD) au format big-endian. Le nouveau driver lisait les valeurs en little-endian, interprétant les octets dans le mauvais ordre. Résultat : les mots de 16 bits donnaient des valeurs doubles, les doubles mots de 32 bits des valeurs incohérentes, et les bits individuels tombaient sur le mauvais octet.
Perte de confiance dans le système de supervision.
Alarmes ignorées par habitude, y compris les alarmes réelles.
Risque de décision de production basée sur des données erronées.
Analyse des trames brutes acquises (wireshark sur le flux S7comm) pour identifier l'inversion d'octets.
Configuration du byte swapping dans le driver d'acquisition (paramètre 'swap' ou 'endian' selon le driver).
Validation sur un jeu de variables connues (température fixe, compteur séquentiel, état binaire forcé).
Écriture d'une procédure de test systématique du byte ordering après chaque changement de driver ou de firmware.
Les valeurs supervisées sont cohérentes avec la réalité terrain.
Les opérateurs ont retrouvé confiance dans le système d'alarmes.
Le taux d'acquittement sans vérification physique a été réduit à zéro.
La procédure de validation du byte ordering est désormais systématique.
06 — Quand l'ERP et l'atelier vivent dans des réalités parallèles
Industrie manufacturière — Intégration ERP / MES
Les stocks affichés dans l'ERP présentaient des écarts réguliers avec les quantités réelles en atelier. Les équipes de production et les équipes administratives travaillaient sur des données différentes. Les réconciliations manuelles en fin de journée mobilisaient plusieurs personnes.
Deux systèmes alimentaient les mêmes données sans synchronisation fiable. Les saisies manuelles introduisaient des délais et des erreurs. Certains événements atelier (rebuts, retouches, arrêts) n'étaient pas remontés dans l'ERP. La fréquence de synchronisation était insuffisante pour les besoins opérationnels.
L'intégration entre l'atelier et l'ERP reposait sur des exports manuels planifiés. Toute interruption du processus manuel créait un écart non détecté. Il n'existait aucun mécanisme de contrôle de cohérence entre les deux systèmes.
Décisions d'approvisionnement basées sur des données fausses.
Temps opérateur consommé par des saisies redondantes.
Risque d'erreur de livraison ou de rupture non anticipée.
Cartographie complète des flux de données entre atelier et ERP.
Mise en place d'une synchronisation automatique en temps réel sur les événements critiques.
Suppression des saisies redondantes sur le périmètre concerné.
Ajout de contrôles de cohérence avec alertes en cas d'écart détecté.
Écarts de stock réduits à zéro sur le périmètre synchronisé.
Les réconciliations manuelles quotidiennes ont été supprimées.
Les équipes travaillent sur une source de données unique et fiable.
07 — Quand les sauvegardes n'ont jamais été testées
Industrie — Continuité de service
Une entreprise disposait d'un système de sauvegarde en place depuis plusieurs années. Les sauvegardes s'exécutaient quotidiennement sans erreur apparente. Lors d'un incident matériel, la tentative de restauration a révélé que les sauvegardes étaient inutilisables.
Les fichiers de sauvegarde existaient et semblaient complets. La procédure de restauration n'avait jamais été exécutée en conditions réelles. Les sauvegardes incluaient des fichiers verrouillés par les applications en cours d'exécution, rendant les archives corrompues.
Le système de sauvegarde capturait les fichiers à chaud sans mécanisme de cohérence applicative. Les bases de données n'étaient pas mises en état cohérent avant la sauvegarde. Aucune procédure de test de restauration n'avait été définie ni planifiée.
Perte définitive de données de production sur plusieurs mois.
Arrêt prolongé de l'activité le temps de reconstruire l'environnement.
Fausse sécurité ayant conduit à ne pas prendre d'autres précautions.
Audit complet du dispositif de sauvegarde existant.
Mise en place de sauvegardes cohérentes avec arrêt applicatif contrôlé ou snapshots transactionnels.
Définition et documentation d'une procédure de restauration testée.
Planification de tests de restauration réguliers sur environnement isolé.
Dispositif de sauvegarde fiable et testé.
La durée de restauration est désormais connue et maîtrisée.
L'entreprise dispose d'une réelle capacité de reprise après incident, et non d'une illusion de sécurité.
08 — Quand le serveur critique ne peut plus être restauré
Industrie — Infrastructure critique
Un serveur hébergeant plusieurs applications métier critiques présentait des signes de vieillissement. Une tentative de migration vers un nouveau matériel a révélé que l'environnement ne pouvait pas être reproduit : dépendances inconnues, licences introuvables, configurations perdues.
L'environnement avait été construit progressivement sur plusieurs années. Aucune documentation ne décrivait l'état réel du système. Certains composants avaient été installés manuellement sans traçabilité. Des dépendances implicites entre applications n'étaient connues que par observation.
L'absence de documentation et de gestion de configuration avait rendu le système opaque. La connaissance de l'environnement était distribuée entre plusieurs personnes qui n'étaient plus toutes disponibles. Aucune procédure de migration ou de reprise n'avait jamais été préparée.
Blocage total de la migration.
Impossibilité de reprendre l'activité sur un nouveau matériel en cas de panne.
Dépendance à un matériel obsolète sans alternative connue.
Inventaire exhaustif des composants, services et dépendances réels.
Documentation de l'architecture existante avant toute intervention.
Reconstruction progressive de l'environnement sur nouveau matériel avec validation à chaque étape.
Mise en place d'une gestion de configuration pour éviter la récurrence.
Migration réussie vers un environnement documenté et reproductible.
Le nouveau serveur peut être reconstruit depuis la configuration en cas d'incident.
La dépendance au matériel obsolète a été supprimée.
09 — Quand l'interface métier est devenue un obstacle
Industrie — Application métier interne
Une interface utilisée quotidiennement par les équipes de production avait été développée plusieurs années auparavant. Elle était devenue lente, difficile à utiliser sur les postes de l'atelier et ne correspondait plus aux processus réels. Les opérateurs avaient développé des contournements parallèles sur papier ou tableur.
L'interface avait été conçue pour un processus initial qui avait évolué. Les ajouts successifs avaient complexifié la navigation sans refonte globale. Les performances s'étaient dégradées avec l'augmentation du volume de données. L'interface n'avait pas été adaptée aux contraintes des postes atelier (écrans tactiles, gants, luminosité).
Absence de maintenance évolutive et de recueil des besoins terrain. L'outil avait été livré puis abandonné sans suivi. Les utilisateurs avaient adapté leurs pratiques à l'outil plutôt que l'inverse.
Données saisies en double ou non saisies.
Perte de traçabilité sur les opérations non enregistrées.
Temps opérateur consommé par des interfaces inadaptées.
Risque d'abandon total de l'outil au profit de pratiques non contrôlées.
Recueil des usages réels et des contournements existants.
Refonte de l'interface centrée sur les flux opérateurs réels.
Optimisation des performances sur les écrans et requêtes critiques.
Adaptation aux contraintes physiques des postes atelier.
Suppression des contournements papier et tableur.
Taux de saisie en temps réel significativement amélioré.
Les opérateurs utilisent l'outil sans friction sur l'ensemble du périmètre concerné.
10 — Quand le flux MQTT sature et que les données disparaissent
Industrie — Architecture de collecte temps réel
Un système de collecte de données machine reposant sur MQTT présentait des pertes de messages lors des pics de production. Les données manquantes n'étaient pas détectées en temps réel. Les anomalies n'apparaissaient qu'a posteriori lors de l'analyse des historiques.
Le broker MQTT était correctement configuré en apparence. Les clients publiaient sans erreur signalée. L'analyse des séquences temporelles révélait des lacunes systématiques aux mêmes plages horaires, correspondant aux pics de cadence machine.
Le broker était sous-dimensionné pour le volume de messages générés en pic de production. La configuration QoS utilisait le niveau 0 (fire and forget) sur des topics critiques. Les messages perdus lors de la saturation n'étaient ni détectés ni rejoués. Aucune supervision du broker n'était en place.
Historique de production incomplet sur les périodes de forte activité.
Indicateurs de performance calculés sur des données partielles.
Absence de détection en temps réel des pertes, rendant le problème invisible.
Audit de la configuration QoS sur l'ensemble des topics.
Migration des topics critiques vers QoS 1 avec accusé de réception.
Redimensionnement du broker et mise en place d'une file de persistance.
Ajout d'une supervision des métriques broker avec alertes sur saturation.
Mise en place de contrôles de séquence pour détecter les lacunes en temps réel.
Zéro perte de message depuis la correction, y compris en pic de production.
Les lacunes sont désormais détectées en temps réel avant d'impacter les historiques.
La supervision broker permet d'anticiper les montées en charge.