Aller au contenu
Inspection sur site

Comment conserver en toute sécurité les enregistrements de contrôle périodique sans Internet ?

Rédaction VizyonTech 6 minutes de lecture Tous les articles inspection sur site
Un spécialiste en équipement de protection tient un enregistrement de contrôle périodique sur tablette sur un site industriel sans Internet

Guide pratique pour collecter sans perte les données de contrôle périodique sur un site sans Internet, surveiller la file d'envoi et synchroniser sans doublon à la reconnexion.

Réponse courte : comment tenir l'enregistrement de contrôle sans Internet ?

Enregistrez le formulaire de contrôle dans une base de données locale transactionnelle sur l'appareil ; donnez à chaque enregistrement un identifiant de transaction unique, maintenez visible l'état d'envoi et, au retour de la connexion, réconciliez avec le serveur sans générer de doublon.

En mode hors ligne, « enregistré » n'est pas un état unique. À l'utilisateur, les états enregistré sur l'appareil, en attente d'envoi, accepté par le serveur et revue requise doivent être affichés séparément. Ainsi, en connexion faible, le fait que le formulaire apparaisse à l'écran ne laisse pas croire qu'il est parvenu au centre.

Quelles données charger sur l'appareil avant de partir sur le terrain ?

Réponse courte : ne charger que le paquet de données à jour et autorisé, nécessaire à l'achèvement de la mission assignée.

  • L'ordre de travail et l'identité immuable de l'équipement
  • La version figée du formulaire de contrôle lié au type d'équipement
  • Les critères de contrôle requis et les listes de sélection
  • Le périmètre de mission du personnel affecté et les références d'appareils
  • L'heure de dernière synchronisation et la version du paquet

La spécification W3C Service Workers explique qu'il est possible de construire des applications web hors ligne avec un worker interceptant les requêtes et un magasin local requête/réponse. Dans le flux VizyonTech, l'équivalent n'est pas de mettre en cache la seule coquille de page, mais de préparer avant le terrain, sous forme de paquet vérifié, les formulaires et données de référence de la mission assignée.

Si le paquet n'est pas à jour, l'application ne doit pas ouvrir silencieusement l'ancien formulaire. L'heure de dernière synchronisation, la version du formulaire et la limite d'utilisation hors ligne doivent être visibles ; si des données de référence critiques manquent, la création de l'enregistrement doit être bloquée selon le principe fail-closed. Vous pouvez voir comment la relation entre ordre de travail, équipement et formulaire est établie dans le guide du plan de contrôles périodiques .

Comment le formulaire doit-il être enregistré sur l'appareil ?

Réponse courte : écrivez chaque modification de champ non pas dans la mémoire d'écran temporaire, mais dans une transaction locale courte et atomique.

Le brouillon W3C IndexedDB 3.0 définit, pour les besoins web hors ligne, le stockage local d'objets structurés et des transactions écrites entièrement ou annulées en cas d'erreur. Sur le formulaire terrain, cela signifie écrire la valeur de mesure, l'unité, la description, le lien photo et l'heure d'enregistrement dans une version de brouillon cohérente.

ChampPourquoi le conserver ?Contrôle
Identifiant de transactionEmpêche l'enregistrement en double lors de la répétition d'un même envoiGénéré une seule fois sur l'appareil, immuable
Version localeOrdonne chaque modificationIncrémentée après un commit réussi
Heure de création/modificationExplique l'ordre des événementsL'horloge de l'appareil et l'heure d'acceptation du serveur sont conservées séparément
Version du formulaireConserve les critères appliquésFiguée à l'ouverture de l'intervention
État de la fileDistingue l'enregistrement de la remiseLocal, en attente, envoi en cours, accepté, erreur
Lien du fichier jointAssocie la photo au bon enregistrementL'empreinte du fichier et la référence locale sont vérifiées

