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.
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.
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 :
C'est un filtre d'achat, pas une validation finale.
[BANNER type="lead_banner_1" title="Grille de questions sur les données RGPD (imprimable)" description="Saisissez votre adresse e-mail pour recevoir un guide complet, étape par étape" picture-src="/upload/medialibrary/c0f/04zrwoo0jpzvirn15czqu595pynw0yl9.webp" file-path="/upload/medialibrary/9ee/cz8mxzd1tj307fh84mlcc5yrdbzl348w.pdf"]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 :
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 :
"Ç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.
"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 :
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.
[BANNER type="lead_banner_2" blockquote="\"Le CRM Bitrix24 est un outil qui possède de nombreuses possibilités d’automatisation.\"" user-picture-src='/upload/optimizer/converted/upload/iblock/684/gin5o3pfp0a0n0zcmf0t70cjehj86ttu.png.webp?1745926552452' user-name="Formateur, Lionel Graf" user-description="LGXR Consulting"]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 :
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.
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.
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 :
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.
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 :
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.
Centralisez CRM, RH et projets avec droits par rôle, exports fiables et option On-Premise pour garder le contrôle de vos données.
Essayer gratuitementNon. La conformité dépend de vos usages, de vos données et de votre configuration, pas d'un label affiché par l'éditeur. Deux entreprises peuvent utiliser le même outil, l'une en règle, l'autre non. Vérifiez les capacités produit, puis faites valider par votre juridique.
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. Demandez laquelle s'applique, dans quels délais la donnée disparaît, et ce qu'il advient des sauvegardes.
Un export qui sort les données principales, mais aussi les pièces jointes, les métadonnées, les historiques, les commentaires et les relations entre objets, dans un format réutilisable et en respectant les droits de l'utilisateur. S'il ne restitue que l'affichage écran, il ne permet ni migration ni restitution fiable.
L'important est surtout de savoir où sont stockées les données et les sauvegardes, qui y accède, et si vous pouvez verrouiller la région. Demandez la liste des sous-traitants et les flux transfrontaliers avant de vous prononcer sur une exigence de localisation.
Mieux vaut filtrer le produit d'abord. Si l'hébergement, la suppression, l'export ou les droits ne tiennent pas, aucun contrat ne comblera le manque. Utilisez ces vérifications comme un go/no-go, puis passez le relais au juridique.