[Algaudit] 3 - Evaluer une solution d’audit algorithmique

Rédigé par Félicien Vallet & Clément Henin

 - 

20 septembre 2022


Dans quelle mesure les outils d’audit sont-ils capables d’aider à mieux comprendre le choix d’un système algorithmique ? Après avoir présenté les « règles du jeu » dans l’article précédent, voici la description des conditions dans lesquelles a été menée l’expérimentation et les résultats obtenus. Ces derniers démontrent clairement l’intérêt de tels outils, mais exposent également certaines limites.

algaudit_3.jpg

Sommaire :

[Algaudit] 1 - Choisir une solution d’audit algorithmique

[Algaudit] 2 - Expérimenter une solution d’audit algorithmique

[Algaudit] 3 - Evaluer une solution d’audit algorithmique

Dans la peau d’un auditeur…

Comme présenté dans l’article [Algaudit] 2 - Expérimenter une solution d’audit algorithmique, l’expérimentation Algaudit repose sur la création d’une situation fictive s’approchant aussi près que possible d’un cas pouvant être rencontré dans le cadre d’un contrôle mené par la CNIL. L’idée a donc été d’offrir une expérience ludique (ou « gamifiée ») aux utilisateurs en leur proposant des mises en situation concrètes comme celles indiquées ci-après pour les deux outils testés IBEX et Algocate.

 

Mise en situation pour l’outil IBEX

 

À l’issue du contrôle sur place de la société « Mon prêt auto », vous devez finaliser l’analyse des pièces dont vous avez pris copie pour clore la procédure.

Concrètement, il s’agit de mener une investigation afin de vous assurer que le système satisfait bien la réglementation en matière de protection des données. Collecte illégale, discrimination, traitement non-autorisé de données sensibles, etc. Des pratiques illicites sont-elles mises en œuvre dans ce traitement de données et si oui, lesquelles ?

Pour cela, vous êtes invités à manipuler le système pour essayer d’en comprendre le fonctionnement. IBEX, un outil d’audit est également mis à votre disposition.

À l’issue de cette investigation, vous tirerez des conclusions sur le fonctionnement du système et ses éventuels manquements avant de proposer les suites à donner à ce contrôle.

L’outil Algocate suppose que l’utilisateur dispose de « normes », c’est-à-dire de règles explicites de fonctionnement du système d’IA. Dans le cas de l’expérimentation, trois normes sont proposées. Les deux premières sont basées sur une règle, alors que la troisième est basée sur un objectif. La base de données historique mentionnée dans la troisième norme est la base de données d’entraînement de l’arbre de décision dont la variable cible est l’événement de défaut de paiement (voir la description dans l’article [Algaudit] 2 - Expérimenter une solution d’audit algorithmique).

Mise en situation pour l’outil Algocate

 

Ici, vous vous intéressez à vérifier s’il y a adéquation entre le fonctionnement du système tel que présenté par les responsables de la société à l’occasion du contrôle et son comportement réel.

En reprenant le Procès-Verbal du contrôle, vous relevez cette déclaration du responsable technique de la société : « […] Avons pris connaissance par Charles X, responsable technique de la société Mon crédit auto, que l’algorithme d’aide à la décision pour l’octroi de crédit se base sur trois « normes » pour fonctionner :

- NORME 1 : Règle métier d'exclusion des demandes ayant été deux fois en défaut dans les 6 derniers mois. Afin de minimiser les risques de défauts et de surendettement, les demandes des personnes ayant été au moins deux fois en défaut de crédit dans les 6 derniers mois sont systématiquement refusées.

- NORME 2 : Règle métier pour l'acquisition de nouveaux clients. Afin de faciliter l'accès au marché de nouveaux clients, les personnes demandant un crédit pour la première fois sont acceptées quel que soit les caractéristiques de leur demande, à la seule condition que le prix du véhicule soit faible (<=55 000).

