Legiscope ou Didomi : comparer les usages RGPD

Legiscope et Didomi doivent être comparés à partir des opérations à organiser : recueillir un choix, appliquer ce choix, répondre à une demande et documenter les traitements. Une liste de modules portant des noms proches ne démontre pas qu’ils réalisent le même travail.

Les pages officielles ont été consultées le 28 septembre 2026. Cette analyse documentaire ne constitue pas un essai des produits. L’auteur est fondateur de Legiscope.

Les périmètres annoncés

Didomi présente une CMP multicanal, la gestion des préférences, la surveillance des traceurs et le server-side Addingwell. Les demandes de droits y sont proposées en accès anticipé : leur disponibilité doit être confirmée.

Legiscope décrit un registre assisté à partir de sources, avec propositions soumises à révision. Il faut en examiner les résultats sur les documents et activités de l’organisation.

Vérifiez les modules inclus dans l’offre proposée, leur documentation et leurs conditions d’utilisation. L’absence de description sur une page publique ne démontre pas l’absence d’une fonction dans une offre. Une réponse commerciale doit préciser le périmètre couvert et les options nécessaires.

Un cas concret pour distinguer les opérations

Prenez le parcours d’un prospect qui visite un site, choisit ses traceurs, s’inscrit à une communication puis demande l’effacement de ses données. À chaque étape, identifiez le système qui reçoit l’information, celui qui exécute l’action et celui qui conserve la preuve.

Une connexion doit être démontrée : ne supposez pas qu’un signal de consentement modifie automatiquement un registre ou qu’un ticket fermé prouve la suppression dans tous les systèmes.

Le guide CMP traite les choix liés aux traceurs. Notre fiche sur la gestion du refus dans les indicateurs marketing aide à éviter de confondre baisse de collecte et panne.

Ce que les obligations imposent de distinguer

L’Art. 82 de la loi Informatique et Libertés encadre les opérations dans le terminal. La documentation des activités relève, lorsqu’il s’applique, de l’Art. 30 du RGPD. Une réponse à l’un de ces besoins ne démontre pas la couverture de l’autre.

Pour choisir un outil documentaire, le cahier des charges logiciel RGPD précise les livrables à examiner. Une information inconnue doit rester signalée comme telle : un texte généré avec assurance ne remplace pas la validation d’une finalité ou d’une durée.

Vérifier les interfaces et les responsabilités

Demandez un schéma propre à votre projet : données échangées, sens des échanges, fréquence, erreurs et responsable de leur traitement. Préparez un scénario où une intégration échoue. L’équipe doit pouvoir repérer l’échec et corriger le statut sans perdre la trace de l’action initiale.

Vérifiez séparément les contrats, les prestataires, les accès et les transferts. Le pays d’origine d’un éditeur ou un hébergement annoncé en Europe ne suffit pas à conclure à l’absence de transferts. La grille de fiabilité d’un logiciel recense les pièces à demander.

Décider sur une offre vérifiée

Il n’est pas établi que toute organisation ait besoin d’acheter ces deux produits. Listez les fonctions déjà couvertes, les lacunes et les options requises. Comparez ensuite les coûts complets, y compris installation, maintenance et réversibilité. Demandez un devis pour votre périmètre et mesurez les tâches concernées avant de retenir une estimation de gain de temps.

Si vous envisagez de quitter Didomi, utilisez plutôt le dossier alternatives et migration CMP, consacré à la reprise des configurations et preuves.

Définir le résultat attendu pour chaque équipe

Le marketing cherche à appliquer les choix des personnes dans ses outils. Le DPO doit comprendre les traitements et leurs justifications. L’équipe technique doit savoir quels événements transmettre et comment traiter une erreur. Ces besoins se croisent, mais un même écran de suivi ne prouve pas qu’ils sont tous satisfaits.

Écrivez le résultat attendu avant de comparer les offres. Pour les traceurs, il peut s’agir d’empêcher les opérations soumises au consentement tant que celui-ci n’est pas obtenu. Pour une préférence commerciale, il peut s’agir de retirer une personne de la population sollicitée pour une finalité déterminée. Pour le registre, il faut documenter l’activité et ses caractéristiques, sans recopier tous les choix individuels dans la fiche de traitement.

Cette distinction permet de mesurer une lacune réelle. Si vous possédez déjà un mécanisme de choix correctement intégré, votre besoin peut porter sur la documentation ou le suivi des demandes. Si vos fiches sont solides mais que les choix ne sont pas appliqués dans les outils, un enrichissement documentaire ne résoudra pas à lui seul le problème opérationnel.

Préparer un parcours fictif dont les choix restent distincts

Voici un protocole proposé, sans réalisation d’un essai comparatif. Une personne entièrement fictive, Camille, consulte un site et refuse les traceurs publicitaires. Elle choisit ensuite de recevoir une lettre d’information sur une adresse créée pour la démonstration. Ces décisions portent sur deux objets différents : le refus publicitaire ne signifie pas nécessairement le refus de la lettre demandée ; l’inscription à la lettre n’autorise pas les traceurs refusés.

Demandez aux éditeurs et intégrateurs de décrire les informations nécessaires à chaque étape : finalité, statut, contexte du choix, version de l’information et système destinataire. Faites préciser ce qui est réellement enregistré par l’offre retenue. La simple existence d’un identifiant commun ne démontre ni l’identité de la personne sur tous les appareils ni la validité d’un rapprochement entre comptes.

