Résumé pour la direction

Le RGPD n’a presque pas changé, la technologie sur laquelle il s’applique si
Les compétences techniques font la différence entre connaître une mesure et savoir contre quoi elle protège
Threat modeling et AIPD se complètent : ensemble, ils révèlent ce que chacun manque séparément
La pseudonymisation n’est pas l’anonymisation, et le cloud n’est pas un bloc unique
Le tracking va bien au-delà de ce que couvre un bandeau cookies
La question la plus efficace en réunion technique porte sur les conséquences, pas sur la conformité

Le RGPD n’a pas changé. La technologie sur laquelle vous l’appliquez, si.

Vous sortez d’une réunion technique sur une nouvelle application. Vous avez compris chaque mot — chiffrement, API, tokenisation, tenant — et pourtant vous ne sauriez pas dire si le risque est couvert ou simplement déplacé. Ce n’est pas un manque de compétence. C’est un problème de traduction.

Le texte avec lequel vous travaillez n’a pratiquement pas bougé depuis 2018. La technologie sur laquelle il faut l’appliquer, elle, est méconnaissable : l’infrastructure est passée dans le cloud, des fonctions d’IA sont intégrées à des logiciels que vous utilisez depuis des années, et le tracking ne passe plus uniquement par les cookies. Celui qui a construit sa représentation technique il y a quelques années applique des règles correctes à une image périmée.

La conformité n’est pas la même chose que comprendre où se situe le risque. Pour la première, un registre suffit. Pour la seconde, il faut pouvoir tenir la conversation avec l’IT.

Pourquoi ce n’est pas un luxe pour un juriste

On répète souvent qu’un DPO n’a pas à être un technicien. C’est exact. Mais la fonction exige quelque chose qui s’en approche : la capacité d’évaluer si une explication technique est complète.

Quand un développeur vous dit que les données « sont chiffrées », c’est une réponse à une question — mais pas nécessairement à la vôtre. Chiffrées en transit, ou également au repos ? Qui gère les clés ? Que se passe-t-il si le fournisseur reçoit une injonction légale ? Le chiffrement n’est pas une réponse. C’est la réponse à une question précise.

Le problème vient rarement d’une mesure absente. Il vient de ce que personne ne sait expliquer contre quoi elle protège. Ce n’est pas une question technique, c’est une question de gouvernance : personne n’a été désigné pour faire la traduction entre ce qui a été construit et ce qui est promis à la personne concernée.

Qu’est-ce que le threat modeling, et à quoi cela vous sert-il ?

Le threat modeling est une méthode structurée qui permet de déterminer, avant la construction, ce qui peut mal tourner dans un système, qui aurait intérêt à l’exploiter et quelles mesures couvrent réellement ces scénarios. Dans le monde de la security, c’est un classique. Pour la protection des données, l’outil est tout aussi utile — et pourtant rarement mobilisé.

L’intérêt tient à l’ordre des opérations. Une AIPD part du traitement et remonte vers les risques. Le threat modeling part du système et descend vers les chemins d’attaque. Placez les deux côte à côte et vous trouvez précisément ce qu’aucune des deux méthodes ne révèle seule : des traitements que personne n’avait déclarés, et des risques couverts sur le papier mais pas dans l’architecture.

Pour qui prend la protection des données dès la conception au sérieux, c’est l’instrument le plus concret qui existe. Il déplace la discussion vers le moment où elle peut encore changer quelque chose.

Les notions qui prêtent le plus à confusion

Trois exemples tirés de la pratique quotidienne.

Pseudonymisation et anonymisation. La pseudonymisation réduit le risque. L’anonymisation fait sortir les données du champ d’application du RGPD. Cette différence n’est pas une nuance : c’est une frontière juridique — et le premier terme sert régulièrement à revendiquer le second.

Le cloud comme bloc unique. Un environnement cloud est une architecture en couches, et la couche que vous gérez détermine ce que vous devez documenter. La répartition entre ce que couvre le fournisseur et ce qui reste chez vous est le cœur de la discussion — et elle figure rarement dans le contrat avec la clarté qu’on espérerait.

Le tracking dépasse largement les cookies. Le suivi par wifi ou bluetooth, le fingerprinting et la mesure côté serveur fonctionnent en dehors des mécanismes couverts par la plupart des bandeaux de consentement. Limiter son analyse à ce que règle le bandeau, c’est passer à côté d’une partie des traitements.

Pourquoi la technologie évolue plus vite que la réglementation

C’est exactement pour cette raison que nous continuons à actualiser cette formation. Ce qui relevait encore de l’exception il y a quatre ans est devenu la norme : des fonctions d’IA dans des logiciels existants, des API reliant des systèmes qui n’ont pas été conçus l’un pour l’autre, des applications mobiles embarquant des SDK tiers.

