conformité rgpd

Les 4 principaux points à surveiller pour un site internet conforme au RGPD

Les 4 principaux points à surveiller pour un site internet conforme au RGPD

5 décembre 2022

– 6 min de lecture

Louis Allavena

Consultant Transformation Data

Le site internet est une vitrine de l’entreprise, celui qui vous permet de vous présenter à vos
partenaires, candidats, clients, prospects… bref, à tout votre écosystème. Il est donc primordial qu’il
donne confiance quant à la gestion des données de vos visiteurs, et qu’il soit conforme à la
réglementation en vigueur. Un site conforme au RGPD, transparent sur l’utilisation qu’il fait des
données que le visiteur lui fournit, offre une bonne première impression et évite de devoir expliquer
à vos clients que vous n’êtes pas conforme RGPD si la CNIL décide d’auditer votre entreprise.

Le RGPD n’est pas l’unique règle qu’il faille appliquer pour considérer son site internet
comme absolument conforme (règle EPrivacy, régle de régulation des mentions légales, …). Nous
nous sommes principalement focalisés ici sur le RGPD.

Il n’est toutefois pas toujours aisé de démêler concrètement les impacts de la réglementation sur
votre site et de savoir s’il est bien en phase avec celle-ci. Chez Rhapsodies Conseil, nous vous avons
donc préparé une synthèse des quelques points clefs auxquels vous devez vous intéresser.

1. Les cookies

Première action du visiteur sur le site : le bandeau cookie

Un bandeau cookie, doit répondre à 3 obligations indispensables :

Les boutons accepter tous les cookies et refuser tous les cookies sont obligatoires. L’interface ne doit pas avantager un choix plus qu’un autre, les deux boutons doivent, entre autre, avoir la même taille, la même forme et la même couleur.

Le bouton paramètrage n’a pas l’obligation d’être identique aux deux autres, et doit permettre de choisir quel type de cookie j’accepte et quel type de cookie je refuse.

Lors du paramètrage, les opt-in doivent obligatoirement être désactivés par défaut. Accepter tel ou tel type de cookie doit résulter d’une action du visiteur.

Une image contenant table

Description générée automatiquement

Chaque type de cookie (Fonctionnel, Performance, Analytique, …) doit être décrit afin d’éclairer le visiteur dans son choix. Chaque choix doit se faire par finalité, c’est-à-dire que le visiteur peut refuser les cookies de Performance et de Publicité et accepter tous les autres sans que son parcours sur le site ne soit différent.

Une image contenant texte

Description générée automatiquement

Tant que le visiteur n’a pas donné son accord explicite de dépôt de cookies (autre qu’obligatoire), aucun cookie ne doit être déposé.

L’utilisateur doit pouvoir revenir sur son choix dès qu’il le souhaite, il doit donc y avoir un moyen pour le visiteur de revenir sur le paramétrage des cookies afin de refuser/accepter les cookies.

Il arrive souvent que, bien que le bandeau cookie permette de refuser le dépôt de certains cookies, celui-ci ne soit pas totalement fonctionnel. Il est donc primordial de vérifier régulièrement que l’outil de paramétrage est bien opérationnel.

Enfin, il est indispensable de pouvoir conserver la preuve du consentement (article 7 du RGPD).

Le visiteur doit pouvoir accéder à la politique d’utilisation des cookies, rapidement et avant de faire son choix. Un lien vers la politique d’utilisation des cookies doit donc être présent sur le bandeau

Cette Politique des cookies doit comprendre : une description de ce qu’est un cookie, une description de comment supprimer les cookies par navigateur, la finalité et la durée de conservation des cookies, le type de cookies et préciser (dans le cas d’un cookie tiers) le tiers en question et le lien vers sa propre politique de confidentialité ou de cookies. Contrairement aux idées reçues, la liste exhaustive des cookies n’est pas obligatoire.

ATTENTION : les cookies collectent des données personnelles, ils ne peuvent donc pas être transférés vers des pays où la réglementation sur la protection des données personnelles n’est pas conforme au RGPD. Les Etats-Unis, par exemple, ne donnent pas une protection sur les données personnelles suffisante pour que les données y soient envoyées. L’utilisation des Cookies Google Analytics (_ga, _gat, …) n’est donc pas acceptée.

2. Les mentions d’informations et la charte des données personnelles

Les mentions d’informations sont les petits textes se trouvant sous les « points de collecte de données » (Newsletter, point de contact, inscription, …). Afin de pouvoir faciliter la compréhension, j’aime décrire les mentions d’informations comme une « charte des données personnelles spécifique au point de collecte »

Une mention d’information doit notamment contenir certaines informations que sont : 

Une image contenant texte

Description générée automatiquement

Toutes les informations peuvent se trouver dans un texte sous le point de collecte, il est possible de créer une page spécifique à la mention d’information accessible via un lien (cf. exemple ci-dessus). L’important est de respecter le principe de transparence qui implique que les informations soient présentées d’une forme claire. Il est conseillé que cela soit ludique et adapté aux interlocuteurs concernés.

La charte des données personnelles quant à elle est indispensable dès qu’une donnée personnelle est collectée sur le site. Cette charte doit comprendre les informations suivantes :

La charte doit être mise à jour dès qu’un nouveau traitement est créé.

Il est possible que vous n’ayez pas besoin de créer de charte des données personnelles. C’est le cas si les mentions d’informations de tous les points de collecte de votre site internet contiennent des mentions d’informations spécifiques et complètes comprenant les informations obligatoires. Si vous répondez à ce cas de figure, il vous faudra cependant une charte des cookies.

3. CGU, CGV, mentions légales

Les CGU ne sont pas obligatoires mais apportent un cadre d’utilisation du site internet (droits et obligations respectives à l’éditeur et au visiteur). Si votre site internet n’est qu’une vitrine et qu’il ne permet pas la création d’un compte, un achat, le dépôt d’un commentaire, … il n’est pas obligatoire d’avoir des CGU.