- NORME 3 : Objectif de minimisation des risques de défaut. Les risques de défaut de crédit doivent être minimisés. Une base historique de demandes de crédit est utilisée pour estimer les risques de défaut d'une nouvelle demande.

En cas de conflit, un système de hiérarchie permet de trancher. Ainsi, la norme 1 est prioritaire par rapport à la norme 2, elle-même prioritaire par rapport à la norme 3. […] »

A l’aide de l’outil Algocate, vous êtes invité à confronter ces assertions au fonctionnement en situation du système et à vérifier si ces règles sont correctement mises en application. Vous en tirerez ensuite des conclusions sur les suites à donner à ce contrôle.

L’expérimentation Algaudit a rassemblé 29 agents de la CNIL volontaires. Si tous étaient des experts du domaine de la protection des données, certains, comme les auditeurs des systèmes d’information, possédaient un important bagage technique. D’autres en revanche, comme des agents en charge de la mise en conformité des organismes, présentaient un profil juridique.

Par ailleurs, cette expérimentation, qui s’est déroulée entre le 27 mai et le 9 juin 2021, a dû s’accommoder du « contexte Covid ». Un site dédié a donc été mis en ligne afin que les volontaires puissent participer à distance. Concrètement plusieurs sessions en petits groupes ont été organisées afin de présenter l’expérimentation aux utilisateurs, de leur expliquer le fonctionnement des outils IBEX et Algocate et d’assurer un support en ligne pour les utilisateurs qui rencontraient des problèmes.

 

…et dans le respect du RGPD

La mise en œuvre de l’expérimentation Algaudit a impliqué un traitement de données personnelles, ce traitement devant bien évidemment satisfaire la réglementation en vigueur. Concrètement, il a donc été nécessaire de définir (entre autres) :

  • une finalité : la mise en place d’une expérimentation d’outils d’audit algorithmique (sous finalité : évaluation de l’intérêt et de l’appétence d’agents de la CNIL à l’utilisation d’outils d’audit algorithmique)
  • un responsable de traitement (en l’occurrence deux) : la CNIL et Inria
  • une base légale : l’exécution d’une mission d’intérêt public (article 6.1 (e))
  • les personnes concernées : 1) Les personnes ayant souscrit un crédit automobile et présentes dans le jeu de données utilisé et 2) les agents de la CNIL ayant pris part à l’expérimentation
  • les catégories de données traitées :  issues du jeu de données utilisé (prix du véhicule, pourcentage d'apport, âge, type d'emploi, nombre de crédits, etc.) et collectées auprès des utilisateurs (réponses aux questions et formulaires, interactions sur le site web (boutons cliqués, horodatage des actions, navigation, etc.) et optionnellement coordonnées (adresse mail) permettant de réaliser des entretiens)
  • une durée de conservation des données : la durée du projet augmentée de trois ans (à des fins de recherche et de communication)

L’expérimentation s’est déroulée sur la base du volontariat. Chaque utilisateur disposait par ailleurs d’un identifiant personnel lui permettant d’exercer ses droits s’il le souhaitait (accès ou opposition par exemple).

 

Evaluer, c’est décider

La constitution d’un protocole expérimental est un élément essentiel de la mise en œuvre de toute expérimentation scientifique. Une fois, les contours de l’expérimentation Algaudit dessinés (voir [Algaudit] 2 - Expérimenter une solution d’audit algorithmique), il a donc fallu déterminer comment pourrait être mesurés les éventuels apports pour les utilisateurs des solutions IBEX et Algocate. Pour ce faire, trois grandes dimensions ont été évaluées : 1) la pertinence des outils testés, 2) « l’opérationnalité » de ces outils dans un contexte professionnel et 3) la satisfaction des utilisateurs ayant pris part à l’expérimentation. Concrètement, une évaluation quantitative et qualitative a donc été menée.

