Blog BA

Capitaliser sur ses processus pour se conformer au RGPD

by Laurent Hassid on 05/03/2018 Commentaires fermés sur Capitaliser sur ses processus pour se conformer au RGPD

irecteur associé chez BPMS

Le RGPD, de quoi s’agit-il ?

Le RGPD sert à protéger, à l’échelle européenne, la vie privée de l’individu contre une utilisation abusive de ses données personnelles, alors que les injonctions paradoxales ne manquent pas :

  • pour l’entreprise, la donnée est devenue un actif stratégique avec des besoins de corrélation et d’analyse des données massives,
  • ladite entreprise s’appuie sur des organisations et des systèmes d’information largement ouverts aux clients et partenaires, avec des services désormais proposés dans le Cloud.

Ce contexte a amené le régulateur, l’Union Européenne, à exiger des entreprises une capacité à s’autoréguler et à prouver la conformité de leurs traitements, en remplacement des exigences de déclarations préalables antérieures.

La définition d’un traitement est large : «toute opération ou tout ensemble d’opérations effectuées ou non à l’aide de procédés automatisés et appliquées à des données ou des ensembles de données à caractère personnel, telles que la collecte, l’enregistrement, l’organisation, la structuration, la conservation, l’adaptation ou la modification, l’extraction, la consultation, l’utilisation, la communication par transmission, la diffusion ou toute autre forme de mise à disposition, le rapprochement ou l’interconnexion, la limitation, l’effacement ou la destruction».

La notion de données est donc une composante essentielle de la RGPD, mais sous un angle synthétique particulier, seules les données personnelles et sensibles nécessitant une protection encadrée par la loi. Les durées de conservation sont également une préoccupation renforcée, pour ne pas dire nouvelle.

L’enjeu de l’exigence de la capacité à s’autoréguler est d’importance, car les sanctions encourues se veulent représentatives des dommages causés aux individus : là où l’entreprise pouvait jusqu’à présent limiter son évaluation du risque à un impact interne (par exemple pour un vol de données : une perte d’actif et le cas échéant un risque de réputation) elle devra désormais considérer la probabilité d’une forte sanction financière.

Les étapes incontournables

La CNIL propose une démarche en 6 étapes dans un excellent document de synthèse :

  1. Désigner un délégué à la protection des données, le DPO, qui va orchestrer les travaux en lien avec les responsables de traitements et les sous-traitants et gérer la relation avec l’autorité de contrôle
  2. Cartographier les traitements et pour chacun les catégories de données personnelles exploitées et compléter cet inventaire selon 5 axes : Qui sont les responsables du traitement ? Pourquoi les données sont-elles traitées ? Où sont-elles hébergées ou transférées ? Combien de temps sont-elles conservées ? Comment sont-elles protégées ?
  3. Prioriser les actions suite à une revue orientée risques et conformité légale des traitements décrits à l’étape 2. Deux livrables sont attendus : les premières mesures d’urgence et l’identification des traitements à risque.
  4. Ces traitements à risques doivent faire l’objet de mesures de protection adaptées au risque encouru. Elles sont recensées dans le cadre d’études d’impact sur la protection des données (PIA).
  5. Les processus internes doivent ensuite porter la préoccupation de protection des données à tous les niveaux, de la conception des applications [Security by Design], aux rapports avec les individus concernés, jusqu’au lien avec les autorités de contrôle.
  6. La dernière étape de documentation de la conformité vise à garantir la pérennité de l’implication de l’entreprise au-delà du mode projet initial.

A compter de la seconde étape, la présentation suivante pourrait également être proposée :

La contribution de l’approche processus (Connaître)

[C1] Le référentiel processus constitue un excellent support pour identifier la maille pertinente des traitements à analyser, par processus ou regroupement de processus, et donc construire l’inventaire des traitements.

[C2] Une approche « moderne » de la modélisation des processus, permettant un dialogue étroit entre métier et SI, vous aura amené à formaliser les jalons clés d’un processus : ces étapes, qui ont vocation à être

  • pilotables par le métier,
  • et donc matérialisées dans le SI.

En créant un lien entre processus et données à piloter, ces jalons constituent une source précieuse pour nourrir l’inventaire des données métier associées à chaque traitement.