Le bouton Enregistrer ne doit afficher un succès que lorsque la transaction locale est achevée. La fermeture de l'application, l'épuisement de la batterie ou le retour fugace du réseau ne doivent pas faire passer un formulaire inachevé à l'état « envoyé ».

Un spécialiste en équipement de protection vérifie les enregistrements terrain hors ligne sur tablette
Même si l'enregistrement local est achevé, l'acceptation par le serveur est suivie séparément ; au retour de la connexion, la file est envoyée de manière contrôlée.

Comment réaliser la synchronisation au retour de la connexion ?

Réponse courte : envoyez la file dans l'ordre, réessayez chaque élément avec le même identifiant de transaction et ne marquez comme terminé qu'après la réponse d'acceptation explicite du serveur.

  1. Ne vérifiez pas seulement la présence de la connexion, mais l'accès au serveur d'applications.
  2. Revérifiez l'intégrité locale de l'enregistrement dans la file et ses champs obligatoires.
  3. Envoyez l'enregistrement et ses pièces jointes avec l'identifiant de transaction immuable et la version locale.
  4. Laissez le serveur exécuter les contrôles d'autorisation, d'ordre de travail, de version de formulaire et de version d'enregistrement actuelle.
  5. En cas d'acceptation réussie, écrivez sur l'appareil l'identifiant d'enregistrement du serveur et l'heure d'acceptation.
  6. Distinguez l'erreur temporaire, soumise à une nouvelle tentative contrôlée, de l'erreur de validation définitive, renvoyée à la revue humaine.

La RFC 9110 explique qu'une requête idempotente peut être répétée après une erreur de connexion avec le même effet attendu. Pour l'enregistrement de contrôle périodique, le nom de la méthode ne suffit pas : le serveur ne doit pas ajouter comme nouveau rapport une seconde requête portant la même clé de transaction ; il doit renvoyer le résultat de l'acceptation précédente.

L'API Background Synchronization peut différer la tâche vers un service worker au retour de la connexion ; toutefois MDN la signale comme une fonctionnalité sans large prise en charge par les navigateurs. C'est pourquoi la file ne doit pas dépendre du seul événement d'arrière-plan ; elle doit aussi fonctionner de manière fiable à l'ouverture de l'application et lors de l'action « envoyer maintenant » de l'utilisateur.

Que se passe-t-il si le même enregistrement est modifié sur deux appareils ?

Réponse courte : n'appliquez pas l'approche du dernier écrivain gagne aux champs de mesure et de conformité ; suspendez le conflit de version et présentez les deux modifications à l'utilisateur autorisé.

Si la version sur le serveur est en avance sur la version de base reçue par l'appareil au début de l'intervention, un écrasement automatique peut entraîner une perte de données. Les champs non conflictuels peuvent être fusionnés de manière contrôlée ; si la même mesure, le même résultat ou une description critique a changé des deux côtés, l'enregistrement doit passer à l'état revue requise .

  • Comparez la version du serveur avec la version de base de l'appareil.
  • Conservez dans la piste d'audit les champs modifiés et les acteurs.
  • Ne remplacez pas silencieusement un rapport publié par un brouillon hors ligne.
  • Enregistrez la résolution du conflit dans une nouvelle révision avec justification.
  • Indiquez clairement à l'utilisateur sur quel appareil se trouve l'enregistrement en attente.

Comment protéger les données hors ligne sur l'appareil ?

Réponse courte : ne téléchargez que les données nécessaires, protégez les données locales avec le stockage sécurisé de la plateforme et appliquez un nettoyage contrôlé lié au cycle de vie de l'appareil et de la session.

