Expertise · Conformité GDPR et Loi 195/2024

Nous apportons un système qui parle avec les clients dans un état où il peut être montré à un contrôleur, et nous vérifions cela à partir du code, pas à partir d’un questionnaire.

La loi n° 195/2024 s’applique en République de Moldova à partir du 23 août 2026 et transpose le GDPR. Nous faisons la partie technique : nous inventorient ce que le système collecte réellement, nous vérifions le comportement réel de la page, nous rédigeons le registre des activités de traitement et nous implémentons la rétention, le consentement et la suppression comme des fonctions qui s’exécutent. Nous ne donnons pas de conseil juridique.

Discuter d'un projet

Déjà construitDeux implémentations propres, plus le travail fait sur nous-mêmes. Premièrement : `gdpr-scan-md`, un scanner déterministe, sans composant d’intelligence artificielle, public sur `ongdpr.md` (vérifié avec curl le 06.09.2026 : redirect 308 vers `/ro`, puis 200 avec 95.131 octets). Il a sept modules, des pondérations et des seuils écrits dans un seul fichier comme source unique de vérité, et 488 cas de test `it()`/`test()` dans le répertoire de tests du moteur. Deuxièmement : le texte intégral de la Loi 195/2024 modélisé en format machine — 90 articles, 384 alinéas, 408 lettres, 9 chapitres, 16 sections — avec le MD5 du PDF source et la méthode d’extraction enregistrés dans le fichier, de sorte qu’une citation puisse être vérifiée jusqu’à la page. Troisième preuve, celle qui en dit le plus : le registre de l’art. 30 de ce site, rédigé pour nous, avec ses propres limitations déclarées et huit points encore ouverts. Réserve obligatoire : nous ne sommes pas un cabinet d’avocats et nous n’émettons pas d’avis juridiques. Un outil technique ne remplace pas un juriste, et nous le disons aussi dans le produit, pas seulement ici.

La Loi n° 195/2024 concernant la protection des données à caractère personnel a été adoptée le 25 juillet 2024, publiée au Monitorul Oficial n° 367-369 du 23 août 2024 et est entrée en vigueur le 23 août 2026. Elle transpose le Règlement (UE) 2016/679. Pour une entreprise en Moldavie, cela signifie que les obligations dont on parlait jusqu’à présent comme de « quelque chose d’européen » sont aujourd’hui des obligations locales, avec une autorité locale et avec des amendes calculées en lei ou en pourcentage du chiffre d’affaires, la valeur la plus élevée étant retenue.

La partie dont nous nous occupons est d’ordre technique. Un système qui parle avec les clients — un site avec formulaire, un assistant de chat, un agent qui répond au téléphone, un CRM — collecte des données à des endroits que plus personne ne garde en mémoire après la deuxième année. La politique publiée dit une chose, le code en fait une autre, et la divergence ne se voit pas jusqu’à ce que quelqu’un pose la question. Le travail commence donc par le code et par le comportement réel de la page, et non par un questionnaire rempli par quelqu’un qui se souvient de comment c’était l’an dernier.

Nous disons clairement ce que nous ne faisons pas : nous ne donnons pas de conseil juridique, nous n’émettons pas d’opinions, nous ne rédigeons pas de défenses et nous ne nous substituons pas à un juriste ni au responsable de la protection des données. Nous sommes des constructeurs. Nous produisons l’inventaire vérifié, la preuve technique, le registre et l’implémentation — le matériau avec lequel un juriste peut travailler, au lieu de partir de déclarations. Lorsque la question devient juridique, nous la marquons comme telle et la transmettons plus loin.

Le résultat se mesure autrement qu’on n’en a l’habitude. Non pas par le nombre de documents produits, mais par le nombre d’affirmations publiques qui ont tenu après vérification. Sur notre propre site, cet exercice a d’abord signifié des suppressions : un test de pénétration indépendant annuel, un journal d’audit de 180 jours, un chiffrement sur toutes les bases de données, des sauvegardes quotidiennes hors site, quatorze sous-traitants et deux emplacements d’hébergement — aucune n’a pu être étayée par une preuve, donc aucune n’est restée sur la page.