Difficulté supplémentaire qui n’est pas propre au RGPD mais caractérise tout chantier SI ciblé données, il s’agira d’assurer au sein du référentiel la cohérence entre 2 visions de la donnée :

  • la vision métier, qui reprendra le vocable familier des parties prenantes
  • et la vision SI, qui permettra de faire le lien avec les référentiels de données.

Cette dernière, plus rigoureuse mais aussi plus complexe et fragmentée, peut difficilement servir de base à des échanges avec le métier : il est en effet fréquent qu’une « donnée métier » se traduise au plan informatique par une demi-douzaine de « données SI ». Ainsi, derrière la notion de « client entreprise », se cachent le tiers personne morale, le tiers personne physique, le rôle client, la localisation géographique,…

Seul un sous-ensemble de ce périmètre étant susceptible de porter des données pouvant être qualifiées de personnelles.

[C3] La description des traitements sensibles peut ensuite faire l’objet d’une modélisation spécifique RGPD. La norme BPMN permet de décrire des enchaînements d’opérations manuelles ou automatisées, en qualifiant chacune des opérations, et permet d’indiquer les données utilisées. Le traitement RGPD peut donc être considéré comme un « sous-processus » réutilisable si besoin, dans différents contextes.

[C4] Les mesures de protection appliquées aux traitements sensibles à identifier à cette étape ne concernent à mon sens que les mesures très spécifiques et directes au traitement concerné. De nombreux dispositifs essentiels de maîtrise des risques sur les systèmes d’information ont une portée générale (sur l’accès au système d’information ou les moyens d’extraction de données par exemple) et leur place est dans une approche globale de management du risque (voir ci-dessous les points [M2] et suivants).

[LIV1] Pour produire le registre des traitements il faut établir les liens entre les traitements (et leurs finalités), les acteurs (et leurs habilitations), les données (et leur qualification éventuelle Données Personnelles ou DP sensibles), les applications et les dispositifs de maîtrise de risques (DMR) en vigueur. Par rapport à la norme BPMN, seuls les derniers éléments devront être complétés : les applications et les risques, eux-mêmes reliés aux dispositifs de maîtrise de risques. Si quelques compléments s’imposent, comme l’identification de rôles précis tels que le DPO, le responsable de traitement ou les sous-traitants RGPD, la plupart des informations requises sont probablement déjà disponibles, sous une forme ou sous une autre, dans votre référentiel processus.

[LIV2] Enfin, le référentiel devra porter les processus requis par le RGPD :

  • concevoir une application ou un traitement. Il s’agira de prendre en compte la protection des données personnelles dès la conception : minimisation de la collecte de données au regard de la finalité, cookies, durées de conservation, mentions d’information, recueil du consentement, sécurité et confidentialité des données, rôle et responsabilité des acteurs impliqués ;
  • traiter les réclamations et les demandes des personnes concernées quant à l’exercice de leurs droits : droits d’accès, de rectification, d’opposition, droit à la portabilité, retrait du consentement ;
  • mais aussi l’ensemble des activités visant à documenter la conformité au RGPD.

Des processus à la gouvernance des données (Maîtriser le besoin de données)

Rappelons que la réalisation de l’inventaire des traitements et des données a amené à se poser les questions suivantes :

  • Qui sont les responsables du traitement ?
  • Pourquoi les données sont-elles traitées ?
  • Où sont-elles hébergées ou transférées ?
  • Combien de temps sont-elles conservées ?
  • Comment sont-elles protégées ?

La mise en pratique est potentiellement délicate, quand, avec la généralisation de traitements dans le Cloud, il devient parfois impossible de localiser le stockage de la donnée. Les réponses, au-delà d’un inventaire ponctuel, permettent de formaliser et d’impulser une véritable approche de gouvernance des données à partir des étapes manuelles et automatisées identifiées et du cycle de vie de la donnée défini par des jalons.

Il restera alors à construire un dispositif pérenne de gouvernance :

  • en instituant un lien régulier entre DPO, services opérationnels et services IT qui amènera nécessairement à une meilleure maîtrise des données et traitements,
  • en appliquant aux données les mêmes règles SI ou métier,
  • et enfin pilotant les données (nombre, qualité, ancienneté…).

Management du risque (Maîtriser les risques liés aux données strictement nécessaires)

