Leçon 5 — La responsabilité
« C'est l'algorithme » n'est pas une réponse
Quand un système automatisé cause un préjudice, une phrase revient : « c'est l'algorithme qui a décidé ». Elle ne tient ni juridiquement, ni pratiquement, ni moralement.
Juridiquement, la responsabilité suit l'organisation qui déploie le système. Un modèle n'a pas de personnalité juridique, ne peut pas être partie à un litige et ne détient aucun patrimoine. Celui qui agit sur la sortie du modèle en répond.
Pratiquement, chaque décision du système résulte de choix humains : la cible prédite, les données retenues, la métrique optimisée, le seuil fixé, la décision de déployer. Le modèle n'est que l'exécution de ces choix.
Moralement, invoquer l'algorithme revient à revendiquer les bénéfices de l'automatisation sans en assumer les conséquences.
Le problème des mains multiples
La difficulté réelle n'est pas de savoir qu'il y a une responsabilité, mais de l'attribuer quand beaucoup d'acteurs ont contribué.
Une décision automatisée mobilise typiquement : le fournisseur du modèle de base, l'équipe qui l'a affiné, celle qui a constitué les données, celle qui l'a intégré, celle qui l'exploite, le métier qui l'a commandé, et l'opérateur qui applique la décision.
Chacun peut affirmer sincèrement n'avoir fait que sa part. C'est le problème des mains multiples : une responsabilité collective diffuse qui n'oblige personne en particulier.
Chaque système d'IA en production a un propriétaire nommé — une personne, pas une équipe, pas un comité.
Ce propriétaire n'a pas à tout maîtriser techniquement. Il doit répondre à trois questions : que fait ce système, comment sait-on qu'il fonctionne encore correctement, et que se passe-t-il si quelqu'un le conteste ?
Un système sans propriétaire nommé est un système dont personne ne surveille la dérive et que personne n'arrêtera à temps.
Les cinq éléments d'une gouvernance qui tient
Pas un cadre théorique : cinq dispositifs qui produisent des effets observables.
1. Un inventaire des systèmes
Vous ne pouvez pas gouverner ce que vous ne recensez pas. Beaucoup d'organisations ignorent combien de modèles tournent réellement chez elles, parce que des systèmes ont été déployés dans des équipes sans référencement central.
L'inventaire minimal, par système : ce qu'il fait, qui en est propriétaire, quelles données il utilise, quelles décisions il influence, son niveau de risque, sa date de dernière évaluation.
2. Une fiche de modèle
Un document court accompagnant chaque modèle : son usage prévu, ses usages exclus, les données d'entraînement et leur période, les performances par groupe, les limites connues, et la date de la dernière évaluation.
La partie la plus utile est celle des usages exclus. Beaucoup d'incidents proviennent d'un modèle réutilisé pour une tâche voisine pour laquelle il n'a jamais été évalué — un modèle de tri de courriels employé pour évaluer des candidatures.
3. Une décision de déploiement documentée
Le déploiement d'un système à enjeu se décide explicitement, et cette décision se trace : qui a décidé, sur la base de quels résultats, avec quelles réserves, et à quelle échéance de réexamen.
Ce document est ce qui distingue une organisation qui a examiné la question d'une organisation qui l'a laissée arriver.
4. Une surveillance avec seuils d'alerte
Un engagement éthique pris au moment du déploiement ne vaut rien s'il n'est pas vérifié ensuite. Un modèle équitable au lancement peut le devenir moins à mesure que les données changent — c'est la dérive décrite dans la leçon MLOps sur la surveillance.
Ce qu'il faut suivre : les performances par groupe, pas seulement globales ; les taux de décision par groupe ; le volume de contestations et leur issue ; les cas remontés par les opérateurs.
5. Une voie de recours accessible
C'est l'élément le plus souvent absent, et le plus important pour les personnes concernées.
Une voie de recours réelle suppose que la personne sache qu'une décision automatisée la concerne, qu'elle puisse demander un réexamen sans obstacle disproportionné, que ce réexamen soit fait par une personne habilitée à changer la décision, et que le résultat soit suivi — un taux d'infirmation élevé est le signal le plus fiable d'un problème de modèle.
Ce qu'exige une supervision humaine réelle
Comme signalé en leçon 1 avec le biais d'automatisation, un humain placé dans la boucle n'est pas automatiquement un garde-fou. Quatre conditions sont nécessaires.
Du temps. Un opérateur qui doit traiter deux cents dossiers par jour approuvera les recommandations. La supervision demande un temps compatible avec un examen réel.
De l'information. Il faut voir sur quoi la recommandation s'appuie, et connaître le taux d'erreur du modèle sur des cas comparables.
De l'autorité. Il faut pouvoir contredire le système sans avoir à se justifier plus qu'en l'approuvant. Si l'écart demande une note explicative et l'accord non, l'asymétrie décide à la place de l'opérateur.
Une mesure. Suivez le taux de désaccord. S'il est proche de zéro, la supervision est fictive : soit le modèle est parfait, soit personne ne regarde. La seconde hypothèse est de loin la plus probable.
Les questions à poser avant de déployer
Onze questions. Si trois restent sans réponse, le système n'est pas prêt.
- Quelle décision ce système influence-t-il, et avec quel effet sur les personnes ?
- Que prédisons-nous exactement, et est-ce bien ce qui nous intéresse ?
- D'où viennent les données, et quelle population représentent-elles ?
- Quelles sont les performances par groupe, et non seulement en moyenne ?
- Quelle définition de l'équité avons-nous retenue, et pourquoi ?
- Que se passe-t-il en cas d'erreur, et qui en supporte le coût ?
- La personne concernée sait-elle qu'une décision automatisée la concerne ?
- Peut-elle obtenir une explication qu'elle comprend, et contester ?
- Qui est le propriétaire nommé de ce système ?
- Comment saurons-nous que le modèle s'est dégradé ?
- Comment l'arrêter rapidement, et qui a l'autorité pour le faire ?
À retenir
- « C'est l'algorithme » ne tient ni juridiquement, ni pratiquement, ni moralement : la responsabilité suit l'organisation qui déploie.
- Le problème des mains multiples dilue la responsabilité ; la réponse est organisationnelle : un propriétaire nommé par système.
- Cinq dispositifs : inventaire, fiche de modèle, décision de déploiement documentée, surveillance par groupe, voie de recours.
- La partie la plus utile d'une fiche de modèle est la liste des usages exclus.
- Une supervision humaine réelle exige temps, information, autorité et une mesure du taux de désaccord.
- Le taux d'infirmation des recours est le signal le plus fiable d'un problème de modèle.
Leçon suivante — Récapitulatif, glossaire et FAQ →