Skip to content

Latest commit

 

History

History
1125 lines (779 loc) · 93.8 KB

referentiel_evaluation.md

File metadata and controls

1125 lines (779 loc) · 93.8 KB
Raw

Data science responsable et de confiance - Référentiel d'évaluation

Le référentiel d'évaluation ci-dessous est le fruit du travail participatif initié au printemps 2019 par Labelia Labs (ex- Substra Foundation) et en cours depuis. Il procède de l'identification des risques que l'on cherche à prévenir en visant une pratique responsable et de confiance de la data science, et des bonnes pratiques qui permettent d'y faire face. Il regroupe également pour chaque sujet des ressources techniques qui peuvent être de bons points d'entrée pour les organisations intéressées.

Dernière mise à jour : 1er semestre 2021.

Référentiel d'évaluation de la maturité d'une organisation

L'évaluation est composée des 6 sections suivantes :

Section 1 - Protéger les données à caractère personnel ou confidentielles

[Protection des données]

L'utilisation de données à caractère personnel ou confidentielles fait porter le risque d'exposition de celles-ci, ce qui peut avoir des conséquences très préjudiciables pour les producteurs, gestionnaires, ou sujets de ces données. En particulier dans les projets de data science, elles doivent donc être protégées et les risques qu'elles fuitent ou soient exposées doivent être minimisés.

[⇧ retour à la liste des sections]
[⇩ prochaine section]

Q1.1 : Législation et exigences contractuelles applicables - Identification
En ce qui concerne les données à caractère personnel ou confidentielles, les exigences légales, statutaires, réglementaires et contractuelles en vigueur et concernant votre organisation sont :

