Étude de cas · Sécurité physique · Mobile
Comment nous avons livré Grom Security — une application native iOS et Android pour un opérateur de sécurité physique dont les clients, aux États-Unis et dans l'Union européenne, jonglaient avec trois applications distinctes pour armer une maison, regarder une caméra et allumer une lumière. Construite sur un modèle d'habilitations unique, un flux d'armement et de désarmement par zone, la vidéo intégrée et une surface de contrôle domotique — avec une architecture audit-ready conforme aux exigences RGPD et CCPA dès le premier jour.
L'équipe produit de Grom Security est arrivée avec une douleur opérationnelle précise. Leurs clients — des propriétaires aux États-Unis et dans l'Union européenne — payaient déjà pour un service de gardiennage, une vidéosurveillance et un écosystème domotique connecté, mais chaque sous-système était livré avec sa propre application mobile, sa propre identification et son propre flux de notifications. Un propriétaire qui souhaitait armer sa maison, regarder la caméra du jardin et allumer la lumière du porche au crépuscule devait ouvrir trois icônes, gérer trois sessions et réconcilier trois journaux d'audit distincts en cas de problème. Nous avons entièrement repensé cette surface à partir des principes fondamentaux sous la forme d'une seule application native iOS et Android : un modèle d'habilitations par zone où chaque propriété se divise en zones indépendantes (maison, sauna, garage, terrain), un flux d'armement et de désarmement unifié, la vidéo en direct intégrée et une surface de contrôle domotique intégrée à l'écosystème existant du client. Le résultat est une application de sécurité unifiée déployée aux États-Unis et dans l'UE, conforme aux exigences du RGPD et de la CCPA / CPRA dès le premier jour, qui fait partie du portefeuille de développement d'applications mobiles de YuSMP Group et offre au propriétaire une source unique de vérité sur ce qui est actuellement armé.
Un aperçu de ce que le projet Grom Security a livré sur iOS, Android et un back-office renforcé lors de son premier cycle en production.
La décision d'habilitation détermine chaque autre choix architectural dans une application de sécurité multi-locataires. Nous avons opté pour un modèle d'habilitations par zone — où chaque propriété se divise en zones indépendantes et où chaque zone possède son propre état d'armement, ses propres affectations de rôles et son propre journal d'audit — plutôt que pour le plus courant interrupteur global par propriété, pour une seule raison : c'est le seul modèle qui décrit honnêtement ce que veut vraiment un propriétaire. Un propriétaire qui arme sa maison la nuit laisse généralement le garage désarmé parce qu'un membre de la famille est encore dans l'atelier. Un opérateur de location de vacances souhaite armer le périmètre du terrain mais désarmer le cottage pour un locataire entrant. L'interrupteur global force l'utilisateur à choisir entre précision et commodité ; le modèle par zone lui offre les deux.
Les modèles à interrupteur global par propriété — du type fourni avec les SDK d'alarme en marque blanche de première génération — ont été éliminés tôt. Leur structure de données ne pouvait pas représenter « maison armée, garage désarmé » sans stocker l'un d'eux dans un état côté client que le back-office ne pouvait pas auditer. Passer à un modèle zonal signifiait que l'ensemble de la pile — interface client, service d'habilitations, journal d'audit, pipeline de push — est géré par zone et peut être cité de bout en bout par rapport aux propres registres de dispatch de l'opérateur.
| Dimension | Modèle zonal (Grom) | Interrupteur global par propriété | SDK fournisseur en marque blanche |
|---|---|---|---|
| État d'armement indépendant par zone | Natif — maison et garage séparément | Contournement via « modes » | Défini par le fournisseur ; souvent opaque |
| Accès basé sur les rôles par zone | Propriétaire / famille / employé / invité | À l'échelle de la propriété uniquement | Catalogue de rôles limité par le fournisseur |
| Granularité du journal d'audit | Par zone, par utilisateur, par événement | Au niveau de la propriété uniquement | Export contrôlé par le fournisseur |
| Intégration domotique | Natif — par zone | Ajout a posteriori — souvent une application séparée | Écosystème fourni par le fournisseur uniquement |
| Vidéo intégrée | Lecteur natif, contrôlé par les rôles | Lien profond vers l'application fournisseur | Lecteur SDK fournisseur uniquement |
| Adéquation App Store / Play Store | Enveloppe légère sur les API natives | Bundle plus lourd ; schémas hérités | Chargé en SDK ; friction à la revue |
| Minimisation des données | Lectures délimitées par rôle — pas de collecte excessive | Lectures à l'échelle de la propriété | Contrôlé par le fournisseur — opaque |
Références plateformes : Documentation Apple UserNotifications, Référence notifications Android.
Le client iOS est développé en Swift avec SwiftUI pour la couche interface et une couche de rendu délimitée par capacités qui n'affiche que les contrôles que l'utilisateur actuel est autorisé à utiliser sur la zone en cours. L'ensemble de la surface d'armement et de désarmement se condense en une seule machine à états — désarmé, armement en cours, armé, désarmement en cours, alarme déclenchée — et l'écran d'accueil est une liste des zones auxquelles l'utilisateur a accès, chacune avec un interrupteur en un tap qui pilote la machine à états. La distribution push s'appuie sur UserNotifications et APNs avec l'habilitation critical-alert pour les événements d'alarme, de sorte qu'une alarme déclenchée parvient au propriétaire même avec l'appareil en mode Ne pas déranger.
Le parcours tap-pour-armer est là où la plupart des applications de sécurité perdent du temps et de la confiance, et là où nous avons investi un effort d'ingénierie disproportionné. Le flux est le suivant : tap, validation de la capacité rôle-sur-zone de l'utilisateur par rapport à l'habilitation en cache local (sans aller-retour réseau si valide), émission de la commande d'armement signée via TLS vers le back-office, écriture de la demande dans le journal d'audit, et réception par le dispatcher du changement d'état en temps réel. Sur les réseaux mobiles américains et européens typiques, l'ensemble du parcours se termine en moins d'une seconde du point de vue de l'utilisateur, et l'entrée du journal d'audit — qui a armé quelle zone depuis quel appareil à quelle heure — est validée avant que l'interface ne revienne à l'état inactif. La surface iOS de bout en bout est livrée dans le cadre de notre pratique d'ingénierie iOS et Android.
Le client Android est écrit en Kotlin avec Jetpack Compose pour l'interface et un service de premier plan pour la distribution push longue durée — sur les appareils Samsung, Xiaomi, OnePlus et Pixel, les optimiseurs de batterie agressifs terminent les gestionnaires de push en arrière-plan en quelques minutes, rompant le contrat de distribution d'alarme auquel l'utilisateur s'inscrit implicitement. Le service de premier plan affiche une notification persistante minimale qui maintient le pipeline push actif pendant les cycles du mode Doze, et WorkManager gère les opérations non urgentes — actualisation des habilitations, replay du journal d'audit, rotation des certificats — avec une sémantique de back-off respectant les états d'économie de batterie sous Android 10 à Android 14.
La surface de contrôle domotique est là où le client Android démontre toute sa valeur. L'application s'intègre à l'écosystème domotique existant du client via une fine couche d'adaptation de protocoles — protocoles de sécurité tiers côté alarme, API domotiques côté automatisation — de sorte que le propriétaire peut allumer la lumière du porche depuis le même écran qui affiche le flux de la caméra du jardin et l'état d'armement en cours. Le lecteur vidéo intégré diffuse proprement en LTE et Wi-Fi sans forcer l'utilisateur à basculer vers une application fournisseur, et la lecture contrôlée par les rôles impose qui peut regarder quelle caméra. Après un passage de Wi-Fi à LTE, le client rétablit automatiquement la session vidéo. La même équipe d'ingénierie maintient iOS et Android en parallèle dans le cadre de notre pratique de développement d'applications mobiles.
La posture multi-utilisateur déclarée de Grom Security était une décision architecturale avant d'être un argument marketing. Chaque propriété est l'objet d'habilitation racine ; chaque zone hérite de cette propriété ; et chaque utilisateur reçoit un rôle par zone — propriétaire, famille, employé, invité — avec des capacités associées par rôle. Les clients mobiles n'affichent que les contrôles que l'utilisateur est autorisé à utiliser sur la zone en cours, et le back-office applique la même matrice de capacités à chaque appel API pour qu'une requête falsifiée ou rejouée depuis le client ne puisse pas élever les privilèges. Il n'existe aucun suivi de localisation par utilisateur, aucune capture en écoute continue depuis le microphone de l'appareil et aucun flux de métadonnées vers un fournisseur d'observabilité tiers en dehors du propre système de dispatch de l'opérateur.
Le journal d'audit est au cœur du modèle. Chaque armement, désarmement, consultation vidéo et modification de configuration génère un enregistrement immuable indexé par zone, utilisateur, appareil et type d'événement. La fenêtre de conservation par défaut de 90 jours est extensible selon la réglementation locale, et le propriétaire peut exporter le journal en JSON ou CSV à tout moment. Les politiques d'infrastructure-as-code imposent les invariants d'accès — toute pull request qui élargirait la portée de lecture d'un rôle ou introduirait un suivi non auditables par zone fait échouer la CI. La posture est conçue pour s'aligner sur les obligations du RGPD pour les utilisateurs de l'Union européenne et les obligations de la CCPA / CPRA pour les utilisateurs de Californie et des États-Unis — et pour qu'un futur audit indépendant soit un exercice documentaire, non une refactorisation architecturale.
Posture de conformité : aligné RGPD · prêt ISO 27001 · SOC 2 Type II en cours · compatible HIPAA · CCPA pris en compte.
Un projet en cinq phases qui a conduit Grom Security de la spécification produit à la mise en production sur iOS, Android et un back-office d'habilitations unifié.
Entretiens clients sur des propriétés multi-zones, modélisation des menaces (commandes falsifiées, élévation de portée, appareils perdus), cartographie de la posture RGPD + CCPA, revue des habilitations des applications de sécurité sur App Store et Google Play.
Schéma d'habilitations par zone, matrice capacités-rôles, adaptateur de protocoles de sécurité tiers, adaptateur de protocoles domotiques, contrat d'immuabilité du journal d'audit, conception du pipeline push.
Client iOS Swift / SwiftUI avec rendu délimité par capacités et push critical-alert ; client Android Kotlin / Jetpack Compose avec service de premier plan pour la fiabilité du push ; lecteur vidéo intégré sur les deux plateformes.
Politiques d'infrastructure-as-code bloquant les régressions de portée de rôle, QA de la fiabilité du push sur les réseaux Apple et Google, tests d'immuabilité du journal d'audit, mise en place de l'évaluation tierce.
Soumission App Store + Google Play pour les marchés américain et européen, basculement du flux d'événements temps réel côté dispatcher, configuration de la conservation du journal d'audit par zone selon la réglementation locale.
La couche domotique de Grom Security a été conçue pour que l'identité alarme et l'identité domotique restent provablement alignées, car la promesse de l'application unifiée s'effondre dès qu'un propriétaire doit se connecter à un compte d'écosystème séparé pour allumer une lumière. La surface de contrôle domotique s'intègre à l'écosystème existant du client via une fine couche d'adaptation de protocoles qui fait correspondre les capacités délimitées par rôle — allumer / éteindre / graduer — au schéma de commande propre à l'écosystème. Côté serveur, l'intégration est un mapping stateless ; le back-office ne conserve aucune copie persistante des identifiants de l'écosystème au-delà du token de rafraîchissement OAuth rotatif, et un propriétaire qui révoque l'intégration voit la vignette domotique disparaître de son application en quelques secondes. La vue dispatcher, utilisée par l'équipe d'intervention de garde de l'opérateur, lit depuis le même flux du journal d'audit que le client voit dans l'application — de sorte qu'une alarme déclenchée se réconcilie proprement entre l'écran mobile du client, la console du dispatcher et le rapport d'incident final. L'ensemble du sous-système a été conçu dans un souci d'extensibilité : l'ajout d'un nouvel adaptateur d'écosystème, d'un moteur de planification par zone ou d'un niveau B2B multi-propriétés avec gestion d'équipe est une modification de configuration dans le service d'habilitations, pas une release de code.
Grom Security a été lancé sur l'App Store d'Apple et Google Play avec des vitrines actives aux États-Unis et dans l'Union européenne. La version en langue anglaise dessert les utilisateurs en Californie, New York, Texas, Floride et Washington aux États-Unis, et les utilisateurs aux Pays-Bas, en Allemagne, en France, en Irlande et en Suède dans l'UE, sans base de code distincte par région. Les flux de consentement sont géolocalisés au niveau de la couche client : les utilisateurs de l'UE et de l'EEE reçoivent un écran de consentement RGPD granulaire avec des interrupteurs distincts pour les analyses produit optionnelles ; les utilisateurs de Californie reçoivent une divulgation CCPA de type « Ne pas vendre ni partager mes informations personnelles » dans le même flux. Les pratiques de traitement des données sont alignées sur le RGPD pour les utilisateurs européens et sur le patchwork de lois américaines sur la vie privée — CCPA / CPRA (Californie), VCDPA (Virginie), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas) et Oregon CPA. L'architecture d'habilitations par zone minimisant la collecte de données par utilisateur, la conformité régionale se réduit à une divulgation honnête plutôt qu'à une ségrégation des données par juridiction.
Le parc back-office a été déployé en parallèle dans les régions UE et américaine — Pays-Bas, Allemagne, France, Suède et Irlande pour la couverture UE ; Est et Ouest des États-Unis pour l'Amérique du Nord — chaque région étant provisionnée de manière identique avec des workers stateless. Le flux dispatcher qui achemine les événements d'alarme vers l'équipe d'intervention de garde s'exécute sur des workers stateless pouvant être ancrés dans les régions UE ou US indépendamment pour de futurs engagements de résidence des données. La classification par âge sur l'App Store et la classification de contenu sur Google Play ont été calibrées pour l'ensemble des fonctionnalités de sécurité, et la politique de confidentialité intégrée à l'application a été rédigée pour documenter précisément l'architecture ci-dessus, citant directement les obligations RGPD et les obligations CCPA californienne. L'équipe d'ingénierie à l'origine du projet est répartie sur le fuseau CET et travaille avec un chevauchement quotidien de quatre heures avec la côte Est américaine (9 h–13 h ET) pour les points d'équipe, la coordination des soumissions aux stores et la gestion des incidents.
La feuille de route active de développement logiciel sur mesure pour Grom Security inclut l'intégration du protocole Matter pour le contrôle domotique inter-écosystèmes, un moteur de planification par zone permettant au garage de s'armer automatiquement à minuit, un niveau de push critical-alert avec escalade optionnelle vers une équipe d'intervention payante, et un client desktop construit sur Tauri pour partager la logique métier avec la base de code mobile. Un niveau B2B avec apport de portefeuille de propriétés, gestion d'équipe et SSO est prévu pour les opérateurs mid-market américains et européens, le sous-système d'habilitations étant déjà structuré pour l'assignation multi-propriétés. Les plans d'infrastructure comprennent une automatisation cloud & DevOps supplémentaire du pipeline de déploiement régional, un environnement de vérification continue interne pour le contrat de portée des rôles et une future évaluation indépendante de l'état de préparation intégrée à la cadence opérationnelle.
Si vous planifiez une application de sécurité unifiée, un produit de télésurveillance ou toute application mobile où la sécurité physique, la vidéo intégrée et le contrôle domotique doivent se trouver derrière une seule icône pour des audiences aux États-Unis et en Europe, nous avons livré ce stack de bout en bout et pouvons réduire significativement le délai de développement. Le produit en production est exploité par le fournisseur de sécurité sur yusmpgroup.ru/cases/gromsecurity (page du cas), et l'équipe d'ingénierie à l'origine du projet est intégrée à YuSMP Group. Nous travaillons en prix fixe pour les MVP bien délimités et en équipes dédiées pour la livraison continue, avec un travail sur le fuseau CET et une fenêtre garantie de chevauchement avec la côte Est américaine (9 h–13 h ET) pour les points d'équipe, les démos et la gestion des incidents.
Une application mobile de télésurveillance d'alarme avec clients iOS et Android, armement et désarmement par zone, notifications push et back-office d'habilitations coûte généralement entre 120 k€ et 280 k€ pour un MVP. L'ajout de flux vidéo intégrés, d'intégrations de protocoles domotiques (Matter, Zigbee, Z-Wave ou SDK fournisseur), de permissions multi-utilisateur basées sur les rôles et d'un journal d'audit porte un déploiement complet à 320 k€–680 k€. Les principaux postes de coût sont l'intégration des protocoles de sécurité tiers et le modèle de permissions multi-utilisateur.
Un propriétaire qui paye déjà pour un service de gardiennage ne souhaite pas trois icônes sur son écran d'accueil, trois identifiants et trois flux de notifications provenant du même fournisseur. Regrouper alarme, vidéo et domotique dans une seule application supprime la charge cognitive liée à la mémorisation de l'application qui contrôle quel sous-système, nous permet de partager une identité utilisateur unique et un modèle de permissions unique sur les trois surfaces, et offre au propriétaire une source unique de vérité sur ce qui est actuellement armé, qui a accès et ce qui vient de se passer.
Un modèle multi-utilisateur solide est une décision de rôles, pas une bascule de fonctionnalité. La propriété est l'objet d'habilitation racine ; chaque zone (maison, garage, terrain, sauna) hérite de cette propriété ; et chaque utilisateur reçoit un rôle par zone — propriétaire, famille, employé, invité. Les rôles correspondent à des capacités — armer, désarmer, voir la vidéo, configurer — et les clients mobiles n'affichent que les capacités dont dispose l'utilisateur. Les entrées du journal d'audit enregistrent qui a armé, désarmé ou reconfiguré chaque zone, avec une période de conservation par défaut de 90 jours que le propriétaire peut prolonger selon la réglementation locale.
Grom Security est l'interface mobile unique qu'un propriétaire emporte avec lui sur plusieurs adresses. Elle liste chaque site dont il est propriétaire avec un contrôle d'armement et de désarmement en un tap par zone, affiche les flux vidéo en direct des caméras intégrées sur chaque site, expose les actions domotiques pour l'éclairage, le climat et les prises via l'écosystème connecté, et achemine les événements d'alarme sous forme de notifications push avec escalade optionnelle vers l'équipe d'intervention de garde. Les membres de la famille et les employés reçoivent un accès délimité via le modèle de permissions basé sur les rôles.
Un MVP ciblé avec clients iOS et Android, armement et désarmement par zone, notifications push et back-office d'habilitations prend généralement 14 à 22 semaines. L'ajout de l'intégration vidéo intégrée, de la couche de protocoles domotiques, du modèle de permissions multi-utilisateur basé sur les rôles et du journal d'audit ajoute 8 à 12 semaines. La phase de durcissement — fiabilité des push sur les réseaux Apple et Google, QA des permissions par rôle, immuabilité du journal d'audit, évaluation de l'état de préparation tierce — est fréquemment sous-estimée et doit être budgétée à 4 à 6 semaines de travail dédié.
Cas associés
VPN grand public WireGuard pour iOS & Android avec un plan de contrôle sans journaux et une posture audit-ready aux États-Unis et en Europe.
Voir le cas →
Plateforme sociale native iOS + Android avec découverte par géo-radar, messagerie temps réel et économie de monnaie virtuelle aux États-Unis et en Europe.
Voir le cas →
Workflow mobile de signature électronique audit-ready avec accès strictement délimité par rôle et journal d'audit inviolable.
Voir le cas →Partagez quelques détails et un consultant senior vous répondra dans un délai d'un jour ouvrable.