Cependant, celles-ci sont indispensables dans les cas contraires. En effet, les CGU peuvent être considérées comme le “règlement intérieur du site”. Elles donnent les droits de l’utilisateur, ses responsabilités et également celles en cas de non-respect.

Les droits de l’utilisateur doivent être précisés, par exemple dans le cas de la création d’un espace personnel. Ces dispositions des conditions générales d’utilisation permettent d’engager la responsabilité de l’utilisateur en cas de dommage résultant du non-respect desdites obligations.

Francenum.gouv.fr

L’utilisateur du site doit accepter explicitement les CGU pour qu’elles puissent être considérées comme légales.

Contrairement aux CGU, les CGV sont obligatoires dès que le site propose un service de paiement, vente, livraison en ligne. Les CGV correspondent à la politique commerciale du site internet (modalité de paiement, délais de livraison, rétractation, …). Elles sont particulièrement utiles en cas de contentieux. Cependant, il n’est pas obligatoire de les avoir disponibles directement sur votre site internet, si vos clients sont professionnels (B2B). Elles le sont si vos clients sont des particuliers (obligation précontractuelle d’information du vendeur). Pour chaque vente, les CGV doivent être acceptées par le particulier (B2C).

Les mentions légales sont les informations permettant d’identifier facilement les responsables du site. Pour une personne physique, il faut inclure : 

Pour une personne morale (une société), il faut inclure : 

Il est aussi impératif de préciser les mentions relatives à la propriété intellectuelle :

En complément de ces informations, il est indispensable d’inclure :

Certaines activités impliquent d’ajouter certaines informations : 

4. Le principe de minimisation

Très souvent, on a tendance à vouloir collecter le plus de données possibles « au cas où », sans finalité précise. Cependant, depuis le RGPD, le principe de minimisation limite cette tendance.

Le principe de minimisation prévoit que les données à caractère personnel doivent être adéquates, pertinentes et limitées à ce qui est nécessaire au regard des finalités pour lesquelles elles sont traitées.

CNIL

Ainsi, il n’est plus possible de collecter des données ne pouvant pas être justifiées par la finalité de traitement. Par exemple, demander le genre de la personne pour une inscription à une Newsletter n’est pas possible, sauf si on le justifie (par ex. le contenu de la Newsletter est différent selon que l’on est un homme ou une femme).



Ces quelques points vous donnent une première approche à avoir pour vérifier que votre site est bien conforme. La revue du site est aussi un bon moyen de faire une passe sur les données collectées et lancer une véritable mise en conformité de vos traitements de données (bases de données, contrats, CRM, …).

Chez Rhapsodies Conseil, nous nous appuyons sur des outils internes et externes qui ont fait leurs preuves et sur l’expertise de consultants expérimentés pour analyser la conformité de vos sites internet.

machine learning

Réconcilier IA et privacy grâce aux données synthétiques

Réconcilier IA et privacy grâce aux données synthétiques

18 mai 2022

– 6 min de lecture

Valentin Defour

Consultant Senior Transformation Data

Dans un récent post de blog, le Gartner prévoit que d’ici 2030, 60% des données d’entrainement des modèles d’apprentissage seront générées artificiellement. Souvent considérées comme substituts de qualité moindre et uniquement utiles dans des contextes réglementaires forts ou en cas de volumétrie réduite ou déséquilibrée des datasets, les données synthétiques ont aujourd’hui un rôle fort à jouer dans les systèmes d’IA.

Nous dresserons donc dans cet article un portrait des données synthétiques, les différents usages gravitant autour de leur utilisation, leur histoire, les méthodologies et technologies de génération ainsi qu’un rapide overview des acteurs du marché.

Les données synthétiques, outil de performance et de confidentialité des modèles de machine learning

Vous avez dit données synthétiques ?

Le travail sur les données d’entrainement lors du développement d’un modèle de Machine Learning est une étape d’amélioration de ses performances parfois négligée, au profit d’un fine-tuning itératif et laborieux des hyperparamètres. Volumétrie trop faible, déséquilibre des classes, échantillons biaisés, sous-représentativité ou encore mauvaise qualité sont tout autant de problématiques à adresser. Cette attention portée aux données comme unique outil d’amélioration des performances a d’ailleurs été mis à l’honneur dans une récente compétition organisée par Andrew Ng, la Data-centric AI competition.

Également, le renforcement des différentes réglementations sur les données personnelles et la prise de conscience des particuliers sur la valeur de leurs données et la nécessité de les protéger imposent aujourd’hui aux entreprises de faire évoluer leurs pratiques analytiques. Fini « l’open bar » et les partages et transferts bruts, il est aujourd’hui indispensable de mettre en place des protections de l’asset données personnelles.

C’est ainsi qu’entre en jeu un outil bien pratique quand il s’agit d’adresser de front ces deux contraintes : les données synthétiques.

Par opposition aux données « traditionnelles » générées par des événements concrets et retranscrivant le fonctionnement de systèmes de la vie réelle, elles sont générées artificiellement par des algorithmes qui ingèrent des données réelles, s’entraînent sur les modèles de comportement, puis produisent des données entièrement artificielles qui conservent les caractéristiques statistiques de l’ensemble de données d’origine.

D’un point de vue utilisabilité data on peut alors adresser des situations où :

Comparaison-donnees-reelles-vs-synthetiques

Mais comme vu précédemment, ces données synthétiques permettent aussi d’adresser certaines problématiques de confidentialité des données personnelles. En raison de leur nature synthétique, elles ne sont pas régies par les mêmes réglementations puisque non représentatives d’individus réels. Les data scientists peuvent donc utiliser en toute confiance ces données synthétiques pour leurs analyses et modélisations, sachant qu’elles se comporteront de la même manière que les données réelles. Cela protège simultanément la confidentialité des clients et atténue les risques (sécuritaires, concurrentiels, …) pour les entreprises qui en tirent parti, tout en levant les barrières de conformité imposées par le RGPD…

Parmi les bénéfices réglementaires de cette pratique :

Un peu d’histoire…