Ainsi, pour l’évaluation de l’outil IBEX, après avoir présenté le cas d’usage et cinq décisions de l’algorithme audité aux participants, ceux-ci ont été répartis en deux groupes : un groupe test ayant accès à IBEX et un groupe témoin, de taille similaire, n’ayant accès qu’au système audité et étant en mesure d’interagir avec lui (en lui soumettant différents profils de demandeurs et en observant les réponses obtenues). Après s’être entrainé à manipuler les outils (IBEX ou algorithme seul) sur deux exemples, chaque utilisateur devait procéder à l’analyse de six décisions individuelles tirées au hasard dans le jeu de données d’entraînement. Pour chaque décision analysée, les utilisateurs devaient répondre à trois questions :

  • Quel a été le facteur déterminant de la décision (entrée à choix unique) ?
  • D’autres facteurs ont-ils influencé la décision (entrée à choix multiples) ?
  • Comment comprenez-vous la décision ? S’agit-il d’un cas limite ou d’un cas simple (texte libre) ?

Les interactions des utilisateurs avec les outils ont également été enregistrées. Cinq mesures quantitatives permettant d’évaluer l’utilité d’IBEX ont ensuite été proposées et comparées à celles obtenues par le groupe témoin :

  • Capacité à identifier le « facteur principal » de la décision
  • Capacité à identifier les autres facteurs de la décision
  • Capacité à expliquer la décision sous forme d’un texte libre
  • Capacité à distinguer les cas simples (correspondant à des cas pour lesquels les données d’entraînement contiennent de nombreux exemples concordants) des cas limite (pour lesquels les données d’entraînement ne sont pas unanimes).
  • Durée nécessaire pour réaliser une tâche

Pour l’outil Algocate, dont le test se déroulait consécutivement à celui d’IBEX, le choix a été fait de ne pas recourir à un groupe témoin. Là encore, deux exemples tirés au hasard ont permis aux utilisateurs de se familiariser avec l’outil. Six décisions individuelles, elles aussi tirées au hasard, devaient ensuite être analysées par les agents volontaires. Pour chaque décision analysée, les utilisateurs devaient répondre à trois questions :

  • La décision vous paraît-elle justifiée au regard des normes déclarées par la société contrôlée (oui ou non) ?
  • Indiquer le niveau de confiance de votre réponse (sur une échelle de 1 à 5).
  • Justifier votre choix (sous forme de texte libre).

Les normes considérées (et exposées plus haut) décrivent effectivement le fonctionnement de l’algorithme audité et décrit dans [Algaudit] 2 - Expérimenter une solution d’audit algorithmique. Par conséquent, afin d’introduire artificiellement des décisions « injustifiées », une décision sur deux est volontairement inversée par la plate-forme d’expérimentation. Ainsi, avec une probabilité 1/2, les données d’entrée correspondant à une demande acceptée par le système à auditer sont associées à une décision de refus, ou inversement. L’objectif était de mesurer la capacité des utilisateurs à détecter ces décisions volontairement rendues « injustifiées » à l’aide de l’outil Algocate.

Suite à l’expérimentation, cinq entretiens ont été réalisés avec des utilisateurs de profils différents : deux profils juridiques et trois profils techniques. Ceux-ci visaient à apporter des éléments de compréhension plus fins relativement à l’expérience des utilisateurs et à l’interface d’expérimentation qui leur avait été proposée. Une analyse qualitative de ces entretiens a ensuite été menée.

 

Résultats obtenus pour l’outil d’explication IBEX

D’un point de vue qualitatif, les participants à l’étude ont jugé le contenu des explications globalement compréhensible et utile. Tous les participants qui ont eu accès à IBEX, sauf deux n’ayant pas répondu, ont déclaré que l’outil pourrait être utile pour un audit d’algorithme. L’interaction avec les trois grandes dimensions d’explication proposées : forme, simplicité et réalisme (voir la description dans [Algaudit] 2 - Expérimenter une solution d’audit algorithmique) a été jugée simple et intuitive, même si la manière d’utiliser le réalisme de l’explication pour répondre aux questions a suscité des interrogations de la part de certains utilisateurs. Les participants ont apprécié la possibilité de changer la forme de l’explication afin d’avoir différents « angles d’approche » sur le système et pour confirmer les informations comprises avec les autres formes.