La question juridique reste la même — quelles données, quelle base légale, quelles mesures. La réponse, elle, évolue avec l’architecture. Une formation technique destinée aux juristes qui n’est pas régulièrement retravaillée vous enseigne une image qui n’existe plus.

Poser les bonnes questions

C’est au fond la compétence qui compte. Non pas concevoir l’architecture vous-même, mais orienter la discussion de manière à rendre les risques visibles.

Quelques questions qui fonctionnent dans presque toutes les réunions techniques :

quelles données quittent ce système, et vers où
que deviennent les données si nous changeons de fournisseur demain
qui peut accéder aux données sans que cela soit journalisé
quels composants proviennent de tiers, et qu’en font-ils
quel est ici le scénario que nous aurions le plus de mal à expliquer à une personne concernée

C’est la dernière qui fait le plus de travail. Elle déplace la conversation de la conformité vers les conséquences, et c’est précisément le pont entre votre rôle et celui des personnes assises en face de vous.

Par où commencer ?

Demandez un schéma d’architecture pour vos trois traitements les plus importants. S’il n’existe pas, vous tenez déjà votre premier constat.
Confrontez votre registre aux systèmes réels, pas aux noms de fournisseurs mais à ce qui tourne effectivement.
Vérifiez une affirmation par réunion. Choisissez « les données sont chiffrées » ou « c’est anonymisé » et creusez jusqu’à pouvoir le réexpliquer vous-même.
Cartographiez vos flux vers des tiers, y compris les SDK des applications mobiles et les scripts de mesure du site web.
Demandez à être associé avant que la conception ne soit figée. La protection des données dès la conception ne fonctionne que si vous êtes à table pendant qu’il reste des choix à faire.

Apprenez à parler la langue du département IT

Data Protection & Technology est une formation de deux jours destinée aux juristes, avocats et professionnels de la privacy sans bagage informatique. Elle a été entièrement retravaillée récemment, parce que la technologie le méritait.

Au programme, notamment :

le threat modeling appliqué à l’analyse de protection des données
data protection by design et by default, avec exercices en groupe
les normes de sécurité de l’information, comme l’ISO 27701
l’infrastructure de périmètre et l’architecture d’un environnement cloud
la cryptographie et les techniques de pseudonymisation
cookies, analytics et tracking via wifi et bluetooth
les concepts techniques de l’intelligence artificielle, les applications mobiles et les API

15–16 octobre 2026 — Van der Valk Hôtel Nivelles-Sud, en français.
Formateurs : Herman Maes et Christoph Balduck.
1 375 € HTVA, 1 095 € pour les institutions publiques, lunch, supports de cours et accès à la plateforme d’apprentissage compris.
Portefeuille PME possible sous le thème cybersécurité pour les entreprises disposant d’un siège d’exploitation en Flandre.

Découvrez le programme complet et inscrivez-vous dès aujourd’hui

Sources et pour aller plus loin

Règlement (UE) 2016/679 (RGPD) — EUR-Lex, articles 25 et 32
Autorité de protection des données — recommandations sur les mesures de sécurité
Centre pour la Cybersécurité Belgique
Threat Modeling Practitioner — pour approfondir le sujet

Questions fréquentes

Faut-il des connaissances informatiques préalables ?

Non. La formation s’adresse explicitement aux profils non techniques : juristes, avocats, DPO et professionnels de la privacy. Nous attendons en revanche une connaissance juridique du RGPD et une utilisation courante de l’informatique.

Est-ce une formation en security ?

Non. Une formation en security vous apprend à sécuriser des systèmes. Celle-ci vous apprend à suivre une discussion technique, à poser les bonnes questions et à repérer les risques pertinents pour la protection des données.

Quelle différence avec L’IA pour les DPD ?

Data Protection & Technology couvre l’ensemble des bases techniques — réseaux, cloud, cryptographie, tracking, pseudonymisation — l’IA n’étant qu’un sujet parmi d’autres. L’IA pour les DPD consacre trois jours à l’IA seule, AI Act compris. Les deux formations se complètent.

Y a-t-il un examen ?

Non. Un test de connaissances est disponible sur la plateforme d’apprentissage et vous recevez une attestation de participation.

Quelle est la taille du groupe ?

Entre 8 et 24 Students, en pratique une vingtaine. Assez petit pour soumettre votre propre situation.

La formation donne-t-elle droit à des points de formation permanente ?

Elle est reconnue par l’Institut des juristes d’entreprise (IJE), la FSMA, l’IEC et l’IRE, et elle entre en ligne de compte pour leurs obligations de formation continue.

Data Protection & Technology : dialoguer avec l’IT