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

Etape 1 : identifier un jeu de données pertinent.

Tout d’abord, un jeu de données permettant la mise en œuvre de l’expérimentation a dû être sélectionné. Pour ce faire, différents jeux de données librement accessibles ont été envisagés. Après des échanges avec des agents de l'Autorité de contrôle prudentiel et de résolution (ACPR) travaillant également sur les enjeux d’explicabilité, le choix s’est porté sur le jeu de données Vehicle Loan Default Prediction fourni par la société L&T dans le cadre d’un hackathon et disponible sur la plateforme Kaggle. Celui-ci présentait en effet des caractéristiques intéressantes comme illustré dans le Tableau 1 : 112 000 enregistrements avec, en plus de l’indication de l’obtention ou refus du prêt, de nombreux descripteurs relatifs au véhicule et au prêt (prix, montant de l’emprunt demandé, nombre de mensualités, etc.) à l’historique de crédit de l’emprunteur (nombre de crédits contractés, en défaut, etc.), à sa socio-démographie (âge, type d’emploi, preuve de l’identité, etc.). Toutefois, ces descripteurs ne donnent qu’une vision partielle de la situation de l’emprunteur puisqu’aucune variable relative au salaire n’est disponible dans le jeu de données. Par ailleurs, l’utilisation de ces données collectées dans un contexte différents de celui envisagé pour l’expérimentation nécessite un ajustement de la part des utilisateurs (les montants ne sont par exemple pas exprimés en euros mais en roupie indienne). A noter que l’utilisation de jeu de données librement accessible n’exonère pas de s’assurer que les droits des personnes concernées sont bien respectés (voir l’article [Algaudit] 3 - Evaluer une solution d’audit algorithmique).

Tableau 1. Présentation des variables du jeu de données utilisé pour l’expérimentation Algaudit.

Etape 2 : construire un algorithme à auditer

Il a ensuite fallu créer un algorithme à analyser avec les solutions d’audit sélectionnées. Si un système d’IA utilisant des méthodes d’apprentissage automatique (machine learning) complexe aurait très bien pu être retenu (par exemple un réseau de neurones profond), le choix s’est plutôt porté sur un système facile à interpréter et cela pour des raisons scientifiques.  En effet, à ce stade l’expérimentation il était indispensable de pouvoir s’assurer que les explications fournies par les outils IBEX et Algocate correspondaient effectivement au fonctionnement du système audité. Cette tâche aurait été beaucoup plus délicate dans le cas d’un système utilisant une méthode complexe d’apprentissage automatique et les conclusions de l’expérimentation auraient donc été plus incertaines. Par conséquent, le choix a été fait d’utiliser un arbre de décision (decision tree) pour modéliser la décision d’octroi/refus du prêt à la consommation sur la base des données présentées plus haut (voir Figure 1).

Figure 1. Représentation visuelle de l’arbre de décision implémenté.

Par ailleurs, la question s’est posée de savoir comment modéliser une utilisation de cet algorithme qui présente des manquements au RGPD pouvant être caractérisées par des contrôleurs et susceptibles de donner lieu à d’hypothétiques sanctions de la part du régulateur. Plusieurs pistes ont ainsi été explorées : utilisation non-autorisée de variables sensibles au sens de l’article 9 du RGPD, non-respect du principe de minimisation, présence de discrimination, etc. Toutefois, « coder en dur » de tels manquements ne s’est pas avéré évident dans tous les cas et des choix ont dû être faits. En pratique, trois règles « spéciales » furent ainsi ajoutées pour modifier le comportement de l’arbre de décision à auditer (cet arbre ayant été préalablement entrainé sur les données historiques du jeu présenté plus haut) :

• Règle 1 : tous les dossiers dont le demandeur est âgé de plus de 60 ans sont systématiquement refusés (règle volontairement discriminatoire),
• Règle 2 : les demandes ayant eu plus de deux crédits ayant fait l’objet de défaut de remboursement dans les 6 derniers mois sont systématiquement refusées,
• Règle 3 : les premiers crédits (aucun crédit en cours) pour les faibles montants (avec un seuil fixé) sont systématiquement acceptés.

