Sommaire
2. Mesures de sécurité intégrées
2.1 Chiffrement des données au repos
2.2 Phrase de récupération des sauvegardes
2.3 Protection contre la capture d’écran
2.4Détection d’appareil compromis (root/jailbreak)
3. Consignes relatives aux sauvegardes
3.2 Sauvegardes automatiques locales – transfert hors appareil
4. Points d’attention pour l’AIPD
1. Architecture technique
Application hors-ligne, fonctionnant exclusivement sur tablette (iOS/Android), sans synchronisation ni sauvegarde vers un service distant.
- Aucune donnée n’est transmise à un serveur, un cloud ou un service tiers : l’application ne contient aucun appel réseau applicatif, aucun SDK d’analytics ni de reporting de plantages (pas de Firebase, Sentry, Crashlytics ou équivalent).
- Toutes les données (personnes accompagnées, situations, protocoles, notes) sont stockées localement sur l’appareil, dans un espace de stockage privé propre à l’application (stockage AsyncStorage, géré par la bibliothèque redux-persist).
- L’accès à l’application est protégé par un verrou biométrique ou code de l’appareil à chaque ouverture/retour au premier plan.
- Deux mécanismes de sauvegarde existent, tous deux strictement locaux :
- une sauvegarde automatique (la version la plus récente, écrasant la précédente), dont l’emplacement exact dépend de la plateforme (voir § 3.2),
- un export manuel déclenché par l’utilisateur (voir § 3).
- Aucune donnée n’existe en clair hors de la RAM de l’application : tout ce qui est écrit sur le disque de l’appareil (base de données de l’app et sauvegardes) est chiffré (voir § 2).
Conséquence pour l’AIPD : la surface d’exposition se limite à l’appareil physique lui-même (perte, vol, accès non autorisé à la tablette), il n’y a pas de risque de fuite via un tiers hébergeur, une API ou un flux réseau, puisqu’aucun de ces éléments n’existe dans l’architecture.
2. Mesures de sécurité intégrées
2.1 Chiffrement des données au repos
- L’intégralité de la base de données locale de l’application est chiffrée avec AES, avec une clé de 256 bits.
- Cette clé de chiffrement est générée aléatoirement à la première utilisation (source d’aléa cryptographique du système), puis stockée dans un coffre-fort matériel dédié aux données sensibles, séparé du stockage applicatif classique et fourni nativement par le système d’exploitation (Keychain iOS / Keystore Android), jamais dans le stockage applicatif classique, jamais exportable en clair.
- L’accès à cette clé est lui-même conditionné à une authentification biométrique ou par code de verrouillage de l’appareil à chaque lecture (empreinte, reconnaissance faciale, ou code de déverrouillage), ce qui ajoute une couche de protection indépendante du chiffrement.
- Si l’appareil ne dispose d’aucun code de verrouillage configuré, l’application refuse de démarrer plutôt que de stocker une clé non protégée. Ce refus déclenche un message explicite à l’écran « Configurez un code de verrouillage sur cet appareil pour pouvoir utiliser l’application », avec la possibilité de réessayer une fois le code configuré.
2.2 Phrase de récupération des sauvegardes
- Les sauvegardes automatiques locales (§ 1) sont chiffrées avec une phrase de récupération distincte de la clé principale, générée elle aussi de façon aléatoire et cryptographiquement sûre.
- Cette phrase est composée de 20 caractères (5 groupes de 4), tirés dans un alphabet de 31 caractères sans ambiguïté de lecture (exclusion des caractères visuellement confondables comme 0/O ou 1/I/L), pour un total d’environ 100 bits d’entropie.
- Elle est indépendante de la clé Keychain : ce choix est délibéré, car la clé Keychain est supprimée par le système lors d’une désinstallation, alors que cette phrase, notée par l’utilisateur en dehors de l’appareil, permet de restaurer les données après réinstallation.
- Cette phrase n’est affichée qu’une seule fois à l’utilisateur, à charge pour lui de la conserver en lieu sûr (hors de l’appareil).
2.3 Protection contre la capture d’écran
Android : l’affichage de l’application est marqué comme protégé au niveau du système d’exploitation (indicateur FLAG_SECURE). Toute tentative de capture d’écran ou d’enregistrement d’écran (par une autre application, ou via les fonctions natives de l’appareil) est bloquée par le système pendant que l’application est affichée. L’aperçu de l’application dans le sélecteur de tâches multitâche (« Recents ») n’affiche pas non plus le contenu réel.
iOS : Apple ne permet à aucune application tierce de bloquer techniquement la capture d’écran (limitation du système d’exploitation, pas de l’application). L’application masque néanmoins le contenu affiché derrière un voile opaque dès qu’elle quitte le premier plan, pour empêcher que l’instantané généré par le système pour le sélecteur d’applications multitâche n’expose des données en clair.
Conséquence pour l’AIPD : sur Android, le risque de capture d’écran non autorisée est neutralisé techniquement. Sur iOS, ce risque reste une mesure organisationnelle à documenter côté structure partenaire (ex. : ne pas laisser la tablette sans surveillance pendant une consultation), l’application ne pouvant pas s’en prémunir techniquement sur cette plateforme.
2.4Détection d’appareil compromis (root/jailbreak)
Au démarrage, l’application vérifie si le système d’exploitation de l’appareil a été modifié en profondeur (root sur Android, jailbreak sur iOS). Ce type de modification contourne les protections natives du système sur lesquelles reposent le chiffrement et le stockage sécurisé de la clé (§ 2.1). Une modification aussi profonde du système ne peut pas être neutralisée par l’application elle-même, seulement détectée.
Si l’appareil est détecté comme compromis, l’application refuse de démarrer et affiche un message explicite, avant tout accès aux données ou à la clé de chiffrement.
Limite de cette détection : elle vise une modification non autorisée du système (root/jailbreak). Elle ne détecte pas, et n’a pas vocation à détecter, un appareil enrôlé dans une solution de gestion de flotte (MDM/EMM) : il s’agit d’un mécanisme légitime du système d’exploitation, distinct d’une compromission technique, qui accorde néanmoins des privilèges élevés à l’administrateur de la solution voir § 5.
2.5 Résumé des garanties
| Élément | Mécanisme |
| Stockage principal des données | AES-256, clé aléatoire en enclave sécurisée (Keychain/Keystore) |
| Accès à la clé de chiffrement | Authentification biométrique / code appareil obligatoire |
| Sauvegardes automatiques locales | AES, phrase de récupération à environ 100 bits d’entropie, indépendante de la clé principale |
| Export manuel de sauvegarde | Archive ZIP chiffrée AES-256, mot de passe choisi par l’utilisateur |
| Transmission réseau Capture d’écran / enregistrement d’écran Appareil root/jailbreak | Aucune, application strictement hors-ligne Bloqué techniquement sur Android ; atténué sur iOS (limitation Apple, voir § 2.3) Détecté au démarrage, accès à l’application refusé |
3. Consignes relatives aux sauvegardes
3.1 Export manuel
L’export manuel (menu dédié dans l’application) génère un fichier .xlsx ou .pdf intermédiaire, immédiatement compressé dans une archive ZIP chiffrée AES-256 avec un mot de passe saisi par l’utilisateur au moment de l’export.
Ce fichier intermédiaire, écrit temporairement en clair dans le stockage privé de l’application le temps de la mise en zip, est systématiquement supprimé une fois l’archive créée, y compris si la création de l’archive échoue en cours de route (suppression exécutée sans condition, quelle que soit l’issue de l’étape de compression). Aucune copie non chiffrée du contenu exporté ne subsiste donc sur le disque au-delà de cette étape transitoire. Seule l’archive ZIP chiffrée est conservée dans le dossier Documents de l’appareil.
Consignes à respecter lors de la manipulation de ce fichier :
- Choisir un mot de passe robuste lors de chaque export. La sécurité du fichier exporté dépend entièrement de ce mot de passe, qui n’est pas généré automatiquement par l’application (contrairement à la phrase de récupération des sauvegardes automatiques). L’application impose une longueur minimale de 12 caractères. Cette contrainte technique réduit le risque de mot de passe trop faible mais ne dispense pas l’utilisateur de choisir un mot de passe réellement difficile à deviner.
- Ne jamais transmettre le mot de passe par le même canal que le fichier (ex. : ne pas joindre le mot de passe dans le même e-mail que la pièce jointe).
- Ne pas stocker le fichier exporté sur un espace partagé non maîtrisé (cloud grand public, clé USB non chiffrée, messagerie) sans garantie équivalente de confidentialité.
- Considérer ce fichier comme une donnée de santé/sociale sensible au sens du RGPD dès sa génération : il contient les mêmes informations que l’application (identité, situations, protocoles, notes), sous une forme certes chiffrée mais transportable.
- Supprimer les copies obsolètes du fichier exporté une fois son usage terminé (ex. : après transmission à un tiers autorisé, ou après import dans un autre système).
- Limiter la diffusion du fichier aux seules personnes habilitées à en connaître le contenu, conformément au principe de minimisation.
- En cas de perte ou de compromission suspectée d’un fichier exporté, traiter l’incident selon la procédure de notification de violation de données de la structure (le chiffrement AES-256 réduit le risque mais ne dispense pas d’une analyse d’impact au cas par cas).
3.2 Sauvegardes automatiques locales – transfert hors appareil
Le mécanisme de sauvegarde automatique (§ 1, § 2.2) écrit une copie chiffrée dans un dossier nommé Sauvegardes_GLMApp, à chaque mise en arrière-plan de l’application (au maximum une fois toutes les 15 minutes) ainsi qu’à chaque ouverture. Un déclenchement manuel est également disponible dans l’application (bouton « Sauvegarder maintenant »), pour forcer une copie immédiate sans attendre le prochain déclenchement automatique. Une seule version est conservée sur l’appareil : la plus récente écrase la précédente, qu’elle ait été créée automatiquement ou manuellement. L’historique dans le temps est de la responsabilité de l’utilisateur, via ses transferts périodiques (voir consignes ci-dessous).
L’emplacement de ce dossier diffère selon la plateforme :
Android : Stockage interne › Documents › Sauvegardes_GLMApp
iOS : dans l’espace de stockage privé de l’application (pas un dossier « Documents » classique, et non visible depuis l’app Fichiers de l’iPad). Il n’est accessible qu’en connectant la tablette à un Mac par câble USB : il apparaît alors dans le Finder, sous le nom de l’application (« GLMApp »), avec un sous-dossier Sauvegardes_GLMApp.
Ce mécanisme protège contre une réinstallation ou une réinitialisation de l’appareil, mais pas contre sa perte ou sa destruction physique : le fichier de sauvegarde étant stocké sur la tablette elle-même, il disparaît avec elle. La phrase de récupération (§ 2.2) seule, sans une copie du fichier, ne permet de restaurer aucune donnée.
Pour couvrir ce second risque, une copie du dossier Sauvegardes_GLMApp doit être transférée périodiquement vers un support distinct de la tablette, à une fréquence à définir par la structure partenaire en fonction de son activité (ex. : hebdomadaire).
Consignes à respecter lors de ce transfert :
- Appliquer les mêmes consignes de confidentialité, de minimisation de la diffusion et de traitement d’incident qu’au § 3.1 (points 4, 6 et 7).
- Choisir un support maîtrisé par la structure partenaire pour la copie (ordinateur professionnel dédié, serveur de fichiers interne). Ne jamais utiliser un service cloud grand public non certifié hébergeur de données de santé (HDS) — ces sauvegardes contiennent les mêmes catégories de données sensibles que l’application (identité, situations, protocoles, notes), au sens du RGPD.
- Ne jamais transmettre la phrase de récupération par le même canal que le fichier, pour les mêmes raisons qu’au § 3.1.
- Ne pas modifier ni renommer les fichiers copiés : la restauration dans l’application s’appuie sur leur nom d’origine pour identifier leur date.
- Conserver plusieurs copies dans le temps plutôt qu’une seule écrasée à chaque transfert, pour disposer d’un point de restauration antérieur en cas de problème découvert tardivement.
4. Points d’attention pour l’AIPD
- Le périmètre de risque de cette application est local à l’appareil : les mesures organisationnelles à documenter côté structure partenaire concernent principalement la gestion physique des tablettes (procédure en cas de perte/vol, verrouillage de session, politique de mise à jour du système d’exploitation) et la diffusion des exports (§ 3).
- Ce document décrit les garanties techniques intégrées à l’application. Il ne se substitue pas à l’analyse de risque propre à la structure partenaire (procédures internes, habilitations, durée de conservation, etc.), qui reste de la responsabilité du responsable de traitement.
- Le choix du support de destination pour le transfert visé au § 3.2 relève de la responsabilité du responsable de traitement. Ce document ne tranche pas la question de savoir si un support donné (ordinateur professionnel, serveur interne, service cloud) satisfait à la réglementation applicable à l’hébergement de données de santé (HDS, article L.1111‑8 du Code de la santé publique) : cette analyse dépend de la qualification exacte des données traitées et du support retenu, et doit être conduite par la structure partenaire, le cas échéant avec son délégué à la protection des données ou un conseil spécialisé.
- Chaque professionnel ou structure utilisant l’application est responsable de traitement au sens du RGPD pour les données qu’il y saisit. L’éditeur de l’application n’accède, ne reçoit ni ne traite aucune de ces données (§ 1).