Une application de livraison conçue pour une PME casablancaise demande cinq autorisations dès le premier lancement : localisation en arrière-plan, accès aux contacts, caméra, notifications, stockage. Le code est propre, l’app passe la revue Apple du premier coup. Quand le responsable conformité du client demande à qui ces données sont transmises et sur quelle base, personne dans l’équipe projet ne sait répondre précisément.
Ce décalage est la norme plutôt que l’exception. Une application mobile collecte structurellement plus de données personnelles qu’un site web, parce qu’elle accède à des capteurs et à des identifiants que le navigateur ne donne pas. Et la plus grande partie de ces flux ne vient pas du code que vous avez commandé : elle vient des bibliothèques tierces intégrées pour aller plus vite.
La loi 09-08 ne distingue pas le site de l’application : dès qu’un traitement de données personnelles est mis en œuvre, il relève des formalités CNDP, et certaines catégories exigent une autorisation préalable et non une simple déclaration. La conformité CNDP application mobile ne se règle donc pas en copiant la politique de confidentialité du site dans l’app. Elle se joue permission par permission et SDK par SDK.
Permissions mobiles : ce que chaque autorisation révèle vraiment
Le dialogue système que voit l’utilisateur (« Autoriser l’accès à votre position ? ») accorde un accès technique à une ressource de l’appareil. Il ne dit ni la finalité précise, ni les destinataires, ni la durée de conservation. C’est la première chose à regarder dans un audit, parce que l’écart entre ce que l’app demande et ce qu’elle utilise réellement est presque toujours là.
Les permissions application mobile Maroc qui soulèvent le plus de questions côté CNDP :
- Localisation précise et en arrière-plan. Une position toutes les trente secondes pendant six mois, c’est un historique de déplacements : domicile, lieu de travail, habitudes, fréquentations. Beaucoup d’applications demandent l’arrière-plan alors que la localisation pendant l’usage suffirait largement.
- Carnet d’adresses. Lire les contacts revient à collecter les données de personnes qui n’ont jamais installé votre app et n’ont rien consenti. C’est la permission la plus difficile à justifier, et celle que je recommande le plus souvent de supprimer.
- Caméra et photothèque. Une CIN photographiée pour un parcours KYC devient un document d’identité stocké quelque part. Où, chiffré comment, effacé quand ?
- Micro. Rarement nécessaire en dehors d’une messagerie vocale, souvent présent par héritage d’un template ou d’un plugin.
- Identifiant publicitaire (IDFA sur iOS, AAID sur Android). Identifiant unique rattachable à un profil chez un tiers. C’est une donnée personnelle même sans nom ni e-mail.
- Bluetooth et scan Wi-Fi. Utilisés aussi pour localiser en intérieur, ce que l’écran de permission ne mentionne jamais.
Demandez à votre prestataire un tableau d’une ligne par permission : à quoi elle sert, dans quel écran, quelle donnée elle produit, vers où cette donnée part. Toute permission qui reste dans le manifeste Android ou dans l’Info.plist sans usage actif doit disparaître avant la publication, pour la conformité comme pour le taux d’acceptation.
SDK tiers : Firebase, Analytics, Facebook SDK, où partent les données
Une application Flutter ou React Native de taille moyenne embarque facilement entre quinze et quarante dépendances, dont une poignée ouvrent des connexions réseau vers l’extérieur. Le code métier que vous avez payé représente parfois la plus petite partie des flux sortants.
Firebase Analytics enregistre par défaut des événements automatiques, le modèle d’appareil, la version d’OS, une localisation approximative déduite de l’adresse IP et un identifiant d’installation pseudonyme. Crashlytics remonte des traces d’exécution qui contiennent exactement ce que vos développeurs y ont mis, et j’ai déjà vu des e-mails et des numéros de commande apparaître dans des logs de crash. Cloud Messaging stocke le token de l’appareil. Le SDK Facebook enregistre des événements applicatifs automatiquement dès l’initialisation, souvent avant tout écran de consentement, et les rapproche d’un compte Meta existant. Les SDK d’attribution de type AppsFlyer ou Adjust construisent, par nature, une empreinte de l’installation.
Tous ces flux sortent du Maroc. Un transfert de données personnelles vers l’étranger ne s’improvise pas : il doit figurer dans votre dossier et s’appuyer sur un cadre que la CNDP accepte, et le fournisseur du SDK est votre sous-traitant, ce qui suppose un contrat et des engagements de sécurité. Les conditions évoluent, vérifiez la procédure applicable sur le site de la CNDP plutôt que de vous fier à un vieux modèle de dossier.
Le sujet SDK tiers et données personnelles se vérifie concrètement, pas sur déclaration : faites tourner le binaire derrière un proxy d’inspection et regardez les domaines contactés au tout premier lancement. Notez aussi que le choix de la pile technique change la liste à auditer, puisqu’un projet Flutter ou React Native tire des plugins communautaires que personne n’a relus, là où un projet natif ou Flutter ne pose pas les mêmes questions de dépendances.
Le token de notification push, la donnée personnelle qu’on oublie
Pour envoyer une notification, l’application s’enregistre auprès de Firebase Cloud Messaging ou d’APNs et reçoit un token. Ce token identifie une installation précise sur un appareil précis. Dès que vous le rangez dans votre base à côté d’un identifiant client, d’un numéro de téléphone ou d’un historique de commandes, le sujet des notifications push données personnelles cesse d’être théorique : vous détenez un identifiant rattaché à une personne.
Ce qui se passe en pratique est toujours le même. La table des tokens grossit, personne ne la purge, et elle finit par contenir des installations désinstallées depuis deux ans avec leur profil associé. La logique de conservation est celle de n’importe quelle autre donnée, et les durées de conservation attendues par la CNDP s’appliquent aussi à cette table que personne ne regarde.
Trois corrections suffisent la plupart du temps : supprimer le token à la déconnexion et à la suppression de compte, purger les tokens que FCM vous signale comme invalides, et séparer les notifications de service (commande expédiée, rendez-vous confirmé) des notifications marketing, qui relèvent du consentement et doivent être désactivables dans l’application elle-même, pas uniquement dans les réglages du téléphone.
Biométrie et localisation continue : le régime le plus strict
Deux choses que les devis confondent régulièrement méritent d’être séparées. Utiliser Face ID ou l’empreinte via l’API système pour déverrouiller l’app, c’est demander au système d’exploitation de répondre oui ou non : le gabarit ne quitte jamais l’enclave sécurisée de l’appareil et vous ne le recevez jamais. Construire votre propre reconnaissance faciale, par exemple un onboarding avec selfie comparé à la photo de la CIN, c’est collecter et traiter un gabarit biométrique sur vos serveurs.
Le second cas change de catégorie. Biométrie et loi 09-08, c’est le terrain de l’autorisation préalable de la CNDP et non de la déclaration ordinaire, avec une instruction qui porte sur la finalité, les mesures de sécurité, la durée de conservation du gabarit et les alternatives proposées à l’utilisateur. Le suivi de localisation en continu de salariés ou de livreurs relève d’une vigilance comparable, avec en plus la dimension droit du travail. Avant de chiffrer ce type de fonctionnalité, vérifiez le formulaire et les délais en vigueur sur le site de la CNDP : c’est souvent ce poste qui décale une date de lancement.
Ce que les stores exigent déjà, et ce qui dépasse leurs formulaires
Apple impose une fiche App Privacy, Google Play un formulaire Data safety, et les deux exigent une URL de politique de confidentialité accessible. Google réclame en plus un écran explicite pour la localisation en arrière-plan, et les deux stores demandent désormais un parcours de suppression de compte accessible depuis l’application. Ces formulaires restent déclaratifs : personne ne vérifie ligne à ligne ce que vos SDK envoient réellement.
Ce qu’ils ne couvrent pas du tout : la formalité CNDP elle-même, la base de chaque traitement, les durées de conservation, l’identité du responsable de traitement, les modalités d’exercice des droits d’accès, de rectification et d’opposition, et les contrats avec vos sous-traitants. Remplir sérieusement la fiche Apple est un bon exercice de cartographie, mais la confondre avec la conformité marocaine est une erreur fréquente. La préparation d’une soumission en store et la préparation du dossier CNDP sont deux chantiers parallèles, qui ne se valident pas au même endroit.
Ce que couvre un audit CNDP application mobile avant publication
Sur une app de taille raisonnable, le travail tient entre une demi-journée et deux jours. L’ordre des étapes compte plus que les outils.
- Extraire la liste réelle des permissions du manifeste Android et de l’Info.plist iOS, puis rattacher chacune à un écran précis. Tout ce qui n’a pas d’écran associé sort du projet.
- Lister les dépendances avec leur version et isoler celles qui ouvrent une connexion réseau.
- Lancer l’app derrière un proxy d’inspection et relever les domaines contactés au premier démarrage, avant que l’utilisateur n’ait accepté quoi que ce soit. C’est l’étape qui surprend le plus les équipes de développement.
- Construire la cartographie : donnée collectée, finalité, base, destinataire, pays d’hébergement, durée de conservation.
- En déduire le régime applicable, déclaration ou autorisation préalable selon la nature des données et des transferts.
- Rédiger les écrans d’information et de recueil du consentement dans l’app, en français et en arabe si votre audience le justifie, et pas seulement une politique de confidentialité renvoyée vers un lien externe.
Le raisonnement est celui de la conformité CNDP d’un site web, avec deux différences : le nombre de points de collecte est bien plus élevé, et une bonne partie reste invisible depuis l’interface.
La checklist à exiger de votre prestataire avant de signer
Ces points se négocient au devis, pas à la recette. Les faire entrer dans le périmètre initial ne coûte presque rien ; les ajouter après coup se paie en jours de développement.
- La liste des permissions demandées, avec une justification écrite, annexée au cahier des charges.
- L’inventaire des SDK tiers prévus, nommés dans le devis, plus une clause interdisant d’en ajouter un nouveau sans votre accord écrit.
- Un rapport de capture réseau fourni avant la soumission en store.
- La cartographie des traitements livrée en fin de projet, dans un format que vous pouvez maintenir vous-même.
- Qui rédige et dépose le dossier CNDP, et si cette prestation est incluse ou facturée séparément.
- La suppression de compte avec effacement effectif en base, tokens de notification et sauvegardes compris.
- La propriété des comptes développeur Apple et Google, du projet Firebase et des clés de signature.
- Les engagements de sécurité : chiffrement en transit et au repos, rotation des clés d’API, aucun secret en dur dans le binaire.
Questions fréquentes
Faut-il une formalité CNDP distincte pour l’app si le site est déjà déclaré ?
Dans la plupart des cas oui, parce que la formalité porte sur un traitement et ses finalités, pas sur un support. Si l’application crée de nouvelles collectes (localisation, notifications, biométrie) ou de nouveaux destinataires, le récépissé existant ne les couvre pas. Relisez la portée exacte de ce que vous avez déclaré avant de conclure.
Le consentement affiché par iOS ou Android suffit-il ?
Non. Le dialogue système ouvre un accès technique à une ressource de l’appareil. La loi 09-08 attend en plus une information claire sur la finalité, les destinataires, la durée et les droits de la personne, ainsi qu’un moyen de revenir sur son choix. Concrètement, cela se traduit par un écran d’explication affiché juste avant la demande de permission.
Peut-on utiliser Firebase pour une application marocaine ?
Beaucoup d’apps marocaines l’utilisent. Cela implique un hébergement hors du Maroc, donc un transfert transfrontalier à traiter dans votre dossier, un contrat de sous-traitance avec le fournisseur, et une configuration volontairement réduite : désactiver la collecte automatique d’événements dont vous n’avez pas l’usage, et interdire l’envoi d’identifiants directs dans les logs de crash.
À quel moment faire cet audit dans le projet ?
Au cadrage, pas à la recette. Retirer un SDK d’attribution ou revoir un flux biométrique après le développement coûte plusieurs jours, et la correction tombe toujours au pire moment, juste avant la soumission en store.
Où cet audit se place dans un projet mobile
Chez Arrowlancer, la cartographie des permissions, des SDK tiers et des flux de localisation ou de biométrie fait partie du cadrage de chaque application iOS, Android, Flutter ou React Native que nous développons, avant que les intégrations ne soient figées. Le périmètre du pôle mobile figure parmi nos services. Si vous préparez un lancement ou une refonte, écrivez-nous avec la liste des permissions que votre app demande aujourd’hui : c’est le point de départ le plus utile d’une discussion.