RGPD et développement d’applications : bonnes pratiques

RGPD et développement d’applications : bonnes pratiques La loi RGPD en quelques mots RGPD est l’abréviation de Règlement Général sur la Protection des Données. Il régit le traitement des données personnelles au sein de l’Union européenne et fait l’objet d’une mise à jour pour suivre les évolutions technologiques et sociétales, telles que l’essor du numérique et du commerce en ligne. Le règlement est en phase avec la loi française de 1978 sur la protection des données et renforce le contrôle des utilisateurs sur leurs données. Le RGPD fournit un cadre juridique cohérent aux professionnels opérant en Europe, leur permettant de mener leurs activités numériques en toute confiance avec les utilisateurs. Le 24 novembre 2022, la CNIL a annoncé son plan d’action pour protéger la vie privée des utilisateurs et assurer la conformité des applications mobiles. Les applications mobiles étant une porte d’entrée majeure vers les contenus et services numériques, la CNIL s’engage à protéger la vie privée des utilisateurs par le biais de son plan d’action. Qu’est-ce qu’une donnée personnelle ? Le terme « données à caractère personnel » désigne toute information relative à une personne physique qui peut être identifiée directement ou indirectement. Il peut s’agir d’identifiants tels que des noms ou des numéros de clients, mais aussi de données biométriques, de caractéristiques physiques et d’éléments culturels ou sociaux. L’identification d’une personne peut se faire à l’aide d’une seule donnée ou par la combinaison de plusieurs informations. Par exemple, le numéro de sécurité sociale d’une personne peut être utilisé pour l’identifier, tout comme une combinaison de son adresse, de sa date de naissance, de ses abonnements à des magazines et de son implication dans diverses associations. Le terme « traitement de données à caractère personnel » désigne une série d’actions entreprises à l’égard de données à caractère personnel, quelle que soit la méthode utilisée, telles que la collecte, l’enregistrement, l’organisation, le stockage, la modification, l’extraction, la consultation, l’utilisation, la transmission, la diffusion ou la fourniture de données par le biais de toute forme de communication. Parmi ces actions, on peut citer la tenue d’un fichier clients, la collecte d’informations de contact par le biais d’enquêtes et la mise à jour des dossiers des fournisseurs. Il convient de noter que le traitement des données à caractère personnel englobe également les dossiers papier, et pas seulement les dossiers informatisés. En revanche, un document contenant uniquement les coordonnées d’entreprises n’est pas considéré comme un traitement de données à caractère personnel. Pour finir, il est essentiel que le traitement des données ait une finalité spécifique et légitime. La collecte ou le traitement de données à caractère personnel sans objectif clair n’est pas acceptable. Chaque activité de traitement des données doit être légale et pertinente pour les activités de votre entreprise. Par exemple, lorsque vous fournissez un service ou un produit à vos clients, comme la livraison de marchandises, l’émission d’une facture ou la mise en place d’un programme de fidélisation, la collecte d’informations les concernant entre dans la catégorie du traitement des données à caractère personnel. L’objectif de ce traitement est de gérer vos clients. Développement d’applications : la responsabilité liée au traitement des données personnelles Une entreprise propriétaire d’une application est concernée par la loi RGPD dès lors qu’elle traite des données personnelles de personnes situées sur le territoire européen par le biais de ladite application. Elle doit donc s’assurer que son processus de traitement des données est conforme avec la loi RGPD. Chez LINKAVIE, la prise en compte des spécificités liées à la loi RGPD et à la protection des données personnelles est prise en compte dès la conception de l’application. C’est-à-dire que les questions de la définition des données collectées, leur finalité et les techniques de récolte sont déterminées dès les premiers échanges entre l’agence et le client. Dans les grandes lignes, il faut être conscient que l’utilisateur de l’application doit : être informé de la récolte de ses données personnelles ainsi que de sa finalité, donner volontairement son consentement avant toute collecte de donnée, pouvoir rectifier ou contester cette récolte à n’importe quel moment. D’une façon plus générale, les données récoltées doivent être reconnues comme étant “nécessaires à la réalisation du service attendu” et doivent surtout être sécurisées.  Les sanctions en cas de non-respect du RGPD La formation restreinte de la CNIL peut prononcer un rappel à l’ordre, ordonner la mise en conformité d’un traitement, restreindre temporairement ou définitivement un traitement, suspendre des flux de données ou infliger une amende administrative lorsqu’elle reçoit des signalements de manquements au RGPD ou à la loi. En outre, elle peut également ordonner la réalisation de demandes de droits individuels, sous peine de sanctions. En cas de manquement des responsables de traitement et des sous-traitants aux dispositions du RGPD ou de la loi, à la suite de contrôles ou de plaintes, la formation restreinte de la CNIL ou son président peuvent prononcer des sanctions à leur encontre. Les sanctions peuvent être lourdes dans le cadre de la procédure ordinaire, conformément au règlement général sur la protection des données, avec un maximum de 20 millions d’euros ou de 4 % du chiffre d’affaires annuel mondial dans le cas des entreprises. En outre, ces sanctions peuvent être rendues publiques. RGPD et développement d’applications : les bonnes pratiques Gestion des consentements Les utilisateurs de votre application devront être informés du traitement de données mis en place ainsi que de leurs droits par le biais de mentions accessibles depuis n’importe quelle page de votre application, d’une politique de confidentialité visible. Tenue d’un registre des activités de traitement et data mapping Lors du traitement des données, il est important de cartographier la transmission de données. Ainsi, il est obligatoire pour toute organisation de tenir un registre des activités de traitement qui comprend une analyse complète du traitement des données dès la phase de conception de l’application, qu’elle soit Web ou mobile. Ce registre doit couvrir différents aspects tels que les endroits où sont collectées les données, les personnes impliquées dans le traitement des données, les catégories de données traitées, la finalité