L’idée de mettre en place des techniques de préservation de la confidentialité des données via les données synthétiques date d’une trentaine d’années, période à laquelle le US Census Bureau (organisme de recensement américain) décida de partager plus largement les données collectées dans le cadre de son activité. A l’époque, Donald B. Rubin, professeur de statistiques à Harvard, aide le gouvernement américain à régler des problèmes tels que le sous-dénombrement, en particulier des pauvres, dans un recensement, lorsqu’il a eu une idée, décrite dans un article de 1993 .

« J’ai utilisé le terme ‘données synthétiques’ dans cet article en référence à plusieurs ensembles de données simulées. Chacun semble avoir pu être créé par le même processus qui a créé l’ensemble de données réel, mais aucun des ensembles de données ne révèle de données réelles – cela présente un énorme avantage lors de l’étude d’ensembles de données personnels et confidentiels. »

Les données synthétiques sont nées.

Par la suite, on retrouvera des données synthétiques dans le concours ImageNet de 2012 et, en 2018, elles font l’objet d’un défi d’innovation lancé par le National Institute of Standards and Technology des États-Unis sur la thématique des techniques de confidentialité. En 2019, Deloitte et l’équipe du Forum économique mondial ont publié une étude soulignant le potentiel des technologies améliorant la confidentialité, y compris les données synthétiques, dans l’avenir des services financiers. Depuis, ces données artificielles ont infiltré le monde professionnel et servent aujourd’hui des usages analytiques multiples.

Méthodologies de génération de données synthétiques

Pour un dataset réel donné, on peut distinguer 3 types d’approche quant à la génération et l’utilisation de données synthétiques :

Données entièrement synthétiques – Ces données sont purement synthétiques et ne contiennent rien des données d’origine.

Données partiellement synthétiques – Ces données remplacent uniquement les valeurs de certaines caractéristiques sensibles sélectionnées par les valeurs synthétiques. Les valeurs réelles, dans ce cas, ne sont remplacées que si elles comportent un risque élevé de divulgation. Ceci est fait pour préserver la confidentialité des données nouvellement générées. Il est également possible d’utiliser des données synthétiques pour adresser les valeurs manquantes de certaines lignes pour une colonne donnée, soit par méthode déterministe (exemple : compléter un âge manquant avec la moyenne des âges du dataset) ou statistique (exemple : entraîner un modèle qui déterminerait l’âge de la personne en fonction d’autres données – niveau d’emploi, statut marital, …).

Données synthétiques hybrides – Ces données sont générées à l’aide de données réelles et synthétiques. Pour chaque enregistrement aléatoire de données réelles, un enregistrement proche dans les données synthétiques est choisi, puis les deux sont combinés pour former des données hybrides. Il est prisé pour fournir une bonne préservation de la vie privée avec une grande utilité par rapport aux deux autres, mais avec un inconvénient de plus de mémoire et de temps de traitement.

GAN ?

Certaines des solutions de génération de données synthétiques utilisent des réseaux de neurones dits « GAN » pour « Generative Adversarial Networks » (ou Réseaux Antagonistes Génératifs).

Vous connaissez le jeu du menteur ? Cette technologie combine deux joueurs, les « antagonistes » : un générateur (le menteur) et un discriminant (le « devineur »). Ils interagissent selon la dynamique suivante :

L’objectif final est que le générateur soit capable de produire des données qui semblent si proches des données réelles que le discriminateur ne puisse plus éviter la tromperie.

Pour une lecture plus approfondie sur le sujet des GANs, il en existe une excellente et détaillée dans un article du blog Google Developers.

Un marché dynamique pour les solutions de génération de données synthétiques

Plusieurs approches sont aujourd’hui envisageables, selon que l’on souhaite s’équiper d’une solution dédiée ou bien prendre soi-même en charge la génération de ces jeux de données artificielles.

Parmi les solutions Open Source, on peut citer les quelques librairies Python suivantes :

Mais des éditeurs ont également mis sur le marché des solutions packagées de génération de données artificielles. Aux Etats-Unis, notamment, les éditeurs spécialisés se multiplient. Parmi eux figurent Tonic.ai, Mostly AI, Latice ou encore Gretel.ai, qui affichent de fortes croissances et qui ont toutes récemment bouclé d’importantes levées de fond

Un outil puissant, mais…

Même si l’on doit être optimiste et confiant quant à l’avenir des données synthétiques pour, entre autres, les projets de Machine Learning, il existe quelques limites, techniques ou business, à cette technologie.

De nombreux utilisateurs peuvent ne pas accepter que des données synthétiques, « artificielles », non issues du monde réel, … soient valides et permettent des applications analytiques pertinentes. Il convient alors de mener des initiatives de sensibilisation auprès des parties prenantes business afin de les rassurer sur les avantages à utiliser de telles données et d’instaurer une confiance en la pertinence de l’usage. Pour asseoir cette confiance :

Aussi, si les données synthétiques permettent d’adresser des problématiques de confidentialité, elles ne protègent naturellement pas des biais présents dans les jeux de données initiaux et ils seront statistiquement répliqués si une attention n’y est pas portée. Elles sont cependant un outil puissant pour les réduire, en permettant par exemple de « peupler » d’observations synthétiques des classes sous-représentées dans un jeu de données déséquilibré. Un moteur de classification des CV des candidats développé chez Amazon est un exemple de modèle comportant un biais sexiste du fait de la sous représentativité des individus de sexe féminin dans le dataset d’apprentissage. Il aurait pu être corrigé via l’injection de données synthétiques représentant des CV féminins.

On conclura sur un triptyque synthétique imageant bien la puissance des sus-cités réseaux GAN, utilisés dans ce cas là pour générer des visages humains synthétiques, d’un réalisme frappant.

(source : ThisPersonDoesNotExist.com)

Il est à noter que c’est également cette technologie qui est à l’origine des deepfakes, vidéos mettant en scène des personnalités publiques ou politiques tenant des propos qu’ils n’ont en réalité jamais déclarés (un exemple récent est celui de Volodymyr Zelensky, président Ukrainien, victime d’un deepfake diffusé sur une chaine de télévision d’information).