Conformité GDPR et loi n° 195/2024 — la partie d’ingénierie · vidéo en roumain, avec sous-titres et transcription en français

La transcription complète

Entrons directement dans le sujet. Bienvenue dans une nouvelle analyse, aujourd’hui nous abordons un défi énorme pour tout ce que signifie le monde des affaires, surtout dans le contexte des nouvelles réglementations en Repubblica Moldova. Notre focus absolu aujourd’hui : comment vérifier la conformité directement dans le code, et non à partir de tas infinis de papiers. Très souvent, lorsqu’il s’agit de confidentialité, tout le monde regarde les documents juridiques mis en ligne sur le site, mais, surprise, ces documents ne reflètent presque jamais la réalité technique du système, alors aujourd’hui nous explorons exactement comment nous pouvons extraire la pure vérité directement de l’infrastructure. Section 1. L’illusion de la conformité déclarative. Ou, en d’autres mots, ce que nous déclarons officiellement sur le papier versus ce que nous faisons réellement en pratique.

Réfléchissez un peu à ce que fait en réalité un site en arrière-plan quand personne ne le regarde. Un assistant virtuel ou une boutique en ligne fait fuir les données par toutes sortes de coins que, soyons honnêtes, l’équipe technique a probablement complètement oubliés deux ans après le lancement. Des dizaines d’outils tiers, de scripts d’analyse, de codes marketing, tout cela tourne silencieusement en arrière-plan, sans qu’un regard technique ne soit porté sous le capot, il est tout simplement impossible de savoir avec précision qui extrait quelles données ou où elles les envoie. Et voilà le piège ici. D’un côté, nous avons la théorie, cette politique de confidentialité statique, inchangée depuis des années et, le plus souvent, basée sur un modèle.

Et de l’autre ? Eh bien, de l’autre, il y a la réalité. Le code est vivant, extrêmement dynamique, il se met à jour en continu et aspire des données en arrière-plan. Cette rupture entre théorie et pratique est invisible, jusqu’au moment d’un audit sévère ou, bien pire, lors d’une faille de sécurité, quand plus personne ne peut ignorer l’éléphant dans la pièce. Nous passons maintenant à la section 2, MISA, à savoir la Loi 195/2024, avec un impact direct et assez dur à partir du 23 août 2026. Nous parlons en pratique d’obligations européennes transposées ici, sous forme de règles locales strictes, en République de Moldova, et le plafond maximal des amendes ? 2 millions de lei. Oui, vous avez bien entendu ?

2 millions. Ces sanctions sont pensées spécialement pour décourager l’ignorance. Un pauvre banner de cookies qui ne fonctionne pas correctement sur le plan technique n’est plus une simple erreur de design. C’est une énorme vulnérabilité juridique et financière. La loi est très claire et ne pardonne pas vraiment. Elle applique toujours la valeur la plus élevée entre le montant fixe et le pourcentage du chiffre d’affaires. Pour les obligations de base, les sanctions atteignent 1 million de lei ou 1 % du chiffre d’affaires. Mais attention, les éléments essentiels, c’est-à-dire tout ce qui concerne le consentement, les droits des personnes et les transferts de données, passent automatiquement dans la tranche supérieure, maximum 2 millions de lei ou 2 %. L’idée à retenir ici : toute erreur technique côté consentement est sanctionnée sans aménagement au niveau maximum.

Ce qui nous amène à la troisième section, la vérification dans le code ou, comme j’aime l’appeler, l’extraction de la vérité technique absolue. Vu les amendes énormes, nous ne pouvons tout simplement plus nous fier à la mémoire des gens ni à des questionnaires cochés à la hâte. La solution réside dans l’ingénierie, et le processus a trois étapes de fer. Étape 1. Nous lisons la source. Nous interrogeons le serveur pour voir clairement ce qui arrive en mémoire. Étape 2. Extrêmement important. Nous appuyons sur le bouton de refus des cookies et nous écoutons le trafic réseau pendant environ 3 secondes. Si les outils en arrière-plan continuent d’aspirer des données, c’est clair, il y a un problème. Et l’étape 3.

