Mis à jour le 17 août 2026
Le 16 janvier 2026, la CNIL a publié ses recommandations finales sur le consentement multi-terminaux, quelques semaines après avoir infligé 1 million d'euros à Mobius Solutions Ltd, l'ancien sous-traitant publicitaire de Deezer, pour avoir conservé les données de plus de 46 millions d'utilisateurs après la fin du contrat (CNIL, décision du 11 décembre 2025). Les deux décisions visent le même point aveugle : une fois que l'équipe produit sait qu'elle doit bloquer les SDK avant consentement, la question qui reste sans réponse dans la plupart des organisations est juridique, pas technique — qui est responsable de quoi contractuellement, quelle base légale couvre réellement chaque finalité de traitement, et quelle architecture de gestion du consentement peut le prouver lors d'un contrôle. Ce guide s'adresse aux équipes juridiques, conformité et produit qui ont déjà lu l'état des lieux réglementaire sur la conformité RGPD des applications mobiles, la campagne de contrôle CNIL et le rôle des SDK et cherchent maintenant la couche opérationnelle : mécanique juridique fine et décisions d'architecture de consentement.
Points clés
- Depuis la mise à jour du 8 avril 2025, la recommandation CNIL sur les applications mobiles présume que le fournisseur de SDK est sous-traitant, et non responsable conjoint, sauf s'il poursuit sa propre finalité sur les données. Cette qualification par défaut n'est pas automatiquement valide : elle doit être vérifiée cas par cas.
- L'avis 22/2024 du Comité européen de la protection des données (CEPD, 7 octobre 2024) impose au responsable de traitement une obligation de vérification active de chaque sous-traitant et sous-traitant ultérieur, indépendamment du niveau de risque du traitement.
- La sanction de 1 million d'euros contre Mobius Solutions Ltd (CNIL, décembre 2025) montre que le sous-traitant d'une app peut être sanctionné directement, sans passer par l'éditeur, pour un manquement à l'article 28(3)(g) : la suppression des données en fin de contrat.
- Une analyse d'impact (AIPD) devient obligatoire dès que deux des neuf critères du CEPD sont réunis ; le suivi de localisation à grande échelle et le profilage publicitaire via SDK tiers suffisent, à eux deux, à franchir ce seuil dans la majorité des apps grand public.
- Depuis le 16 janvier 2026, la CNIL encadre formellement le consentement multi-terminaux : un mécanisme facultatif, mais qui, une fois activé, doit respecter une obligation d'information, une règle explicite de résolution des conflits de choix, et une facilité de refus égale à celle de l'acceptation.
Le Périmètre de Ce Guide
La mécanique technique du blocage de consentement, la campagne de contrôle CNIL et les sanctions déjà rendues publiques (Voodoo, Tilting Point) sont traitées en détail dans l'article référencé plus haut et ne sont pas reprises ici. Ce texte se concentre sur trois couches que ce premier article ne couvrait pas : l'analyse de base légale par finalité, le partage de responsabilité juridique entre éditeur et fournisseur de SDK, et les critères de décision pour choisir une architecture de CMP mobile.
Base Légale RGPD Par Finalité de Traitement Dans Une Application Mobile
Une erreur fréquente consiste à chercher une base légale unique pour « l'application » plutôt que pour chaque finalité qu'elle poursuit. Le RGPD n'évalue pas une app dans son ensemble : il évalue chaque traitement, défini par sa finalité, indépendamment des autres. Une même application peut donc légitimement combiner plusieurs bases légales, à condition que chacune corresponde réellement à la finalité qu'elle couvre.
L'article 5(3) de la directive ePrivacy ajoute une contrainte qui s'applique en amont du RGPD lui-même : tout accès à des informations stockées sur le terminal, y compris via un SDK, exige un consentement préalable, sauf exception strictement limitée à ce qui est nécessaire au fonctionnement du service demandé par l'utilisateur. Cette exigence ePrivacy prime sur toute tentative de fonder un traitement de mesure d'audience ou de publicité sur l'intérêt légitime : l'intérêt légitime peut couvrir le traitement des données une fois collectées, jamais l'accès initial au terminal lui-même.
| Finalité de traitement | Base légale RGPD envisageable | Contrainte ePrivacy 5(3) | Commentaire |
|---|---|---|---|
| Fonctionnement technique de base (session, panier, préférences de langue) | Exécution du contrat ou intérêt légitime | Exemptée si strictement nécessaire au service demandé | La marge d'erreur est faible : dès qu'une donnée sert aussi une finalité secondaire (ex. amélioration produit), la base légale doit être réévaluée pour cette finalité précise |
| Mesure d'audience et analytique produit | Consentement ; intérêt légitime possible seulement pour une mesure strictement agrégée et non intrusive | Consentement requis pour l'accès au terminal, sauf mesure d'audience exemptée au sens strict de la CNIL | La plupart des SDK analytiques commerciaux dépassent le périmètre de l'exemption CNIL et nécessitent donc un consentement complet |
| Publicité ciblée et profilage comportemental | Consentement explicite, quasi systématiquement | Consentement requis, sans exception | L'intérêt légitime est structurellement inadapté ici : le CEPD a rappelé en octobre 2024 que le profilage à des fins publicitaires prive l'utilisateur d'un contrôle réel, ce qui échoue au test de mise en balance |
| Diagnostics techniques et rapports de crash | Intérêt légitime, si les données sont limitées au strict nécessaire au débogage | Généralement exemptée si limitée à la stabilité technique du service | Un SDK de crash reporting qui capture des identifiants publicitaires ou des données comportementales sort de ce périmètre et bascule vers le consentement |
| Notifications push personnalisées | Consentement | Non concernée directement (canal OS, pas un accès terminal au sens de l'article 5(3)) | L'autorisation système (iOS/Android) et le consentement RGPD au ciblage du contenu de la notification restent deux couches distinctes |
| Prévention de la fraude et sécurité du compte | Intérêt légitime, ou obligation légale selon le secteur | Généralement exemptée si strictement liée à la sécurité | Base légale parmi les plus solides du tableau, à condition que les données collectées restent proportionnées au risque réellement traité |
Le point structurant de ce tableau : dès qu'une finalité implique un accès au terminal au sens de l'article 5(3), l'intérêt légitime devient juridiquement indisponible comme base légale d'accès, même s'il pourrait théoriquement justifier le traitement des données une fois obtenues. Le CEPD a d'ailleurs rappelé, dans ses lignes directrices d'octobre 2024, les conditions strictes qui encadrent le recours à l'intérêt légitime pour justifier un suivi comportemental, un test de mise en balance que la plupart des SDK publicitaires échouent d'emblée. Documenter une base légale par SDK, et non par application, est ce qui permet de répondre précisément à un contrôle CNIL plutôt que de défendre une position globale difficile à tenir.
Qualifier Chaque SDK : Responsable, Sous-Traitant, ou Aucun Rôle RGPD
La recommandation CNIL sur les applications mobiles distingue trois qualifications possibles pour un fournisseur de SDK : responsable de traitement, lorsqu'il utilise tout ou partie des données pour son propre compte ; sous-traitant, lorsqu'il se limite à traiter les données pour le compte et sur instruction de l'éditeur ; ou aucun rôle RGPD, lorsqu'aucune donnée personnelle n'est réellement traitée par le SDK. Entre la version initiale de septembre 2024 et la version modifiée du 8 avril 2025, la CNIL a fait évoluer sa position par défaut sur les SDK de géolocalisation : d'une responsabilité conjointe présumée, elle est passée à une présomption de sous-traitance, considérant que le fournisseur ne poursuit généralement aucune finalité propre.
Cette présomption ne dispense pas l'éditeur de la vérifier. La CNIL le souligne explicitement dans son guide dédié à l'intégration des SDK : de nombreux fournisseurs se qualifient eux-mêmes, précontractuellement, comme sous-traitants pour l'ensemble des traitements qu'ils réalisent, et cette qualification imposée n'est pas systématiquement conforme aux critères du RGPD. La qualification correcte dépend de l'usage concret des données, pas de la formulation choisie dans les conditions générales du fournisseur. Un SDK publicitaire qui agrège des données comportementales issues de plusieurs applications clientes pour entraîner son propre modèle de ciblage agit pour son compte propre, quelle que soit la clause qu'il a rédigée pour se présenter comme simple sous-traitant.
L'avis 22/2024 du CEPD, adopté le 7 octobre 2024, renforce l'obligation qui pèse sur l'éditeur une fois cette qualification établie : le responsable de traitement doit vérifier que chaque sous-traitant, et chaque sous-traitant ultérieur dans la chaîne, présente des garanties suffisantes, et cette obligation de vérification s'applique indépendamment du niveau de risque associé au traitement. Concrètement, cela signifie que l'éditeur doit être en mesure de nommer, à tout moment, l'ensemble des sous-traitants et sous-traitants ultérieurs impliqués dans le traitement réalisé via ses SDK, pas seulement le fournisseur avec lequel il a signé un contrat direct.
Ce que révèle la sanction Mobius Solutions : le 11 décembre 2025, la CNIL a infligé 1 million d'euros à Mobius Solutions Ltd, ancien sous-traitant publicitaire de Deezer, pour un manquement direct à l'article 28(3)(g) — l'obligation de supprimer les données du responsable de traitement à la fin de la relation contractuelle. Mobius avait conservé une copie des données de plus de 46 millions d'utilisateurs Deezer après l'expiration du contrat, et n'avait pas non plus tenu de registre des traitements réalisés en tant que sous-traitant. Cette décision confirme que la CNIL sanctionne désormais le sous-traitant lui-même, pas uniquement le responsable de traitement qui l'a choisi. Pour un éditeur d'application intégrant un SDK tiers, la conséquence pratique est double : d'une part, un contrat qui ne prévoit pas de clause de suppression vérifiable à l'échéance n'offre aucune protection réelle si le fournisseur ne s'y conforme pas ; d'autre part, l'incapacité du fournisseur à respecter cette obligation devient un signal de risque à évaluer avant l'intégration, pas seulement après un incident.
DPIA / AIPD : Quand Une Application Mobile Franchit le Seuil
Une analyse d'impact relative à la protection des données devient obligatoire, au sens de l'article 35 du RGPD, dès que le traitement envisagé réunit au moins deux des neuf critères identifiés par le CEPD : évaluation ou notation, décision automatisée à effet juridique, surveillance systématique, données sensibles, traitement à grande échelle, croisement de données, personnes vulnérables, usage innovant, ou traitement faisant obstacle à l'exercice d'un droit.
Pour une application mobile grand public, ce seuil est franchi plus vite qu'il n'y paraît. Le suivi de localisation combiné à un profilage publicitaire réunit à lui seul deux critères distincts : la surveillance systématique du comportement de déplacement, et l'évaluation à des fins de personnalisation. Une application destinée à un usage régulier par une base d'utilisateurs dépassant quelques centaines de milliers de comptes actifs entre en outre dans le critère du traitement à grande échelle. Dans la pratique, la plupart des applications intégrant à la fois un SDK de mesure d'audience comportementale et un ou plusieurs SDK publicitaires réunissent déjà, sans même tenir compte des autres critères, un motif suffisant pour déclencher l'obligation d'AIPD.
Le contenu de l'AIPD doit refléter la réalité technique décrite plus haut dans ce guide, pas une description générique de l'application. Trois éléments sont spécifiquement attendus pour un contexte mobile : un inventaire exhaustif des SDK intégrés avec, pour chacun, la finalité réelle du traitement et sa base légale associée ; une cartographie des flux de données sortant du terminal vers chaque fournisseur, incluant les sous-traitants ultérieurs identifiés au titre de l'obligation de vérification du CEPD ; et une évaluation spécifique du risque que représente la persistance d'un identifiant publicitaire ou technique en cas de refus de consentement non respecté par un SDK. L'AIPD doit être reprise, et non simplement archivée, à chaque intégration d'un nouveau SDK dont le comportement de collecte diffère de celui déjà documenté — un point que la cartographie complète des flux de données permet de vérifier avant même de rouvrir l'analyse d'impact elle-même.
Traiter ces questions dès la sélection d'un SDK, plutôt qu'au moment où l'AIPD doit être rédigée, relève des principes de protection de la vie privée dès la conception : un SDK évalué avant intégration coûte une revue technique, le même SDK découvert non conforme après publication coûte une refonte d'architecture et, potentiellement, une notification de violation.
Choisir l'Architecture du CMP Mobile : SDK Natif ou Passerelle WebView
Le choix technique de la plateforme de gestion du consentement (CMP) pour une application mobile a des conséquences juridiques directes, pas seulement une différence d'expérience utilisateur. Deux approches dominent le marché, et elles ne portent pas le même niveau de risque de conformité.
Une passerelle WebView consiste à afficher l'interface de consentement dans un composant web intégré à l'application native, souvent parce que le fournisseur du CMP a d'abord développé sa solution pour le web et l'a ensuite adaptée au mobile. Le risque de conformité principal ne tient pas à l'apparence, qui peut être identique à celle d'un composant natif, mais à la difficulté de garantir que l'état de consentement calculé dans le WebView est effectivement transmis, avant toute initialisation, aux SDK natifs qui s'exécutent en dehors de ce composant. Le délai entre le rendu du WebView et la lecture de son résultat par le code natif de l'application est précisément la fenêtre pendant laquelle un SDK mal configuré peut s'initialiser avant que le refus n'ait été pris en compte, ce qui reproduit le défaut d'architecture que la campagne de contrôle CNIL cible en priorité.
Un SDK de CMP nativement compilé pour iOS et Android, en revanche, s'exécute dans le même processus applicatif que les SDK qu'il doit bloquer, ce qui lui permet de s'initialiser en tout premier et d'intercepter l'appel d'initialisation des autres SDK au niveau du code natif lui-même, sans dépendre du rendu d'un composant web. Cette architecture réduit structurellement la fenêtre de risque, mais elle a un coût organisationnel : elle exige que le fournisseur du CMP maintienne, teste et publie une version native distincte pour chaque plateforme, y compris pour les frameworks hybrides comme React Native ou Flutter, et qu'il la mette à jour à chaque changement majeur d'iOS ou d'Android. Un fournisseur qui ne propose qu'un SDK web adapté, sans SDK natif réellement compilé pour chaque plateforme, ne peut pas offrir cette garantie, quelle que soit sa documentation marketing.
Ce que cela signifie concrètement pour le choix d'un fournisseur : demander, avant contractualisation, si le blocage de consentement est appliqué au niveau du code natif de l'application ou au niveau d'un composant web encapsulé, et exiger une preuve technique — pas une déclaration — que l'état de consentement est disponible avant l'appel d'initialisation de chaque SDK tiers. Une solution de consentement dotée de SDK natifs pour iOS, Android, React Native et Flutter, avec journalisation exportable de chaque consentement et de chaque révocation, répond directement à cette exigence de preuve sans que l'équipe produit ait à l'établir elle-même à chaque contrôle.
Synchroniser le Consentement Entre Appareils Sans Recréer le Problème
À mesure que les utilisateurs passent d'une app mobile à un site web puis à une télévision connectée sous le même compte, la tentation de synchroniser le consentement entre ces terminaux grandit, en particulier pour éviter l'effet de « consentement redemandé » qui agace l'utilisateur et fait chuter le taux d'acceptation. Le 16 janvier 2026, la CNIL a publié ses recommandations finales encadrant ce mécanisme, qu'elle qualifie de consentement multi-terminaux : il ne s'applique qu'aux environnements où l'utilisateur est authentifié sur un compte, et reste facultatif, mais dès qu'il est activé, il doit respecter un cadre précis.
Trois exigences structurent ce cadre. D'abord, une obligation d'information explicite : l'utilisateur doit savoir, au moment même où il exprime son choix, que celui-ci s'appliquera à l'ensemble des terminaux connectés à son compte, pas seulement à celui qu'il utilise. Ensuite, une règle de résolution des conflits, pour le cas où un utilisateur aurait déjà exprimé un choix différent sur un autre appareil avant de se connecter : la CNIL autorise deux méthodes, retenir le choix le plus récent, ou faire prévaloir la préférence déjà enregistrée sur le compte, mais impose que l'une des deux soit choisie et appliquée de façon cohérente, pas laissée à un comportement non défini du système. Enfin, une information renouvelée lors de la connexion depuis un nouveau terminal, rappelant que le choix qui va s'appliquer provient d'un autre appareil.
Pour une application mobile qui partage un compte utilisateur avec un site web ou une application TV, la conséquence pratique est qu'un identifiant de synchronisation ne peut pas être une simple valeur en clair partagée entre systèmes : le mécanisme doit permettre de retrouver quel choix s'applique, quand il a été exprimé, et sur quel terminal, de façon exportable pour un contrôle. À l'inverse, une application qui n'implémente pas cette synchronisation reste parfaitement conforme : la CNIL ne rend pas le mécanisme obligatoire, elle encadre uniquement ceux qui choisissent de l'activer.
Les Clauses à Exiger Contractuellement de Chaque Fournisseur de SDK
Le guide des accords de traitement des données détaille la structure générale d'un DPA ; les paragraphes qui suivent se concentrent sur ce qu'un contrat de SDK doit ajouter à ce socle. L'article 28 du RGPD impose un contrat écrit entre le responsable de traitement et chaque sous-traitant, couvrant au minimum huit obligations : traitement sur instruction documentée uniquement, confidentialité du personnel autorisé, mesures de sécurité appropriées, recours à un sous-traitant ultérieur seulement avec autorisation préalable, assistance pour répondre aux demandes des personnes concernées, assistance en cas de violation de données, suppression ou restitution des données à l'issue du contrat, et mise à disposition des informations nécessaires à un audit.
Pour un fournisseur de SDK spécifiquement, la recommandation CNIL ajoute trois exigences qui ne figurent pas explicitement dans le texte générique de l'article 28 mais qui en découlent directement dans ce contexte. Le contrat doit prévoir la fourniture d'une documentation technique précise du traitement réellement mis en œuvre par le SDK une fois intégré, distincte de toute documentation marketing générique. Il doit également garantir le blocage effectif de tout traitement ou accès aux données du terminal nécessitant un consentement, jusqu'à ce que celui-ci soit valablement obtenu — une garantie contractuelle, pas seulement une capacité technique annoncée. Enfin, il doit organiser la capacité du fournisseur à traiter les demandes d'exercice des droits des personnes concernées, via une API ou un canal documenté, et non uniquement la collecte des données.
À ces obligations s'ajoute, depuis l'avis 22/2024 du CEPD, une exigence de traçabilité de la chaîne de sous-traitance : le contrat devrait donner à l'éditeur un droit d'être informé de tout sous-traitant ultérieur introduit par le fournisseur de SDK, avec une description suffisante du traitement qu'il réalise, pour que l'éditeur puisse remplir son propre devoir de vérification sans dépendre uniquement de la bonne foi du fournisseur direct. La sanction Mobius Solutions illustre pourquoi la clause de suppression en fin de contrat mérite une attention particulière plutôt qu'une formulation type : elle devrait prévoir un mécanisme de confirmation vérifiable de la suppression, et pas seulement l'engagement de principe à la réaliser.
Comparatif : Architectures de Consentement Mobile
| Approche | Ce qu'elle exige du fournisseur | Risque de conformité principal | Quand elle convient |
|---|---|---|---|
| SDK natif dédié par plateforme (iOS, Android, React Native, Flutter) | Maintenance et mise à jour de plusieurs SDK distincts, alignées sur chaque version majeure d'OS | Faible si le blocage est réellement appliqué au niveau du code natif ; dépend de la rigueur de maintenance du fournisseur | Applications avec volume d'utilisateurs important ou exposition réglementaire élevée, où la preuve technique de blocage doit résister à un contrôle |
| Passerelle WebView unique adaptée du web | Un seul composant à maintenir, mais dépendant du rendu du navigateur embarqué | Élevé : délai entre rendu du consentement et lecture par le code natif, difficile à documenter comme preuve de blocage | Applications à très faible volume de SDK tiers, en phase de test, où le risque d'exposition reste limité |
| CMP hybride (interface native minimale + WebView pour les préférences détaillées) | Un socle natif pour le blocage initial, une interface web pour la granularité fine | Modéré : le blocage initial est fiable, mais la synchronisation entre les deux couches doit être vérifiée explicitement | Applications avec un grand nombre de catégories de traceurs à présenter, où l'expérience de personnalisation détaillée prime sur la simplicité |
| Solution développée en interne | Ressources d'ingénierie dédiées en continu, sur chaque plateforme et à chaque mise à jour d'OS | Élevé à long terme : la charge de maintenance dépasse rapidement les ressources allouées, ce qui dégrade la fiabilité du blocage dans le temps | Rare en pratique au-delà d'un prototype ; justifiable seulement pour des besoins de conformité très spécifiques qu'aucun fournisseur du marché ne couvre |
Erreurs de Gouvernance Qui Reviennent le Plus Souvent
Accepter la qualification de sous-traitant proposée par le fournisseur de SDK sans la vérifier au regard de l'usage réel des données reste l'erreur la plus fréquente chez les équipes juridiques qui traitent la conformité SDK comme une simple case à cocher contractuelle. La qualification correcte dépend de ce que le fournisseur fait des données, pas de ce qu'il déclare dans ses conditions générales.
Ne pas relancer l'analyse d'impact après l'ajout d'un nouveau SDK publicitaire ou analytique est une deuxième erreur structurelle : l'AIPD documente un état des traitements à un instant donné, et un SDK ajouté six mois plus tard avec un comportement de collecte différent rend cette documentation obsolète, précisément sur le point qu'un contrôle CNIL vérifiera en priorité.
Signer un contrat de sous-traitance sans clause de suppression vérifiable en fin de relation, ou sans droit d'audit réellement exerçable, expose l'éditeur au même type de risque que celui matérialisé par la sanction Mobius Solutions, même si c'est le fournisseur, et non l'éditeur, qui a été directement sanctionné dans ce dossier précis. Un contrat qui prévoit la suppression sans mécanisme de confirmation reste, en pratique, un engagement de principe difficile à faire respecter ; la liste des amendes RGPD les plus importantes donne un ordre de grandeur de ce que ce type de manquement peut coûter une fois un dossier instruit.
Activer une synchronisation de consentement entre terminaux sans définir de règle explicite de résolution des conflits de choix, en s'appuyant sur le comportement par défaut d'un fournisseur de CMP plutôt que sur une décision documentée, expose à un manquement direct aux recommandations CNIL du 16 janvier 2026 dès que deux appareils du même compte présentent des historiques de consentement divergents.
Checklist de Conformité Opérationnelle
- Chaque SDK intégré dispose d'une finalité documentée et d'une base légale associée à cette finalité précise, pas à l'application dans son ensemble.
- La qualification de chaque fournisseur de SDK (responsable, sous-traitant, aucun rôle) a été vérifiée au regard de l'usage réel des données, pas seulement de sa déclaration contractuelle.
- Le contrat avec chaque fournisseur de SDK contient les huit obligations de l'article 28, plus la documentation technique du traitement réel, la garantie de blocage effectif, et une clause de suppression vérifiable en fin de contrat.
- L'AIPD est à jour par rapport à l'inventaire actuel des SDK et a été relancée depuis le dernier ajout ou changement de comportement d'un SDK existant.
- L'architecture du CMP applique le blocage de consentement au niveau du code natif de l'application, avec une preuve technique disponible, pas seulement une déclaration du fournisseur.
- Si une synchronisation de consentement entre terminaux est active, elle respecte l'obligation d'information, la règle de résolution des conflits, et le rappel lors de la connexion depuis un nouveau terminal exigés par la CNIL depuis janvier 2026.
- La liste des sous-traitants ultérieurs de chaque fournisseur de SDK est connue et documentée, conformément à l'obligation de vérification issue de l'avis 22/2024 du CEPD.
FAQ
Un fournisseur de SDK peut-il se déclarer sous-traitant par contrat même s'il traite les données pour son propre compte ?
Non. La CNIL a explicitement averti que la qualification pré-contractuelle qu'un fournisseur de SDK s'attribue lui-même n'est pas systématiquement conforme au RGPD si elle ne correspond pas à l'usage réel des données. Si le fournisseur poursuit sa propre finalité, il doit être qualifié de responsable de traitement, quelle que soit la clause rédigée dans ses conditions générales.
À partir de quel seuil une application mobile doit-elle réaliser une AIPD ?
Dès que deux des neuf critères du CEPD sont réunis : évaluation, décision automatisée, surveillance systématique, données sensibles, grande échelle, croisement de données, personnes vulnérables, usage innovant, ou obstacle à l'exercice d'un droit. Le suivi de localisation combiné à un profilage publicitaire suffit généralement, à lui seul, à franchir ce seuil.
Une passerelle WebView pour le consentement mobile est-elle interdite par le RGPD ?
Non, elle n'est pas interdite, mais elle porte un risque de conformité plus élevé qu'un SDK natif : le délai entre le rendu du composant web et la lecture de son résultat par le code natif de l'application est plus difficile à documenter comme preuve d'un blocage effectif, ce qui complique la démonstration de conformité lors d'un contrôle.
Le consentement multi-terminaux est-il obligatoire pour une application mobile ?
Non. Les recommandations CNIL du 16 janvier 2026 encadrent ce mécanisme, elles ne l'imposent pas. Une application qui ne le met pas en place reste conforme, à condition de recueillir un consentement propre sur chaque terminal.
Qui est responsable si un SDK tiers continue de collecter des données après un refus de consentement ?
L'éditeur de l'application reste responsable du traitement effectué par le SDK, y compris lorsque le comportement réel de celui-ci diverge de sa documentation. Le fournisseur du SDK peut également être directement sanctionné s'il agit en tant que sous-traitant défaillant, comme l'a montré la sanction de 1 million d'euros contre Mobius Solutions Ltd en décembre 2025, mais cette sanction du sous-traitant ne dispense pas l'éditeur de sa propre responsabilité de contrôleur.
Faut-il reprendre l'analyse d'impact chaque fois qu'un nouveau SDK est intégré ?
Uniquement lorsque le nouveau SDK modifie les catégories de données collectées, les finalités poursuivies, ou le niveau de risque déjà documenté. Un SDK dont le comportement de collecte diverge de ce qui figure dans l'AIPD existante rend cette dernière obsolète sur ce point précis, ce qui justifie une mise à jour ciblée plutôt qu'une reprise complète du document.
La conformité mobile, une fois la mécanique de blocage technique en place, se joue désormais sur trois terrains distincts : la base légale attribuée à chaque finalité, la qualification vérifiée de chaque fournisseur de SDK, et une architecture de consentement capable de prouver, pas seulement d'afficher, qu'un refus a été respecté. Documenter ces trois couches séparément, plutôt que de les traiter comme un bloc de conformité générique, est ce qui distingue une application qui résiste à un contrôle CNIL de celle qui ne le découvre qu'au moment du contrôle. La Solution de Consentement Cookie & SDK de Secure Privacy, avec ses SDK natifs pour iOS, Android, React Native et Flutter, ses journaux de consentement exportables et infalsifiables, et sa prise en charge de plus de 55 régimes de confidentialité, donne à l'équipe juridique la preuve technique qu'un contrôle demandera, sans que l'équipe produit ait à la construire elle-même à chaque nouvelle intégration de SDK. Planifiez une démonstration pour évaluer comment elle s'applique à l'architecture de votre application.