Choisir un logiciel professionnel conforme au RGPD : les questions sur les données à régler d’abord

TL;DR (Quick Summary)

Avant de demander un avis juridique, filtrez le logiciel sur ce qu'il sait vraiment faire avec vos données. Si le produit ne permet pas l'hébergement attendu, la suppression ciblée, l'export complet ou des droits fins, aucun contrat ne réparera le problème.

• Cadrer l'évaluation avant la revue juridique : filtrez le produit en amont, un contrat ne crée pas une fonction absente.
• Lister les données et les usages : partez des flux réels et de scénarios concrets à rejouer en démo.
• Vérifier l'hébergement et les sous-traitants : sachez où sont stockées les données et qui les traite vraiment.
• Tester la suppression et la rétention : distinguez suppression logique et définitive, sauvegardes et legal holds compris.
• Contrôler la complétude des exports : un export partiel enferme vos données et bloque les demandes internes.
• Examiner la granularité des droits : l'accès doit se limiter aux seules personnes concernées.
• Transformer les vérifications en checklist : décidez sur preuves, pas sur promesses commerciales.
• Takeaway: Traitez ces sujets comme des critères produit, pas comme une formalité contractuelle. Ce qui n'est pas démontrable en démo, en sandbox ou par la documentation est un risque d'achat immédiat, même avant la revue juridique.

Vous évaluez un CRM, un outil RH, un ERP ou une solution métier, et la question RGPD arrive vite. Le bon réflexe n'est pas d'attendre la revue juridique, c'est de vérifier d'abord ce que le logiciel sait faire avec vos données. Cet article ne constitue pas un conseil juridique. Il donne les questions produit à régler en amont, celles qui décident souvent si un outil est utilisable dans votre cadre.

Cadrer l'évaluation avant la revue juridique

Le blocage arrive souvent trop tard. L'équipe métier adore l'outil, l'achat avance, puis le dossier part chez le DPO, le RSSI ou le juridique. On découvre alors que les données partent dans une région non acceptée, qu'aucun export complet n'existe, ou que la suppression ciblée est impossible. Ce n'est plus un détail de contrat, c'est parfois un logiciel inutilisable chez vous.

Vérifiez d'abord le produit, pas les promesses. Un éditeur peut annoncer une roadmap, mais s'il n'a pas aujourd'hui de permissions au niveau champ ou d'export exploitable, vous n'achetez pas une capacité. Vous achetez une dépendance à une future version. Ces points sont rarement corrigés après signature.

Le périmètre est volontairement étroit. On ne traite pas ici toutes les obligations RGPD, ni la rédaction du contrat de sous-traitance (DPA), ni l'analyse de base légale. On se concentre sur ce qui se teste pendant l'évaluation : hébergement, sous-traitants, suppression, export et droits d'accès.

La logique tient en trois temps :

• partez des flux de données réels, pas d'une liste générique de questions ;
• testez cinq capacités produit liées au RGPD ;
• documentez les preuves obtenues pour la décision d'achat et la revue interne.

C'est un filtre d'achat, pas une validation finale.

Grille de questions sur les données RGPD (imprimable)

Saisissez votre adresse e-mail pour recevoir un guide complet, étape par étape

Je confirme d'avoir lu et compris la Politique de confidentialité de Bitrix24

Lister les données et les usages à couvrir

Sortez de l'abstrait. Beaucoup d'évaluations se limitent à demander si l'éditeur est conforme, il répond oui, et tout le monde avance. La vraie question est plus concrète : quelles données personnelles vont entrer dans l'outil, qui va les utiliser, et pour quoi faire ?

Listez d'abord les catégories de données. Selon le logiciel : clients, prospects, salariés, candidats, fournisseurs, et données sensibles si le métier en manipule. N'oubliez pas les pièces jointes, les notes libres, les transcriptions, les historiques de workflow, les commentaires, les journaux d'usage et les copies envoyées vers d'autres outils. Un registre des traitements vous aide à poser cet inventaire une bonne fois.

Cartographiez ensuite les opérations. Une vue simple suffit si elle répond à quelques questions :