sobriete-numerique-sobriete

Data sobriety : plus de qualité, moins de quantité

Data sobriety : plus de qualité, moins de quantité

13 octobre 2021

Jean-Baptiste Piccirillo

Manager Transformation Data

Nous entrons dans une ère où les actifs de l’organisation doivent être mis au service de l’essentiel. Il est temps de dire au revoir au data lake « fourre tout », et d’assurer la maîtrise des données essentielles pour la stratégie et la raison d’être de l’organisation. La gouvernance des données devra être pragmatique pour assurer que les investissements (stockages, traitements, compétences data, …) sont mis au service de ce qui compte vraiment.


Le rôle du Chief Data Officer de 2021 est de réguler/minimiser au maximum les comportements automatisés ou humains qui génèrent toujours plus de volume, mais… pas toujours plus de valeur. Ces comportements prennent parfois la forme de boucles de rétroactions positives, non régulées. Il est temps de trouver le bon niveau de régulation pour limiter ces proliférations, vers plus de sobriété. Ce sera un bien pour votre portefeuille et pour l’environnement.

regulation volume donnees
Une donnée… fait des petits

Voici un exemple de rétroaction :

Une donnée fait des petits (copies, données transformées pour des usages spécifiques, parfois ponctuels, ,..). Plus les volumes de données stockées sont importantes dans votre organisation et plus l’augmentation de ces mêmes volumes demain aura tendance à être grande. Duplication des données, copier coller à droite à gauche… Sans une gouvernance aboutie des données en guise de régulation : plus il y a de données… plus il y aura de données, sans même que vous l’ayez demandé ou voulu ! Au même titre que plus il y a de gens sur cette planète, plus il y aura de naissances…

Quelles régulations ?

Faire le tri dans vos données existantes, c’est comme faire le tri dans votre appartement après une grosse dépression : C’est le « bordel ». Vous devez ranger. Vous commencez par enlever tout ce qui n’a clairement rien à faire là et qui n’est pas utile (les déchets, les vieux papiers sans utilité, …), vous remplissez quelques poubelles sans trop d’état d’âme. Puis vient l’étape plus minutieuse, où vous prenez le temps par catégorie. Vous vous posez vraiment la question : « Dans ce qui reste, de quoi puis-je me passer ? ». Alors vous triez en paquets « je garde, je ne peux pas m’en passer », « ça peut, peut être, servir », « je suis décidé, je m’en débarrasse ».

Pour les données c’est pareil. Il y a toujours des petits malins pour dire : « Gardons l’historique, après tout, ça peut peut être servir un jour, c’est le principe du data lake non ? » Non, parce qu’une donnée stockée a un coût environnemental et financier, si on ne sait pas dire simplement pourquoi elle est là, alors elle n’a pas à être là. Fin de la partie. « Delete »… Dans l’ère du « Big Data », ce réflexe n’est pas naturel (c’est le moins qu’on puisse dire) et pourtant il est précieux, et vous évitera bien des problèmes, plus qu’il ne vous fera manquer d’opportunités…

L’ajout d’une nouvelle donnée doit être justifiée « by design ». Une application sera conçue en appliquant le principe de « Data Minimization », pas seulement pour les données personnelles mais pour toutes les données. Si la valeur de la donnée n’est pas avérée, alors on ne demande pas à l’utilisateur de la saisir. L’UX n’en sera que plus épurée, et ça fera un problème de moins à gérer, et un bienfait pour la charge mentale de vos utilisateurs, clients, collaborateurs.

La gouvernance des données doit intégrer dans son ADN ce principe simple et parfois oublié : une donnée qui n’a pas d’usages clairement qualifiés n’a rien à faire dans les bases de données de votre organisation.

Et malheureusement, l’augmentation des volumes peut générer rapidement des pertes de qualité

Parce que plus il y a d’objets et de meubles dans votre appartement, plus il faut prendre du temps pour nettoyer…Il faut bouger les meubles pour nettoyer derrière, soulever les objets pour nettoyer en dessous… Vous n’y échapperez pas, pour les données c’est pareil. La gouvernance des données doit assurer le coup de chiffon qui va bien au bon moment pour limiter les risques de non qualité ou de sécurité, et réduire l’empreinte carbone du système d’information.

Voilà un challenge que le Chief Data Officer devrait s’approprier davantage à l’échelle de son organisation. Maîtriser les volumes et la prolifération des données, pour être capable de maintenir un niveau de qualité acceptable, et documenté : Un utilisateur ou un projet doit être alors capable en toute autonomie de décider si le niveau de qualité de l’information est suffisant pour l’usage qu’il veut en faire, et, si son usage le justifie, qualifier des exigences de qualité supérieur à ce qu’il a aujourd’hui (fraicheur, complétude, ..) avec les équipes en charge des données.

C’est également la juste contribution du CDO dans les prochaines années à la maîtrise de l’empreinte carbone du numérique, en régulant la masse de ses actifs data plus sérieusement qu’il ne le fait aujourd’hui.

Moins de volume ET plus de valeur : Vous relevez le défi ?

cdo-en-2021

Retour sur le rôle de Chief Data Officer en 2021

Retour sur le rôle de Chief Data Officer en 2021

21 juin 2021

– 4 min de lecture

Maureen Delaloi

Manager Transformation Data

« La data actif essentiel et incontestable de nombreuses organisations ».

Il suffit de poursuivre cette phrase en citant 2 ou 3 chiffres clefs de grands cabinets de conseil en stratégie, et voilà l’argument d’autorité posé… Oui mais quand on a dit ça, hé bien, qu’est-ce qu’on en fait ?

