RGPD : ce que doit prévoir une application métier

Une application métier conforme au RGPD se construit dès le cahier des charges, pas après la mise en ligne. Elle ne collecte que les données utiles à une finalité écrite, fixe une durée de conservation pour chacune, permet d'exercer les droits des personnes, protège l'accès et trace les opérations sensibles. Le contrat avec le prestataire, enfin, doit contenir les clauses de sous-traitance exigées par l'article 28.

Cet article donne une check-list pratique pour une PME qui fait développer un outil interne ou un portail client. Il s'appuie sur le texte du règlement et sur le guide RGPD du développeur de la CNIL, mais il ne remplace pas l'avis de votre délégué à la protection des données (DPO) ou d'un avocat pour les traitements sensibles.

Pourquoi le RGPD se joue au moment de la conception

L'article 25 du règlement (UE) 2016/679 impose la protection des données dès la conception et par défaut : le responsable du traitement doit mettre en place des mesures techniques et organisationnelles adaptées dès la définition des moyens du traitement, et ne traiter par défaut que les données nécessaires à chaque finalité.

Concrètement, une décision prise dans un écran du prototype (un champ « date de naissance » obligatoire, un historique conservé sans limite, un export ouvert à tous les profils) devient une question de conformité. Corriger ces choix après coup coûte une reprise de données et des développements ; les poser dès le cadrage ne coûte presque rien.

Rappel utile : c'est vous, l'entreprise qui décide de la finalité, qui êtes responsable du traitement. Le prestataire qui développe, héberge ou maintient l'application est en général sous-traitant. La responsabilité de la conformité ne se délègue donc pas entièrement, même si le prestataire doit vous y aider.

La check-list, principe par principe

Les principes de l'article 5 du RGPD se traduisent assez directement en exigences de développement.

Finalité et base légale. Chaque traitement doit avoir un objectif explicite et une base légale (contrat, obligation légale, intérêt légitime, consentement). Pour un outil interne, ce sont le plus souvent l'exécution du contrat de travail ou l'intérêt légitime. Le consentement est rarement la bonne base entre un employeur et ses salariés.

Minimisation. Chaque champ de formulaire se justifie. Le numéro de téléphone personnel d'un technicien, la photo d'un client, la date de naissance d'un contact : si l'application fonctionne sans, on ne les demande pas. C'est aussi ce qui réduit les dégâts en cas de fuite.

