Cas terrain : ce qu’on trouve quand on
Des analyses chirurgicales d’incidents tirées de situations réelles.
Pour chaque cas : la situation de départ, ce qui a été trouvé, et ce qui a changé concrètement.
Je ne nomme jamais un client : je dis seulement le secteur.
Les situations sont anonymisées et généralisées pour préserver la confidentialité des organisations concernées.
Industrie manufacturière, connectivité IIoT Quand l’ajout d’un équipement arrête toute la collecte
Résultat : Rétablissement complet de la collecte et élimination des pertes de données par collision d’adresses matérielles. Lire le cas Fermer le cas
Situation
Une usine disposait d’un boîtier IIoT pour remonter sa production. Lors de l’extension du parc, l’ensemble du système de collecte s’est brutalement arrêté sans explication apparente.
Ce qui était en jeu
- 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.
L’enquête
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.
La cause
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.
Ce qui a été fait
- 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.
Le résultat
- Rétablissement complet de la collecte et élimination des pertes de données par collision d’adresses matérielles.
- Plus aucune perte de données constatée depuis la correction.
- La procédure de contrôle a été intégrée au processus d’installation standard.
Secteur bancaire, interopérabilité applicative Quand un protocole propriétaire bloque toute nouvelle intégration
Résultat : Protocole rétro-conçu avec succès par analyse de trames (Wireshark) et dépendance éditeur éliminée. Lire le cas Fermer le cas
Situation
Une brique bancaire utilisait un protocole propriétaire non documenté imposé par un tiers : tout nouveau projet d’intégration était bloqué face au refus de coopérer de l’éditeur.
Ce qui était en jeu
- Impossibilité d’interfacer le système avec de nouveaux projets.
- Migration bloquée tant que la dépendance au protocole propriétaire n’était pas levée.
- Dépendance totale à un éditeur tiers sans alternative connue.
L’enquête
Aucune spécification du protocole n’était disponible, ni en interne ni auprès de l’éditeur.
La seule voie d’analyse consistait à observer le comportement réel du système en fonctionnement : capture et analyse des échanges réseau entre le client et le serveur d’origine.
La cause
Le protocole avait été conçu comme un mécanisme propriétaire, sans intention d’interopérabilité. Aucune documentation publique ni privée ne décrivait sa structure.
Toute intégration tierce dépendait donc entièrement de la bonne volonté et de la disponibilité de l’éditeur d’origine.
Ce qui a été fait
- Capture et analyse de la structure des trames échangées (Wireshark).
- Rétro-ingénierie du protocole : identification des champs, séquences et règles d’échange client/serveur.
- Développement d’une brique logicielle indépendante, interopérable, reproduisant le comportement du protocole d’origine.
- Validation du comportement face au système existant avant mise en production.
Le résultat
- Protocole rétro-conçu avec succès par analyse de trames (Wireshark) et dépendance éditeur éliminée.
- Une brique interopérable, maîtrisée en interne, remplace la dépendance à l’éditeur d’origine.
- La migration bloquée a pu reprendre sur les bases de cette nouvelle interopérabilité.
Industrie, infrastructure applicative critique Quand on ne peut plus toucher au serveur sereinement
Résultat : Fin de la peur d’intervenir : infrastructure déclarative versionnée et retour arrière instantané en cas d’erreur. Lire le cas Fermer le cas
Situation
Une application critique tournait sur une infrastructure modifiée au fil des ans sans documentation. Le départ de l’unique référent a transformé chaque intervention en roulette russe.
Ce qui était en jeu
- 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.
L’enquête
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.
La cause
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.
Ce qui a été fait
- 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.
Le résultat
- Fin de la peur d’intervenir : infrastructure déclarative versionnée et retour arrière instantané en cas d’erreur.
- Déploiements reproductibles, documentés par le code et traçables dans le temps.
- Réduction définitive du risque lié à la dépendance à une connaissance individuelle.
- L’équipe peut faire évoluer le système sans craindre de casser un état fragile.
Industrie, base de données de production Quand la base SQL ralentit la production sans raison apparente
Résultat : Temps d’exécution passés de plusieurs minutes à quelques secondes sur l’ensemble des requêtes critiques. Lire le cas Fermer le cas
Situation
Une base de données de production ralentissait de jour en jour : des requêtes simples prenaient plusieurs minutes, bloquant les équipes et forçant des exports manuels à répétition.
Ce qui était en jeu
- 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.
L’enquête
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 cause
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.
Ce qui a été fait
- 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.
Le résultat
- Temps d’exécution passés de plusieurs minutes à quelques secondes 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.
Industrie, acquisition et historisation de données machine Quand l’historisation industrielle perd des données en silence
Résultat : Traçabilité garantie à 100 % et zéro perte de données, même lors de micro-coupures réseau prolongées. Lire le cas Fermer le cas
Situation
L’historisation atelier présentait des trous inexpliqués : des plages horaires manquaient dans les rapports, menaçant la traçabilité des lots et la conformité des audits qualité.
Ce qui était en jeu
- 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é.
L’enquête
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.
La cause
Le composant de collecte ne gérait pas correctement les micro-coupures réseau. Lors d’une interruption brève, les données mises en tampon 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.
Ce qui a été fait
- Identification du comportement défaillant par simulation de coupures contrôlées.
- Mise en place d’un tampon local persistant avec un 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.
Le résultat
- Traçabilité garantie à 100 % et zéro perte de données, même lors de micro-coupures réseau prolongées.
- La traçabilité est désormais complète et exploitable pour les audits qualité.
Logistique, application terrain mobile Quand la saisie terrain doit fonctionner sans connexion
Résultat : Continuité opérationnelle intégrale : 100 % des saisies garanties hors ligne avec synchronisation automatique. Lire le cas Fermer le cas
Situation
En entrepôt logistique, le WiFi était instable sur de vastes zones : l’application bloquait les opérateurs à chaque déconnexion, interrompant les flux et le suivi des expéditions.
Ce qui était en jeu
- Saisies impossibles dans les zones non couvertes, quelle que soit leur durée.
- Interruption du travail des équipes en attente de connexion.
- Risque d’abandon de l’outil au profit de pratiques non tracées (papier, mémoire).
L’enquête
Une application classique, dépendante d’un aller-retour serveur à chaque saisie, ne répondait pas au besoin réel.
Il ne s’agissait pas d’améliorer la couverture réseau physique ni de rendre l’application simplement tolérante aux coupures, mais de concevoir un fonctionnement complet sans connexion, la synchronisation devenant une étape seconde et non une condition préalable à la saisie.
La cause
L’application existante n’avait pas été conçue pour un usage déconnecté : chaque saisie nécessitait un aller-retour immédiat avec le serveur.
Sur un site de grande surface où le réseau WiFi ne pouvait pas garantir une couverture totale, cette architecture rendait l’outil inutilisable par endroits.
Ce qui a été fait
- Développement d’une application PWA (Ionic) installable sur les terminaux des équipes.
- Stockage local des données sur SQLite embarqué : la saisie fonctionne intégralement sans connexion, pas seulement en cas de coupure brève.
- Mécanisme de synchronisation automatique des données dès le retour de la connexion, sans intervention manuelle.
- Tests de terrain dans les zones non couvertes pour valider le fonctionnement réel en usage hors ligne.
Le résultat
- Continuité opérationnelle intégrale : 100 % des saisies garanties hors ligne avec synchronisation automatique.
- Les données sont synchronisées automatiquement dès que la connexion revient, sans intervention manuelle.
- L’application reste pleinement utilisable sur l’ensemble du site, y compris dans les zones sans réseau.
Industrie, connectivité automate / supervision Quand l’automate S7 remonte des valeurs qui n’ont aucun sens
Résultat : Faux positifs et alarmes aberrantes éliminés à 100 % grâce à la correction de l’inversion d’octets. Lire le cas Fermer le cas
Situation
Un automate Siemens S7 remontait des températures négatives et des compteurs aberrants sur la supervision. Face au déluge d’alarmes fausses, les opérateurs ne surveillaient plus rien.
Ce qui était en jeu
- 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.
L’enquête
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.
La cause
Un problème de byte swapping (endianness) dans le nouveau pilote d’acquisition. L’automate Siemens S7 stocke les mots (WORD, DWORD) au format big-endian. Le nouveau pilote 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.
Ce qui a été fait
- Analyse des trames brutes acquises (Wireshark sur le flux S7comm) pour identifier l’inversion d’octets.
- Configuration du byte swapping dans le pilote d’acquisition (paramètre « swap » ou « endian » selon le pilote).
- 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 de l’ordre des octets après chaque changement de pilote ou de firmware.
Le résultat
- Faux positifs et alarmes aberrantes éliminés à 100 % grâce à la correction de l’inversion d’octets.
- 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 de l’ordre des octets est désormais systématique.
Industrie manufacturière, intégration ERP / MES Quand l’ERP et l’atelier vivent dans des réalités parallèles
Résultat : Élimination de 100 % des erreurs de saisie et suppression des réconciliations manuelles quotidiennes. Lire le cas Fermer le cas
Situation
Les stocks ERP divergeaient des quantités réelles en atelier : données faussées, décisions risquées et réconciliations manuelles mobilisant plusieurs personnes chaque soir.
Ce qui était en jeu
- 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.
L’enquête
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.
La cause
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.
Ce qui a été fait
- 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é.
Le résultat
- Élimination de 100 % des erreurs de saisie et suppression des réconciliations manuelles quotidiennes.
- Les équipes de gestion et de production travaillent sur une source de données unique et fiable.
- Plusieurs heures de travail opérateur réaffectées chaque jour à des tâches à valeur ajoutée.
Industrie, continuité de service Quand les sauvegardes n’ont jamais été testées
Résultat : Dispositif de sauvegarde cohérent et plan de reprise d’activité (PRA) validé par test réel sur machine isolée. Lire le cas Fermer le cas
Situation
Les sauvegardes s’exécutaient sans erreur apparente depuis des années, jusqu’au crash matériel où la restauration a révélé que les archives étaient toutes corrompues.
Ce qui était en jeu
- 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.
L’enquête
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.
La cause
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.
Ce qui a été fait
- 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é.
Le résultat
- Dispositif de sauvegarde cohérent et plan de reprise d’activité (PRA) validé par test réel sur machine isolée.
- 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.
Industrie, infrastructure critique Quand le serveur critique ne peut plus être restauré
Résultat : Migration réussie vers un environnement virtuel reproductible, reconstructible en quelques heures en cas d’incident. Lire le cas Fermer le cas
Situation
Sur un serveur critique vieillissant, la migration a révélé l’impasse : dépendances inconnues, configurations perdues et impossibilité totale de restaurer l’environnement en cas de panne.
Ce qui était en jeu
- 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.
L’enquête
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.
La cause
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.
Ce qui a été fait
- 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.
Le résultat
- Migration réussie vers un environnement virtuel reproductible, reconstructible en quelques heures en cas d’incident.
- 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.
Industrie, application métier interne Quand l’interface métier est devenue un obstacle
Résultat : Fin définitive des doubles saisies papier et tableur, adoption immédiate par 100 % des opérateurs. Lire le cas Fermer le cas
Situation
Devenue lente et inadaptée aux postes atelier, l’interface de production ralentissait les équipes, forçant les opérateurs à multiplier les contournements sauvages sur papier et tableurs.
Ce qui était en jeu
- 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.
L’enquête
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é).
La cause
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.
Ce qui a été fait
- 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.
Le résultat
- Fin définitive des doubles saisies papier et tableur, adoption immédiate par 100 % des opérateurs.
- 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é.
Industrie, architecture de collecte temps réel Quand le flux MQTT sature et que les données disparaissent
Résultat : Zéro perte de message constatée depuis la correction, y compris lors des cadences maximales de production. Lire le cas Fermer le cas
Situation
Un système de collecte MQTT perdait des messages à chaque pic de production. L’anomalie était invisible en direct et n’apparaissait qu’a posteriori lors de l’analyse des historiques.
Ce qui était en jeu
- 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.
L’enquête
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.
La cause
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.
Ce qui a été fait
- 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 du broker avec alertes sur saturation.
- Mise en place de contrôles de séquence pour détecter les lacunes en temps réel.
Le résultat
- Zéro perte de message constatée depuis la correction, y compris lors des cadences maximales de production.
- Les lacunes sont désormais détectées en temps réel avant d’impacter les historiques.
- La supervision du broker permet d’anticiper les montées en charge.
Une de ces situations vous parle ?
Prenez un échange préalable de 15 minutes en visio ou par téléphone, ou décrivez votre situation par écrit : je vous dis si je peux vous aider, et si ce n’est pas le cas, je vous le dis aussi.