« La data » est en effet transverse aux entités d’une organisation, source d’opportunités commerciales, d’innovation ou de relation client de qualité, mais elle est bien souvent jugée comme un sujet technique ou abstrait. Le rôle de CDO est encore récent dans de nombreuses organisations : il lui faut trouver sa place et la meilleure articulation avec les Métiers, la DSI, mais aussi la Direction Générale. Il y a donc un enjeu à ce que ce dernier asseye son rôle stratégique dans toute organisation qui veut gérer ses données comme des actifs stratégiques. Le Chief Data Officer a un rôle clef, transverse et à de multiples facettes pour exploiter pleinement le potentiel que représentent les données : compétences humaines, techniques et de leadership. Il doit incarner la transformation vers un mode d’organisation orienté données.

Constructeur de fondations stables

Partons du plus évident (mais pas forcément du plus simple !). Pour toute construction il faut des fondations stables, hé bien avec la data c’est pareil. Des « datas », objets parfois suspects et mal identifiés, sont stockées un peu partout dans les bases de données des entreprises, des Sharepoint collaboratifs ou des fichiers Excel sur le disque dur des collaborateurs… La clef sera dans un premier temps de maîtriser et de sécuriser ces données. Le CDO doit impulser cette dynamique, s’assurer que les données soient connues (recensement dans un data catalog par exemple), accessibles (stockage efficient ), de qualité (règle de gouvernance des données avec des data owners), conformes aux réglementations et à l’éthique (RGPD ou autre) et répondent à des cas d’usages simples et concrets (avant de vouloir faire de l’IA ne faut-il pas que les reporting opérationnels les plus basiques et indispensables soient bien accessibles par les bonnes personnes au bon moment et avec le bon niveau de qualité ?).

Le CDO : architecte et chef d’orchestre

Le Chief Data Officer doit être l’architecte (rôle opérationnel) et le chef d’orchestre (rôle stratégique) de ces projets de fondations en concertation avec les métiers et l’IT. Avec son équipe, il doit accompagner les métiers pour répondre aux usages à valeur et avancer de façon pragmatique. Rien ne sert de lancer 12 projets stratégiques sur la data en même temps : apporter des preuves concrètes en traitant de façon pertinente 2 ou 3 cas d’usages clefs pour améliorer les enjeux opérationnels et vous pouvez être certain que la dynamique métier autour de votre transformation data sera bien mieux lancée ! Il en est de même pour l’IT : il doit aussi soigner sa relation avec la DSI avec laquelle il doit travailler sur des solutions concrètes nécessaires à la mise en œuvre de sa vision data et des usages métiers. 

Le Chief Data Officer doit être fédérateur

Le CDO n’a pas nécessairement pour vocation à prendre en charge lui-même l’ensemble des sujets qui traitent de la donnée. Les métiers doivent être des acteurs de première ligne sur le sujet. Le CDO s’intègre régulièrement à un existant désordonné, où les sujets sont déjà plus ou moins traités, mais de façon dispersée. Il doit apporter la vision transverse tout en laissant de l’autonomie aux métiers. Dans la mesure où les équipes data se sont constituées et professionnalisées dans les grands groupes, l’enjeu se déplace aujourd’hui vers la capacité à faire travailler ensemble tous les départements de l’organisation. L’acculturation de l’entreprise et la formation des équipes sont au cœur des enjeux du CDO en 2021.

En résumé : le Chief Data Officer doit faire preuve de savoir-faire mais aussi de savoir-être. Il doit incarner la vision, adosser son action au sponsorship inconditionnel de la Direction Générale, tout en restant au contact des équipes métier et en travaillant avec bonne intelligence avec les équipes IT.

Chiefs Data Officers, si vous n’aviez qu’une idée à retenir de cet article : pour en tirer sa valeur, la data doit pouvoir être expliquée et comprise par ma grand-mère (et je précise que ma grand-mère n’est pas data scientist !) ; visez le pragmatisme et les sujets à valeur immédiate pour votre organisation. Cela fondera le socle indispensable de votre transformation data dans la durée : expériences, résultats concrets et crédibilité ! 

Les idées exposées ici sont peut-être évidentes pour certains, utiles pour d’autres ! En tout cas, chez Rhapsodies Conseil, au sein de notre équipe Transformation Data, nous essayons d’appliquer cela systématiquement, et nous pensons que c’est le minimum vital.

explicabilite-machine-learning

Interprétez simplement vos modèles de Machine Learning

Interprétez simplement vos modèles de Machine Learning

17 juin 2021

– 8 min de lecture

Valentin Defour

Consultant Senior Transformation Data

A l’heure de l’omniprésence algorithmique dans une multitude de domaines de notre société, une commission européenne dédiée publiait, il y a un an déjà, un livre blanc mettant en lumière le concept d’IA de confiance. Si ce concept englobe une multitude de notions et d’axes de réflexion (prise en compte des biais, robustesse des algorithmes, respect de la privacy, …), nous nous intéresserons ici particulièrement à la transparence et l’explicabilité des systèmes d’IA. Dans cette optique et après un rappel des enjeux et challenges de l’explication des modèles, nous construirons un simple tableau de bord rassemblant les principales métriques d’explicabilité d’un modèle, à l’aide d’une librairie Python spécialisée : Explainer-Dashboard.

Vous avez dit “explicabilité” ?

L’IA Explicable est l’intelligence artificielle dans laquelle les résultats de la solution peuvent être compris par les humains. Cela contraste avec le concept de «boîte noire» où parfois même les concepteurs du modèle ne peuvent pas expliquer pourquoi il est arrivé à une prédiction spécifique.

Le besoin d’explicabilité de ces algorithmes peut être motivé par différents facteurs :

Quand on adresse cette problématique, il convient de définir les différents termes (étroitement liés) que l’on peut retrouver :

Si l’on considère des travaux de chimie au lycée, une interprétabilité de cette expérience serait “on constate un précipité rouge”. De son côté, l’explicabilité de l’expérience nécessitera de plonger dans les formules des différents composants chimiques.

Note : dans un souci de simplification, nous utiliserons largement le terme “explicabilité” dans la suite de cet article.

Via l’explication d’un modèle, nous allons chercher à répondre à des questions telles que :

Quelles sont les causes d’une décision ou prédiction donnée ?

Quelle est l’incertitude inhérente au modèle ?

