Les DPDP Rules indiennes : le travail d'ingénierie à terminer d'ici mai 2027

L'Inde a publié les Digital Personal Data Protection Rules, 2025 le 13 novembre 2025, sous la référence G.S.R. 846(E). La plupart des règles qui touchent votre produit ne sont pas encore en vigueur. La règle 1(4) prévoit que les règles 3, 5 à 16, 22 et 23 « entrent en vigueur dix-huit mois après la date de publication de la présente Gazette ». Comptez dix-huit mois et vous arrivez au 13 mai 2027, soit un peu plus de sept mois à partir d'aujourd'hui.

Elles couvrent l'information des personnes, la sécurité, la notification des violations, la conservation et l'effacement, les données des enfants et les demandes d'exercice des droits. La règle 4, qui permet aux gestionnaires du consentement (Consent Managers) de s'enregistrer auprès du Data Protection Board, l'autorité de protection des données, arrive plus tôt : un an après la publication, donc vers le 13 novembre 2026. L'annonce du gouvernement parle d'un calendrier progressif sur 18 mois.

Cet article s'adresse aux CTO et aux responsables produit des applications grand public, fintechs, edtechs et sociétés d'e-commerce indiennes, ainsi qu'aux entreprises étrangères qui ont des utilisateurs en Inde. La loi s'applique aux traitements effectués hors d'Inde lorsqu'ils sont réalisés « dans le cadre de toute activité liée à l'offre de biens ou de services aux personnes concernées sur le territoire de l'Inde » (section 3(b)). Ce qui suit décrit le logiciel que vous devez construire ou modifier. Ce n'est pas une analyse juridique des écarts : savoir si vous êtes dans le champ, quelles exemptions s'appliquent et comment formuler vos finalités sont des questions pour votre avocat.

Qui a réellement du développement à faire

Si toutes vos données clients se trouvent dans une seule plateforme SaaS du marché, une grande partie de la tuyauterie (chiffrement, journaux d'accès, tâches d'effacement) vient de la feuille de route de l'éditeur. Votre travail porte sur l'information des personnes, la configuration et les contrats. Lisez ces contrats : la règle 6(1)(f) veut que les mesures de sécurité y soient inscrites, et une illustration de la règle 8 vous rend responsable de la conservation, par votre fournisseur cloud, des données et des journaux pendant l'année requise.

Le gros du travail retombe sur les entreprises qui exploitent leurs propres applications et bases de données, alimentent un entrepôt de données par une douzaine de pipelines et embarquent des SDK tiers dans leur client mobile. C'est-à-dire la majeure partie de l'internet grand public indien.

Ce que chaque règle exige de votre logiciel

L'information des personnes (règle 3)

La notice doit être « compréhensible indépendamment de toute autre information » que vous publiez. Elle donne au minimum « une description détaillée, poste par poste, de ces données personnelles », la finalité déterminée, et une description précise des biens, services ou usages que permet le traitement. Elle doit aussi indiquer comment retirer son consentement, exercer ses droits et saisir le Board.

En pratique :

• Générez les notices à partir d'un inventaire des données. Champ par champ, rattaché aux finalités. « Nous pouvons collecter des informations telles que » n'est pas une description poste par poste.
• Versionnez chaque notice. Chaque enregistrement de consentement doit pointer vers le texte exact que l'utilisateur a vu.
• Prévoyez les langues. La section 6(3) de la loi impose la possibilité de lire une demande de consentement en anglais ou dans l'une des langues de la huitième annexe de la Constitution. Gardez le contenu des notices sous forme de chaînes traduisibles, pas de PDF.
• Couvrez les utilisateurs existants. La section 5(2) impose une notice, « dès que cela est raisonnablement possible », aux personnes qui ont consenti avant l'entrée en vigueur de la loi. C'est une campagne à destination de toute votre base d'utilisateurs.

Consentement, retrait et gestionnaires du consentement

Le consentement prévu à la section 6 doit être spécifique et limité aux données dont la finalité a besoin. La section 6(10) vous impose la charge de la preuve : en cas de litige, c'est à vous de montrer que la notice a été fournie et le consentement obtenu. C'est cette phrase qui explique pourquoi il vous faut un registre des consentements plutôt qu'une colonne booléenne.