Nous rédigeons le célèbre Registre des Activités de Traitement en nous appuyant strictement sur ces preuves techniques incontestables. Ainsi, le document devient ancré dans la réalité. Pour standardiser toute cette histoire, les outils techniques, comme le scanner GDP Scan MD, utilisent un score mathématique fixe, avec un maximum de 1. Mais il y a ici une règle d’or, une règle très stricte. Un seul élément critique échoué plafonne instantanément le score final à 0,49. Bam, non conforme. Cela signifie que vous pouvez avoir la plus belle et la mieux rédigée politique de confidentialité au monde : si un tracker se lance avant que le visiteur n’appuie sur accepter, vous avez échoué au test. Les documents ne peuvent tout simplement pas sauver un code mal écrit.

Passons à la section 4. Le cas réel sur une plateforme propre. Un audit technique d’une transparence radicale. Pour démontrer que cela fonctionne, l’équipe derrière la méthodologie a décidé de tester son propre outil exactement sur son site. Et que voit-on ? Au fil des années, sur leur page publique, s’étaient accumulées toutes sortes d’affirmations corporatives fantastiques. Un journal d’audit de 180 jours, un chiffrement sur absolument toutes les bases de données, quelque 14 sous-traitants. Cela sonnait extrêmement professionnel, n’est-ce pas ? Seulement, tout cela était apparu là par inertie. Ils avaient simplement copié d’un document interne à un autre, sans vérifier dans le code source si ces choses étaient encore valables. Alors ils ont appliqué la règle technique avec une rigueur absolue.

Vous n’avez pas de document source extrait directement du code pour une affirmation ? On le retire ! Ils ont fait un grand nettoyage général. Toute une série de phrases pompeuses sur d’anciens tests ou des sauvegardes non pertinentes ont disparu complètement. La raison ? Simple. Il est beaucoup, beaucoup plus sûr d’avoir une page de conformité plus courte, honnête et ancrée à 100 % dans des faits réels, qu’un dossier rempli de promesses que vous ne pouvez pas prouver en cas de contrôle. Ah, et en plus de ce nettoyage, l’auto-audit a mis au jour quelque chose de fascinant à propos des chatbots intelligents basés sur l’AI. Ils apportent trois risques majeurs avec eux. 1. À la main, ils retiennent toutes sortes de données sensibles que les visiteurs y jettent complètement sans demande préalable.

2. Le transfert inévitable de ces textes vers un fournisseur de modèle tiers, généralement dans un autre pays. Et 3. L’aspect le plus critique, écoutez bien ici. L’écriture dans la mémoire du navigateur dès la simple ouverture de la page, avant que la personne ne clique. La seule solution ? Aller dans le code et bloquer le chargement du modèle jusqu’à ce que le visiteur décide effectivement d’appuyer sur le bouton de démarrage de la conversation. Nous arrivons aussi à la section 5, les limites techniques et juridiques. Jusqu’où va l’ingénierie et où faut-il laisser les professionnels du legal faire leur travail. Il est absolument clair que la méthodologie dans le code est vitale, mais ne nous faisons pas d’illusions, elle ne résout pas tout à elle seule.

L’outil technique s’occupe des choses tangibles. Il inventorie l’infrastructure, regarde dans le code et fournit des preuves claires sur le comportement du système. Cependant, attention, il ne représente pas un avis juridique. Un outil technique ne peut pas décider des fondements juridiques d’un contrat et n’interprète pas les lois. Cette partie est le territoire exclusif des avocats. En bref, la technologie coule une base en béton super solide, faite de preuves, et les juristes viennent construire la légalité au-dessus. Cette délimitation met en lumière une chose extraordinaire à propos du célèbre article 30, le Registre des Activités de Traitement. Je vous confie un secret, un registre vivant réellement généré à partir du code n’aura jamais l’air immaculé au premier scan.

