Publication par la CNIL d’un kit de bonnes pratiques pour les développeurs

Après un an de mise en application du RGPD, nous commençons à y voir plus clair sur les diverses obligations de tous les acteurs économiques qui participent à la mise en œuvre des traitements automatisés parmi lesquels au premier rang les développeurs d’application. Ce Règlement adopté le 27 avril 2016 et rendu définitivement obligatoire sur tout le territoire de l’union européenne au 25 mai 2018 a pour finalité de créer la confiance des personnes concernées en permettant le développement de l’activité économique des entreprises européennes traitant des données. Le RGPD s’applique au traitement automatisé des données, ainsi les développeurs d’applications doivent intégrer à tous les stades de leur développement les dispositions de l’article 25 du RGPD soit la « protection des données dès la conception » ou Privacy by Design et la « protection des données par défaut » ou Protection by default. Pour bien les en persuader, et les rappeler à leur responsabilité en cas de non-respect du règlement (Amende maximale de 20.000.000 d’euros ou 4 % du chiffre d’affaires), la CNIL vient de mettre en ligne un « kit de bonnes pratiques  à destination des développeurs » pour qu’ils améliorent la gestion des données et la sécurisation de leur programme afin que tous les intervenants économiques concernés par la mise en œuvre des traitements automatisés : développeurs, responsables de traitements, et/ou sous-traitants, soient sensibilisés aux enjeux de protection de la vie privée.  Ce « Kit de bonnes pratiques » se décline en 6 rubriques ici décryptées et commentées. 1) le choix des outils de travail :         Développer un projet data en lien avec une application logicielle suppose l’accès à des données appartenant à l’entreprise, la mise en œuvre de la Privacy by Design ou Privacy by default appelé ci-avant dans l’article 25 du RGPD consiste donc à : D’abord cartographier les outils de travail, détail des utilisations :(messagerie instantanée interne à l’entreprise et/ou ouvertes sur l’extérieur ; environnement de développement ; supports numériques collaboratifs d’échange de documents) C’est à ce stade que l’identification des rôles est importante et outre la cartographie elle passe aussi par une nécessaire rédaction contractuelle pour distribuer entre  ceux-ci leurs obligations :

• Qui sera responsable de traitement, sous-traitant ou cotraitant,
• Qui décide d’ouvrir l’accès aux données et dans quelles conditions, ce qui suppose aussi de cartographier la répartition des rôles entre ceux qui sont autorisés à accéder à la donnée, à la lire, à la modifier, à l’effacer ou à déléguer son autorisation, (Privacy by Défault)
• Ou la donnée sera-t-elle stockée en interne ou en externe et dans quelles conditions ? (Privacy by Défault)