Un registre exploitable enregistre, par utilisateur et par finalité : la version de la notice, l'horodatage, le canal (web, application, gestionnaire du consentement) et l'action (consentement donné ou retiré). En ajout seul.

Le retrait doit être aussi simple que le consentement (règle 3(c)(i), section 6(4)). Si le consentement tenait en un geste pendant l'inscription, le retrait ne peut pas être un e-mail au support. Il doit aussi se propager. La section 6(6) vous impose de cesser le traitement, et de le faire cesser par vos sous-traitants (Data Processors), dans un délai raisonnable. Le service de consentement publie donc les événements de retrait vers chaque système et chaque prestataire qui agit pour cette finalité : CRM, plateforme marketing, pipeline d'analytique.

Un gestionnaire du consentement est un point de contact unique enregistré par lequel un utilisateur peut « donner, gérer, revoir ou retirer son consentement » (section 6(7)). Selon la première annexe, il doit s'agir d'une société constituée en Inde dont l'actif net atteint au moins deux crores de roupies (20 millions), sa plateforme doit être certifiée de façon indépendante selon des normes que publie le Board, il ne doit pas pouvoir lire les données qu'il achemine, et il conserve les enregistrements de consentement pendant au moins sept ans.

Les règles laissent cette norme au Board. Construisez dès maintenant un chemin entrant, pour qu'un consentement ou un retrait provenant d'une plateforme externe soit traité exactement comme s'il venait de votre propre interface, et ne vous engagez sur un format d'échange qu'une fois que le Board en aura publié un. Les enregistrements ouvrent vers le 13 novembre 2026 : l'intégration commencera donc réalistement début 2027.

Mesures de sécurité et journaux (règle 6)

La liste minimale : chiffrement, obfuscation, masquage ou tokenisation ; contrôle d'accès sur les systèmes concernés ; « une visibilité sur l'accès à ces données personnelles, au moyen de journaux, d'une surveillance et d'un examen appropriés » ; des sauvegardes permettant de poursuivre le traitement après un incident ; et la conservation de « ces journaux et données personnelles pendant une durée d'un an ».

C'est sur l'exigence de journalisation que la plupart des systèmes pèchent. Les journaux d'infrastructure ne vous disent pas qui a lu la fiche de quel client depuis quel service, et vous avez besoin de cette réponse un an plus tard. Donc : une journalisation des accès au niveau applicatif sur chaque magasin de données personnelles, envoyée vers un endroit que les services ne peuvent pas modifier, et conservée au moins un an. Commencez tôt ; la déployer sur de nombreux services prend plus de temps que n'importe quelle fonctionnalité de cette liste.

La notification des violations (règle 7)

Dès que vous avez connaissance d'une violation, vous en informez chaque utilisateur concerné « sans délai », via son compte ou un canal de contact enregistré : ce qui s'est passé, les conséquences probables pour lui, ce que vous faites, ce qu'il peut faire, et qui contacter. Le Board reçoit une description sans délai, puis, dans les 72 heures, un rapport détaillé sur les causes, les mesures d'atténuation, les éventuelles conclusions sur l'auteur, les mesures correctives et les notifications envoyées aux utilisateurs. Le Board peut accorder un délai plus long sur demande écrite.

Côté logiciel : un moyen de calculer l'ensemble des personnes concernées (qui dépend des journaux d'accès ci-dessus), des modèles rédigés à l'avance, un chemin de notification qui ne passe pas par le système compromis, et une procédure qui désigne qui dépose le rapport auprès du Board.

Effacement et conservation (règle 8)

La section 8(7) impose l'effacement lorsque le consentement est retiré ou que la finalité n'est plus servie, sauf si une autre loi impose la conservation. La règle 8 ajoute deux choses.