Les techniques de priorisation en développement logicie

Les techniques de priorisation en développement logiciel Le projet est maintenant bien cadré, les exigences sont réunies et tout le monde se prépare pour commencer la course. Mais un rapide coup d’œil à la longue liste de user stories vous laisse pressentir qu’il sera impossible de toutes les traiter dans le délai imparti. Il est donc essentiel de passer à la prochaine étape : la priorisation du Backlog. Prioriser : une clé du succès Pourquoi prioriser ?  L’objectif est de fournir une valeur « business » maximale le plus tôt possible. Le chemin le plus court vers la mise en production consiste à développer le Produit Minimum Viable (MVP), nécessitant alors de revoir et prioriser le Backlog. Comment prioriser ? Alors que le client et les parties prenantes sont en mesure d’estimer valeur apportée par chaque fonctionnalité, seuls les développeurs et les experts peuvent estimer la charge de travail et les risques techniques associés. Pour le succès du projet, la prise en compte de ces deux aspects est primordial. La priorisation requiert alors une approche collaborative. Jetons un coup d’œil à quelques techniques de priorisation du backlog ayant fait leur preuve en matière d’assistance à maitrise d’ouvrage et de développement logiciel. Analyse MoSCoW Cette technique tire son nom des initiales de chaque catégorie proposée – en anglais : les « Must-have » ou les « incontournables », les « Should-have » ou les « essentiels », les « Could-have » ou les « conforts » et enfin les « Won’t-have » ou les « Pas maintenant ». La répartition des fonctionnalités dans chacune des quatre catégories est proposée comme suit : « Must-have » ou les « Incontournables »  – c’est le minimum absolu à livrer pour constituer le  MVP. Sans eux, le produit ne pourra pas délivrer, selon les cas,  la valeur, la sécurité ou la qualité attendue. « Should-have » ou les « Essentiels » – ce sont les fonctionnalités pas nécessairement vitales, mais importantes. Celles-ci sont largement souhaitables en raison de leur valeur pour les parties prenantes ou pour les utilisateurs finaux. « Could-have » ou les « Conforts » – moins d’impact sur le produit final s’il est laissé de côté. « won’t have » ou les « Pas maintenant » – – les fonctionnalités pas prévues pour maintenant et considérées dans l’immédiat comme un luxe, mais il est toujours important de les documenter au cas où elles pourraient être réintroduites plus tard. Le succès de cette technique dépend de la distinction claire des quatre catégories ci-dessus et du consentement mutuel sur le statut attribué à chaque fonctionnalité. Par ailleurs, il est conseillé de conserver un rapport de 3 : 1 : 1 entre les Must-have, Should-have et Could-have afin d’équilibrer et de pouvoir gérer tout imprévu. La méthode MoSCoW, si elle est correctement appliquée, offre au client et à l’équipe de développement une bonne perspective de réussite d’un projet. Le test des cent euros Le test des cent Euros consiste à « acheter » des idées avec une « monnaie à idées ». Chaque participant dispose de cent euros et pourra acheter les fonctionnalités ou les idées du backlog à la valeur qui lui donne. Plus la valeur cumulée attachée à une fonctionnalité est élevée, plus sa priorité sera élevée. En limitant le montant d’argent dépensé par participant, on gardera le vote équitable. Cette technique peut être mise en œuvre pour obtenir des résultats clairs et impartiaux. Le Poker des  priorités  Il s’agit d’une variante du Planning Poker qui se concentre sur la priorité des fonctionnalités. Les parties prenantes reçoivent une liste de fonctionnalités qui seront à prioriser sur une certaine échelle comme par exemple : 5 (priorité très élevée), 4, 3, 2, 1 (priorité très faible), les priorités étant matérialisées par un jeu de cartes distribuées à chaque participant. Le Scrum Master lit alors la description de chaque user story puis chaque participant lui attribue une priorité en plaçant l’une des cartes priorité face cachée en premier. Les cartes sont ensuite retournées simultanément. Il y aura forcément des écarts de score. Suit après une discussion afin d’atteindre un consensus sur l’importance de chaque user story. Il est aussi possible de calculer un score global pour chaque story pour déterminer les priorités relatives. Répétez l’exercice avec tous les éléments du backlog. Priorisation en deux étapes La priorisation du backlog est la prérogative du Product Owner et à ce titre implique généralement le client et les parties prenantes. Ces derniers sont mieux placés pour l’appréciation de la valeur business tandis que l’équipe technique peut fournir des estimations d’experts sur les aspects techniques. Il peut être alors logique que l’équipe de développement ait également son mot à dire. Ainsi, après avoir estimé la valeur et l’effort, il est essentiel d’avoir une discussion tous ensemble. Les techniques évoquées ci-dessous permettent d’aligner les besoins business et les contraintes techniques. Approche Business Vs Effort Cette approche est assez facile à mettre en œuvre pour des projets de petite taille où l’on peut assez facilement diviser les fonctionnalités sur deux axes : l’axe « important / sans importance » et l’axe « simple / complexe ». Le backlog est alors grossièrement distribué selon quatre catégories selon ces deux axes : « valeur commerciale » et « effort estimé » (mesuré en story points). Voici une représentation graphique de l’idée : Mais alors, une fois cette cartographie réalisée,  quelle catégorie développer en premier ? Étant donné que la création de valeur le plus tôt possible est la clé du succès, nous commencerons par les stories « à haute valeur ajoutée et à effort réduit ». Celles-ci sont en général peu nombreuses et les livrer tôt permet de recevoir des retours tôt dans le projet. Ensuite, au fur et à mesure que l’équipe monte en puissance, il est bon de proposer des fonctionnalités « à haute valeur ajoutée, à haut niveau d’effort ». Celles-ci prendront une part importante du temps et de l’effort, mais elles seront essentielles pour générer de la valeur. Avec le temps, les exigences seront affinées, les estimations de chaque story seront plus faciles à réaliser et les risques liés à l’incertitude diminueront probablement. Le quadrant « faible valeur, faible effort » ne sont que des « nice-to-have » et ne feront pas beaucoup la différence. Leur mise en œuvre dépendra donc du budget disponible. Quant aux