OWASP MASVS-STORAGE-1 exige un stockage sécurisé des données sensibles quel que soit leur emplacement sur l'appareil. MASWE-0006 recommande de ne pas conserver localement de données sensibles inutiles, de protéger les clés dans le trousseau sécurisé de la plateforme et d'utiliser un chiffrement approprié.

  • N'embarquez dans le paquet hors ligne que la mission assignée, et non toute l'archive client.
  • Protégez le jeton de session, les données personnelles, les photos et les pièces jointes de mesure selon leur classe de données.
  • Ne conservez pas la clé de chiffrement à côté du fichier de données ni dans le code source.
  • Testez les scénarios de perte d'appareil, de changement d'utilisateur et de révocation d'habilitation.
  • Purgez en toute sécurité les pièces jointes locales déjà envoyées conformément à la politique de conservation.
  • N'écrivez pas d'enregistrements sensibles dans un espace de fichiers partagé ou dans une sauvegarde non maîtrisée.

Le fonctionnement hors ligne ne supprime pas le contrôle d'autorisation. Même si l'appareil a été précédemment autorisé, le serveur doit revérifier l'utilisateur, l'organisation, l'ordre de travail et la version du formulaire lors de la synchronisation.

Quels scénarios tester avant la mise en production ?

Réponse courte : le test en mode avion ne suffit pas ; il faut prouver que la coupure survient à chaque étape de l'enregistrement et que la nouvelle tentative ne génère aucun doublon.

  1. L'application s'ouvre-t-elle lors d'une première ouverture hors ligne, ou signale-t-elle correctement un manque de préparation ?
  2. Si l'application se ferme pendant la saisie d'un champ, la dernière transaction locale achevée est-elle conservée ?
  3. Si la connexion se coupe pendant le téléversement d'une photo, le lien entre le formulaire et la pièce jointe est-il rompu ?
  4. Si le serveur accepte l'enregistrement mais que la réponse n'atteint pas l'appareil, le renvoi ouvre-t-il un second enregistrement ?
  5. Lorsque la version du formulaire change au central, comment l'ancienne intervention hors ligne est-elle arbitrée ?
  6. Lorsque la même intervention est modifiée sur deux appareils, le conflit sur un champ critique est-il suspendu ?
  7. Un utilisateur dont l'habilitation a été révoquée voit-il son envoi refusé et son enregistrement conservé lors de la reconnexion ?
  8. Lorsque la file attend plusieurs jours, l'utilisateur peut-il comprendre quels enregistrements ne sont pas au central ?

Vizyon Periyodik dans l'évaluation, la fonctionnalité hors ligne ne doit pas être testée par la seule démonstration « le formulaire s'ouvre » ; le commit local, la file visible, l'acceptation idempotente, la gestion des conflits et la sécurité de l'appareil doivent être testés ensemble. Pour les autres contrôles fail-closed dans le choix du logiciel, consultez le guide de choix d'un logiciel de contrôles périodiques vous pouvez l’examiner.

Sources

  1. W3C — Service Workers (agents de service) (Candidate Recommendation Draft, 8 juin 2026).
  2. W3C — API de base de données indexée 3.0 (Working Draft, 13 août 2025).
  3. Android Developers — Créer une application conçue pour fonctionner hors ligne (consulté le 11 août 2026).
  4. IETF — RFC 9110, HTTP Semantics : méthodes idempotentes (juin 2022).
  5. OWASP — MASVS-STORAGE-1 : Stockage sécurisé (consulté le 11 août 2026).
  6. MDN — API de synchronisation en arrière-plan (consulté le 11 août 2026 ; prise en charge limitée par les navigateurs).

Les champs à conserver hors ligne doivent en outre être validés selon la classification des données de l'organisation, la politique d'appareils, le périmètre de mission et la plateforme client prise en charge par le produit.

Rédaction VizyonTech L'équipe de contenu technique VizyonTech
02 — Poursuivre la lecture

Articles techniques connexes.

D'autres guides VizyonTech que vous pouvez utiliser pour décider dans le même processus.

Numérisons ce processus selon votre équipe.

Nous pouvons écouter votre flux opérationnel réel et clarifier ensemble la solution VizyonTech adaptée.