• comment les données entrent : saisie, formulaire, import, API, synchronisation ;
• qui les consulte, les modifie et les partage en interne ;
• ce qui doit pouvoir être exporté ;
• ce qui doit être supprimé, archivé ou conservé ;
• quels outils reçoivent une copie : CRM, SIRH, support, BI, messagerie, stockage.

Préparez 2 ou 3 scénarios à rejouer en démo. Sans cela, l'éditeur vous montrera le parcours standard, or les problèmes sortent presque toujours des cas particuliers. Par exemple :

• un candidat demande la suppression de son dossier, mais le recruteur doit garder certains éléments de suivi ;
• un commercial quitte l'entreprise, ses comptes doivent être réattribués sans exposer tout l'historique à une équipe trop large ;
• un client grand compte demande une restitution complète, documents et échanges compris ;
• une filiale d'un autre pays travaille dans l'outil sans que ses données soient visibles par les autres entités du groupe, et un prestataire externe ne voit qu'un périmètre limité.

"Ça doit être faisable" ne vaut rien en achat. Ces scénarios forcent l'éditeur à montrer le produit réel. C'est là qu'apparaissent les bricolages, les clics manuels intenables à l'échelle, ou les réponses floues.

Vérifier l'hébergement et les sous-traitants

"Hébergé en Europe" ne suffit pas. Demandez où les données sont stockées au repos, où elles transitent, et si vous pouvez choisir ou verrouiller une région conforme à vos exigences. Certains éditeurs affichent une région principale mais utilisent d'autres localisations pour le support, la recherche, les sauvegardes ou l'emailing.

À demander noir sur blanc :

• les régions de stockage des données de production et des sauvegardes ;
• la localisation des environnements de test et de support si des données réelles y passent ;
• les flux transfrontaliers liés à l'exploitation du service ;
• la possibilité de choisir la région à la création du compte ;
• la possibilité de verrouiller la région et d'empêcher une migration automatique sans validation client, avec contrôle de changement et approbation.

Exigez une liste publique des sous-traitants. Un éditeur mature publie sur une URL accessible la liste de ses sous-traitants : support, analytics, emailing, sauvegarde, moteur de recherche, monitoring, transcription, IA. Vérifiez trois choses : à quelle fréquence cette page est mise à jour, comment vous êtes prévenu d'un changement (abonnement par email ou flux RSS), et si un préavis vous permet de refuser un nouveau sous-traitant. La CNIL rappelle les bonnes pratiques pour encadrer les sous-traitants.

Désactivez ce qui n'est pas nécessaire. Certains modules optionnels activent des sous-traitants supplémentaires. S'ils ne servent pas, vérifiez qu'ils se coupent.

Gardez la main sur l'emplacement. Pour les organisations qui doivent maîtriser où vivent les données, certains éditeurs proposent une version auto-hébergée. Bitrix24, par exemple, propose une version On-Premise où les données sont stockées sur votre infrastructure plutôt que dans le cloud de l'éditeur, ce qui déplace de votre côté le choix de la région et des sauvegardes quand vous décidez de l'héberger sur vos serveurs. C'est une option parmi d'autres, à mettre en regard du coût d'exploitation d'un hébergement interne.

Un éditeur qui hésite est un signal. S'il ne sait pas expliquer simplement qui traite quoi et où, le problème n'est pas seulement juridique. C'est un indice sur la maturité du produit.

"Le CRM Bitrix24 est un outil qui possède de nombreuses possibilités d’automatisation."

Formateur, Lionel Graf

LGXR Consulting

Obtenir Bitrix24 gratuitement

Tester la suppression sélective et la rétention

La suppression est un excellent révélateur. Beaucoup d'outils savent archiver, masquer ou désactiver. Moins savent supprimer proprement sans casser le reste du dossier.

Distinguez suppression logique et définitive. La suppression logique (soft delete) masque la donnée mais la conserve en base, souvent récupérable. La suppression définitive (hard delete) l'efface réellement. Vous devez savoir laquelle s'applique, et à quel moment la donnée disparaît vraiment.

Testez plusieurs niveaux. Vérifiez si l'outil supprime :

• une personne complète ;
• un champ précis ;
• un document ou une pièce jointe ;
• un commentaire, une note ou un événement d'historique ;
• un ensemble de données selon une règle de rétention.