D’un point de vue quantitatif, sur les cinq critères évalués (et présentés dans la section précédente), IBEX s’avère plus performant que l’utilisation du seul système audité (groupe témoin). Cette différence est significative pour trois critères (voir Figure 1). En particulier, IBEX permet efficacement de détecter le facteur principal dans 81 % des décisions soumises (contre 66 % pour le groupe témoin) et permet d’identifier en moyenne 1,83 autres facteurs (contre 1,39 pour le groupe témoin). Ces résultats sont encourageants et valident l’utilité pratique d’IBEX et plus généralement de la démarche en boîte noire.

De plus, il a été possible de comparer la détection de la règle discriminante introduite (refus systématique des dossiers des demandeurs âgés de plus de 60 ans) entre le groupe test et le groupe témoin. Seul 1 participant sur 14 du groupe IBEX n’a pas mentionné le caractère discriminant de l’algorithme contre 3 sur 15 dans le groupe témoin.

comparaison_resultats_ibex.png

Figure 1. Comparaison des résultats obtenus avec IBEX et avec le groupe témoin. Le symbole ** indique une différence significative (p-valeur < 0.05).

Les résultats décomposés selon les dimensions explicatives montrent que concernant la forme, les explications en diagrammes semblent globalement préférées par les utilisateurs, même si les autres formes sont également largement consultées. D’après les informations recueillies lors des entretiens, les explications en diagrammes sont plus appréciées par les personnes ayant peu ou aucun bagage technique. Il est intéressant de noter que les explications par règles sont significativement plus efficaces que les autres formes dans la détection du facteur principal de la décision auditée. En contrepartie, elles conduisent à des durées d’exécution de la tâche significativement plus longues. Cette forme d’explication semble avoir été préférée par les profils techniques.

Concernant, la dimension relative à la simplicité, conformément à l’intuition, les explications les moins simples conduisent à des meilleurs résultats, puisque les informations fournies sont plus complètes et exactes, en contrepartie les durées d’exécution ont été rallongées car le temps d’absorber les informations est plus long. Toutefois, l’écart avec les autres explications n’est pas significatif.

 

Résultats obtenus pour l’outil de justification Algocate

Les retours qualitatifs obtenus sur l’outil Algocate offrent un regard contrasté. En premier lieu, l’immense majorité des utilisateurs a pu intégrer rapidement les notions de normes, de contestation et de justification. Une partie d’entre eux estime par ailleurs que l’utilisation de normes dans le cadre de contrôle ou d’audit algorithmique pourrait être éclairante puisqu’elle permettrait de confronter directement le responsable de traitement avec ses déclarations. Toutefois, les utilisateurs ont globalement trouvé l’outil complexe à utiliser (notamment en comparaison d’IBEX) et ont souligné qu’en l’état, il n’était pas adapté aux contrôles et audits car les responsables de traitement dont les systèmes d’IA seraient audités n’explicitent généralement pas les normes de la manière dont l’exige Algocate. Globalement, l’outil a davantage été perçu comme un outil à destination des clients ou des utilisateurs finaux qu’à des auditeurs professionnels.

Concernant la prise en main de l’outil, une partie des utilisateurs a déclaré avoir eu des difficultés à comprendre l’interface d’affirmations. C’est en particulier le nombre de champs pouvant être remplis et l’utilisation des symboles (≥ et ≤) qui semblent avoir gêné certains participants. En revanche, tous ont compris et globalement apprécié la forme des justifications fournies et particulièrement l’usage des statistiques qui rendent l’argument compréhensible et neutre.

Enfin, les normes elles-mêmes ont été globalement bien comprises. C’est la norme sous forme d’objectif (qui se base sur l’historique des demandes de crédits passées) qui a soulevé le plus d’interrogation de la part des participants. Elle a été qualifiée de norme « floue » dans le sens où elle peut être utilisée à la fois pour soutenir et pour contester une même décision en fonction de l’affirmation choisie. Toutefois, ces retours apparaissent cohérents puisqu’ils correspondent à une réalité dans laquelle certains sous-ensembles du jeu de données soutiennent un refus alors que d’autres soutiennent une acceptation pour une même décision.