Les lignes marquées comme non vérifiées, qui demandent une décision humaine, juridique, ce sont précisément elles qui montrent la transparence réelle d’une organisation. Tout registre qui, dès le premier jour, semble parfait, complet et sans aucune erreur ouverte est, dans presque tous les cas, une illusion bon marché, une simple fiche remplie à partir d’un modèle qui ignore complètement la complexité réelle d’un logiciel. Donc, en faisant le bilan de tout ce que j’ai raconté, en voyant cette différence colossale entre ce qui est écrit sur le papier et ce que la machinerie exécute en réalité, chez vous dans l’organisation, à quoi ressemble le processus de vérification ? La conformité repose-t-elle sur des documents poussiéreux, oubliés quelque part dans le sous-sol du site, ou sur des certitudes incontestables extraites directement du code actif ?

Passer à une vérification technique n’est pas seulement une case à cocher sur papier pour échapper à la Loi 195/2024. C’est la garantie suprême que vous respectez vraiment les données des gens. Un changement de perspective qui transforme tout simplement la manière dont nous pensons la sécurité.

Ce que cela comprend

Le travail, par composantes

L’inventaire se fait à partir du code et du serveur en production, pas à partir d’un questionnaire

La première étape consiste à lire le code source et à interroger la production : quels champs sont réellement écrits, où ils vont, ce qui est placé dans la mémoire du navigateur et à quel moment, quels services tiers chargent la page, ce que retient le journal du serveur et pendant combien de temps. Un exemple concret de notre propre inventaire : l’assistant de chat du site se chargeait à chaque affichage de page et écrivait l’identifiant de session et l’historique dans la mémoire locale du navigateur **avant** que le visiteur ne demande quoi que ce soit. Aucun questionnaire n’aurait révélé cela, car personne ne le savait.

Vérification comportementale : nous appuyons sur le bouton de refus et écoutons le réseau

La présence d’une bannière de consentement ne prouve rien. Notre scanner trouve la bannière, appuie effectivement sur le contrôle de refus, puis écoute le trafic réseau pendant trois secondes. Un outil de suivi ne compte comme infraction que s’il tirait déjà avant tout consentement et continue à tirer après le refus, sans signal de consentement refusé. Un site qui applique correctement le refus par défaut n’est pas sanctionné pour ses ping sans cookies — la règle a été ajoutée explicitement pour ne pas contredire la vérification qui récompense précisément ce comportement.

Le registre des activités de traitement, rédigé comme un document vivant

L’article 30 exige un registre des activités de traitement avec les finalités, les catégories de personnes et de données, les destinataires, les transferts, les délais de suppression et une description des mesures de sécurité. Nous le rédigeons ligne par ligne à partir de l’inventaire vérifié, et ce qui n’a pas pu être vérifié reste marqué « non vérifié », et non complété à partir d’un modèle. La règle de maintenance est écrite dans le document : si une modification de code change ce qui est collecté, à qui cela va ou combien de temps cela est conservé, le registre et la politique publiée sont modifiés **dans le même commit**. L’écart entre le code et la politique est précisément le problème qui génère le document.

Un score qui peut être reconstitué, pas une coche

Les sept catégories ont des pondérations fixes : cookies 0,25, mécanisme de consentement 0,20, politique 0,20, transport 0,15, formulaires 0,08, juridiction 0,07, identité du responsable du traitement 0,05 — somme exacte 1,0, vérifiée par un test. Une constatation échouée réduit sa catégorie proportionnellement à sa gravité : critique 1,0, élevé 0,6, moyen 0,3, faible 0,15 ; un avertissement coûte la moitié. Au-dessus de 80, c’est conforme, au-dessus de 50, c’est à risque, en dessous — non conforme. Tous les chiffres figurent dans un seul fichier, comme source unique de vérité, justement pour que chacun puisse refaire le calcul.

La règle stricte pour les violations qui se produisent en ce moment même

Une seule constatation critique échouée impose le verdict « non conforme » et plafonne le score à 49, quoi que dise la formule pondérée. La raison est simple : des outils de suivi qui tirent avant le consentement, ou un bouton de refus qui n’arrête rien, affectent chaque visiteur à cet instant. Une politique de confidentialité impeccable n’a pas le droit de relever la moyenne au-dessus de cela.

La rétention comme tâche automatique qui laisse une trace, et non comme promesse dans la politique