Ces règles de fonctionnement de l’algorithme n’étaient bien évidemment pas connues des agents prenant part à l’expérimentation.

IBEX : un outil pour expliquer les décisions de l’algorithme

Une fois le jeu de données utilisé pour l’expérimentation identifié et l’algorithme d’estimation de la probabilité de défaut de crédit mis en place, s’est posée la question des explications à produire pour les utilisateurs prenant part à l’expérimentation afin de leur permettre de comprendre et évaluer l’algorithme. Cette question relative à la transparence et aux informations à fournir à un utilisateur, qu’il soit profane ou expert, est centrale dans le cas des systèmes d’audit. Afin d’évaluer la pertinence des outils proposés, différentes formes d’explication ont ainsi été proposées et leur pertinence a fait l’objet d’une évaluation.

• 3 formes d’explication ont été testées

Dans le cadre de l’expérimentation, IBEX proposait aux utilisateurs trois types d’explications de formes différentes :

1) Explication en diagrammes, montrant l’importance relative de diverses variables

Les explications en diagrammes donnent une représentation graphique de la pondération des différentes variables appliquée au cas de la décision individuelle étudiée par rapport au cas général. La pondération est calculée en comparaison de décisions similaires. Ainsi, par exemple, si les personnes jeunes voient leurs demandes plus facilement acceptées, l'âge aura un impact positif sur la décision si l'intéressé a un âge plus faible que celui des demandeurs des autres dossiers. L’importance de cette variable sera modélisée par un histogramme vert. Les impacts négatifs sont identifiés par la couleur orange et orientés en sens inverse.

Figure 2. Exemple d’explication en diagramme montrant les variables ayant joué favorablement dans la décision d’octroi de crédit.

2) Explication sous la forme de règles de décision

Une explication sous forme de règles donne une représentation du comportement de l’algorithme au voisinage de la situation de l’intéressé, c’est-à-dire par l’analyse de dossiers proches de celui du demandeur. Cette explication permet de fournir à l’évaluateur une règle associée à un pourcentage de réalisation. Il s’agit en pratique de quelques critères qu’il faut respecter afin d’obtenir la même décision que l’intéressé.

Figure 3. Exemple d’explication par règle qui précise les critères principaux ayant, dans ce cas précis, motivé le refus du crédit.

3) Explication par la présentation d’un contrefactuel

Introduites par (Wachter et al., 2018), les explications contrefactuelles font intervenir des éléments de causalité en mettant en exergue comment la variation d’une variable modifie la décision de l’algorithme. En pratique, si l’explication concerne une entrée spécifique x, un exemple contrefactuel sera l’entrée x’ la plus proche de x et pour laquelle le système fournira un résultat différent ( f (x) ≠ f (x’) ). Ce type d’explication est présenté comme particulièrement utile pour contester une décision algorithmique.

Figure 4. Exemple d’explication contrefactuelle (avec « focus algorithme »).

Par ailleurs, derrière ces critères de formes d’explications, se cachent d’autres choix de conception qui détermineront les explications qui seront fournies à un utilisateur dans le cadre d’un audit de système d’IA. Il était ainsi également proposé aux utilisateurs de jouer sur deux autres paramètres :

• Simplicité
  Selon le niveau d'expertise de l'utilisateur ou son objectif, le niveau de détail attendu de l'explication peut être ajusté. IBEX propose deux niveaux : « Plus simple » ou « Plus complète ». Une explication plus simple est plus rapide à analyser, mais contient moins d'information qu'une explication plus complète. Par exemple, une explication simple sous forme de règles ne contiendra qu’une ou deux règles, alors qu’une explication plus complète pourra en contenir trois ou quatre. La contrepartie de la simplicité d’une explication est bien sûr la précision et l’exactitude de cette dernière. En proposant plus de détails, une explication complète s’approche plus de la vérité qu’une explication simple qui se focalise sur les facteurs principaux.