Quelles informations supplémentaires sont disponibles pour la prise de décision finale ?

Les objectifs de ces explications sont multiples, car dépendants des parties prenantes :

Et concrètement ?

Le caractère “explicable” d’une IA donnée va principalement dépendre de la méthode d’apprentissage associée. Les méthodes d’apprentissage sont structurées en deux groupes conduisant, selon leur type, à un modèle explicite ou à une boîte noire :

Dans le cas d’un modèle explicite (linéaire, gaussien, binomial, arbres de décision,…), la décision qui en découle est nativement explicable. Sa complexité (principalement son nombre de paramètres) peut toutefois endommager son explicabilité ;

La plupart des autres méthodes et algorithmes d’apprentissage (réseaux neuronaux, agrégation de modèles, KNN, SVM,…) sont considérés comme des boîtes noires avec néanmoins la possibilité de construire des indicateurs d’importance des variables.

Lors du choix d’un modèle de Machine Learning, on parle alors du compromis Performance / Explicabilité.

Récupérer les données et entraîner un modèle simple

Pour cette démonstration, notre cas d’usage analytique sera de prédire, pour un individu donné, le risque d’occurrence d’une défaillance cardiaque en fonction de données de santé, genre, âge, vie professionnelle, …

Si cette problématique ne revêt pas spécifiquement d’aspect éthique relatif à la transparence de l’algorithme utilisé, nous pouvons toutefois bien percevoir l’utilité de l’explicabilité d’un diagnostic de risque assisté par IA : collaboration facilitée avec l’expert métier (en l’occurrence, le médecin) et information plus concrète du patient, entre autres bénéfices.

Le jeu de données éducatif utilisé est fourni par l’OMS et peut être téléchargé sur la plateforme de data science Kaggle :

Il contient les données de 5110 personnes, réparties comme suit :

Données :

  • Age du sujet ;
  • Genre du sujet ;
  • A déjà souffert d’hypertension (oui / non)
  • A déjà souffert de maladies cardiaques (oui / non)
  • Statut marital
  • Type d’emploi
  • Type de résidence (citadin, rural)
  • Niveau moyen sanguin de glucose
  • IMC
  • Fumeur (oui / non)

Note : nous avons procédé à une simple préparation des données qu’il est possible de retrouver dans le notebook complet en bas de page.

Pour la partie modélisation, nous utiliserons un modèle « baseline » de Random Forest. Pour éviter que notre modèle ne reflète seulement que la distribution des classes (très déséquilibrée dans notre cas, 95-5), nous avons ajouté des données “synthétiques” à la classe la moins représentée (i.e. les patients victimes de crises cardiaques) en utilisant l’algorithme SMOTE, pour atteindre une répartition équilibrée (50-50) :

Notre modèle est prêt, nous pouvons à présent l’utiliser en input du dashboard !

Création du dashboard

Nous avons donc à disposition un modèle entraîné sur notre dataset et allons à présent construire notre tableau de bord d’interprétation de ce modèle.

Pour ce faire, nous utilisons la librairie explainer-dashboard, qui s’installe directement via le package installer pip :


pip install --upgrade explainerdashboard

Une fois la librairie installée, nous pouvons l’importer et créer simplement une instance “Explainer” à l’aide des lignes suivantes :


from explainerdashboard import ClassifierExplainer, ExplainerDashboard

explainer = ClassifierExplainer(RF, X_test, y_test)

db = ExplainerDashboard(explainer,
                       n_jobs = -1,
                        title="Heart Stroke Prediction Explainer"
                       )

db.run(port=8050)

Plusieurs modes d’exécution sont possibles (directement dans le notebook, dans un onglet séparé hébergé sur une IP locale, …) (plus d’informations sur les différents paramètres de la librairie dans sa documentation).

Note : le dashboard nécessitera d’avoir installé la librairie de visualisation “Dash” pour fonctionner.

Interprétation des différents indicateurs

Le tableau de bord se présente sous la forme de différents onglets, qu’il est possible d’afficher / masquer via son paramétrage :

Plongeons à présent dans les détails de chacun de ces onglets !

Features Importance

A l’instar de l’attribut feature_importances_ de notre modèle de Random Forest, cet onglet nous permet de visualiser, pour chaque colonne de notre dataset, le pouvoir de prédiction de chaque variable.

L’importance des features a ici été calculée selon la méthode des valeurs de SHAP (acronyme de SHapley Additive exPlanations). Nous n’approfondirons pas ce concept dans cet article (voir rubrique “aller plus loin”).

Ces scores d’importance peuvent permettre de :

Dans l’exemple ci-dessous, on peut constater que :

Classification Stats

Cet onglet nous permet de visualiser les différentes métriques de performance de notre modèle de classification : matrice de confusion, listing des différents scores, courbes AUC, … Il sera utile en phase de paramétrage / optimisation du modèle pour avoir un aperçu rapide et complet de sa performance :

Individual Predictions

Cet onglet va nous permettre, pour un individu donné, de visualiser les 2 indicateurs principaux relatifs à la décision prise par le modèle :

Le graphe des contributions : 

La contribution d’un feature à une prédiction représente l’impact probabilistique sur la décision finale de la valeur de la donnée considérée.

Suite à notre traitement du déséquilibre des classes, nous avons autant de sujets “sains” que de sujets “à risque” dans notre jeu de données d’apprentissage. Un estimateur aléatoire aura donc 50% de chances de trouver la bonne prédiction. Cette probabilité est donc la valeur “baseline” d’entrée dans notre graphe des contributions.

Ensuite, viennent s’ajouter en vert sur le visuel les contributions des features pour lesquelles la valeur a fait pencher la décision vers un sujet “à risque”. Ces features et leur contribution amènent la décision à une probabilité de ~60% de risque.

Puis, les features dont la contribution fait pencher la décision vers un sujet “sain” viennent s’ajouter (en rouge sur le graphe). On retrouve ici nos prédicteurs forts tels que l’âge ou encore l’IMC.

On a donc :

décision finale = 50% + probabilité(sain) + probabilité(à risque) = 5.08%