« Nous conservons les données 24 mois » est une affirmation qui se vérifie d’une seule manière : en exécutant la suppression. Chez nous, le journal des demandes du site a le délai lu depuis la configuration (`LEAD_RETENTION_DAYS`, par défaut 730 jours) et nettoie à chaque écriture. Dans une plateforme plus grande, le nettoyage est une tâche planifiée qui s’exécute **après** la sauvegarde et seulement si celle-ci a réussi — une suppression sans copie fraîche est la seule forme de suppression dont il n’y a pas de retour — et écrit une ligne dans une table d’exécutions. Cette ligne est la preuve de conformité exigée par l’art. 5 para. (2). Avant la première activation réelle, la tâche s’exécute à blanc pendant au moins une semaine et le journal est lu.

Les transferts : où l’obligation s’arrête et où elle commence

L’art. 44 para. (2) dit que tout le chapitre sur les transferts **ne s’applique pas** aux transferts vers les États de l’Espace économique européen, où aucune autorisation spéciale n’est nécessaire. Cela change complètement l’analyse : l’hébergement dans l’Union européenne n’est pas une préférence esthétique, c’est la différence entre « rien à justifier » et « un dossier de garanties ». Pour le reste, nous vérifions concrètement : quel fournisseur reçoit quoi, sur quelle base, et si la dérogation invoquée correspond. Exemple tiré de notre propre registre : la notification via Telegram est un transfert vers un État tiers, et nous avons écrit dans le registre que la dérogation invoquée est conçue pour des transferts occasionnels, tandis que le nôtre est systématique. C’est une limitation reconnue, avec l’alternative technique écrite à côté.

Détection de bannière qui ne prétend pas tout voir

Dix-huit sélecteurs de plateformes de consentement connus, chacun avec sa source citée, plus une heuristique pour les bannières écrites à la main — très fréquentes dans les petites entreprises de Moldavie — qui lit les styles calculés depuis la page vivante, et non le HTML statique. Le parcours entre dans le shadow-DOM ouvert et dans les iframes, car certaines bannières vivent entièrement là. Les shadow-roots fermées restent invisibles par construction : nous le disons ouvertement et nous avons un test qui maintient l’affirmation en place.

Suppression des affirmations que nous ne pouvons pas étayer

La partie la moins agréable et la plus utile. Une page de conformité qui énumère des certifications, audits et pratiques inexistants présente un risque plus grand qu’une page courte, car chaque ligne devient une déclaration vérifiable face à l’autorité. La règle que nous appliquons : une affirmation publique a une ligne dans un registre de preuves, avec le document primaire — et non avec le document interne qui la répète. Les affirmations sans document primaire sont retirées jusqu’à l’apparition du document.

À quoi cela ressemble

Le parcours, étape par étape.

Nous scannons de l’extérieur et lisons de l’intérieur, en parallèle

Le scan automatique donne l’état public en quelques secondes : transport, cookies avant consentement, comportement réel de la bannière, éléments de contenu de la politique, formulaires, juridiction, identité de l’opérateur. En parallèle, le code est lu. Nous livrons un rapport avec les constats, les preuves et le renvoi à l’article correspondant de la Loi n° 195/2024 — ainsi que la liste des divergences entre ce que dit la politique publiée et ce que fait le système.

Nous rédigeons le registre et marquons ce qui n’a pas pu être vérifié

Le registre des activités de traitement, une activité par ligne, avec finalité, base, catégories, destinataires, transferts, lieu, délai, mesures et renvoi au fichier dans le code où elle est implémentée. Nous livrons aussi la liste des points restant ouverts, avec le nom de la personne qui doit décider. Un registre sans points ouverts, au premier passage, est généralement un registre rempli à partir d’un modèle.

Nous corrigeons dans le code ce qui se corrige dans le code

Consentement implicite refusé, composants tiers chargés seulement après acceptation, minimisation appliquée à l’écriture, rétention comme tâche automatique avec journal, points de vérification de l’état, droits sur les fichiers. Chaque correction arrive avec la modification du document qui la décrit, dans le même passage. Nous livrons le code et le résultat du rescan, afin que la différence soit mesurable, et non déclarée.

Nous remettons le dossier et la procédure qui le maintient en vie