[M2] [M3] L’identification et l’évaluation des risques liés aux données ne sont pas nouvelles par nature. Néanmoins dans le cadre imposé par le RGPD, les sanctions encourues prennent en compte les dommages causés aux individus là où l’entreprise pouvait jusqu’à présent limiter son évaluation du risque à un impact interne (par exemple pour un vol de données : une perte d’actif et le cas échéant un risque de réputation). De plus :

  • des diligences d’évaluation et de traitement des risques sont précisées,
  • la notion de responsabilité est étendue, et notamment dans le cadre des traitements sous-traités,
  • le cadre fixé est celui des « traitements » là où vos travaux antérieurs se sont sans doute appuyés sur les applications.

L’ensemble de ces éléments devrait amener à restructurer un large périmètre de l’approche « classique » de cartographie des risques liés aux systèmes d’information. Les principes restent toutefois les mêmes : identification du risque, évaluation brute, mise en place et de dispositifs de maîtrise du risque et évaluation nette.

[M4] La capacité à documenter la conformité RGPD de l’entreprise sera toutefois fortement consolidée par l’usage d’un outil de Gouvernance des risques et de la conformité (GRC) pour démontrer l’exhaustivité de travaux réalisés et l’efficacité des dispositifs de maîtrise de risques. Ce type d’outil permet d’impulser les travaux récurrents, permettant ainsi de passer d’un mode « projet » de mise en conformité RGPD à un mode permanent d’évaluation des risques et de documentation de la conformité.

En conclusion

La boîte à outil Processus s’avère parfaitement adaptée pour aborder la problématique RGPD et permettra à l’entreprise de maîtriser sa démarche vis à vis des exigences définies par le législateur : maîtrise des bases juridiques de sa collecte d’information, de leur caractère proportionné (nature, durée de détention), de l’exploitation transparente et loyale de l’information…

Elle devra toutefois être complétée par des outils de Gestion des Risques et de la Conformité pour couvrir la dimension dynamique de la Gouvernance du dispositif.

Ce travail contraint par le RGPD offre également l’opportunité de revisiter les processus sous l’angle de l’interaction avec les individus (expérience client, usager, salarié…). La sélection par l’entreprise des seules informations à caractère personnel qui lui sont strictement nécessaires peut incidemment conduire, au-delà du respect de la norme imposée, à une meilleure expérience client.

  • RGPD
  • Approche Processus
  • Risque
  • Conformité
read more
Laurent HassidCapitaliser sur ses processus pour se conformer au RGPD

L’architecture fonctionnelle en support de l’analyse métier ciblée SI

by Admin BPMS France on 20/02/2018 Commentaires fermés sur L’architecture fonctionnelle en support de l’analyse métier ciblée SI

Extrait de l’ouvrage «Maîtriser les techniques de Business Analyse: Outils et cas pratiques » publié par BPMS et disponible sur Amazon.

Dès lors que la réponse à une problématique comporte une forte composante système d’information, se pose la question de la conception de cette brique. Avec souvent un double enjeu d’évolutivité et d’intégration à l’existant. Pour parvenir à améliorer, au travers de cette refonte, l’agilité globale du système d’information, il est utile pour le Business analyste de maîtriser les principes fondateurs des techniques d’urbanisation qui ont inspiré l’approche orientée service (SOA, API) mais peuvent être également utiles pour cibler correctement les outils du marché.

Le découpage urbanisé d’un système d’information s’appuie sur les données

De la même façon qu’un référentiel des processus métier, pour être maintenable dans la durée, doit s’appuyer sur des fondations stables, il n’est pas possible de piloter l’évolution permanente du patrimoine applicatif sans référence à un fonds de carte tout aussi stable.

Ce qui, côté métier, correspond à une cartographie des processus indépendante de l’organisation trouve son pendant, côté SI, dans la carte fonctionnelle. Qui pour être pérenne doit être correctement structurée.

C’est le but de l’architecture fonctionnelle que de proposer un fonds de carte stable sur lequel on pourra plaquer les évolutions successives du patrimoine applicatif : celui-ci pourra également servir à mesurer la redondance applicative (plusieurs applications couvrant le même périmètre fonctionnel) ou à anticiper les contraintes d’intégration d’un nouveau composant.

[…]

Comment parvenir à un découpage pertinent d’un domaine fonctionnel ?

Commençons par identifier ce qui ne fonctionne pas :

–       découper selon les fonctionnalités. Rien ne ressemble plus à une fonctionnalité de contrôle de la paie qu’une fonctionnalité de reporting commercial et pourtant factoriser cette fonction aurait probablement plus d’inconvénients que d’avantages ;