> Le sujet est proposé comme sain par l’algorithme

Le graphe des dépendances partielles :

Ce visuel nous permet de visualiser la probabilité de risque en fonction de la variation d’une des features, en conservant la valeur des autres constantes. Dans l’exemple ci-dessus, on peut voir que pour l’individu considéré, augmenter son âge aura pour effet d’augmenter sa probabilité d’être détecté comme “à risque”, ce qui correspond bien au sens commun.

What if Analysis

Dans l’optique de l’onglet précédent, l’analyse “what if” nous permet de renseigner nous mêmes les valeurs des différents features et de calculer l’output du modèle pour le profil de patient renseigné :

Il reprend par ailleurs les différents indicateurs présentés dans l’onglet précédent : graphe des contributions, dépendances partielles, …

Features Dependance

Cet onglet présente un graphe intéressant : la dépendance des features.

Il nous renseigne sur la relation entre les valeurs de features et les valeurs de SHAP. Il permet ainsi d’étudier la relation générale entre la valeur des features et l’impact sur la prédiction.

Dans notre exemple ci-dessus, le nuage de points nous apprend deux choses :

Decision Trees

Enfin, dans le cas où l’input du dashboard est un modèle à base d’arbres de décisions (gradient boosted trees, random forest, …), cet onglet sera utile pour visualiser le cheminement des décisions de la totalité des arbres du modèle.

Dans l’exemple ci-dessous, nous considérons le 2712ème individu du jeu de données pour lequel 50 arbres ont été calculés via l’algorithme de Random Forest. Nous visualisons la matrice de décision de l’arbre n°13 :

Ce tableau nous montre le cheminement de la décision, depuis une probabilité de ~50% (qui serait la prédiction d’un estimateur ne se basant que sur la moyenne observée sur le jeu de données). On peut constater que, pour cet individu et pour l’arbre de décision considéré :

L’onglet nous propose également une fonctionnalité de visualisation des arbres via la librairie graphviz.

L’étude des différents indicateurs présentés dans les onglets du dashboard nous a permis :

L’étude de ces indicateurs doit être partie intégrante de tout projet d’IA actuel et futur

L’explicabilité des modèles de Machine Learning, aujourd’hui considéré comme l’un des piliers d’une IA éthique, responsable et de confiance, représente un challenge important pour accroître la confiance de la société envers les algorithmes et la transparence de leurs décisions, mais également la conformité réglementaire des traitements en résultant.

Dans notre cas d’étude, si la librairie explainer-dashboard est à l’initiative d’un particulier, on remarque une propension à l’éclosion de plusieurs frameworks et outils servant le mouvement “Fair AI”, dont plusieurs développés par des mastodontes du domaine. On peut citer le projet AIF360 lancé par IBM, une boîte à outils d’identification et de traitement des biais dans les jeux de données et algorithmes.

Cette librairie est utile en phase de développement et d’échanges avec le métier mais peut toutefois ne pas suffire en industrialisation. Alors un dashboard “maison” sera nécessaire. Elle a toutefois un potentiel élevé de personnalisation qui lui permettra de répondre à de nombreux usages.

Note : l’intégralité du notebook utilisé est disponible sur ce lien.



Pour aller plus loin :

principes-data-science-passer-du-metier-a-ux

La data science, du besoin métier à l’UX : 4 principes clés

La data science, du besoin métier à l’UX : 4 principes clés

8 juin 2021

– 6 min de lecture

Jean-Baptiste Piccirillo

Manager Transformation Data

La data science est devenue un levier clé aujourd’hui, pour mettre les données au service de bénéfices et de problématiques métiers : Automatisation de tâches & de choix, Fourniture de nouveaux services « intelligents », Amélioration de l’expérience client, Recommandations, etc.

C’est aussi une discipline qui passionne par son caractère particulièrement « innovant », encore aujourd’hui, mais qui génère des croyances sur ce qu’elle peut réellement apporter à une organisation. Certains dirigeants ont souvent donné trop de valeur intrinsèque à la discipline, s’attendant à des retours importants sur leurs investissements (data lake & armées de data scientist / engineers). 

En réalité, la Data Science n’est qu’une technique qui a besoin de méthodologie et de discipline. A ce titre, elle nécessite au préalable de très bien définir les problèmes métiers à résoudre. Et quand bien même le problème est bien défini, et le modèle statistique pour y répondre performant, cela ne suffit pas encore. Le modèle doit être utilisable « en pratique » dans les processus métiers opérationnels, s’intégrer parfaitement dans l’expérience utilisateur, etc.


Quels principes clés peut-on se proposer d’appliquer pour maximiser la valeur de cette capacité ? Essayons ici de donner quelques pistes. 

Comprendre le métier : analyser les risques, les besoins d’optimisation, les nouvelles opportunités

L’identification d’usages métier, qui nécessitent des méthodes d’analyse de données avancées, est une étape clé. Ces usages ne tombent souvent pas du ciel. Une démarche proactive avec les métiers est nécessaire pour les identifier. C’est d’autant plus vrai lorsque le métier est encore peu familiarisé avec les techniques de data science, et ce qu’il est possible d’en tirer concrètement. 

C’est un travail de “business analysis”, dont la Data Science n’a absolument pas le luxe de se passer contrairement à ce qui est pratiqué parfois : Comment travaille le métier aujourd’hui ? Quels sont ses enjeux, ses drivers, ses axes d’innovation, ses axes d’optimisations des processus opérationnels en place, et quelles données sont manipulées aujourd’hui, comment et pour quoi faire ? Quel est le niveau de qualité de la donnée, manque-t-il des informations clés pour répondre aux problèmes quotidiens, ou pour innover ? etc. 

Quand on est au clair sur toutes ces questions, on est prêt à identifier des usages concrets avec le métier, qui pourraient bénéficier de techniques d’analyse avancée.

Comprendre l’usage et le système concerné : adopter le point de vue systémique !