Durées de conservation. C'est le point le plus souvent oublié. Une application qui garde tout pour toujours n'est pas conforme. Il faut fixer une durée par catégorie de données (fiches clients inactives, dossiers d'intervention, journaux de connexion), puis la faire appliquer par le logiciel : suppression, archivage intermédiaire ou anonymisation.

Droits des personnes. Accès, rectification, effacement, opposition, portabilité : l'application doit permettre de retrouver toutes les données d'une personne et de les exporter ou de les supprimer sans intervention d'un développeur. Une fonction d'export par personne et une suppression qui couvre aussi les fichiers joints suffisent souvent.

Information. Les personnes concernées doivent savoir quelles données sont traitées, pourquoi, combien de temps et par qui. Pour un portail client, cela passe par une politique de confidentialité accessible depuis l'application ; pour un outil interne, par une note d'information aux salariés.

La sécurité, une obligation de moyens adaptés au risque

L'article 32 demande des mesures de sécurité « appropriées » au risque et cite notamment la pseudonymisation et le chiffrement, la capacité à garantir la confidentialité, l'intégrité et la disponibilité, la capacité à rétablir l'accès aux données après un incident, et des tests réguliers de l'efficacité des mesures. Pour une application métier, le socle est connu :

• authentification solide, avec double facteur pour les comptes d'administration ;
• droits par rôle : un commercial ne voit pas la paie, un sous-traitant ne voit que ses chantiers ;
• chiffrement des échanges (HTTPS) et des sauvegardes ;
• journalisation des accès et des exports sensibles ;
• sauvegardes testées, avec une restauration réellement essayée ;
• mises à jour des dépendances, qui relèvent de la maintenance.

Le sujet est développé dans notre article sur la sécurité d'une application métier.

En cas de violation de données, l'article 33 impose de la notifier à la CNIL dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance, sauf si elle ne présente pas de risque pour les personnes. L'application doit donc produire les journaux qui permettent de comprendre ce qui s'est passé, et le contrat doit obliger le prestataire à vous prévenir sans délai.

Le registre et l'analyse d'impact

Le registre des activités de traitement (article 30) recense les traitements, leurs finalités, les catégories de données et de personnes, les destinataires et les durées de conservation. Le texte dispense les organisations de moins de 250 salariés, mais pas lorsque le traitement est susceptible de comporter un risque, n'est pas occasionnel, ou porte sur des données sensibles ou pénales. La CNIL précise sur sa page consacrée au registre que la gestion de la paie ou des clients est un traitement non occasionnel, et que la dérogation est donc limitée à des cas très particuliers. Une nouvelle application métier s'ajoute presque toujours au registre.

L'analyse d'impact (AIPD) de l'article 35 n'est obligatoire que pour un traitement susceptible d'engendrer un risque élevé : évaluation systématique de personnes avec profilage, données sensibles à grande échelle, surveillance à grande échelle d'une zone publique. La géolocalisation continue de salariés ou des données de santé méritent une vérification avec votre DPO.

Ce que le contrat avec le prestataire doit contenir

Dès que le prestataire accède à des données personnelles pour votre compte, l'article 28 exige un contrat écrit. Il doit notamment prévoir que le prestataire :

• ne traite les données que sur vos instructions documentées, y compris pour un transfert hors de l'Union ;
• impose la confidentialité aux personnes autorisées ;
• applique les mesures de sécurité de l'article 32 ;
• ne recourt à un autre sous-traitant (un hébergeur, un outil d'envoi d'e-mails) qu'avec votre autorisation écrite, et vous informe des changements ;
• vous aide à répondre aux demandes des personnes et à gérer une violation ;
• supprime ou restitue les données, à votre choix, à la fin de la prestation ;
• vous fournit les informations utiles et accepte les audits.

Ces clauses s'ajoutent au reste du contrat de développement (périmètre, recette, propriété, réversibilité), détaillé dans notre article sur les clauses à vérifier. Le lieu d'hébergement et les transferts hors de l'Union sont traités à part, dans où héberger une application métier.

Les erreurs les plus fréquentes

• Copier la base de production sur un poste de développement. Les tests se font sur des données fictives ou pseudonymisées.
• Laisser des exports Excel circuler. Un export illimité ouvert à tous annule les droits par rôle. Limitez-le et tracez-le.
• Oublier les fichiers joints. Supprimer une fiche sans supprimer ses pièces jointes, c'est garder les données.
• Multiplier les outils tiers. Chaque service ajouté (analyse d'audience, support, envoi d'e-mails) est un sous-traitant de plus, à déclarer et à encadrer.
• Ne rien documenter. Sans registre ni description des mesures, vous ne pouvez pas démontrer votre conformité, ce que l'article 5 exige.

L'enjeu n'est pas théorique : les manquements les plus graves peuvent être sanctionnés jusqu'à 20 millions d'euros ou 4 % du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu (article 83). Mais pour une PME, le premier bénéfice est ailleurs : une application qui ne garde que l'utile est plus simple à sécuriser et à maintenir.

Par où commencer

Faites la liste des données que l'outil manipulera, avec pour chacune son usage et sa durée de conservation, avant d'écrire la moindre fonctionnalité. Chez LPR Studio, ces questions se posent dès le cadrage (voir notre approche) : le prototype gratuit, présenté en visio sous 5 jours ouvrés, montre déjà les écrans, les champs et les profils, donc ce que chacun pourra voir. C'est le bon moment pour les relire avec votre DPO.