D'abord, trois catégories de la troisième annexe sont réputées avoir atteint la fin de leur finalité après trois ans sans contact : les entités d'e-commerce comptant au moins deux crores (20 millions) d'utilisateurs enregistrés en Inde, les intermédiaires de jeux en ligne en comptant au moins cinquante lakhs (5 millions), et les intermédiaires de réseaux sociaux en comptant au moins deux crores. L'accès au compte et les jetons de valeur stockée font exception. Vous devez prévenir l'utilisateur au moins 48 heures avant l'effacement, et une connexion l'annule. Cela représente un suivi de l'inactivité, un planificateur et une tâche de notification. Les trois ans courent à compter du dernier contact ou de l'entrée en vigueur des Rules, la date la plus tardive étant retenue : aucun effacement n'est donc dû avant des années, mais le suivi doit être juste dès le départ.

Ensuite, la règle 8(3) fixe un plancher : les données personnelles, les données de trafic et les journaux de traitement sont conservés au moins un an à compter du traitement. L'illustration de la règle est une commande de livre numérique dont les détails doivent survivre à la suppression du compte. « Supprimer mon compte » ne peut donc pas signifier DELETE FROM users. Cela signifie : cesser le traitement, déplacer ce qui doit être conservé dans un magasin à accès restreint avec une date de conservation, et l'effacer une fois cette date passée. Chaque table a besoin d'une classe de conservation, tout comme chaque copie dans les sauvegardes, l'entrepôt de données et les systèmes de vos sous-traitants.

Demandes d'exercice des droits et coordonnées (règles 9 et 14)

Les utilisateurs peuvent demander un récapitulatif de leurs données et des traitements, ainsi que l'identité de chaque responsable de traitement (Data Fiduciary) et sous-traitant avec qui vous les avez partagées (section 11), demander leur rectification, leur complément, leur mise à jour ou leur effacement (section 12), et désigner une personne pour agir en leur nom en cas de décès ou d'incapacité (section 14). La règle 14 vous impose de publier la manière de faire une demande et l'identifiant dont vous avez besoin, et de répondre aux réclamations dans un délai publié qui ne peut excéder quatre-vingt-dix jours. La règle 9 impose les coordonnées de votre Data Protection Officer, ou d'une personne capable de répondre, dans chaque réponse.

À construire : un formulaire de demande dans l'application, une vérification d'identité liée au compte, un suivi des dossiers qui gère le délai de quatre-vingt-dix jours, un export qui retrouve les données d'un utilisateur dans tous les services, et un registre des partages pour que la question « avec qui les avez-vous partagées » soit une requête plutôt qu'une enquête.

Enfants et personnes en situation de handicap (règles 10 à 12)

Au sens de la loi, un enfant est toute personne de moins de dix-huit ans. Avant de traiter les données d'un enfant, il vous faut le consentement vérifiable d'un parent, et la règle 10 impose de vérifier que ce parent est un adulte identifiable. La vérification peut s'appuyer sur des données d'identité et d'âge que vous détenez déjà pour un parent inscrit, sur des données que le parent fournit, ou sur « un jeton virtuel associé à ces données » émis par une entité habilitée, ce qui inclut un fournisseur de services Digital Locker. DigiLocker, du MeitY, publie des API pour les demandeurs à destination des organisations qui récupèrent des documents vérifiés ; faites confirmer par votre avocat quelles sources satisfont à la règle pour vos parcours.

La section 9(3) interdit le pistage, la surveillance comportementale et la publicité ciblée visant les enfants. Pour une application grand public, c'est un problème de SDK, et le choix par défaut le plus sûr consiste à désactiver les SDK d'analytique et de publicité pour tout compte signalé comme mineur plutôt que de les configurer pour qu'ils deviennent conformes.

La règle 11 couvre les tuteurs légaux des personnes en situation de handicap : vous vérifiez que le tuteur a été désigné par un tribunal, une autorité désignée ou un comité local. Cela représente un téléversement de documents et une file d'examen manuel.

La règle 12 et la quatrième annexe exemptent certains traitements de l'exigence de consentement parental et de l'interdiction du pistage, notamment les soins de santé, les établissements d'enseignement (pour les activités éducatives et la sécurité), la localisation en temps réel à des fins de sécurité, et la vérification qu'un utilisateur n'est pas un enfant. Une edtech ne doit pas supposer qu'elle compte comme « établissement d'enseignement ». Obtenez une réponse écrite sur ce point.

Significant Data Fiduciaries (règle 13)