• Réalisme
  Un dernier critère peut également être proposé aux utilisateurs, celui du réalisme. Concrètement, il s’agit de choisir si seules les variables réellement utilisées par le système sont présentées à l’utilisateur ou si sont également considérées les variables qui leur sont corrélées. On parle ainsi dans l’expérimentation de « focus algorithme » dans le premier cas et de « focus utilisation » dans le second. Les figures 4 et 5 permettent de voir les deux types d’explications produites dans le cadre de l’utilisation de contrefactuelles.

Figure 5. Exemple d’explication contrefactuelle avec « focus utilisation ».

Cette distinction « algorithme / utilisation » peut s’avérer intéressante pour apprécier certains comportements.  Ainsi, on peut imaginer qu'une explication « focus algorithme » indique que la variable Pourcentage d'apport a de l'importance, mais que la variable Prix du véhicule en a peu. Cela peut sembler surprenant car on peut s'attendre à ce que les véhicules chers conduisent globalement à des pourcentages d'apport plus faibles et qu'ainsi les deux informations aient des importances similaires. Pour résoudre cette apparente contradiction, il peut être intéressant de consulter une explication « focus utilisation ». Si elle indique que la variable Prix du véhicule est également importante, alors le prix est vraisemblablement pris en compte par l'intermédiaire du Pourcentage d'apport. Ainsi, dans cet exemple, bien que le prix du véhicule n’apparaisse pas explicitement comme une variable déterminante pour le système audité, les véhicules chers sont tout de même pénalisés car ils conduisent à des pourcentages d'apport plus faibles.

Par conséquent, dans le cadre d'un audit, l'option « focus algorithme » devrait être l'option par défaut car elle donne des informations sur la logique du système. L'option « focus utilisation » peut toutefois se révéler utile pour un observateur humain afin de comprendre les implications de la logique appliquée par le système.

Algocate : un outil pour justifier les décisions de l’algorithme

Le système de justifications d’algorithme Algocate (concatenation de algorithm et advocate) fonctionne selon un système d'affirmation. Pour obtenir une justification, il faut d'abord que soit défendue une décision, la « décision attendue ». Il peut par exemple s’agir de vouloir contester une décision prise par un système d’IA. Un utilisateur doit donc en pratique donner les raisons qui lui laissent penser que la décision fournie par le système est mauvaise en s’appuyant sur les éléments du dossier. Par exemple, une personne dont la demande aurait été refusée pourrait objecter de la manière suivante : « Je pense que ma demande devrait être acceptée car c'est ma première demande de crédit (Nb crédits <= 0) et qu'il s'agit d'un montant faible (Prix du véhicule <= 55 000) ». La Figure 6 montre la forme que prend cette affirmation sur l'interface d'Algocate.

Figure 6. Exemple d’utilisation de l’interface Algocate pour configurer une décision à tester.

Une fois l’affirmation (dans notre exemple la contestation) formalisée, celle-ci est analysée par Algocate au regard des normes affichées par la société. Ces normes, qui sont décrites plus précisément dans l’article ([Algaudit] 3 - Evaluer une solution d’audit algorithmique), peuvent être de nature juridique, si une décision enfreint les règles anti-discrimination par exemple, mais d’autres type de normes sont également envisageables, tels que la décision d’octroi de crédit à toutes les personnes présentant certaines caractéristiques (une première demande par exemple). Dans l’exemple donné plus haut, la justification de la Figure 7 est proposée à l’utilisateur :

Figure 7. Premier exemple de justification produite par Algocate.

Le premier paragraphe synthétise l'affirmation. Dans le paragraphe suivant, une norme est invoquée pour contester la décision. En l’occurrence, c’est la norme 2, qui spécifie que les premiers crédits pour les faibles montants doivent être systématiquement acceptés qui est mise en avant et justifie que la demande soit acceptée. On notera qu’Algocate peut produire en fonction des cas des justifications plus détaillées comme montré à la Figure 8.

Figure 8. Second exemple de justification produite par Algocate.

Le troisième et dernier article de cette série, [Algaudit] 3 - Evaluer une solution d’audit algorithmique, donnera l’occasion de décrire les conditions d’expérimentation et de discuter des résultats obtenus.

*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.

Illustration - Fabio Secchia (Flickr)