Surveillez l'intégrité du reste. Si supprimer un document casse un workflow, coupe des liens métier utiles ou laisse des références orphelines, l'équipe contournera et gardera trop longtemps des données mal maîtrisées.

Descendez dans les couches invisibles. Demandez le comportement des sauvegardes, des journaux techniques, de l'index de recherche, des caches et des copies synchronisées. Précisez les fenêtres de rétention des sauvegardes et les objectifs de reprise : le RPO (perte de données maximale acceptée) et le RTO (délai de remise en service). Une suppression peut être immédiate en production mais persister des jours ou des semaines dans les sauvegardes, et ce délai doit être écrit. Prévoyez aussi les legal holds, ces conservations imposées par une obligation légale ou un litige, qui suspendent temporairement la suppression.

La rétention mérite son propre test. Vérifiez si les règles sont configurables par type de donnée, par entité et par durée. Traiter de la même façon candidats, prospects et clients rend vite une purge globale impraticable. La CNIL donne des repères sur les durées de conservation.

Exigez des journaux de suppression exportables. Les équipes doivent tracer qui a supprimé quoi, quand, et par quelle action ou règle automatique. Demandez le format d'export de ces journaux, leur durée de conservation, et s'ils s'intègrent à votre SIEM, l'outil interne qui centralise et surveille les événements de sécurité. Sans cette trace, support, RH ou ventes perdront du temps à reconstituer des incidents simples.

Un test utile en POC. Créez un dossier avec fiche, pièce jointe, commentaire, historique et synchronisation vers un second outil. Supprimez un élément ciblé. Regardez ce qui reste, ce qui disparaît, et ce qui reste retrouvable dans la recherche.

Contrôler la complétude des exports

Un export limité à l'écran n'est pas un export. C'est un confort de reporting, pas une capacité de reprise ou de restitution.

Testez la complétude. Vérifiez si l'export inclut les données principales, les pièces jointes, les métadonnées, les historiques, les commentaires, les relations entre objets, les statuts et les états de workflow. Sans cela, l'extraction est partielle et difficile à exploiter pour une migration, un audit, une demande métier ou une restitution.

Demandez un export réel, puis ouvrez les fichiers. Ne vous contentez pas d'une capture d'écran du menu Export. Sur un jeu de données représentatif, vérifiez si les identifiants relient les objets entre eux, si les pièces jointes sortent, si les colonnes sont compréhensibles, et si l'historique garde une date, un auteur et une action.

Vérifiez les limites techniques. Demandez les limites de l'API (le rate limit, soit le nombre d'appels autorisés par minute, et la pagination), le volume maximal par export, et confirmez que l'export respecte les permissions effectives de l'utilisateur qui le lance. Un export qui ignore les droits recrée exactement le risque que vous cherchez à éviter.

Repérez tôt les zones non exportables. Certaines données restent coincées dans des journaux internes, des commentaires système, des champs calculés ou des modules annexes. D'autres sortent dans un format si opaque que la reprise coûtera cher.

Au-delà de la dépendance à l'éditeur. Le vendor lock-in, dont on ne récupère plus facilement ses données, n'est pas le seul risque : une exportabilité faible crée des angles morts pour des demandes banales, comme un contrôle interne, un changement d'outil, un audit sécurité, une réconciliation entre systèmes ou une restitution à un client. Le droit à la portabilité peut imposer, dans les cas où il s'applique, la restitution de certaines données fournies par la personne dans un format structuré et lisible par machine.

Examiner la granularité des droits d'accès

Bien hébergé ne veut pas dire bien cloisonné. Un outil peut être bien hébergé, documenté et exportable, et rester problématique s'il ouvre trop largement l'accès. C'est fréquent sur les logiciels conçus pour aller vite : trois rôles par défaut, un administrateur tout-puissant, et des exceptions gérées à la main.

À quel niveau règle-t-on les permissions ? Selon vos usages : espace, équipe, rôle, type d'objet, dossier, champ, action ou export. Vérifiez ce que le produit fait vraiment, pas ce que la documentation suggère. Beaucoup de réglages ne s'appliquent qu'à l'interface, pas à l'API, aux exports ou aux objets liés.

