Sur beaucoup de produits, le sujet RGPD arrive trop tard: une fois le SaaS lancé, les données déjà collectées, et les choix techniques déjà figés.
Le résultat est presque toujours le même: une conformité traitée comme un rattrapage, plus coûteux, plus défensif et beaucoup moins propre qu’un cadrage fait en amont. Or les points sensibles étaient souvent visibles dès la conception.
La checklist minimale avant mise en production
Avant un lancement, la bonne question n’est pas “sommes-nous parfaits juridiquement ?”. C’est “avons-nous compris quelles données le produit traite, pourquoi, avec qui et pendant combien de temps ?”.
- Quelles données personnelles le produit traite-t-il vraiment ?
- Qui y accède, dans quelle logique de rôle et de journalisation ?
- Le fournisseur et les sous-traitants sont-ils cadrés contractuellement ?
- Les personnes peuvent-elles être correctement informées et exercer leurs droits ?
- Les durées de conservation et suppressions sont-elles pensées ?
Le point souvent sous-estimé
Le RGPD n’est pas seulement un sujet de documents. Il dépend d’éléments produit très concrets: où la donnée apparaît, qui la voit, comment elle circule, et comment elle s’efface.
Un produit peut avoir une politique de confidentialité correcte tout en restant mal conçu du point de vue conformité: droits trop larges, export facile de données, suppression incomplète, ou absence de logique claire pour les durées de conservation.
C’est pour cela qu’un audit RGPD utile doit parler aussi de rôles, d’écran, d’architecture et d’exploitation. La conformité ne se joue pas seulement dans un registre; elle se joue dans le fonctionnement réel de l’outil.
Ce que rappelle France Num
Une solution peut sembler simple, rapide et fonctionnelle, tout en traitant en réalité beaucoup de données sensibles ou structurantes. Le premier travail consiste donc à cartographier.
Cette cartographie doit être suffisamment concrète pour servir ensuite aux choix produit: écrans d’administration, permissions, exports, sous-traitants, rétention et capacité de réponse aux demandes des personnes.
Les décisions à trancher avant le lancement
Avant la mise en production, il faut arbitrer explicitement plusieurs points: quelles données sont vraiment nécessaires, qui peut les voir, quels exports sont autorisés, et quelles traces doivent être conservées pour rester capables d’expliquer le traitement.
Ce travail peut sembler moins spectaculaire qu’une feature produit, mais il évite ensuite les correctifs lourds, les blocages commerciaux ou les réponses improvisées quand un client, un salarié ou un partenaire demande des garanties.
La conformité RGPD se joue dans le produit, pas seulement dans les documents
Les sources CNIL et France Num rappellent une idée souvent sous-estimée: la conformité n’est pas seulement une politique de confidentialité ou un registre rangé dans un dossier. Dans un SaaS ou une application web, elle se joue dans les écrans, les permissions, les exports, les logs, les durées de conservation, les formulaires et la capacité à répondre concrètement aux demandes des personnes. Un produit peut avoir des textes juridiques corrects tout en étant mal conçu pour respecter le RGPD au quotidien.
La première exigence produit est la minimisation. Si une donnée n’est pas nécessaire, elle ne doit pas être collectée. Si elle est nécessaire seulement à un moment donné, elle ne doit pas rester accessible indéfiniment. Cette logique doit se traduire dans les champs de formulaire, les bases de données, les exports, les dashboards et les droits d’administration. La minimisation n’est pas une abstraction juridique: c’est une décision de design et d’architecture.
La deuxième exigence est l’explicabilité. Une équipe doit pouvoir dire pourquoi une donnée existe, qui y accède, combien de temps elle reste conservée, à quel sous-traitant elle est transmise et comment elle peut être supprimée ou corrigée. Si ces réponses nécessitent une enquête manuelle dans plusieurs outils, le produit n’est pas prêt. Le problème n’est pas seulement réglementaire; il devient aussi opérationnel, car chaque demande utilisateur peut mobiliser trop de temps.
La troisième exigence est la limitation des accès. Beaucoup de produits commencent avec des rôles trop larges parce que c’est plus simple à développer. Mais quand l’équipe grossit, ces raccourcis deviennent des risques: support qui voit trop de données, commerciaux qui exportent trop facilement, administrateurs sans séparation des droits, absence de trace sur les actions sensibles. Une checklist RGPD utile doit donc entrer dans les permissions, pas seulement dans les pages légales.
La checklist produit avant mise en production
Avant le lancement, il faut transformer les principes RGPD en contrôles visibles dans l’application.
- Cartographier les données personnelles par écran, table, formulaire, export, intégration et prestataire.
- Supprimer les champs collectés “au cas où”, ou justifier clairement leur finalité et leur durée de conservation.
- Définir des rôles stricts: lecture, modification, export, suppression, administration, support.
- Prévoir les parcours de demande utilisateur: accès, rectification, opposition, suppression, portabilité si applicable.
- Tracer les actions sensibles, notamment exports, changements de droits, suppressions et accès administrateur.
- Vérifier que les textes légaux correspondent au fonctionnement réel du produit, et non à une intention théorique.
Plus la conformité est intégrée tôt, plus elle coûte peu. Attendue trop tard, elle se transforme en chantier correctif lourd et défensif.
Un bon lancement RGPD n’est donc pas celui qui “coche la case”. C’est celui où le produit, les contrats et l’exploitation racontent enfin la même histoire.
Questions fréquentes
Qui reste responsable des données dans un SaaS ?
L’entreprise qui choisit et exploite l’outil garde ses responsabilités. Le fournisseur doit offrir un cadre, mais cela ne décharge pas le responsable de traitement.
Faut-il tout documenter avant le lancement ?
Il faut au minimum documenter les traitements, les flux, les rôles, les bases légales et les garanties clés avant exposition réelle du produit.
Faut-il attendre la fin du projet pour traiter le RGPD ?
Non. Les sujets de consentement, de minimisation des données, de conservation, d’accès et de rôle doivent être cadrés dès la conception du produit.
Quels sujets RGPD sont le plus souvent oubliés ?
Les exports, les durées de conservation, les sous-traitants, l’historique d’accès, les journaux, et les mécanismes permettant d’exercer réellement les droits des personnes.
Un outil interne est-il aussi concerné qu’un produit client ?
Oui, dès lors qu’il manipule des données personnelles. Le caractère interne ne dispense ni de la gouvernance, ni des rôles, ni de la traçabilité.
Comment transformer cette lecture en décision
Pour transformer “RGPD SaaS : checklist de conformité avant mise en production” en décision, résumez le problème, identifiez le risque principal et choisissez une prochaine étape datée : audit, cadrage, priorisation, recrutement, externalisation ou maintien de l’existant.