Dès qu’une application métier contient des noms, des adresses, des numéros de téléphone ou des informations sur vos salariés, elle traite des données personnelles et entre dans le champ du RGPD. Le règlement demande précisément de penser la protection des données dès la conception : quelles données collecter, combien de temps les garder, qui peut y accéder, comment répondre aux demandes des personnes. Respecter le RGPD dans une application métier est bien plus simple quand ces questions sont posées avant le développement.
Corriger après coup une application qui conserve tout indéfiniment, sans gestion des droits ni possibilité d’export, coûte cher et prend du temps. Voici les points à intégrer à votre projet, présentés de manière pratique.
Les principes du RGPD appliqués à une application
Le RGPD repose sur quelques principes fondamentaux, qui se traduisent directement en choix de conception :
- Licéité, loyauté et transparence : chaque traitement doit reposer sur une base légale (contrat, obligation légale, intérêt légitime, consentement…) et les personnes doivent en être informées.
- Limitation des finalités : les données sont collectées pour un objectif précis et ne sont pas réutilisées pour autre chose sans fondement.
- Minimisation : on ne collecte que les données nécessaires à cet objectif.
- Exactitude : les données doivent pouvoir être corrigées et tenues à jour.
- Limitation de la conservation : les données ne sont pas gardées plus longtemps que nécessaire.
- Intégrité et confidentialité : une sécurité adaptée protège les données contre les accès non autorisés, la perte ou l’altération.
- Responsabilité : l’entreprise doit être capable de démontrer sa conformité.
Le règlement formalise aussi la protection des données dès la conception et par défaut : les réglages par défaut de l’application doivent être les plus protecteurs, par exemple en limitant la visibilité des données aux seules personnes qui en ont besoin.
Minimiser les données dès le cahier des charges
La minimisation se joue au moment où vous définissez les écrans et les formulaires. Pour chaque champ, posez-vous une question simple : à quoi va-t-il servir ? Une date de naissance est-elle utile pour planifier une intervention ? Un numéro de sécurité sociale doit-il vraiment figurer dans la fiche d’un salarié de l’outil de planning ?
Soyez particulièrement vigilant avec les champs de commentaire libre. Un technicien peut y noter « client malade, repasser plus tard », ce qui revient à enregistrer une donnée de santé. Une consigne claire, voire des listes de choix à la place du texte libre, limite ce risque.
Le RGPD prévoit en effet des catégories particulières de données (santé, opinions politiques ou religieuses, origine, données biométriques…) dont le traitement est en principe interdit, sauf exceptions encadrées. Si votre application en traite, par exemple dans le secteur médical ou de l’aide à domicile, des précautions renforcées s’imposent. Intégrer ces réflexions à votre cahier des charges de webapp évite bien des retours en arrière.
Prévoir les durées de conservation dans l’application
Garder des données « au cas où » n’est pas conforme. Chaque catégorie de données doit avoir une durée de conservation définie, qui dépend de sa finalité et de vos obligations légales. Par exemple, les pièces comptables doivent être conservées dix ans, alors que les données d’un prospect qui n’a jamais donné suite n’ont pas vocation à être gardées indéfiniment ; la CNIL publie des référentiels qui donnent des repères par type de traitement.
Côté application, cela se traduit par des fonctionnalités concrètes :
- une suppression ou une anonymisation automatique des données arrivées à échéance ;
- un archivage intermédiaire, accessible à un nombre restreint de personnes, pour les données à garder pour des raisons légales mais plus utilisées au quotidien ;
- la prise en compte des sauvegardes, qui contiennent aussi des données et doivent suivre une politique de rotation.
Prévoir ces mécanismes dès le départ est bien plus simple que de devoir trier des années d’historique accumulé.
Permettre l’exercice des droits des personnes
Les personnes dont vous traitez les données (clients, salariés, usagers) disposent de droits : accès, rectification, effacement, limitation, opposition, et portabilité dans certains cas. Vous devez y répondre dans un délai d’un mois, prolongeable dans certaines situations.
Une application bien conçue facilite ce travail :
- retrouver toutes les données d’une personne depuis une recherche unique ;
- les exporter dans un format lisible et réutilisable ;
- les corriger ou les supprimer proprement, sans casser l’historique nécessaire (une facture, par exemple, doit rester intacte) ;
- pour un portail client, permettre à l’utilisateur de consulter et mettre à jour lui-même ses informations.
Responsable de traitement, sous-traitant : qui fait quoi ?
Dans un projet d’application métier, votre entreprise est en général le responsable de traitement : c’est elle qui décide pourquoi et comment les données sont traitées. L’agence qui développe et maintient l’application, l’hébergeur ou un éditeur de service d’envoi d’e-mails agissent comme sous-traitants : ils traitent les données pour votre compte et selon vos instructions.
| Acteur | Rôle habituel | Points d’attention |
|---|---|---|
| Votre entreprise | Responsable de traitement | Définit les finalités, tient le registre, informe les personnes |
| Agence de développement et maintenance | Sous-traitant | Contrat précisant les obligations, confidentialité, sécurité |
| Hébergeur | Sous-traitant | Localisation des données, garanties de sécurité |
| Services tiers (e-mail, SMS, paiement) | Sous-traitant ou responsable selon les cas | Transferts hors Union européenne, conditions contractuelles |
Le RGPD impose un contrat entre le responsable de traitement et chaque sous-traitant, qui précise notamment l’objet du traitement, les mesures de sécurité et le sort des données en fin de contrat. Lorsque des données sont transférées hors de l’Union européenne, des garanties spécifiques sont nécessaires, un point qui rejoint les questions d’hébergement et de souveraineté des données.
Registre, DPO, analyse d’impact : les obligations documentaires
Le registre des traitements
Le registre recense les traitements de données de l’entreprise : finalités, catégories de données et de personnes, destinataires, durées de conservation, mesures de sécurité. L’exemption prévue pour les structures de moins de 250 salariés est très limitée et ne s’applique pas aux traitements réguliers, si bien qu’en pratique la plupart des entreprises doivent tenir ce registre. Votre nouvelle application doit y figurer.
Le délégué à la protection des données (DPO)
La désignation d’un DPO est obligatoire pour les organismes publics et pour les organismes dont l’activité principale implique un suivi régulier et systématique de personnes à grande échelle, ou le traitement à grande échelle de données sensibles. Dans les autres cas, elle reste facultative, mais désigner un référent interne pour ces sujets est une bonne pratique.
L’analyse d’impact (AIPD)
Lorsqu’un traitement est susceptible d’engendrer un risque élevé pour les personnes, par exemple un suivi de géolocalisation de salariés ou le traitement de données de santé à grande échelle, une analyse d’impact relative à la protection des données doit être menée avant sa mise en œuvre.
Sécurité et violations de données
Le RGPD exige des mesures de sécurité adaptées au risque : contrôle des accès, chiffrement des échanges, journalisation, sauvegardes. Ces mesures sont détaillées dans notre article sur la sécurité d’une application métier. En cas de violation de données présentant un risque pour les personnes, l’entreprise doit la notifier à la CNIL dans un délai de 72 heures après en avoir pris connaissance, et parfois informer les personnes concernées. Une application qui conserve des traces des accès aide à mesurer l’étendue d’un incident.
Conclusion : intégrer le RGPD au projet plutôt que le subir
Le RGPD n’est pas un frein à votre projet d’application métier, c’est une grille de lecture qui pousse à faire des choix sains : collecter moins, conserver moins longtemps, mieux contrôler les accès. Intégré dès la conception, il se traduit par quelques fonctionnalités bien pensées et une documentation à jour, plutôt que par des corrections coûteuses après la mise en ligne.
Vous préparez une application qui traitera des données personnelles et souhaitez partir sur de bonnes bases ? Chez Symbiose, nous abordons ces questions dès les premiers ateliers : contactez-nous pour en parler.