Rejouez des cas fréquents en achat :

• un manager voit trop de dossiers parce que son rôle hérite des droits de toute une équipe ;
• un prestataire externe accède à des documents ou commentaires non prévus ;
• un administrateur fonctionnel exporte tout sans contrôle particulier ;
• un utilisateur modifie des champs sensibles alors qu'il devrait être en lecture seule ;
• un changement de rôle propage automatiquement des accès trop larges.

Regardez les contrôles avancés. En achat, quelques mécanismes font la différence : le principe des quatre yeux (une seconde validation obligatoire) pour les exports sensibles, un flux d'approbation pour toute élévation de droits, et la journalisation des actions d'administration. Ils évitent qu'un seul compte puisse tout faire sans laisser de trace.

Vérifiez l'intégration à votre gestion des identités (IAM). Demandez si l'outil se connecte à votre SSO (l'authentification unique, via SAML ou OIDC), s'il gère le SCIM (la synchronisation automatique des comptes) et le provisioning JIT (la création du compte à la première connexion), et si les rôles se mappent sur vos groupes existants. Sans cela, vous multipliez les attributions manuelles, sources d'erreurs et d'accès oubliés.

Un exemple de granularité produit. Dans Bitrix24, la gestion des droits d'accès par rôle dans le CRM permet de fixer un niveau de droits pour chaque action et chaque type d'élément (accès complet, éléments propres uniquement, ou par département), ce qui limite ce qu'un rôle donné peut lire, modifier ou exporter. À comparer avec la granularité réelle des autres outils de votre short list.

Les journaux d'audit comptent. Demandez si les logs retracent les accès, les modifications, les exports, les changements de droits et les actions d'administration, puis s'ils sont consultables par vos équipes. Un journal accessible seulement côté éditeur sera peu utile en cas d'incident ou de contrôle.

Où cette approche échoue. Si votre organisation sépare nettement les populations, les régions, les clients ou les types de dossiers, des droits trop grossiers deviennent vite un problème d'exploitation : les équipes dupliquent les espaces, contournent les usages ou renoncent à centraliser certaines données.

Transformer les vérifications en checklist d'achat

Sortez du ressenti. Transformez les tests en grille d'évaluation, avec des questions fermées, des preuves attendues et un niveau de criticité. Traitez les cinq sujets comme des critères produit distincts : hébergement, sous-traitants, suppression, export et permissions. Pour chacun, formulez des questions à réponse oui, non, partiel ou non démontré.

Exigez une preuve par item. Une capture produit, une documentation technique, une réponse écrite de l'éditeur, un test en sandbox ou une démonstration scénarisée. Sinon, vous récupérez des promesses commerciales inutilisables en comité d'achat.

Voici une version courte à cocher, avec le type de preuve minimal acceptable pour chaque point :

• Hébergement et sauvegardes dans une région acceptée et verrouillable. Preuve : documentation technique ou capture de configuration.
• Liste publique des sous-traitants, avec notification des changements. Preuve : lien vers la page et son mécanisme d'abonnement.
• Suppression sélective (personne, champ, document) sans casser le dossier. Preuve : test en sandbox.
• Comportement de suppression dans les sauvegardes, délais écrits (RPO, RTO) et legal holds. Preuve : réponse écrite de l'éditeur.
• Export complet et relié (pièces jointes, historiques, relations) respectant les droits. Preuve : export réel ouvert et vérifié.
• Droits configurables au bon niveau, appliqués aussi à l'API et aux exports. Preuve : test en sandbox.
• Intégration SSO/SCIM et journaux d'audit exploitables en interne. Preuve : documentation technique ou démonstration.

Ajoutez une colonne risque d'achat. Elle est utile quand un point n'est pas bloquant seul mais le devient combiné : export partiel, plus permissions grossières, plus module IA impossible à désactiver. Séparément, l'éditeur défend chaque point. Ensemble, cela peut sortir la solution de la short list.

Dernière règle. Tout point non démontrable côté produit se remonte comme risque d'achat, même avant la revue contractuelle. Un contrat encadre des obligations. Il ne crée pas une fonction absente.

FAQ