R1.1 :
(Type : réponse unique)
(Sélectionner une seule réponse, correspondant le mieux au niveau de maturité de l'organisation sur ce sujet)

  • 1.1.a Pas encore identifiées
  • 1.1.b Partiellement identifiées ou en cours d'identification
  • 1.1.c Identifiées
  • 1.1.d Identifiées et maîtrisées par les collaborateurs
  • 1.1.e Identifiées, documentées et maîtrisées par les collaborateurs
Expl1.1 :

Il est crucial de mettre en place des processus pour connaître et suivre l'évolution des réglementations applicables (très spécifiques dans certains domaines, par exemple dans le secteur bancaire), ainsi que pour documenter les approches et choix retenus pour être en conformité à chaque projet de data science. Exemple(s) intéressant(s) : Welfare surveillance system violates human rights, Dutch court rules.

Ressources1.1 :

Q1.2 : Législation et exigences contractuelles applicables - Approche de mise en conformité
Pour satisfaire à ces exigences, l’approche adoptée par votre organisation est :

R1.2 :
(Type : réponse unique)
(Sélectionner une seule réponse, correspondant le mieux au niveau de maturité de l'organisation sur ce sujet)

  • 1.2.a Informelle, basée sur la responsabilité et la compétence de chacun
  • 1.2.b Formalisée et accessible à tous les collaborateurs
  • 1.2.c Formalisée et maîtrisée par les collaborateurs
  • 1.2.d Formalisée, maîtrisée par les collaborateurs, documentée pour chaque traitement de données personnelles ou confidentielles
Expl1.2 :

Il s'agit de s'interroger sur la gestion des données personnelles ou confidentielles (stockage, accès, transfert, protection, responsabilités...), et de documenter les choix effectués.

Q1.3 : Veille réglementaire
Un processus de veille réglementaire est-il mis en place, en interne ou via un prestataire spécialisé, pour connaître les évolutions applicables et impactantes pour votre organisation ?

R1.3 :
(Type : réponse unique)
(Sélectionner une seule réponse, correspondant le mieux au niveau de maturité de l'organisation sur ce sujet)

  • 1.3.a Nous ne faisons pas vraiment de veille réglementaire
  • 1.3.b Nous faisons une veille informelle, chaque collaborateur remonte les informations sur un moyen de communication dédiée
  • 1.3.c Nous avons une veille formalisée, les responsables sont identifiés, le processus est documenté
Expl1.3 :

Au-delà de l'identification des réglementations et des approches de mise en conformité, il est important de mettre en place des processus de veille pour connaître et suivre l'évolution des réglementations applicables (qui peuvent être très spécifiques dans certains secteurs). Exemple(s) intéressant(s) : Welfare surveillance system violates human rights, Dutch court rules.

Q1.4 : Législation et exigences contractuelles applicables - Audit et certification
La conformité de l'organisation aux exigences relatives aux données personnelles et confidentielles a-t-elle été auditée et est-elle reconnue par une certification, un label ou équivalent ?

R1.4 :
(Type : réponse unique)
(Sélectionner une seule réponse, correspondant le mieux au niveau de maturité de l'organisation sur ce sujet)

  • 1.4.a Oui
  • 1.4.b Non
  • 1.4.c Pas encore, nous préparons actuellement l'audit ou la certification de la conformité de notre organisation aux exigences relatives aux données personnelles et confidentielles
  • 1.4.d Pas au niveau de l'organisation, mais c'est en revanche le cas pour un projet au moins
Expl1.4 :

Dans de nombreux secteurs il existe des exigences de conformité spécifiques. Il est généralement possible de formaliser la conformité d'une organisation par une certification, un audit spécialisé ou l'obtention d'un label.

Q1.5 : Principe de minimisation
Dans le cadre des projets de data science, le principe de minimisation doit guider la collecte et l'utilisation de données personnelles ou confidentielles. Comment est-il mis en oeuvre au sein de votre organisation ?

R1.5 :
(Type : réponse unique)
(Sélectionner une seule réponse, correspondant le mieux au niveau de maturité de l'organisation sur ce sujet)
(Domaine de risque spécifique : utilisation de données personnelles ou confidentielles)

  • 1.5.a Nous faisons en sorte de n'utiliser aucune données personnelles ou confidentielles. Nous ne sommes pas concernés par cet univers de risque
  • 1.5.b Nous avons besoin d'en utiliser dans certains projets et le principe de minimisation est alors systématiquement appliqué
  • 1.5.c Le principe de minimisation est connu des collaborateurs, qui l'appliquent en général
  • 1.5.d Le réflexe "qui peut le plus peut le moins" vis-à-vis des données existe encore ici et là au sein de notre organisation. Dans certains projets, nous conservons des jeux de données beaucoup plus riches en données personnelles et confidentielles que ce qui est strictement utile au projet
  • 1.5.e Le principe de minimisation est connu des collaborateurs, mais son application n'est pas la norme. En revanche, nous apportons une attention particulière à mettre en oeuvre des mesures de limitation des risques pour les données à caractère personnel (par exemple : pseudonymiser certaines features par des identifiants avec une table de correspondance séparée, éclater les données en plusieurs bases ou tables réparties)
Expl1.5 :

Le principe de minimisation est parfois aussi évoqué par l'expression privacy by design. Il est un des piliers du RGPD.

Les éléments suivants au sein de cette section ne s'appliquent qu'aux organisations n'ayant pas sélectionné la première réponse de R1.5. Les organisations non concernées sont donc invitées à passer à la Section 2.

Q1.6 : Projet impliquant un nouveau traitement de données personnelles ou confidentielles
(Condition : R1.5 <> 1.5.a)
Pour chaque traitement de données personnelles ou confidentielles nécessaire dans le cadre d'un projet de data science, au sein de votre organisation :

R1.6 :
(Type : réponses multiples possibles)
(Sélectionner tous les éléments de réponse correspondant à des pratiques de votre organisation)

  • 1.6.a Nous élaborons une analyse d'impact relative à la protection des données (AIPD ; en anglais Privacy Impact Assessment)
  • 1.6.b Nous mettons en oeuvre des mesures de protections (concernant notamment le transfert, le stockage, et l'accès aux données concernées)
  • 1.6.c Nous contractualisons les relations avec les fournisseurs et les clients et les responsabilités qui en découlent
  • 1.6.d Nous n'avons pas encore mis en place d'approche organisée sur ces sujets
Expl1.6 :

Le Privacy Impact Assessment (PIA) est une méthode d'évaluation de l'impact d'un traitement de données, proche des méthodes classiques d'évaluation des risques. Dans certains cas, par exemple lorsqu'un traitement présente des risques élevés pour les droits et libertés des personnes physiques, le RGPD rend obligatoire la réalisation d'un PIA avant la mise en oeuvre du traitement.

Q1.7 : Sécurité de l'apprentissage automatique - Niveau de connaissance
(Condition : R1.5 <> 1.5.a)
La sécurité de l'apprentissage automatique (ML security) est un domaine en constante évolution. Dans certains cas de figure, les modèles prédictifs appris sur des données confidentielles peuvent révéler des éléments de ces données confidentielles (cf. articles cités en ressources). Au sein de votre organisation, au sujet des vulnérabilités liées aux modèles de ML et aux techniques pour s'en prémunir, le niveau de connaissance générale des collaborateurs intervenant sur les projets de data science est :

R1.7 :
(Type : réponse unique)
(Sélectionner une seule réponse, correspondant le mieux au niveau de maturité de l'organisation sur ce sujet)

  • 1.7.a Complètement débutant
  • 1.7.b Basique
  • 1.7.c Confirmé
  • 1.7.d Expert
Expl1.7 :

L'état de l'art de la sécurité du ML est en constante évolution, et si la membership inference attack est maintenant relativement connue (voir ressources proposées), d'autres sont publiées régulièrement. S'il est impossible de se prémunir contre toutes les vulnérabilités à tout instant, il est crucial de s'en préoccuper et d'organiser une veille. L'article Demystifying the Membership Inference Attack est par exemple un point d'entrée intéressant dans un contexte de données sensibles.

Ressources1.7 :

Q1.8 : Sécurité de l'apprentissage automatique - Mise en oeuvre
(Condition : R1.5 <> 1.5.a)
Toujours au sujet des vulnérabilités liées aux modèles de ML et aux techniques pour s'en prémunir :

R1.8 :
(Type : réponses multiples possibles)
(Sélectionner tous les éléments de réponse correspondant à des pratiques de votre organisation)

  • 1.8.a Nous faisons une veille technique sur les principales attaques et mesures pour s'en prémunir
  • 1.8.b Les collaborateurs reçoivent régulièrement des informations et formations qui leur permettent de développer leurs compétences dans ce domaine
  • 1.8.c Dans certains projets, nous mettons en oeuvre des techniques spécifiques permettant de réduire les risques liés aux modèles que nous élaborons (par exemple : confidentialité différentielle, distillation...)
  • 1.8.d Sur chaque projet, les vulnérabilités qui s'y appliquent et les techniques mises en oeuvre sont documentées (par exemple dans la généalogie de bout-en-bout de chaque modèle, voir Section 4 et élément 4.1 pour plus d'information sur ce concept)
  • 1.8.e Nous n'avons pas encore mis en place d'approche organisée sur ces sujets
Expl1.8 :

L'état de l'art de la sécurité du ML est en constante évolution, et si la membership inference attack est maintenant relativement connue (voir ressources proposées), d'autres sont publiées régulièrement. S'il est impossible de se prémunir contre toutes les vulnérabilités à tout instant, il est crucial de s'en préoccuper et d'organiser une veille. L'article Demystifying the Membership Inference Attack est par exemple un point d'entrée intéressant dans un contexte de données sensibles.

Selon les niveaux de risque et de sensibilité des projets, certaines approches techniques pour s'en prémunir seront sélectionnées et implémentées. Il est important de suivre l'évolution de l'état de l'art et des pratiques, et de documenter les choix réalisés. On introduit ici la notion de "généalogie de bout-en-bout".

Ressources1.8 :

Q1.9 : Notifications d’incidents de sécurité aux autorités de régulation
(Condition : R1.5 <> 1.5.a)
Dans le cas de figure où un modèle que l'organisation a élaboré est utilisé ou accessible par une ou plusieurs parties prenantes externes, et qu'une vulnérabilité nouvelle est publiée, présente un risque de s'y appliquer et crée ainsi un risque d'exposition de données personnelles ou confidentielles :

R1.9 :
(Type : réponses multiples possibles)
(Sélectionner tous les éléments de réponse correspondant à des pratiques de votre organisation)

  • 1.9.a Nous avons une procédure décrivant la marche à suivre
  • 1.9.b Notre procédure inclut une communication aux parties prenantes en question
  • 1.9.c Notre procédure référence les autorités auxquelles nous devons faire un signalement
  • 1.9.d Nous n'avons pas encore mis en place de procédure pour couvrir ce cas de figure
Expl1.9 :

Il existe dans certains secteurs des obligations de signalement des incidents de sécurité aux autorités de régulation (e.g. CNIL, ANSSI, ARS...). Un point d'entrée intéressant : Notifications d’incidents de sécurité aux autorités de régulation : comment s’organiser et à qui s’adresser ? sur le site de la CNIL.

Section 2 - Prévenir les biais, élaborer des modèles non discriminatoires

[Biais et discriminations]

L'utilisation de modèles prédictifs élaborés à partir de données historiques peut se révéler contre-productive lorsque les données historiques sont contaminées par des phénomènes problématiques (e.g. qualité de certains points de données, données non comparables, phénomène social non souhaitable du fait de l'époque...). Or un enjeu-clé pour la data science responsable et de confiance est de respecter le principe de diversité, non-discrimination et équité (décrit par exemple à la section 1.5 des Ethics Guidelines for Trustworthy AI de l'UE). Il apparaît donc indispensable de s'interroger sur ce risque et d'étudier la nature des données utilisées, les conditions dans lesquelles elles ont été produites et assembées, et ce qu'elles représentent. Entre autres, dans certains cas une spécification de l'équité recherchée entre populations doit également être définie. L'équité d'un modèle peut être définie de plusieurs manières qui peuvent être incompatibles entre elles, et l'interprétation de scores de performances doit donc se faire dans le cadre de l'une de ces définitions.

[⇧ retour à la liste des sections]
[⇩ prochaine section]

Q2.1 : Analyse des données d'entraînement utilisées
Au sein des projets de data science et lors de l'élaboration de jeux de données d'entraînement, un travail de réflexion et recherche de phénomènes problématiques (e.g. qualité de certains points de données, données non comparables du fait des outils ou processus d'enregistrement, phénomène social non souhaitable du fait de l'époque, du contexte, etc.) peut s'avérer crucial pour prévenir des biais portant atteinte au principe de non-discrimination, de diversité et d'équité. Votre organisation :

R2.1 :
(Type : réponse unique)
(Sélectionner une seule réponse, correspondant le mieux au niveau de maturité de l'organisation sur ce sujet)

  • 2.1.a Fonctionne de manière informelle à ce sujet et s'en remet à la pratique de chaque collaborateur impliqué
  • 2.1.b Ne dispose pas d'une approche documentée sur le sujet, mais les collaborateurs impliqués sont formés aux risques et bonnes pratiques sur le sujet
  • 2.1.c Dispose d'une approche documentée et systématiquement mise en oeuvre
Expl2.1 :

Il s'agit de s'obliger à s'interroger sur ces sujets et donc à réfléchir aux données utilisées, la manière dont elles ont été produites etc.

Ressources2.1 :

Q2.2 : Risques de discrimination à l'encontre de certains groupes sociaux
Votre organisation est-elle concernée par des cas de figure où des modèles prédictifs sont utilisés dans des environnements thématiques pour lesquels des risques de discrimination à l'encontre de certains groupes sociaux (genre, origine, âge, etc.) existent ? (L'élément d'évaluation suivant est dédié à ces cas de figure) :

R2.2 :
(Type : réponse unique)
(Sélectionner une seule réponse, correspondant le mieux au niveau de maturité de l'organisation sur ce sujet)
(Domaine de risque spécifique : discrimination à l'encontre de certains groupes sociaux)

  • 2.2.a Concerné
  • 2.2.b Non concerné
Expl2.2 :

Les cas de figure où il existe des risques de discrimination sont particulièrement sensibles pour l'organisation et ses parties prenantes, et requièrent une attention toute particulière.

Les éléments suivants au sein de cette section ne s'appliquent qu'aux organisations ayant sélectionné la réponse "Concerné" de R2.2. Les organisations non concernées sont donc invitées à passer à la Section 3.

Q2.3 : Prévention des biais discriminatoires
(Condition : R2.2 <> 2.2.b)
Dans les cas de figure où les modèles prédictifs que votre organisation élabore sont utilisés dans des environnements thématiques où il y a des risques de discrimination à l'encontre de certains groupes sociaux (genre, origine, âge, etc.) :

R2.3 :
(Type : réponses multiples possibles)
(Sélectionner tous les éléments de réponse correspondant à des pratiques de votre organisation)

  • 2.3.a Nous portons une attention particulière à l'identification d'attributs protégés et à leurs proxys éventuels (par exemple étude une à une des variables utilisées en entrées du modèle pour recenser les corrélations qu’elles pourraient avoir avec des données sensibles)
  • 2.3.b Nous procédons à des évaluations sur des données de test comprenant différentes sous-populations afin d'identifier les éventuels biais problématiques
  • 2.3.c Nous sélectionnons et mettons en oeuvre une ou plusieurs mesure(s) de justice et d'équité (fairness metric)
  • 2.3.d Nous mettons en oeuvre des approches de type data augmentation ou re-weighting dans le but de réduire les éventuels biais des jeux de données
  • 2.3.e Les pratiques ci-dessus que nous mettons en oeuvre sont dûment documentées et intégrées à la généalogie de bout-en-bout des modèles concernés
  • 2.3.f Nous n'avons pas encore mis en place de mesures de ce type
Expl2.3 :

Il s'agit de s'interroger systématiquement, à chaque projet de data science et selon l'objectif et l'usage cible du modèle que l'on veut élaborer, sur les features pouvant directement ou indirectement être à l'origine d'un risque de biais discriminatoire. On parle d'attribut protégé (protected attribute ou protected variable en anglais) pour désigner les attributs dont les valeurs définissent des sous-populations à risque de discrimination. Complément sur l'utilisation de données synthétiques et d'approches de data augmentation, re-weighting dans le but de réduire les éventuels biais des jeux de données : lorsque de telles techniques sont utilisées il est important de les expliciter, au risque sinon de perdre de l'information sur la manière dont un modèle a été élaboré.

Ressources2.3 :

Q2.4 : Liens entre les choix de modélisation et les biais
(Condition : R2.2 <> 2.2.b)
Des travaux récents mettent en évidence le rôle que peuvent jouer les choix de modélisation et d'apprentissage dans la formation de biais discriminatoires. Les techniques de renforcement de la confidentialité, la compression, le choix du learning rate ou les mécanismes d'early stopping par exemple peuvent contribuer à défavoriser certains sous-groupes de manière disproportionnée. Prévenir ces derniers n'est donc pas qu'une question de jeu de données. Au sein de votre organisation, sur ce sujet le niveau de connaissance générale des collaborateurs intervenant sur les projets de data science est :

R2.4 :
(Type : réponse unique)
(Sélectionner une seule réponse, correspondant le mieux au niveau de maturité de l'organisation sur ce sujet)

  • 2.4.a Complètement débutant
  • 2.4.b Basique
  • 2.4.c Confirmé
  • 2.4.d Expert
Expl2.4 :

Si les jeux de données utilisés pour entraîner et évaluer un modèle requièrent une réflexion particulière pour prévenir les biais discriminatoires, des travaux récents montrent qu'il en va de même pour les choix de modélisation. Comme le synthétise très bien l'article Moving beyond “algorithmic bias is a data problem” proposé dans les ressources, les paramètres de l'algorithme d'apprentissage, la structure du modèle, l'adjonction ou non de confidentialité différentielle, la compression éventuelle, etc. peuvent avoir des conséquences sur la fairness d'un modèle. Extraits :

  • A key reason why model design choices amplify algorithmic bias is because notions of fairness often coincide with how underrepresented protected features are treated by the model
  • [...] design choices to optimize for either privacy guarantees or compression amplify the disparate impact between minority and majority data subgroups
  • [...] the impact of popular compression techniques like quantization and pruning on low-frequency protected attributes such as gender and age and finds that these subgroups are systematically and disproportionately impacted in order to preserve performance on the most frequent features
  • [...] learning rate and length of training can also disproportionately impact error rates on the long-tail of the dataset. Work on memorization properties of deep neural networks shows that challenging and underrepresented features are learnt later in the training process and that the learning rate impacts what is learnt. Thus, early stopping and similar hyper-parameter choices disproportionately and systematically impact a subset of the data distribution.

Ces sujets étant très techniques, encore peu diffusés et connus des praticiens, il s'agit dans le cadre de cet élément d'évaluation de s'y acculturer, s'en préoccuper dans les projets et ne pas occulter le sujet, et suivre l'état de l'art et les bonnes pratiques qui émergeront.

Ressources2.4 :

Section 3 - Evaluer la performance de manière rigoureuse

[Evaluation des performances]

Les performances des modèles sont déterminantes pour leur adoption dans des produits, systèmes ou processus. L'évaluation de la performance se doit donc d'être rigoureuse.

[⇧ retour à la liste des sections]
[⇩ prochaine section]

Q3.1 : Séparation des jeux de données de test
Au sein des projets de data science et lors de l'élaboration de jeux de données de test, il est capital d'assurer la non-contamination par des données d'entraînement. Votre organisation :

R3.1 :
(Type : réponses multiples possibles)
(Sélectionner tous les éléments de réponse correspondant à des pratiques de votre organisation. Attention, certaines combinaisons ne seraient pas cohérentes)

  • 3.1.a Fonctionne de manière informelle à ce sujet et s'appuie sur la compétence et la responsabilité des collaborateurs impliquées
  • 3.1.b Dispose d'une approche documentée et systématiquement mise en oeuvre d'isolation des jeux de données de test
  • 3.1.c Utilise un outil de versionnage et de traçabilité des jeux de données d'entraînement et de test utilisés, permettant ainsi de vérifier ou auditer ultérieurement la non-contamination des données de tests
  • 3.1.d Prévoit systématiquement l'élaboration de deux jeux de données de test ou plus pour gagner en résilience
Expl3.1 :

Assurer l'étanchéité des jeux de données d'entraînement et de test est un principe connu et maîtrisé par la plupart des organisations. Il peut se révéler délicats dans certaines configurations particulières (e.g. apprentissage continu, apprentissage distribué privacy-preserving...).

Q3.2 : Projets d'apprentissage distribué préservant la confidentialité
Dans les cas de figure de projets de data science basé sur l'apprentissage distribué ou fédéré (distributed learning ou federated learning) sur des jeux de données multiples et dont la confidentialité doit être préservée vis-à-vis des autres (privacy-preserving) :

R3.2 :
(Type : réponse unique)
(Sélectionner une seule réponse, correspondant le mieux au niveau de maturité de l'organisation sur ce sujet)
(Domaine de risque spécifique : apprentissage distribué sur données sensibles)

  • 3.2.a Nous ne participons pas à des projets d'apprentissage distribué privacy-preserving | (Concerné / Non concerné)
  • 3.2.b Nous maîtrisons et mettons en oeuvre des approches permettant d'élaborer des jeux de données de test de manière à ce qu'il n'y ait pas de contamination croisée entre données d'entraînement et de test provenant des différents partenaires
  • 3.2.c À ce stade nous ne maîtrisons pas les méthodes permettant d'élaborer des jeux de données de test de manière à ce qu'il n'y ait pas de contamination croisée entre données d'entraînement et de test provenant des différents partenaires
Expl3.2 :

Dans ce type de projet d'apprentissage distribué dans des conditions où les données sont maintenues confidentielles, se pose la question de comment composer un jeu de données de test en s'assurant que celles-ci ne figurent pas aussi dans le jeu de données d'entraînement (par exemple chez un autre partenaire).

Ressources3.2 :

Q3.3 : Analyse des données de validation et de test
Au sein des projets de data science et lors de l'élaboration de jeux de données de validation ou de test, un travail de réflexion et recherche de phénomènes problématiques (e.g. qualité de certains points de données, données non comparables du fait des outils ou processus d'enregistrement, phénomène social non souhaitable du fait de l'époque, du contexte, etc.) peut s'avérer crucial pour la signification des scores de performance. Votre organisation :

R3.3 :
(Type : réponse unique)
(Sélectionner une seule réponse, correspondant le mieux au niveau de maturité de l'organisation sur ce sujet)

  • 3.3.a Fonctionne de manière informelle à ce sujet et s'en remet à la pratique de chaque collaborateur impliqué
  • 3.3.b Ne dispose pas d'une approche documentée sur le sujet, mais les collaborateurs impliqués sont formés aux risques et bonnes pratiques sur le sujet
  • 3.3.c Dispose d'une approche documentée et systématiquement mise en oeuvre
Expl3.3 :

L'utilisation de modèles prédictifs validés et testés sur des données historiques peut se révéler contre-productive lorsque les données historiques en question sont contaminées par des phénomènes problématiques. Il apparaît indispensable de s'interroger sur ce risque et d'étudier la nature des données utilisées, les conditions dans lesquelles elles ont été produites et assemblées, et ce qu'elles représentent.

Q3.4 : Validation des performances
Votre organisation met-elle en oeuvre les approches suivantes :

R3.4 :
(Type : réponses multiples possibles)
(Sélectionner tous les éléments de réponse correspondant à des pratiques de votre organisation)

  • 3.4.a Lors de l'élaboration d'un modèle, nous choisissons la ou les métrique(s) de performance en amont de l'apprentissage automatique, parmi les métriques les plus standards possibles
  • 3.4.b La mise en oeuvre de mesures ou tests de robustesse (robustness metrics) est considérée et évaluée pour chaque projet d'élaboration d'un modèle, et appliquée par défaut dans les cas de figure où les données d'entrées peuvent être soumises à des perturbations fines (e.g. images, sons)
  • 3.4.c Les pratiques ci-dessus que nous mettons en oeuvre sont documentées et intégrées à la généalogie de bout-en-bout des modèles concernés, y compris les métriques de performance choisies
  • 3.4.d Nous n'avons pas encore mis en place de mesure de ce type
Expl3.4 :

Sur le fait de choisir les métriques en amont, voir par exemple le risque de p-hacking / data dredging. Sur la robustesse, une définition intuitive est qu'un modèle est robuste lorsque sa performance est stable quand les données d'entrée reçoivent des perturbations. Pour plus d'informations voir les ressources techniques indiquées.

Ressources3.4 :

Q3.5 : Suivi de la performance dans le temps
Dans les cas de figure où des modèles prédictifs élaborés par votre organisation sont utilisés dans des systèmes en production :

R3.5 :
(Type : réponses multiples possibles)
(Sélectionner tous les éléments de réponse correspondant à des pratiques de votre organisation. Attention, certaines combinaisons ne seraient pas cohérentes)
(Domaine de risque spécifique : utilisation de modèles prédictifs dans des systèmes en production)

  • 3.5.a Les modèles que nous élaborons ne sont pas utilisés dans des systèmes en production | (Concerné / Non concerné)
  • 3.5.b La performance est systématiquement ré-évaluée lorsque le modèle est mis à jour
  • 3.5.c La performance est systématiquement ré-évaluée lorsque le contexte d'utilisation du modèle évolue, ce qui peut créer un risque sur la performance du modèle du fait de l'évolution de l'espace des données d'entrée
  • 3.5.d La distribution des données d'entrée est monitorée, et la performance est ré-évaluée régulièrement sur des données de test actualisées
  • 3.5.e Des contrôles aléatoires sont réalisés sur des prédictions afin d'en contrôler la cohérence
  • 3.5.f Nous ne mettons pas systématiquement en place de mesure de ce type
Expl3.5 :

Même sur un modèle stable il existe un risque que les données d'entrée ne soient plus dans le domaine au bout d'un certain temps (population & distribution), exemple : une variable qui ne serait plus renseignée à la même fréquence qu'avant par les utilisateurs dans un SI. Il est donc nécessaire de contrôler régulièrement la performance d'un modèle utilisé dans son contexte d'utilisation. Suivre l'évolution de la performance des modèles dans le temps est également particulièrement important dans les cas de figure d'apprentissage continu, présentant un risque de dégénérescence des modèles.

Ressources3.5 :

Q3.6 : Seuils de décision et plages d'indécision
Pour la définition des seuils de décision des modèles ou des systèmes automatiques s'appuyant dessus, votre organisation :

R3.6 :
(Type : réponses multiples possibles)
(Sélectionner tous les éléments de réponse correspondant à des pratiques de votre organisation. Attention, certaines combinaisons ne seraient pas cohérentes)

  • 3.6.a Fonctionne de manière informelle à ce sujet et s'appuie sur la compétence et la responsabilité des collaborateurs impliquées
  • 3.6.b Dispose d'une approche documentée et systématiquement mise en oeuvre
  • 3.6.c Prend en compte la possibilité de maintenir des plages d'indécision dans certains cas de figure
  • 3.6.d Les choix réalisés pour chaque modèle et mis en oeuvre sont documentés et intégrés à la généalogie de bout-en-bout des modèles concernés
Expl3.6 :

L'étude et à la sélection de seuils de décisions pertinents pour un problème de data science donné (threshold selection) est lié aux métriques retenues. Comme le présente l'article indiqué dans les ressources de cet élément d'évaluation, il peut être intéressant dans certains cas de considérer la possibilité de définir des plages d'indécision.

Ressources3.6 :

Q3.7 : Audits par des tierces parties indépendantes et verifiable claims
Lorsque votre organisation communique sur les résultats ou la performance d'un système d'IA, et s'appuie sur de telles communications pour son développement et vis-à-vis de ses parties prenantes :

R3.7 :
(Type : réponse unique)
(Sélectionner une seule réponse, correspondant le mieux au niveau de maturité de l'organisation sur ce sujet)
(Domaine de risque spécifique : utilisation de l'évaluation de la performance d'un système d'IA comme argument de communication et de marketing)

  • 3.7.a Nous ne communiquons pas et n'utilisons pas les résultats ou la performance de nos systèmes d'IA comme argument vis-à-vis de nos parties prenantes, nous ne sommes pas concernés par cet élément d'évaluation | (Concerné / Non concerné)
  • 3.7.b Nous communiquons sur nos résultats et nous appuyons sur ceux-ci pour notre développement sans faire auditer auparavant nos travaux par une tierce partie indépendante, sans mettre à disposition d'éléments de preuve
  • 3.7.c Nous faisons auditer nos travaux par une tierce partie indépendante, ou nous mettons à disposition des éléments de preuve, avant de communiquer sur nos résultats et de nous en prévaloir vis-à-vis de nos parties prenantes
Expl3.7 :

L'élaboration d'un modèle prédictif, et la détermination d'une mesure de performance de référence, signifiante et fiable, sont des défis complexes. Il est donc souvent délicat pour une organisation d'affirmer l'obtention d'excellents résultats et de s'en prévaloir avec certitude. Et lorsque cela est toutefois possible, il peut être plus délicat encore de mettre à disposition publiquement des éléments de preuve sans avoir à révéler d'information précieuse composant la propriété intellectuelle de l'organisation et la valeur même des travaux réalisés. Dans ces cas de figure, il est recommandé de faire procéder à un audit par une tierce partie indépendante (e.g. sécurité, privacy, fairness, fiabilité...), afin de sécuriser les résultats dont l'organisation souhaite se prévaloir.

Ressources3.7 :

Section 4 - Assurer la reproductibilité des modèles et en établir la chaîne de responsabilité

[Documentation des modèles]

Un modèle prédictif est un objet informatique complexe qui peut évoluer au fil des apprentissages. Tracer les étapes de son élaboration et de son évolution permet d'en constituer une forme de généalogie, pré-requis pour reproduire ou auditer un modèle. Par ailleurs utiliser des systèmes automatiques basés sur des modèles dont les règles ont été "apprises" (et non définies et formalisées) interroge le fonctionnement des organisations. Il apparaît indispensable de garantir une chaîne de responsabilité claire, de personnes physiques ou morales, pour chaque modèle.

[⇧ retour à la liste des sections]
[⇩ prochaine section]

Q4.1 : "Généalogie de bout-en-bout" des modèles
Tracer les étapes de l'élaboration d'un modèle permet d'en constituer une forme de généalogie. Au sein de votre organisation, une généalogie de bout-en-bout des modèles est alimentée et tenue à jour dans le cadre des projets de data science, tout au long des phase de collecte de données, conception, entraînement, validation et exploitation des modèles :

R4.1 :
(Type : réponse unique)
(Sélectionner une seule réponse, correspondant le mieux au niveau de maturité de l'organisation sur ce sujet)

  • 4.1.a À ce stade nous n'avons pas mis en oeuvre d'approche de ce type
  • 4.1.b Ces informations existent et sont enregistrées afin de ne pas être perdues, mais elles peuvent l'être de manière désordonnée et ne sont pas versionnées
  • 4.1.c Elles sont rassemblées en un unique document qui accompagne systématiquement le modèle
  • 4.1.d Elles sont rassemblées en un unique document qui accompagne systématiquement le modèle et versionnées
Expl4.1 :

Ce concept de "généalogie de bout-en-bout" d'un modèle prédictif appris peut se décliner sous la forme par exemple d'un document de référence reprenant tous les choix importants ainsi que tout l'historique d'élaboration du modèle (données utilisées, pré-traitements réalisés, type d'apprentissage et architecture du modèle, hyperparamètres sélectionnés, seuils de décision, métriques de tests...), etc.), et de processus internes organisant cette activité. En particulier, il est intéressant d'y faire figurer les choix de compromis (trade-offs) qui ont été faits et pourquoi (e.g. trade-offs précision-spécificité, performance-privacy, performance-coût computationnel, etc.).

Ressources4.1 :
  • (Software & Tools) Substra Framework: an open source framework offering distributed orchestration of machine learning tasks among partners while guaranteeing secure and trustless traceability of all operations
  • (Software & Tools) MLflow: an open source platform to manage the ML lifecycle, including experimentation, reproducibility, deployment, and a central model registry
  • (Software & Tools) DVC: an Open-source Version Control System for Machine Learning Projects
  • (Software & Tools) DAGsHub: a platform for data version control and collaboration, based on DVC
  • (Software & Tools) Modèle de généalogie de bout en bout: template à destination des Data Scientists pour aider à collecter toutes les informations afin de tracer la généalogie de bout-en-bout d'un modèle, 2020, Joséphine Lecoq-Vallon

Q4.2 : Conditions et limites d'utilisation d'un modèle
Dans le cadre des projets de data science, les "conditions et limites de validité" d'un modèle conçu, entraîné et validé par l'organisation :

R4.2 :
(Type : réponses multiples possibles)
(Sélectionner tous les éléments de réponse correspondant à des pratiques de votre organisation. Attention, certaines combinaisons ne seraient pas cohérentes)

  • 4.2.a Ne sont pas documentées
  • 4.2.b Sont explicitées et documentées
  • 4.2.c Sont versionnées
  • 4.2.d Contiennent une description des risques que présenterait une utilisation en dehors des "conditions et limites de validité"
  • 4.2.e Les documents présentant ces "conditions et limites de validité" accompagnent systématiquement les modèles tout au long de leur cycle de vie
Expl4.2 :

Il s'agit d'expliciter et d'adjoindre au modèle la description du contexte d'utilisation pour lequel il a été conçu et dans lequel sa performance annoncée est significative. Ce concept de "conditions et limites de validité" peut se décliner sous la forme d'un document synthétique ou d'une section spécifique dans la "généalogie de bout-en-bout".

Ressources4.2 :
  • (Academic paper) Model Cards for Model Reporting, M. Mitchell, S. Wu, A. Zaldivar, P. Barnes, L. Vasserman, B. Hutchinson, E. Spitzer, I. D. Raji, T. Gebru, Janvier 2019
  • (Web article) Model Cards de Google est un framework ouvert et évolutif, et propose 2 exemples : To explore the possibilities of model cards in the real world, we've designed examples for two features of our Cloud Vision API, Face Detection and Object Detection. They provide simple overviews of both models' ideal forms of input, visualize some of their key limitations, and present basic performance metrics.
  • (Web article) Model Cards for AI Model Transparency, Salesforce : exemples de Model Cards utilisées et publiées par Salesforce
  • (Software & Tools) AI FactSheets 360 d'IBM Research est un projet visant à définir une méthodologie et des exemples pour cartographier et décrire un modèle et son cycle de vie.

Q4.3 : Analyse et partage d'incidents
Dans le cadre des projets de data science, lorsqu'un comportement inattendu d'un modèle est observé :

R4.3 :
(Type : réponses multiples possibles)
(Sélectionner tous les éléments de réponse correspondant à des pratiques de votre organisation. Attention, certaines combinaisons ne seraient pas cohérentes)

  • 4.3.a À ce stade nous ne faisons pas d'analyse des incidents ou comportements inattendus observés
  • 4.3.b Nous analysons les incidents ou comportements inattendus rencontrés, mais ne les publions pas
  • 4.3.c Nous analysons les incidents ou comportements inattendus rencontrés et les publions lorsque cela est pertinent (e.g. article, blog)
  • 4.3.d Nous nous impliquons dans des clubs, cercles, ou associations professionnelles dans le domaine de la data science, et y faisons des retours d'expérience des incidents comportements inattendus que nous observons
Expl4.3 :

La compréhension voire la maîtrise du comportement d'un modèle prédictif appris sont des défis complexes. De nombreuses recherches sont en cours pour développer des méthodes et des outils dans ce domaine, mais beaucoup reste à faire. Le partage par les praticiens des incidents et comportements inattendus qu'ils rencontrent contribue faire progresser la communauté.

Ressources4.3 :

Q4.4 : Chaîne de valeur et de responsabilités
Dans le cas de figure des projets de data science où plusieurs acteurs, y compris internes à l'organisation (équipes, départements, filiales), sont parties prenantes tout au long de la chaîne de valeur et de responsabilités :

R4.4 :
(Type : réponses multiples possibles)
(Sélectionner tous les éléments de réponse correspondant à des pratiques de votre organisation. Attention, certaines combinaisons ne seraient pas cohérentes)
(Domaine de risque spécifique : rôles et responsabilités morcelés dans les projets de data science)

  • 4.4.a Au sein de notre organisation les projets de data science sont menés de bout-en-bout par des équipes autonomes, y compris l'élaboration de jeux de données et l'exploitation pour son propre compte des modèles. En conséquence, pour chaque projet une équipe autonome est seule responsable | (Concerné / Non concerné)
  • 4.4.b Nous procédons systématiquement à l'identification des risques et responsabilités de chacune des parties prenantes internes ou externes avec lesquelles nous collaborons
  • 4.4.c Nous contractualisons systématiquement avec les acteurs amont (e.g. fournisseurs de données) et aval (e.g. clients, partenaires utilisateurs de modèles)
  • 4.4.d Nous ne mettons pas systématiquement en place de mesure de ce type
Expl4.4 :

Il est important de s'assurer que les organisations en amont et en aval de la chaîne identifient et endossent bien leurs responsabilités sur leurs segments de la chaîne de valeur.

Q4.5 : Sous-traitance de tout ou partie des activités data science
Les activités data science sous-traitées à une ou des organisation(s) tierce(s) sont soumises aux mêmes exigences que celles que votre organisation s'applique à elle-même :

R4.5 :
(Type : réponse unique)
(Sélectionner une seule réponse, correspondant le mieux au niveau de maturité de l'organisation sur ce sujet)
(Domaine de risque spécifique : sous-traitance d'activités de data science)

  • 4.5.a Non concerné, nous ne sous-traitons pas ces activités | (Concerné / Non concerné)
  • 4.5.b Oui, nos réponses à cette évaluation tiennent compte des pratiques de nos sous-traitants
  • 4.5.c Non, nos réponses à cette évaluation ne s'appliquent pas à nos sous-traitants et sur certains points il est possible qu'ils soient moins avancés que nous
Expl4.5 :

Comme dans les cadres connues du management des SI (ISO 27001) ou du RGPD, il est important de ne pas diluer les responsabilités dans des chaînes de sous-traitance non maîtrisées. Cela doit s'appliquer par exemple aux consultants, freelances qui viennent renforcer une équipe interne sur un projet de data science. Il est par exemple possible de demander aux sous-traitants de réaliser cette même évaluation pour leur propre compte et de partager avec vous leurs résultats.

Q4.6 : Répartition de la création de valeur
Dans les cas de figure des projets de data science où plusieurs partenaires concourent aux côtés de votre organisation à l'élaboration d'un modèle, et que celui-ci est ou sera l'objet d'une activité économique :

R4.6 :
(Type : réponses multiples possibles)
(Sélectionner tous les éléments de réponse correspondant à des pratiques de votre organisation. Attention, certaines combinaisons ne seraient pas cohérentes)
(Domaine de risque spécifique : rôles et responsabilités morcelés dans les projets de data science)

  • 4.6.a Notre organisation exerce ses activités de data science de manière autonome, y compris l'élaboration de jeux de données et l'exploitation pour son propre compte des modèles. Elle n'est donc pas concernée | (Concerné / Non concerné)
  • 4.6.b À ce stade nous n'avons pas structuré cet aspect des projets de data science multi-partenaires
  • 4.6.c Dans ces cas de figure nous contractualisons le volet économique de la relation avec les parties prenantes impliquées en amont du projet
  • 4.6.d Notre organisation s'est dotée d'une politique encadrant de manière responsable le partage de valeur avec les parties prenantes impliquées
Expl4.6 :

Lorsque plusieurs partenaires collaborent pour l'élaboration d'un modèle, il est important que la répartition de valeur consécutives à une activité économique dans laquelle le modèle joue un rôle soit explicitée et contractualisée. Dans certains cas de figure cette question peut être complexe, par exemple lorsqu'un modèle est entraîné de manière distribuée sur plusieurs jeux de données.

Ressources4.6 :

Section 5 - Utiliser des modèles en confiance et de manière responsable

[Utilisation des modèles]

Un modèle prédictif peut-être utilisé comme un système automatique, dont les règles de fonctionnement ne sont pas écrites in extenso et ne se prêtent pas ou mal à être explicitées, débattues, ajustées. Utiliser des systèmes automatiques basés sur des modèles dont les règles ont été "apprises" (et non définies et formalisées) interroge donc le fonctionnement des organisations. Il est important de préserver la capacité de réaction et la résilience de l'organisation utilisatrice, notamment pour traiter les cas de figure où les modèles prédictifs auront été à l'origine d'un résultat non souhaitable pour l'organisation ou ses parties prenantes. Par ailleurs, des efforts sont donc nécessaires sur l'interprétation et l'explication des choix réalisés à l'aide de ces systèmes.

[⇧ retour à la liste des sections]
[⇩ prochaine section]

Q5.1 : Utilisation de modèles prédictifs pour son propre compte
Si votre organisation utilise pour son propre compte des modèles prédictifs :

R5.1 :
(Type : réponses multiples possibles)
(Sélectionner tous les éléments de réponse correspondant à des pratiques de votre organisation. Attention, certaines combinaisons ne seraient pas cohérentes)
(Domaine de risque spécifique : utilisation de modèles prédictifs pour son propre compte, fourniture et opération de modèles prédictifs à ses clients ou à des tiers)

  • 5.1.a Notre organisation n'utilise pas de modèles prédictifs élaborés par apprentissage automatique pour son propre compte | (Concerné / Non concerné)
  • 5.1.b Un registre des modèles prédictifs identifie tous les modèles utilisés par l'organisation, nous le maintenons à jour
  • 5.1.c Pour chaque modèle nous disposons d'un responsable point de contact défini, identifiable et contactable simplement
  • 5.1.d Pour chaque modèle, nous réalisons systématiquement une évaluation des risques consécutifs à d'éventuels incidents, défaillances ou biais
  • 5.1.e Des outils de monitoring sont mis en place afin d'assurer une surveillance continue des systèmes basés sur des modèles prédictifs et peuvent déclencher des alertes directement auprès de l'équipe responsable
  • 5.1.f Pour chaque modèle, nous définissons et testons une procédure de suspension du modèle et un mode de fonctionnement dégradé sans le modèle, pour parer au cas de figure où le modèle serait sujet à une défaillance ou un comportement anormal
  • 5.1.g Pour chaque modèle, nous étudions sa généalogie de bout-en-bout (toutes les étapes et tous les choix qui ont conduit à son élaboration et son évaluation), ainsi que ses conditions et limites d'utilisation, pour comprendre le modèle avant de l'utiliser
  • 5.1.h Nous utilisons toujours les modèles pour des usages en adéquation avec leurs conditions et limites d'utilisation
  • 5.1.i Nous n'avons pas encore mis en place de mesure de ce type
Expl5.1 :

Utiliser des systèmes automatiques basés sur des modèles dont les règles ont été "apprises" (et non définies et formalisées) interroge le fonctionnement des organisations. Il est important d'évaluer les conséquences et les réactions en cas d'incident. Par ailleurs il est important qu'une personne responsable soit clairement identifiée de manière à ne laisser aucune partie prenante démunie face à une conséquence inattendue ou inappropriée. Enfin il est important de s'interroger sur les "conditions et limites de validité" des modèles que l'on utilise afin de s'assurer que l'usage que l'on prévoit est bien en adéquation.

Q5.2 : Développement de modèles prédictifs pour le compte de tiers
Si votre organisation fournit à ses clients ou à des tiers, ou opère pour le compte de tiers des applications basées sur des modèles prédictifs :

R5.2 :
(Type : réponses multiples possibles)
(Sélectionner tous les éléments de réponse correspondant à des pratiques de votre organisation. Attention, certaines combinaisons ne seraient pas cohérentes)
(Domaine de risque spécifique : utilisation de modèles prédictifs pour son propre compte, fourniture et opération de modèles prédictifs à ses clients ou à des tiers)

  • 5.2.a Notre organisation ne fournit pas à ses clients ou des tiers, et n'opère pas pour le compte de tiers d'application basée sur des modèles prédictifs élaborés par apprentissage automatique | (Concerné / Non concerné)
  • 5.2.b Un registre des modèles prédictifs identifie tous les modèles ou applications utilisés par ses clients et/ou par l'organisation pour le compte de tiers, nous le maintenons à jour
  • 5.2.c Pour chaque modèle ou application pour un client ou un tiers nous disposons d'un responsable point de contact défini, identifiable et joignable simplement
  • 5.2.d Pour chaque modèle ou application pour un client ou un tiers, nous réalisons systématiquement une évaluation des risques consécutifs à d'éventuels, incidents, défaillances, biais
  • 5.2.e Des outils de monitoring sont mis en place afin d'assurer une surveillance continue des systèmes de ML et peuvent déclencher des alertes directement auprès de l'équipe responsable
  • 5.2.f Pour chaque modèle ou application pour un client ou un tiers, nous définissons et testons une procédure de suspension du modèle et un mode de fonctionnement dégradé sans le modèle, pour parer au cas de figure où le modèle serait sujet à une défaillance ou un comportement anormal
  • 5.2.g Pour chaque modèle ou application pour un client ou un tiers, nous étudions sa généalogie de bout-en-bout et ses conditions et limites d'utilisation pour comprendre le modèle avant de l'utiliser
  • 5.2.h Nous fournissons à nos clients ou opérons pour leur compte des modèles ou applications pour des usages en adéquation avec leurs conditions et limites d'utilisation
  • 5.2.i Nous n'avons pas encore mis en place de mesure de ce type
Expl5.2 :

Utiliser des systèmes automatiques basés sur des modèles dont les règles ont été "apprises" (et non définies et formalisées) interroge le fonctionnement des organisations. Il est important d'évaluer les conséquences et les réactions en cas d'incident. Par ailleurs il est important qu'une personne responsable soit clairement identifiée de manière à ne laisser aucune partie prenante démunie face à une conséquence inattendue ou inappropriée. Enfin il est important de s'interroger sur les "conditions et limites de validité" des modèles que l'on utilise afin de s'assurer que l'usage que l'on prévoit est bien en adéquation.

Q5.3 : Gestion des prédictions problématiques, processus de contournement, human agency
Les systèmes automatiques, en particulier lorsqu'ils s'appuient sur des modèles prédictifs appris, sont utilisés en production généralement pour gagner en efficacité. Il se trouve que par nature, ils génèrent de temps en temps des résultats non souhaitables pour l'organisation et ses parties prenantes (e.g. prédiction erronée), puisqu'ils ne généraliseront jamais une performance de 100%.

R5.3 :
(Type : réponse unique)
(Sélectionner une seule réponse, correspondant le mieux au niveau de maturité de l'organisation sur ce sujet)
(Domaine de risque spécifique : utilisation de modèles prédictifs pour son propre compte, fourniture et opération de modèles prédictifs à ses clients ou à des tiers)

  • 5.3.a Notre organisation n'utilise pas de modèles prédictifs élaboré par apprentissage automatique pour son propre compte ou celui de ses clients, et ne fournit pas à ses clients d'application basée sur des modèles prédictifs | (Concerné / Non concerné)
  • 5.3.b Nous implémentons des modèles prédictifs élaborés par apprentissage automatique dans des systèmes automatiques intégrés, sans mécanismes permettant de pallier à ou d'éviter des résultats non souhaitables dûs aux prédictions des modèles
  • 5.3.c Nous intégrons, dans les systèmes automatiques s'appuyant sur des modèles prédictifs, les fonctionnalités permettant de gérer ces cas de résultats non souhaitables. Pour ces cas de figure, nous mettons en place des mécanismes permettant à un opérateur humain d'aller contre une décision automatique pour gérer de tels résultats non souhaitables ou incidents
  • 5.3.d En complément des mécanismes de gestion d'incident, dans les systèmes automatiques s'appuyant sur des modèles prédictifs, lorsque l'intervalle de confiance pour la décision automatique n'est pas satisfaisant un opérateur humain est sollicité
  • 5.3.e Nous appliquons systématiquement le principe de human agency, les sorties des modèles prédictifs que nous mettons en oeuvre sont utilisées par des opérateurs humains, et ne servent pas de déterminants à des décisions automatiques
Expl5.3 :

Utiliser des systèmes automatiques basés sur des modèles dont les règles ont été "apprises" (et non définies et formalisées) interroge le fonctionnement des organisations. Il est important de préserver la capacité de réaction et la résilience de l'organisation.

Ressources5.3 :

Q5.4 : Explicabilité et interprétabilité
Au sein des projets de data science qui visent à élaborer des modèles prédictifs :

R5.4 :
(Type : réponses multiples possibles)
(Sélectionner tous les éléments de réponse correspondant à des pratiques de votre organisation. Attention, certaines combinaisons ne seraient pas cohérentes)

  • 5.4.a Notre organisation n'est pour l'instant pas familière avec les méthodes et outils d'explicabilité et d'interprétabilité des modèles
  • 5.4.b Nous nous intéressons au sujet de l'explicabilité et l'interprétabilité des modèles et dialoguons avec nos parties prenantes sur ce sujet
  • 5.4.c Nous faisons en sorte que les modèles que nous élaborons fournissent lorsque cela est pertinent a minima un niveau de confiance avec chaque prédiction réalisée
  • 5.4.d Nous déterminons le meilleur compromis entre la performance et l'interprétabilité pour chaque modèle que nous élaborons, ce qui nous amène parfois à opter pour un modèle plus simple à expliquer aux personnes concernées (un modèle performant permettra de diminuer les risques d’erreur tandis qu’un modèle interprétable permettra de mieux justifier les résultats du modèle)
  • 5.4.e Nous maîtrisons et mettons en oeuvre des approches avancées pour l'explicabilité et l'interprétabilité des modèles
Expl5.4 :

L'explicabilité et l'interprétabilité sont des enjeux-clés, en lien avec les exigences croissantes de transparence, d'impartialité et de responsabilité. Dans certains cas, la réglementation impose même de pouvoir expliquer aux personnes concernées comment fonctionne un algorithme. Des ressources techniques comme SHAP ou LIME permettent d'entrer de plain-pied dans le sujet (voir les ressources associées à cet élément d'évaluation).

Ressources5.4 :

Q5.5 : Transparence vis-à-vis des parties prenantes interagissant avec un modèle prédictif appris
Votre organisation utilise pour son propre compte, fournit à ses clients ou opère pour le compte de ses clients des applications basées sur des modèles prédictifs, avec lesquels sont à même d'interagir des utilisateurs. Que met-elle en place pour en informer les utilisateurs ?

R5.5 :
(Type : réponses multiples possibles)
(Sélectionner tous les éléments de réponse correspondant à des pratiques de votre organisation. Attention, certaines combinaisons ne seraient pas cohérentes)
(Domaine de risque spécifique : utilisation de modèles prédictifs pour son propre compte, fourniture et opération de modèles prédictifs à ses clients ou à des tiers)

  • 5.5.a Notre organisation n'utilise pas de modèles prédictifs élaborés par apprentissage automatique pour son propre compte ou celui de ses clients, et ne fournit pas à ses clients d'application basée sur des modèles prédictifs | (Concerné / Non concerné)
  • 5.5.b Les utilisateurs ne sont pas informés qu'ils interagissent avec un modèle prédictif élaboré par apprentissage automatique
  • 5.5.c Une notice d'information est mise à disposition dans les conditions générales d'utilisation du système ou un document équivalent, en libre accès
  • 5.5.d Le système ou le service est explicite vis-à-vis de l'utilisateur quant au fait qu'un modèle prédictif est utilisé
  • 5.5.e Le système ou le service propose à l'utilisateur des informations supplémentaires sur les résultats qu'il aurait fourni dans des cas de figure légèrement différents (par exemple des "explications contrefactuelles" comme le plus petit changement dans les données d'entrée qui aurait permis d'arriver à une sortie donnée)
  • 5.5.f Nous sommes pionniers dans l'utilisation de registres publics pour les modèles d'IA, qui nous permettent de fournir de la transparence à nos parties prenantes et également de capter des retours utilisateurs
Expl5.5 :

Utiliser des systèmes automatiques basés sur des modèles dont les règles ont été "apprises" (et non définies et formalisées) interroge le fonctionnement des organisations mais également le rapport des utilisateurs aux systèmes et services numériques. Dans la plupart des cas il est important d'informer les utilisateurs qu'ils ne font pas face à des règles de gestion classiques.

Ressources5.5 :

Section 6 - Anticiper, suivre et minimiser les externalités négatives de l'activité data science

[Externalités négatives]

La mise en place d'un système automatique basé sur un modèle prédictif peut générer des externalités négatives sociales et environnementales. En prendre conscience est indispensable, ainsi qu'anticiper, suivre et minimiser les différents impacts négatifs.

[⇧ retour à la liste des sections]

Q6.1 : Impact CO2
Au sujet de l'impact CO2 de l'activité data science au sein de votre organisation :

R6.1 :
(Type : réponse unique)
(Sélectionner une seule réponse, correspondant le mieux au niveau de maturité de l'organisation sur ce sujet)

  • 6.1.a À ce stade nous ne nous sommes pas penchés sur l'impact CO2 de notre activité data science ou de nos modèles prédictifs
  • 6.1.b Nous avons élaboré des indicateurs définissant ce que nous souhaitons mesurer
  • 6.1.c Nous mesurons nos indicateurs régulièrement et nous incluons leurs mesures dans les généalogies de bout-en-bout des modèles
  • 6.1.d Le fait de suivre nos indicateurs régulièrement est un processus formalisé et piloté, à partir duquel nous nous fixons des objectifs d'amélioration
Expl6.1 :

Il est important de s'interroger et de conscientiser les coûts environnementaux.

Ressources6.1 :
  • (Software & Tools) ML Impact Calculator
  • (Software & Tools) Code Carbon: librairie Python permettant d'évaluer le coût carbone de l'exécution d'un script

Q6.2 : Impact social
Dans certains cas, la mise en place d'un système automatique basé sur un modèle prédictif peut générer des externalités négatives sur les parties prenantes amont (par exemple annotation de données), et sur les parties prenantes aval (par exemple automatisation de certains postes). Lors de chaque projet d'élaboration ou d'utilisation d'un modèle prédictif, votre organisation :

R6.2 :
(Type : réponse unique)
(Sélectionner une seule réponse, correspondant le mieux au niveau de maturité de l'organisation sur ce sujet)

  • 6.2.a À ce stade nous ne nous penchons pas sur l'impact social de notre activité data science ou de nos modèles prédictifs
  • 6.2.b Dans certains cas nous nous interrogeons sur l'impact social
  • 6.2.c Nous menons ce travail de réflexion sur l'impact social à chaque projet
  • 6.2.d Nous menons ce travail de réflexion sur l'impact social à chaque projet et l'impact social est documenté dans la généalogie de bout-en-bout de chaque modèle
  • 6.2.e Nous menons ce travail de réflexion sur l'impact social à chaque projet, l'impact social est documenté dans la généalogie de bout-en-bout de chaque modèle, et nous entamons systématiquement un dialogue avec les parties prenantes concernées amont et aval
Expl6.2 :

Il est important de s'interroger et d'échanger avec ses parties prenantes. Cela vaut tant pour l'aval (e.g. automatisation de certains emplois) que pour l'amont (e.g. tâches d'annotations de données parfois d'une très grande violence).

Q6.3 : Ethique et non-malfaisance
Au sein de votre organisation :

R6.3 :
(Type : réponses multiples possibles)
(Sélectionner tous les éléments de réponse correspondant à des pratiques de votre organisation. Attention, certaines combinaisons ne seraient pas cohérentes)

  • 6.3.a À ce stade nous ne nous sommes pas encore penchés sur la dimension éthique
  • 6.3.b Les collaborateurs concernés par les activités data science reçoivent une formation à l'éthique
  • 6.3.c Notre organisation s'est dotée d'une politique en matière d'éthique
  • 6.3.d Sur les projets le justifiant, nous mettons en place un comité d'éthique indépendant ou nous sollicitons l'évaluation d'un organisme validant l'éthique des projets
Expl6.3 :

Travailler sur de grands volumes de données dont certaines peuvent être sensibles, utiliser des systèmes automatiques basés sur des modèles dont les règles ont été "apprises" (et non définies et formalisées) interrogent le fonctionnement des organisations et la responsabilité individuelle de chacun, impose d'avoir une réflexion sur l'usage qui en est fait. Il est donc important que l'organisation s'assure que les enjeux éthiques ne soient pas inconnus de son personnel. Un exemple qui revient : certains systèmes ou services d'IA conçus pour s'adapter au comportement des utilisateurs peuvent influencer ceux-ci (par exemple en cherchant à maximiser leurs temps d'utilisation ou les sommes qu'ils dépensent) et présenter des risques non négligeables de manipulation ou d'addiction.

Ressources6.3 :

Risques

Quels sont les risques que l'on souhaite prévenir pour pouvoir parler de data science responsable et de confiance ?

Découpage en thèmes :

  • EDP : l'Exposition de Données Personnelles ou confidentielles
  • PDI : la Prise de Décisions Inappropriées par des systèmes automatiques
  • RC : ne pas Rendre des Comptes de manière responsable à ses parties prenantes
  • ESE : avoir une Empreinte Sociale et Environnementale irresponsable
  • TR : transverses
  • à catégoriser
# Risques Exemples réels ou commentaires
EDP l'Exposition de Données Personnelles ou confidentielles (e.g. données personnelles ou données privées d'une organisation)
EDP-01 des datasets contenant des données personnelles ou confidentielles sont exposés ré-identification de datasets anonymisés ; article Nature : "Using our model, we find that 99.98% of Americans would be correctly re-identified in any dataset using 15 demographic attributes."
EDP-02 un algorithme d'apprentissage machine est utilisé de manière malveillante pour extraire ou exposer des données personnelles ou confidentielles d'un dataset d'entraînement ou de test
EDP-03 l'exploitation malveillante d'un modèle prédictif expose des données personnelles ou confidentielles rétro-engineering des résultats d'un algorithme
EDP-04 des dispositions réglementaires font peser des risques, ou un changement réglementaire augmente les risques d'exposition de données personnelles ou confidentielles Cloud Act ; FATCA en contradiction avec le droit européen ; CNB - Mise en garde HDH
PDI la Prise de Décisions Inappropriées par des systèmes automatiques, qui seraient préjudiciables à des personnes ou des organisations Par inapproprié on entend ici infondé, injuste ou illégitime.
PDI-01 la prise de décisions inappropriées du fait de biais discriminatoires dans les données d'entraînement ou de test cas Apple Card ; algorithme RH d'Amazon ; reconnaissance faciale ; biais dans les systèmes de reconnaissance visuelle
PDI-02 la prise de décisions inappropriées du fait de données empoisonnées (de manière malveillante, ou du fait de phénomènes diffus, mal compris) l'exemple du social cooling illustre la difficulté d'appréhender la fiabilité ou la signification de certains types de données
PDI-03 la prise de décisions inappropriées du fait de l'utilisation de données synthétiques # ce risque est mal identifié/défini à ce stade #
PDI-04 la prise de décisions inappropriées du fait de biais discriminatoires dûs à l'architecture ou la conception même de l'algorithme d'apprentissage et/ou du modèle modèles de word embedding, doc2vec ; utilisation de variables protégées directement
PDI-05 l'utilisation de modèles prédictifs dans des contextes pour lesquels ils ne sont pas suffisamment performants, pas pertinents voire dangereux, pas prévus et validés (où leur performance réelle est insuffisante par rapport au déclaré ou à l'attendu) exemple de Google Flu Trends en santé ; biais et performances limitées du modèle COMPAS de prédiction de la récidive
PDI-06 l'utilisation de modèles ayant subi une dégénérescence ou drift dans le temps (par exemple, dans les cas de figure d'apprentissage en continu, lorsque les nouvelles données inputs proviennent, même indirectement, de situations dans lesquels le modèle a été utilisé) cas à identifier (problème de capteurs de mesure en maintenance prédictive, trading...)
PDI-07 l'utilisation adversariale d'un modèle prédictif de manière préjudiciable à des personnes ou des organisations Three Small Stickers in Intersection Can Cause Tesla Autopilot to Swerve Into Wrong Lane
RC ne pas Rendre des Comptes de manière responsable à ses parties prenantes quant aux conséquences de l'usage de modèles prédictifs
RC-01 dans le cas d'un incident avec ou provoqué par un modèle prédictif, ne pas avoir de personne physique ou morale identifiée à qui demander des comptes cas de Steve Wozniak avec l'Apple Card
RC-02 dans le cas d'un incident avec ou dû à un modèle prédictif : pour l'acteur qui met en oeuvre et opère le modèle, ne pas savoir réagir face à une demande d'interpréter et expliquer une prédiction mise en cause les algorithmes de censure automatiques de Facebook ont été moins efficaces lors de l'attentat de Christchurch qu'avec les vidéos de l'EI : que détectent-ils exactement ? ; An Algorithm that grants Freedom, or Takes it away
RC-03 dans le cas d'un incident avec ou dû à un modèle prédictif : pour l'acteur qui met en oeuvre et opère le modèle, ne plus être capable d'assurer un service critique cas à identifier
RC-04 au sein d'une organisation qui utilise des systèmes automatiques basés sur des modèles prédictifs, ne pas connaître ou ne pas savoir identifier facilement qui sont les responsables de ces systèmes
ESE avoir une Empreinte Sociale et Environnementale irresponsable
ESE-01 ne pas connaître ou ne pas se préoccuper du coût énergétique ou environnemental de l'élaboration et de l'utilisation d'un modèle, ou qu'il soit disproportionné par rapport à l'usage cible du modèle AlphaGo en kW vs. 20W pour un humain ; ML Impact Calculator
ESE-02 ne pas anticiper les impacts sociaux de l'élaboration ou de la mise en place d'un système automatique basé sur un modèle prédictif en amont pour la production de données annotées par exemple, en aval pour l'évolution des activités impactées
ESE-03 ne pas anticiper les effets négatifs/dangereux ou les usages malfaisants d'un modèle lors de la conception Implication analysis and release strategy of gpt2 by OpenAI
TR Transverse
TR-01 ne pas maîtriser les conséquences négatives de l'utilisation d'un modèle donné du fait du manque d'une "gouvernance globale" tout au long de la chaîne de valeur de bout-en-bout (données, conception, entraînement, validation, exploitation)
TR-02 ne pas maîtriser les conséquences de l'utilisation d'un modèle du fait du manque de connaissance de sa généalogie et de maîtrise de ses conditions nominales d'utilisation modèles qui deviennent des références et/ou fournis par des tiers
divers - à catégoriser
se faire "voler" un modèle par multiples inférences (model stealing)
se faire "voler" du temps de calcul par adversarial reprogramming
placement d'offres d'emploi sur les flux d'utilisateurs sélectionnés par un modèle prédictif : y a-t-il un sens à s'interroger sur un risque de discrimination, ou bien est-ce analogue à un chasseur de tête qui décide d'appeler les candidats qui l'intéressent de manière discrétionnaire ?