Si le gouvernement vous désigne comme Significant Data Fiduciary, la règle 13 ajoute une analyse d'impact relative à la protection des données et un audit annuels, avec un rapport au Board, des vérifications démontrant que vos logiciels algorithmiques ne mettent pas en danger les droits des utilisateurs, et la conservation en Inde de toute donnée personnelle désignée par le gouvernement. La section 10 de la loi ajoute un Data Protection Officer basé en Inde et un auditeur indépendant des données.

Ce que coûte une erreur

L'annexe de la loi fixe les sanctions maximales : jusqu'à 250 crores de roupies (2,5 milliards) pour défaut de mesures de sécurité raisonnables, jusqu'à 200 crores (2 milliards) pour défaut de notification d'une violation, jusqu'à 200 crores pour manquement aux obligations relatives aux données des enfants, jusqu'à 150 crores (1,5 milliard) pour les obligations supplémentaires d'un Significant Data Fiduciary, et jusqu'à 50 crores (500 millions) pour la violation de toute autre disposition.

Un plan sur sept mois

Octobre 2026 : inventaire. Recensez chaque magasin et chaque pipeline qui détient des données personnelles d'utilisateurs indiens, y compris les sauvegardes, l'entrepôt de données, les journaux et les sous-traitants. Rattachez chaque champ à une finalité. Signalez les utilisateurs mineurs, vérifiez les seuils de la troisième annexe, et obtenez l'avis de votre avocat sur le champ d'application et les exemptions.

Novembre 2026 : conception. Modèle de contenu et versionnage des notices, schéma du registre des consentements, classes de conservation par table, parcours des demandes d'exercice des droits. Lancez la journalisation des accès. Après le 13 novembre environ, surveillez le Board pour les gestionnaires du consentement enregistrés et la norme d'interopérabilité.

De décembre 2026 à janvier 2027 : notices et consentement. Livrez le service de consentement, avec la diffusion des événements de retrait vers les sous-traitants. Traduisez les notices.

Février 2027 : conservation et effacement. Magasin de conservation à accès restreint, tâches d'effacement dans les magasins principaux et chez les sous-traitants, et le suivi de l'inactivité si vous relevez d'une catégorie de la troisième annexe. Modifiez les contrats de sous-traitance pour les mesures de sécurité et la conservation d'un an.

Mars 2027 : droits et violations. Formulaire de demande, vérification, suivi des dossiers sur quatre-vingt-dix jours, export transversal aux services, registre des partages. Procédure en cas de violation, modèles et chemin de notification indépendant, puis un exercice sur table.

Avril 2027 : enfants et utilisateurs existants. Contrôle d'âge, vérification parentale, désactivation des SDK pour les mineurs, examen des tuteurs. Envoyez la notice de la section 5(2) aux utilisateurs existants. Intégrez les gestionnaires du consentement si la norme est publiée.

Début mai 2027 : tests et gel. Retirez un consentement et vérifiez que la plateforme marketing s'est arrêtée. Demandez un effacement et vérifiez que la copie de l'entrepôt de données est passée en conservation. Rassemblez les preuves, et cessez toute modification la semaine précédant le 13 mai.

Ce plan suppose trois ou quatre chantiers en parallèle. Sur des systèmes anciens ou non documentés, l'inventaire seul prend plus d'un mois.

Où cela s'inscrit

Si vous avez construit pour le RGPD, une bonne partie de la tuyauterie se réutilise, et notre guide d'ingénierie du RGPD couvre les schémas de consentement et d'effacement. Les différences qui font mal sont la notice poste par poste, le plancher de conservation d'un an et le consentement parental vérifiable jusqu'à dix-huit ans. Pour un autre marché asiatique doté de son propre régime, voyez l'enregistrement PSE en Indonésie.

Nous intégrons des services de consentement, des tâches de conservation et d'effacement, la journalisation des accès et des circuits de demandes d'exercice des droits dans des produits existants, et nous ajoutons des ingénieurs à votre équipe par le renforcement d'équipe quand le plan demande plus de bras que vous n'en avez. Nous sommes ingénieurs, pas juristes : le périmètre et la formulation relèvent de votre avocat, et nous construisons selon sa réponse. Écrivez à office@c9group.dev.