Le registre, la procédure de notification des violations, l’évaluation d’impact lorsque celle-ci est requise, la liste des sous-traitants avec ce que reçoit chacun, et le registre des preuves pour les affirmations publiques. Plus la règle qui les maintient à jour : la politique et le code sont modifiés ensemble. Ce qui relève de l’interprétation juridique est transmis au juriste, avec le matériel technique préparé.

Le parcours d'un travail de conformité : scan depuis l'extérieur et lecture du code en parallèle, puis la liste des écarts entre la politique publiée et le comportement réel, puis le registre avec ce qui a été vérifié et ce qui est resté ouvert, puis les réparations dans le code — avec un nouveau scan à la fin, pour que la différence soit mesurée et non déclarée.

Les données

Ce que nous touchons, où elles sont et combien de temps elles restent

Les questions que pose toute personne ayant un délégué à la protection des données — posées ici avant qu'il ne les pose.

Ce que le scan automatique voit effectivement: Uniquement la surface publique du site analysé : les en-têtes de réponse, les cookies écrits, les requêtes réseau déclenchées par la page, le texte de la politique, les champs des formulaires, les domaines tiers appelés. Il ne s’authentifie pas, ne remplit pas de formulaires avec des données réelles et ne touche pas aux zones protégées par mot de passe. Le scan d’un site public est exactement ce que fait tout visiteur, horloge en marche.
Comment se comporte notre robot: Budget de 45 secondes par scan. User-agent propre, qui s’identifie et renvoie à la page qui explique ce que fait le scan et comment le refuser. Le `robots.txt` du site cible est respecté par défaut, avec une lecture séparée plafonnée à 8 secondes, afin qu’un `robots.txt` lent ne grignote pas le budget de l’audit. Avant toute requête, une garde bloque les adresses internes, le réseau local et le point de métadonnées de l’infrastructure cloud.
Ce que nous touchons dans un travail de conformité sur le système du client: Le schéma de la base de données, la configuration, le code et les journaux — pas le contenu des données personnelles. Quand une vérification exige néanmoins un exemple réel (par exemple, ce qui arrive effectivement dans une notification), cela se fait sur un cas de test créé pour cela, et non sur un client vivant. L’accès est accordé pour la durée du travail et retiré à la fin, et le retrait est vérifié.
Où se trouvent nos données et pourquoi cela compte: Ce site fonctionne chez OVHcloud, Bucarest, Roumanie — Espace économique européen. La plateforme d’assistants fonctionne sur Microsoft Azure, Poland Central, confirmé par l’interrogation du service de métadonnées de la machine virtuelle, et non par la documentation du fournisseur. Les journaux du serveur sont rotés quotidiennement avec 14 exemplaires conservés, avec des droits de lecture restreints. Ces trois lignes ont remplacé une liste beaucoup plus longue d’emplacements que nous n’avons pas pu confirmer.
La minimisation, appliquée aussi chez nous: L’adresse IP du visiteur n’est pas écrite en entier : elle est tronquée avant stockage au préfixe réseau — /24 pour IPv4, /48 pour IPv6 — parce que la politique publiée dit que les IP sont anonymisées, et que cette affirmation doit être vraie dans le code. Le journal des requêtes est conservé avec les droits 0600 dans un répertoire 0700. Le point de vérification de l’état du formulaire ne renvoie que des valeurs logiques, jamais le token, l’identifiant de chat ou le nom du bot.

Un cas

Ce qu’il restait d’une page de conformité après qu’on a demandé le document primaire pour chaque ligne

La situation

Le travail a été fait sur nous-mêmes, pas sur un client. La page publique de conformité de l’entreprise avait été rédigée par accumulation : des affirmations apparues dans un document interne, répétées dans un deuxième, reprises dans un troisième et arrivées sur le site sans que personne n’ait jamais demandé l’original. Tout sonnait tout aussi sûr.

Ce que nous avons construit

Nous avons appliqué une seule règle : chaque affirmation publique reçoit une ligne dans un registre de preuves, avec le document primaire — et non le document qui la répète. En parallèle, le comportement réel a été vérifié : quels cookies sont écrits avant l’acceptation, avec la mémoire du navigateur vidée ; ce que charge la page à l’ouverture ; quel délai de rétention existe effectivement dans le code ; où se trouvent les serveurs, en interrogeant le service de métadonnées de la machine, et non la documentation du fournisseur.