–       découper selon les périmètres des outils du marché : la stratégie des éditeurs est souvent de sortir de leur cœur de métier pour étendre leur zone d’influence et aboutir à des périmètres qui sont évolutifs et ne répondent pas forcément à une logique de cohérence forte.

À l’inverse, d’où viennent généralement les causes d’échec des projets informatiques ? Rarement d’un problème de couverture fonctionnelle : il est souvent possible d’enrichir le progiciel. Plus souvent d’un problème de structure de données.

C’est donc logiquement en regroupant par « affinité » les principales données à gérer (on parle généralement d’objets métier) que l’on arrive progressivement à structurer de manière pérenne la cartographie fonctionnelle.

Prenons l’exemple du domaine Ressource Humaines qui se caractérise notamment par le caractère personnel des données gérées des salariés. On trouvera en son sein deux sous-ensembles répondant à cette logique de cohérence forte :

–       un premier ensemble de données ciblées paye (le côté administratif du domaine) : contrat – échelon – paie – cotisations – statut

–       et un second ensemble plus ciblé compétences (le côté développement des ressources humaines) : compétences, formation, certification, parcours professionnels, diplôme,…

Même s’il y a des liens entre ces deux ensembles, qui justifient d’ailleurs leur appartenance au même domaine RH, il est légitime d’attendre qu’une évolution fonctionnelle dans l’administration de la paye soit sans impact sur la « gestion des talents » et inversement. Nous avons bien identifié deux sous-ensembles en couplage faible.

La structuration normalisée d’un SI urbanisé

Appliquées au périmètre de chaque domaine ainsi identifié, les bonnes pratiques d’urbanisation imposent notamment un découpage sur 3 ou 4 niveaux (zone-quartier-îlot–bloc) et une identification systématique de certaines zones :

–       la zone Echanges externes, qui matérialise les échanges de données avec les autres domaines, est un élément essentiel pour anticiper les contraintes d’intégration ;

–       les zones Données et Référentiel qui isolent les données de base de celles qui les encadrent et nécessitent donc une gestion particulière de leur cycle de vie ;

–       une zone Pilotage qui couvrira la dimension Tableaux de bord / requêtes mais aussi les alertes ;

–       une ou plusieurs zones « Métier » (et non pas une zone d’Opération unique si on ne peut justifier de sa cohérence forte) ;

–       enfin une zone Support pour rassembler les services support que l’on retrouve au sein de chaque domaine (sécurité, ergonomie,…).

Cette carte de haut niveau normalisée est désormais prête à être utilisée par le Business analyste pour structurer la liste des exigences solution.

Elle pourra également servir à la DSI pour positionner les logiciels déjà déployés dans l’entreprise, un même outil pouvant se retrouver dans différents domaines. La même carte peut être utilisée pour positionner les outils du marché sur le périmètre fonctionnel de l’étude.

_________________

Les prochaines formations sur l’architecture fonctionnelle que j’aurai le plaisir d’animer se dérouleront les 27-28 mars et les 16-17 juillet 2018.

read more
Admin BPMS FranceL’architecture fonctionnelle en support de l’analyse métier ciblée SI

Faire cohabiter édition papier et numérique : Amazon a des progrès à faire

by Admin BPMS France on 15/01/2018 Commentaires fermés sur Faire cohabiter édition papier et numérique : Amazon a des progrès à faire

Où comment le passage d’une version papier à sa déclinaison électronique s’avère beaucoup plus sinueux que prévu !

La fin d’année 2017 a été l’occasion, pour BPMS, de mener à bien un projet qui a mobilisé depuis deux ans nos consultants à Paris et Genève : celui de publier un ouvrage sur les bonnes pratiques de Business Analyse.

Au départ d’un tel projet se pose rapidement la question du choix du mode d’édition : rechercher un éditeur « traditionnel » ou auto-éditer via Amazon ?

Dans notre cas, le contenu même de l’ouvrage et son format hybride (un contenu primaire, le livre, complété par un contenu en ligne, les corrigés des cas pratiques), amenait une forte exigence d’évolutivité de cette partie « figée », les bonnes pratiques et leur outillage n’ayant pas vocation à rester gravées dans le marbre. Nous avons donc mené une « Business Analyse », allant jusqu’à tester le processus de sélection d’un éditeur « traditionnel ». Et le résultat fut sans appel, compte tenu de nos attentes : Amazon vainqueur par KO.