comparasion_resultats_algocate.png

Tableau 1. Résultats obtenus avec et sans l’outil Algocate. La confiance autodéclarée moyenne sur une échelle de Likert entre 1 et 5 est indiquée entre parenthèse.

Plusieurs critères quantitatifs ont également pu être extraits. Au total, 165 tâches ont été réalisées et Algocate a été utilisé par les participants en moyenne 1,3 fois par tâche à réaliser. L’utilisation n’est toutefois pas uniforme puisque 56 tâches ont été faites sans Algocate. Globalement, les utilisateurs ont été capables de détecter les décisions injustifiées pour 65 % des tâches. Le Tableau 1 décompose les résultats en fonction de l’utilisation ou non de l’outil Algocate. On voit que les participants qui ont utilisé Algocate ont obtenu de meilleurs résultats (67 % contre 61 %), toutefois la différence n’est pas significative. La confiance autodéclarée (sur une échelle de Likert allant de 1 à 5) nous indique qu’Algocate améliore globalement la confiance des participants, notamment lorsque ces derniers ont obtenu la bonne réponse.

 

En guise de conclusion

Comme indiqué précédemment, les outils IBEX et Algocate ont tous deux été appréciés par les utilisateurs même si des avantages et inconvénients propres à chacun ont pu être remontés. Le choix de s’appuyer sur des méthodes globales (voir [Algaudit] 1 - Choisir une solution d’audit algorithmique) a également été questionné. Ainsi, une explication sur le fonctionnement générique du système est apparue plus adaptée aux utilisateurs que des analyses locales, quand bien même une inférence du comportement global du système était réalisée. Certains des participants modéraient toutefois cet aspect en mettant en garde sur d’éventuelles difficultés à convaincre une autorité en charge de statuer sur la présence de manquements (tel qu’un juge, une commission, etc.) à l’aide d’un argument purement statistique. Par ailleurs, les participants à l’expérimentation ont relevé un point qui était apparu délicat dès la conception de l’expérimentation : celui de disposer d’outils permettant d’établir des constats directement opérationnalisables dans le cadre de la réglementation en matière de protection des données. A titre d’exemple, si un outil permettait d’assurer que le système audité n’utilise jamais une donnée particulière, la CNIL pourrait immédiatement constater un manquement au principe de minimisation de la collecte des données.

Au global, l’expérimentation Algaudit peut être considérée comme un succès. En effet, en plus d’avoir permis à Clément Henin* de réaliser un test des outils développés dans le cadre de sa thèse, elle a validé l’hypothèse selon laquelle des outils d’explication et/ou de justification opérationnels pouvaient être conçus et utilisés par des auditeurs professionnels de la CNIL. Elle a par ailleurs permis à la CNIL, à travers la trentaine d’agents volontaires, de se confronter de façon « pratico-pratique » à la possibilité d’intégrer des outils d’audit dans une utilisation professionnelle. Une perspective qui semble inéluctable à la lueur de la règlementation européenne à venir sur l’IA…

Les auteurs remercient Daniel Le Métayer (Inria Privatics), Laurent Dupont et Richard Diani (Pôle Fintech-innovation de l’ACPR), tous les personnels de la CNIL et d’Inria impliquées dans la mise en œuvre de l’expérimentation Algaudit ainsi que bien sûr les 29 agents ayant accepté d’y prendre part !

 

*Clément Henin est conseiller référendaire en service extraordinaire à la Cour des comptes et auteur d’une thèse d’informatique portant sur les explications et les justifications des systèmes de décisions algorithmiques parue en 2021.

Félicien Vallet est adjoint au chef du service de l’expertise technologique.



Article rédigé par Félicien Vallet & Clément Henin