Ce qui en est sorti

Ont notamment disparu : le test indépendant annuel de pénétration, le journal d’audit de 180 jours, le chiffrement déclaré sur toutes les bases de données, l’authentification à deux facteurs sur tous les comptes d’administration, la sauvegarde quotidienne chiffrée hors site, un nombre de sous-traitants trois fois plus élevé que le nombre réel et deux emplacements d’hébergement inexistants. Deux emplacements sont restés, tous deux confirmés dans l’Espace économique européen. Séparément, un problème réel dont personne ne savait rien a aussi été trouvé et corrigé : l’assistant de chat se chargeait à chaque affichage de page et écrivait la session et l’historique dans la mémoire du navigateur avant que le visiteur ne demande quoi que ce soit. Il se charge désormais à l’appui du bouton.

Ce que le cas ne dit pas

Le registre obtenu n’est ni propre ni censé l’être : il comporte huit points ouverts, marqués du nom du rôle qui doit décider, et une limitation explicitement reconnue concernant un transfert systématique couvert par une dérogation conçue pour des transferts occasionnels. Un registre sans points ouverts, rédigé dès le premier passage, est presque toujours un registre rempli à partir d’un modèle. La valeur du document réside dans les lignes qui disent « non vérifié ».

Questions

Ce que les gens nous demandent avant d'appeler

M’apportez-vous une consultation juridique ?

Non, et il est important que ce soit clair dès le départ. Nous ne sommes pas un cabinet d’avocats, nous n’émettons pas d’avis juridiques et nous ne nous substituons pas à un responsable de la protection des données. Nous faisons la partie technique : l’inventaire vérifié dans le code, la preuve du comportement réel du système, le registre de l’art. 30 et la mise en œuvre. C’est le matériau avec lequel un juriste peut travailler. Notre outil public dit la même chose de lui-même — il s’agit d’une analyse technique, et non d’une évaluation juridique.

À partir de quelle date la loi s’applique-t-elle et quel risque concret existe-t-il ?

La Loi n° 195/2024 est entrée en vigueur le 23 août 2026. Les amendes ont deux seuils, et le texte dit que l’on retient la valeur la plus élevée entre le montant et le pourcentage : jusqu’à 1.000.000 de lei ou 1 % du chiffre d’affaires total de l’année précédente pour les obligations du responsable du traitement et du sous-traitant ; jusqu’à 2.000.000 de lei ou 2 % pour les principes de base du traitement et les conditions du consentement, pour les droits des personnes concernées et pour les transferts vers d’autres États. Le consentement et les droits des personnes se trouvent dans la bande supérieure — c’est pourquoi la bannière qui ne fonctionne pas compte plus qu’il n’y paraît.

Nous hébergeons dans l’Union européenne. Avons-nous encore des obligations de transfert ?

Pour les transferts vers des États de l’Espace économique européen, non. L’art. 44 para. (2) dit explicitement que tout le chapitre sur les transferts ne s’applique pas à ces transferts et qu’aucune autorisation spéciale n’est nécessaire. Cela fait du choix de l’hébergement une décision de conformité, et pas seulement une décision de latence. Les obligations restent toutefois pour tout fournisseur situé hors de l’EEE — y compris pour de petits services que personne n’inscrit dans la liste : notifications par messagerie, statistiques de trafic, un service d’e-mail transactionnel.

Devons-nous nommer un responsable de la protection des données ?

La loi l’exige dans trois cas : autorité ou institution publique ; activités principales impliquant un suivi périodique et systématique à grande échelle des personnes concernées ; ou traitement à grande échelle de catégories particulières de données ou de données relatives à des condamnations pénales. Si vous n’entrez pas dans ce cadre, la désignation reste facultative — mais attention au piège que nous avons trouvé chez nous-mêmes : si vous déclarez publiquement un responsable désigné, l’obligation de notification qui accompagne la désignation apparaît. La position publiée et l’évaluation interne n’ont pas le droit de se contredire. Savoir si vous entrez dans ce cadre ou non est une question juridique ; nous la signalons, nous ne la décidons pas.