Et une feuille de route claire : commencer par l’édition papier – que nous voulions riche et en couleur, puis décliner celle-ci en une version électronique.

Dès le contenu du livre en phase de relecture, nous nous lançons donc avec « gourmandise » dans l’appropriation du riche écosystème mis à disposition des auteurs par le géant américain : outil de conception en ligne, contrôle automatique des erreurs,..

Il faut reconnaître que pour celui qui parle un minimum anglais, l’auto-édition est à la portée de tous.

Cette première étape n’est cependant pas exempte de difficultés, parfois inattendues : comment restituer du contenu Powerpoint au niveau de qualité d’image requis pour une édition papier ? Ou comment réaliser, au même niveau de qualité, des copies d’écran d’applications conçues pour le Web… Mais au final, même si cette dernière ligne droite s’avère plus sinueuse que prévue, nous avons la satisfaction de voir la version papier disponible à la vente fin novembre. Fin du premier acte.

Dans notre esprit, le rajout d’une version numérique, largement encouragé par Amazon, n’est qu’une question d’un jour ou deux, le temps de maîtriser les différentes étapes du processus et les délais de validation.

C’est là que notre « expérience utilisateur » va progressivement différer du parcours client optimal. Première surprise, Amazon est organisée en silo et la version Kindle ne sera pas gérée par la division (filiale ?) qui s’occupe de l’auto-édition, Amazon Createspace. Si la création d’un compte Kindle est relativement rapide (mais témoigne quand même d’un SI également en silo), il s’agira donc de gérer les 2 versions au sein de 2 interfaces distinctes. Jusque-là, rien de dramatique.

Cela se corse avec le premier avertissement sur le type de fichier à envoyer : là où Amazon recommande d’utiliser un format Word ou PDF, Kindle annonce d’emblée que le format PDF n’est pas celui qu’il gère le mieux et recommande fortement de repartir de la version Word. Qu’à cela ne tienne, nous avons bien un fichier de référence au format Word qui a servi de base à la génération de notre PDF haute définition. Sauf qu’à l’import, grosse déconvenue : la moitié des images n’est pas reconnue ! Vérification faite, Kindle ne reconnaît qu’un nombre très limité de format image, essentiellement les formats compressés qui nous ont précisément posé des problèmes pour la version papier… Idem pour les polices Word, pourtant très classiques, que nous avons utilisées comme icônes et utilisées abondamment au gré des 286 pages ! Quant à la question de la lisibilité des copies d’écran, que seule la génération d’un PDF haute définition avait permis de solutionner, ce n’est évidemment pas avec un format compressé que nous allons réglé le problème…

Au final, ce qui devait être une simple variante du fichier d’origine devient la nécessaire reprise ligne à ligne d’un fichier de 370 000 caractères… Pas vraiment l’objectif de départ.

Tout cela pour produire un fichier qu’une partie des lecteurs devra lire via une liseuse monochrome. Si nous avons choisi une édition papier intégralement en couleur, ce qui multiplie par 6 le coût d’impression, c’est que nous avons estimé que cela apportait quelque chose au lecteur…

Qui plus est, tous ces efforts n’ont qu’un seul but : gérer des problèmes d’affichage qui n’existent nullement si l’on affiche sur une tablette quelconque le PDF haute définition…

Fin particulièrement frustrante de l’acte II qui en appelle forcément un 3ème.

Début de l’acte III

Car à l’ère du numérique, difficile de se couper de la cible du lecteur nomade pour qui l’achat d’une version papier n’est pas envisageable, s’il veut trouver le temps de lire le contenu et de se lancer dans les cas pratiques.

En somme, ce qui était au départ un simple problème technique de conversion se transforme en une réflexion sur le canal de vente le plus pertinent :

  • vendre une version Kindle remaniée sur Amazon en bénéficiant de la visibilité du distributeur
  • ou une version électronique déjà existante et conforme à l’originale sur notre site Corporate, mais sans pouvoir la mettre en avant sur Amazon…

Cette question n’est à ce jour pas encore tranchée, mais que ceux qui attendent la version électronique se rassurent : elle devrait être disponible en février… et gratuite pour les acquéreurs de la version papier.

En attendant BPMS vous souhaite une excellente année 2018, sous tous ses formats !

read more
Admin BPMS FranceFaire cohabiter édition papier et numérique : Amazon a des progrès à faire