Toutes ces questions doivent être strictement contractualisées et documentées en permanence. 2) la préparation du développement en toute sécurité (Article 25 RGPD) : Pour la CNIL l’organisation de la sécurité du développement s’appuie sur 3 pratiques conjointes pensées dès la conception. Premier réflexe de Privacy by design et by default: L’organisation de la sécurité des méthodes qui passe par une analyse d’impact (AIPD) avant tout développement, la CNIL recommandant, même pour les traitements ou elle n’est pas a priori obligatoire de la faire pour mieux mettre en lumière le respect tout au long du développement et du traitement final des droits des personnes concernées ou datas Subjects. Deuxième réflexe de Privacy by design et by default : Pour s’assurer du bon fonctionnement de la sécurité du traitement et du fonctionnement futur de l’application, rédiger les « récits utilisateurs » ou « User Stories » décrivant de manière précise le contenu des fonctionnalités à développer. On souligne ici que cette documentation particulière à l’organisation du développement de l’application, de toute façon rendra plus facile ensuite pour la phase finale et opérationnelle de mise en œuvre du traitement la rédaction des documents à destination des datas subjects à rédiger par application des dispositions des articles 13 et 14 du RGPD, et ce seront des aides non négligeables pour définir la finalité du traitement (RGPD article 5§b) et sa base légale (RGPD article 6). Par ailleurs les « récits utilisateurs » ou « User stories » devront aussi s’expliquer sur les choix des normes de programmation en se référant à un système de codage justifié incluant les normes et bonnes pratiques de la programmation au meilleur état de l’art informatique au moment du développement et en lien avec la destination de l’application. Troisième réflexe de Privacy by design et by default : Justifier du choix des technologies utilisées et de leur compatibilité avec une sécurité optimale. 3) les bonnes pratiques pour le développement ou la gestion du code source : La CNIL recommande l’utilisation d’un outil de gestion de code source permettant de suivre dans le temps ses différentes versions en insistant sur les réflexes suivants :         Si le projet s’est développé avec une brique de logiciel libre et que l’utilisateur doit rendre disponible la modification qu’il aura apportée à l’écriture du code, Documenter l’origine et les conditions dans lesquelles s’est effectuée le dépôt des retours de l’amélioration de l’écriture. Prévoir la traçabilité de toutes les permissions d’accès à l’écriture du code en ce compris les processus de validation des modifications d’écriture (Commit) en précisant les conditions de réciprocité éventuelle (Checkout) En évitant l’enregistrement de données personnelles ou confidentielles dans le code source. 4) les précautions à l’intégration dans les applications des Bibliothèques, SDK (kits de développement) ou outils tiers (composantes logicielles écrit par des tiers) : La CNIL recommande la cartographie systématique de toutes les Bibliothèques et outils intégrés avec la description de leur mise à jour et caractéristiques. Documenter les conditions dans lesquelles le développeur a adapté à son usage les éléments intégrés en justifiant qu’il a notamment modifié la configuration par défaut et qu’il s’est bien approprié la parfaite utilisation des fonctionnalités en justifiant des essais d’utilisations divers. Vérification que les données qui transitent sur ces dépendances intégrées seront bien protégées : qui sera destinataire de la donnée avec de ce point de vue une veille documentaire constante. Par cette quatrième recommandation de bonne pratique, la CNIL optimise les conséquences de sa très pédagogique décision prise à l’occasion de la mise en demeure rendue publique dans sa décision Vectaury (Décision MED-2018-042 du 30/10/2018) que tous les développeurs d’applications devraient apprendre par cœur !! S’il intègre dans son application des procédés de cryptologie le développeur justifiera son parfait paramétrage en fonction de ses stricts besoins. 5)  L’écriture du code et les bonnes pratiques : La CNIL recommande aux développeurs de développer un code propre ou code auteur en le contrôlant régulièrement 6) Une  documentation des différentes phases de développement : Tout l’enjeu des 6 recommandations du kit de développement proposé par la CNIL renvoie bien aux principes généraux du RGPD qui reposent sur l’Accountability  qui suppose au stade du développement aussi une documentation et une traçabilité permanente de toutes les mesures prises pour, pendant et par le développement, et le développeur aura tout intérêt à s’adjoindre un DPO externe et/ou interne pour l’aider à vérifier si le développement du système intègre les modalités du RGPD de l’article 25 pour assurer la protection des données dès la conception et par défaut. Par ailleurs, même si la CNIL ne l’aborde pas expressément dans ce kit de recommandations à destination des développeurs car elle le fait dans d’autres publications, (Voir son Rapport du 15/12/2017 Comment permettre à l’Homme de garder la Main ? Rapport sur les enjeux éthiques des algorithmes et de l’intelligence artificielle) ; tout développement d’applications logicielles intégrant l’intelligence artificielle et/ou un « traitement automatisé » devra respecter le principe de la transparence algorithmique, donc on ne peut que recommander au développeur de prévoir aussi dans sa documentation en plus des 6 recommandations commentées les principes d’explicabilité et d’intelligibilité algorithmique. Une grande bataille juridique s’annonce car l’explicabilité algorithmique est prévue par le RGPD, le considérant 71 dernier paragraphe pose les bases de cette « explicabilité » qui peut constituer l’esquisse de la documentation type à prévoir mais la mise en œuvre de ce principe émergent de l’explicabilité algorithmique s’avère difficile car les textes rédigés en référence au considérant 71, eux font référence à un autre terme au titre de la notion d’une nécessaire obligation d’information sur la logique sous-jacente du traitement, articles 13 § 2-f et 14 § 2-g du RGPD ainsi que l’article 15 § H pour le droit d’accès. L’article 22 lui aborde le principe de l’explicabilité de manière différente. On reviendra par d’autres articles en préparation très rapidement sur ces problèmes de l’explicabilité algorithmique, car à court et moyen terme cette question fera parler d’elle.  Le développeur prudent, et bien conseillé aura soin de documenter dès la conception de son projet les bases d’une explicabilité de son traitement algorithmique ; dans des conditions respectant si nécessaire le secret des affaires étant entendu que ce principe du secret des affaires ne saurait être un frein à l’exercice de ce que beaucoup considèrent être un nouveau droit et une nouvelle liberté fondamentale numérique à conquérir, le débat ne fait que commencer. Ou l’on voit donc que le RGPD doit donc bien être appréhendé comme une technique d’organisation de l’entreprise transversale à toutes ses activités et dont le respect est un gage de valorisation et de compétitivité des actifs immatériels de l’entreprise. Véronique Rondeau-Abouly Avocat au barreau de Marseille cabinet@rondeau-abouly.com

Retour