De combien de temps disposons-nous en cas de violation ?

La notification au Centre se fait sans retard injustifié et, si possible, dans un délai maximal de 72 heures à compter du moment où l’on en a pris connaissance ; au-delà de ce délai, la notification doit être accompagnée d’une explication motivée du retard. La personne habilitée notifie l’opérateur sans retard injustifié. La partie difficile n’est pas le délai, mais ce que la notification doit contenir : la nature de la violation, les catégories et le nombre approximatif de personnes et d’enregistrements concernés. Sans un relevé correct des données et de leur emplacement, les 72 heures se perdent à chercher. C’est pourquoi le registre se rédige avant l’incident.

Un assistant IA qui parle avec les clients complique-t-il les choses ?

Oui, en trois points concrets. Le premier : la conversation contient ce que le client écrit, et les clients écrivent n’importe quoi, y compris des données sensibles que vous n’avez jamais demandées — cela exige une instruction explicite pour le personnel et un délai de conservation. Le deuxième : l’assistant envoie du texte à un fournisseur de modèle, donc un sous-traitant intervient et, en règle générale, un transfert. Le troisième, le plus souvent négligé : le composant se charge souvent à l’ouverture de la page et écrit dans la mémoire du navigateur avant que le visiteur n’ait demandé quoi que ce soit. C’est exactement ce que nous avons trouvé sur notre propre site et que nous avons corrigé en ne chargeant qu’au clic sur le bouton.

Un score de 100 signifie-t-il que nous sommes en règle juridiquement ?

Non. Le score mesure ce qui peut être mesuré automatiquement depuis la surface publique : transport, cookies, comportement de la bannière, éléments de contenu de la politique, formulaires, juridiction, identité de l’opérateur. Il ne voit pas la base réelle des traitements en arrière-plan, les contrats avec les sous-traitants, le relevé des consentements dans la base de données, la rétention effective ou la manière dont vous répondez à une demande d’accès. Un bon score dit que la surface est propre. Le reste se vérifie de l’intérieur, et l’interprétation reste juridique.

Pouvez-vous scanner notre site sans casser quelque chose ?

Le scan est une visite, pas un test d’intrusion : la page publique se charge, le contrôle de refus de la bannière est cliqué et le trafic est écouté, avec un budget total de 45 secondes. Le robot s’identifie par son propre user-agent et respecte par défaut le `robots.txt` du site. Il ne s’authentifie pas, ne remplit pas de formulaires avec de vraies données, n’atteint pas les zones protégées. Si vous préférez ne pas être scanné, le blocage via `robots.txt` fonctionne et est respecté.

Pourquoi avez-vous supprimé des affirmations de votre propre page de conformité au lieu d’en ajouter ?

Parce que chaque affirmation publique est une déclaration vérifiable. Notre page énumérait un test d’intrusion indépendant annuel, un journal d’audit de 180 jours, un chiffrement sur toutes les bases, une authentification à deux facteurs sur tous les comptes d’administration, des sauvegardes quotidiennes chiffrées hors site, quatorze sous-traitants et plusieurs emplacements d’hébergement. Aucune n’a pu être étayée par un document primaire. Nous les avons retirées et avons gardé ce qui peut être montré. Un dossier court et vrai résiste à une vérification ; un dossier long et décoratif, non.

Sur quoi reposent les affirmations ci-dessus (25 sources)

ongdpr.md répond 308 vers /ro, puis 200 avec 95 131 octetshttps://ongdpr.md · 2026-09-06

24 d'entre elles sont du code et des fichiers de nos dépôts. Nous n'en publions ni le nom ni la ligne : réunies sur une seule page, elles décriraient trop précisément comment sont construits des systèmes qui ne sont pas seulement les nôtres. Nous les parcourons avec vous, dans le dépôt, sur demande — la vérification reste possible, elle se fait simplement lors d'un échange.

Comment nous travaillons Tous les services

Qu'est-ce que vous voudriez voir mieux fonctionner ?

Racontez-nous votre processus. Ensemble, nous décidons ce qui vaut la peine d'être construit, ce que nous pouvons connecter et comment nous vérifions le résultat.

Discutons