Poursuivez le scénario avec le retrait de l’inscription à la lettre. L’Art. 7(3) du RGPD prévoit que le retrait doit être aussi simple que le consentement. Examinez donc le parcours visible, puis l’exécution dans le système d’envoi. Une préférence modifiée dans un centre de préférences reste à rapprocher des listes et automatisations qui en dépendent.

Ce scénario doit être adapté à votre base légale et aux règles propres au canal. Il ne pose pas que toute communication électronique repose toujours sur le consentement. Son intérêt est de vérifier un usage choisi pour l’exercice, sans convertir un statut technique en autorisation générale de solliciter.

Examiner la preuve sans collecter plus que nécessaire

Lorsque le traitement repose sur le consentement, l’Art. 7(1) exige de pouvoir démontrer que la personne l’a donné. La preuve doit être reliée à la finalité et au contexte pertinents. Un indicateur « vrai » sans explication de ce qu’il autorise peut être insuffisant pour comprendre le dossier ; un historique démesuré de navigation n’est pas pour autant nécessaire à cette démonstration.

Demandez comment retrouver la version de l’information présentée et les changements intervenus. Séparez la preuve du choix, la configuration censée l’appliquer et les éléments permettant de vérifier son effet. Une capture du bandeau décrit une interface ; elle ne démontre pas seule le comportement de tous les scripts ou services concernés.

La gestion de cette preuve doit aussi prévoir les accès et les durées. Les informations utiles au suivi juridique ne sont pas destinées automatiquement à toutes les équipes commerciales. Définissez les usages autorisés des journaux et les règles de conservation avant d’activer un enregistrement plus détaillé au motif qu’il faciliterait un audit éventuel.

Rendre les échanges entre systèmes explicables

Faites dresser une correspondance entre les finalités et statuts de départ et ceux du système d’arrivée. Un code nommé « marketing » peut regrouper des opérations différentes selon les outils. Si un statut ne trouve pas d’équivalent, il doit être signalé ; ne le transformez pas par défaut en accord ou en refus sur un périmètre qui n’a pas été examiné.

Demandez ensuite ce qui se passe lorsqu’un échange n’aboutit pas : alerte, nouvelle tentative, traitement manuel et contrôle des résultats. Ce sont des questions de recette à vérifier, pas des fonctionnalités ici attribuées à Didomi ou Legiscope. La décision d’achat doit préciser lesquelles sont disponibles, configurées ou à développer dans votre projet.

Une architecture côté serveur ne retire pas, par son seul nom, les obligations applicables. Examinez les opérations effectivement réalisées dans le terminal au regard de l’Art. 82, puis les traitements de données personnelles au regard du RGPD. La localisation d’une étape technique ne suffit pas à conclure qu’un consentement devient inutile ou qu’un refus peut être ignoré.

Qualifier une demande de droits avant de fermer le dossier

Dans la suite fictive du parcours, Camille demande l’effacement de ses données. Identifiez les traitements concernés et les exceptions éventuellement pertinentes. Le retrait d’une inscription et l’effacement de toutes les données détenues ne sont pas nécessairement la même opération. Un élément conservé pour un motif valable doit rester justifié, limité et traité dans le cadre correspondant.

Demandez comment le dossier permet de suivre les actions dans les différents systèmes, les réponses obtenues et les points non résolus. L’Art. 12(3) impose une réponse dans le délai applicable ; le nom du module ou sa fermeture technique ne suffit pas à démontrer que cette obligation et les conditions de l’Art. 17 sont respectées.

Le registre peut aider à retrouver les activités, prestataires et durées. Il ne constitue pas nécessairement un inventaire de chaque donnée individuelle. Vérifiez comment l’équipe passe de cette documentation aux recherches et opérations réelles, puis comment elle conserve les éléments utiles pour expliquer la réponse apportée à la personne.

Fixer les conditions d’achat sur le parcours complet

Le compte rendu de démonstration doit distinguer ce qui a été observé, ce qui figure dans la documentation et ce qui reste à confirmer au contrat. Pour les fonctions en accès anticipé, précisez les conditions de disponibilité et les limites avant d’en faire une dépendance essentielle du projet.

La comparaison peut aboutir à un seul achat, à une articulation d’outils ou à l’amélioration d’une intégration existante. Justifiez ce choix par les opérations couvertes et le travail restant à votre charge. Une promesse de conformité globale ou un taux de consentement plus élevé ne remplace pas la vérification du parcours, de ses preuves et de ses responsabilités.

Ce qu’il faut retenir

• Distinguez choix, exécution, demandes et documentation.
• Confirmez la disponibilité des modules, notamment ceux annoncés en accès anticipé.
• Faites démontrer les échanges entre systèmes et le traitement des erreurs.
• Choisissez les fonctions manquantes plutôt qu’un ensemble automatique d’abonnements.

FAQ

Didomi et Legiscope couvrent-ils exactement le même besoin ?

Les présentations publiques mettent en avant des usages différents. Vérifiez les modules précis de chaque offre sur votre parcours.

Faut-il acheter les deux ?

Pas systématiquement. Cela dépend des lacunes de votre organisation et des outils existants.

Une intégration garantit-elle l’exécution des demandes ?

Non. Il faut contrôler son périmètre, ses résultats et ses erreurs, puis conserver les éléments utiles.

Recevez nos analyses sur la conformité et les logiciels.

Thiébaut Devergranne, docteur en droit, fondateur de donneespersonnelles.fr et de Legiscope, travaille depuis plus de vingt ans sur le droit des technologies.