Quand on parle de responsabilité dans les systèmes d’IA, il y a une question qu’on devrait toujours se poser en premier. Si une décision automatisée produit un effet contestable… qui doit en répondre, concrètement ?
Et là, un point est non négociable : l’IA, en tant que telle, ne peut pas être responsable. Un algorithme ne se présente pas devant une autorité, ne justifie pas ses choix. Seuls des acteurs humains ou des organisations peuvent rendre des comptes sur la façon dont la décision finale a été produite.
Donc, si vous devez auditer un système d’IA, le bon réflexe, c’est de remonter toute la chaîne. Toute la chaîne, sans laisser de zone grise. On va le faire ensemble, étape par étape.
D’abord, la conception. C’est là que tout se joue au départ. On y définit le cas d’usage, les données qu’on va utiliser, l’architecture du système, les mécanismes de contrôle, et la documentation. En clair : qui a décidé quoi, sur quels éléments, avec quelles limites.
Et là, une question clé apparaît : si un problème surgit plus tard, est-ce qu’on est capable d’identifier précisément qui a fait ces choix… et sur quelles bases ils reposaient ? Si la réponse est floue, vous avez déjà un signal d’alerte.
Dans le cadre du règlement européen sur l’IA, cette responsabilité initiale repose d’abord sur le fournisseur. Mais attention, ce n’est pas toujours la même personne que le développeur d’origine. Si un acteur modifie substantiellement un système, ou le commercialise sous sa propre marque, il devient lui-même fournisseur. Autrement dit, la responsabilité ne s’arrête pas au premier maillon de la chaîne.
Ensuite, il y a une étape qu’on sous-estime souvent, alors qu’elle est décisive : le déploiement. C’est le moment où le système est intégré dans une organisation, dans un processus métier, dans une interface, parfois avec d’autres outils autour. Et là, surprise : un même système peut se comporter très différemment selon l’environnement dans lequel on le place.
Du point de vue de l’audit, on doit donc pouvoir répondre à plusieurs questions très concrètes. Qui décide de la manière dont le système est intégré ? Qui définit les usages autorisés, et ceux qui ne le sont pas ? Qui forme les utilisateurs ? Qui surveille le fonctionnement dans les conditions réelles, pas seulement sur le papier ? Dans ce cadre, le déployeur n’est pas un simple technicien. Il a des obligations propres.
Puis vient l’usage au quotidien. Une fois le système en service, ce sont des opérateurs humains qui s’appuient sur ses résultats dans des situations concrètes. Et là, il ne suffit pas de dire : “le système a recommandé”. Il faut savoir dans quelle mesure les opérateurs suivent cette recommandation, comment ils exercent leur propre contrôle, et comment ils réagissent en cas d’anomalie.
C’est un point de bascule. Utiliser un système ne veut pas dire lui transférer la responsabilité de la décision. Si on suit aveuglément la machine, la question devient : qui a toléré ça ? Qui a défini cette marge de manœuvre ?
Il y a aussi un niveau supérieur, souvent oublié : la décision de confier une décision à l’IA. Choisir d’automatiser quelque chose, ce n’est pas un geste neutre. Il faut pouvoir identifier qui a pris ce choix, dans quel domaine, avec quel niveau de risque, et avec quelles garanties pour les personnes concernées. Sans ça, la chaîne de responsabilité commence déjà sur du sable.
Vous le voyez : cette lecture par étapes est essentielle. Mais elle ne tient debout que si elle repose sur deux éléments très concrets : la transparence et la traçabilité. Sans documentation, sans registres, sans pistes d’audit, sans journalisation des décisions, comment vérifier qui a fait quoi, quand, et avec quels paramètres ? On ne peut pas. Et dans ce cas, l’attribution de responsabilité reste théorique. Corriger les erreurs devient aussi beaucoup plus difficile.
C’est pour cela qu’un mécanisme de contestation doit exister dès le départ. Si une décision automatisée est contestée, il faut qu’un recours soit possible, et que les responsabilités puissent être examinées à partir d’éléments vérifiables, pas seulement de déclarations d’intention.
Un dernier point, qui touche à la gouvernance. On peut présenter un système comme “aligné sur un code éthique”. Très bien. Mais si ce code a été défini par une poignée d’acteurs, la question ne s’arrête pas là. Il ne s’agit pas seulement de savoir si le système suit des principes. Il faut aussi se demander : qui a choisi ces principes ? Est-ce qu’ils ont été débattus collectivement ?
C’est exactement là que la chaîne de responsabilité rejoint une réflexion plus large sur la manière dont on gouverne l’IA. Et, pour vous, le réflexe à garder est simple : avant de déployer, identifiez qui peut être tenu responsable, à chaque maillon, et par quel mécanisme de contestation cette responsabilité peut être effectivement mise en jeu.