Imaginons que nous cherchons à prédire le flux de patients sur un jour donné dans un hôpital, afin d’adapter les ressources, les processus, les dispositifs pour limiter le temps d’attente. Il convient, avant de foncer tête baissée dans l’analyse des données, de comprendre l’ensemble de la problématique. Par exemple, les approches de « system thinking » peuvent être tout à fait adaptées pour que le data scientist s’assure de ne pas oublier de paramètres clés dans la dynamique du problème qu’il veut résoudre. Ainsi, il n’oubliera pas non plus des données clés pour son modèle (existantes ou dont il faudrait organiser la collecte à l’avenir pour améliorer le modèle).

Causal loop diagram


Ce type de représentation (ici : Causal loop diagram), peut permettre au métier de s’exprimer sur le processus, sur l’identification des variables clés, et de formuler ses intuitions sur les paramètres et les dynamiques en jeu qui peuvent influer sur la variable à prédire ! (ici les influences positives ou négatives entre les variables structurantes décrivant la dynamique du système). 

Le diagramme ci-dessus n’est qu’un exemple de représentation systémique, on peut adopter d’autres types de représentation du système au besoin. L’important étant d’étendre la compréhension du système, qui peut nous amener à identifier des variables cachées (non intuitives a priori).

Concrétiser un usage : prototyper au plus tôt avec le métier, dans son environnement de travail, au risque de rester éternellement au statut de POC !

Une fois que le système est bien défini, et que les hypothèses et intuitions sont posées, il faut comprendre : comment le modèle analytique sera concrétisé en pratique, qui sera l’utilisateur final, quel est son environnement de travail actuel et comment on pourra intégrer les résultats d’un modèle statistique dans son travail quotidien. 

Une technique simple et confortable pour le métier : faire un prototype rapide, même avec des fausses données pour commencer, des faux résultats de modèles statistiques. Bref, l’idée est rapidement de se projeter dans l’usage final de la manière la plus concrète possible, pour aider le métier à s’inscrire dans sa future expérience. Évidemment, nous ne resterons pas éternellement avec des fausses données.

L’objectif est d’être tout à fait au clair, dès le départ, sur le produit fini que l’on veut atteindre, et de s’assurer que le métier le soit tout à fait (ce qui est loin d’être toujours le cas). Ensuite, nous pourrons pousser le prototype plus loin (des vrais données, des vraies conditions pour évaluer la performance, etc.).

Cette méthode permet au data scientist de se mettre à la place de l’utilisateur final, et de mieux comprendre comment son modèle devra aider (est-ce qu’il doit apporter juste une classification, un niveau de probabilité, des informations contextuelles sur la décision prise par le modèle, est-ce qu’il doit favoriser le temps de réponse, l’explicabilité, la performance du modèle, etc.). Toutes ces questions trouvent rapidement une réponse quand on se projette dans le contexte d’usage final.

Interagir par itération avec le business, éviter l’effet Kaggle

Nous pouvons rencontrer parfois un comportement (compréhensible), qui est de vouloir faire le modèle le plus performant possible, à tout prix. On passe des heures et des jours en feature engineering, tuning du modèle, on tente toutes combinaisons possibles, on ajoute / teste des données exotiques (au cas où) qui ne sont pourtant pas identifiées en phase de “business analysis”. Je l’appellerai l’effet « Data Challenge » ou l’effet « KAGGLE*». 

Et après avoir passé des jours enfermés dans sa grotte, on arrive tout fier devant le métier en annonçant une augmentation de 1% du score de performance du modèle, sans même avoir songé que 1% de moins pourrait tout à fait répondre aux exigences du métier…
Comme on dit… « Le mieux est l’ennemi du bien ». Pour éviter cet effet tunnel qui peut être tentant pour l’analyste (qui veut annoncer le meilleur score à tout prix ou qui joue trop sur Kaggle*), des itérations les plus fréquentes possibles avec le métier sont clés. 

Arrêtons-nous au bon moment ! Et cela vaut pour toutes les phases du projet. Commençons par chiffrer le système décrit en phase de business analyse, avec des données réelles, et itérons avec le métier sur cette base. Cela permet d’améliorer déjà la compréhension du problème du data scientist, et du métier concerné. Et cela a déjà une vraie valeur pour le métier ! Alors qu’aucun modèle statistique n’a été conçu pour le moment. 

Si un modèle nécessite des données inexistantes, organisons la collecte de ces données avec le Chief data officer, dans le temps. Mais ne nous battons pas à vouloir faire un modèle avec des miettes, si nous savons que cela ne permettra pas d’être à la hauteur des attentes opérationnelles. 

Le Data Scientist peut avoir aussi ce réflexe un peu étrange de dire « On va essayer, on va faire avec ce qu’on a et on verra ! » comme s’il croyait lui-même que son métier relève de l’incantation. 

Evidemment, je ne fais là aucune généralité. Le rôle d’expert nous oblige à prendre nos responsabilités, et à dire « Non, après examen et quelques tests, je ne suis pas confiant du tout pour répondre à votre besoin avec les données qu’on a aujourd’hui ». Humilité, responsabilité et transparence, à chaque itération avec le métier, sont de mise.

On trouve souvent ce risque de dérive dans la relation Expert vs Métier. Ne tombons pas dans le piège de jouer sur l’ignorance de l’autre pour se créer un travail inutile ! 

Ces quelques principes sont peut-être évidents pour certains, utiles pour d’autres ! En tous les cas, chez Rhapsodies Conseil, au sein de notre équipe Transformation Data, nous essayons d’appliquer cela systématiquement, et nous pensons que c’est le minimum vital. 

Pour nous, traiter un usage BI & Analytics, c’est le traiter dans son ensemble, de manière systémique ! Notre solution finale n’est pas un modèle statistique. Notre solution finale est potentiellement un modèle statistique, mais aussi une gouvernance adaptée pour avoir la qualité de données nécessaire, un modèle qui s’adapte à l’expérience utilisateur souhaitée (et pas l’inverse), et un suivi du ROI de l’usage analytique et de sa pertinence par rapport à la stratégie de l’entreprise.