En informatique, un simple code d’éthique ne permet pas d’éviter les mauvaises conduites
Éthique et toc ?

User/Chimera – Clarote & AI4Media – Better Images of AI
L'utilisation non éthique de l'informatique par des entreprises fait régulièrement scandale. Donner un code d'éthique aux ingénieurs peut sembler une première solution pour éviter ce genre de problèmes. Des chercheurs ont constaté que, seul, un code de ce genre n'a pas de réelle influence sur leur comportement.
Le 14 mai à 11h11
5 min
Droit
Droit
La manipulation par Volkswagen des données d'émissions dans ce qu'on a appelé le DieselGate, l'utilisation non éthique par Facebook en 2014 des informations sur les émotions de ses utilisateurs, le scandale Cambridge Analytica et les autres utilisations des réseaux sociaux pour manipuler des élections... Ces dernières années, on ne manque pas d'exemples de logiciels développés, modifiés ou paramétrés dans le but de tromper les autorités ou les utilisateurs.
Comme dans d'autres secteurs comme la biologie, la médecine ou le droit avant elle, l'informatique a vu éclore des « codes d'éthique » et la volonté de faire émerger la réflexion sur les bonnes et mauvaises pratiques dans la discipline. Mais cette approche est-elle efficace ?
Des chercheurs brésiliens et allemands ont essayé de répondre à cette question. Dans une étude repérée par le chercheur Irénée Régnauld sur son blog, ils ont comparé les réponses de 225 étudiants et de professionnels de l'IT répartis dans deux groupes à propos de questions éthiques. À l'un des deux, on a présenté une vidéo présentant un code de déontologie, à l'autre aucune information supplémentaire à leurs connaissances ne leur était fournie.
Cette vidéo, de 9 minutes environ, résume tout le code d'éthique et de conduite professionnelle proposé par l'association internationale de professionnels de l'informatique ACM (Association for Computing Machinery). Celui-ci existe depuis 1972 et a été mis à jour en 2018. C'est « l'un des codes de conduite les plus connus destinés aux professionnels des technologies de l'information et de l'informatique », selon les auteurs de l'étude.
16 dilemmes éthiques et des questions morales
Leur questionnaire comporte 16 dilemmes éthiques très spécifiques à l'univers du numérique. Par exemple, les chercheurs posent la situation suivante :
« Vous faites partie d'une équipe chargée de maintenir un logiciel critique pour le système financier d'un client. Au cours des tests, vous découvrez un bug critique présent depuis longtemps. Vous le corrigez, mais votre responsable ne souhaite pas en informer le client, de peur qu'il ne mette en doute la compétence de votre entreprise ». Et ils demandent ensuite « qu'est-ce que vous faites ? »
Ou encore :
« Vous avez développé un programme de mouvement s'appuyant sur une IA pour un robot industriel qui transporte des matériaux lourds. Après deux mois de test, aucune anomalie n'a été identifiée. Un mois après l'opération de test (maintenant en production), le robot renverse une employée enceinte, ce qui entraîne son décès. Le rapport technique fait état de problèmes liés au programme d'étalonnage des capteurs du robot. Ce mauvais étalonnage trouve son origine dans le code source et les données utilisées lors des essais ». Les chercheurs demandent ensuite à la personne si elle assume ou pas la responsabilité ou si elle est indécise.
Cette série de dilemmes est accompagnée de deux questions d'auto-évaluation sur les connaissances et l'importance de l'éthique dans la pratique et de 10 questions morales plus générale en auto-évaluation. Le questionnaire est disponible intégralement sur GitHub.
Aucune différence
Leur étude ne voit aucune différence significative de résultats entre les deux groupes testés, suggérant qu'une simple exposition à des informations sur un code d'éthique ne permet pas de changer les comportements ni leur perception du sujet. La plupart des participants affirment d'ailleurs avoir déjà été plus ou moins formés sur ces sujets lors de leurs études. Ils sont aussi plus de 90 % des participants à considérer que ce genre de codes d'éthiques sont importants dans les pratiques de leur domaine.
« Les stratégies de management visant à promouvoir un comportement éthique par l'utilisation passive d'un code de bonne conduite peuvent s'avérer inefficaces pour atteindre le résultat escompté », concluent les chercheurs, même s'ils conviennent aussi que la rapidité de leur vidéo de 9 minutes peut avoir influencé leurs résultats.
Dans son billet, Irénée Régnauld ajoute que « le simple fait de spéculer un comportement réel depuis un questionnaire peut s’interroger. D’autre part, en situation réelle, les décisions se prennent rarement seuls : les travailleurs discutent entre eux, s’influencent, etc. Individualiser une décision éthique revient à faire peser la responsabilité sur une seule personne, ce qui est évidemment problématique – à moins d’entrer dans un cadre spécifique qui serait celui du lancement d’alerte, et qui pose d’autres questions ».
En informatique, un simple code d’éthique ne permet pas d’éviter les mauvaises conduites
-
16 dilemmes éthiques et des questions morales
-
Aucune différence
Commentaires (16)
Abonnez-vous pour prendre part au débat
Déjà abonné ? Se connecter
Cet article est en accès libre, mais il est le fruit du travail d'une rédaction qui ne travaille que pour ses lecteurs, sur un média sans pub et sans tracker. Soutenez le journalisme tech de qualité en vous abonnant.
Accédez en illimité aux articles
Profitez d’un média expert et unique
Intégrez la communauté et prenez part aux débats
Partagez des articles premium à vos contacts
Abonnez-vousLe 14/05/2025 à 11h42
Pour moi, le message passe bien mieux à l'écrit que dans une vidéo.
Leurs questions sont effectivement très loin de la réalité du terrain : La seule réponse possible est : j'obéis à la décision de la hiérarchie, la démission est aussi une option mais un peu extrême ici. On peut éventuellement passer par dessus son responsable si c'est lui seul qui a pris la décision et qu'on pense que la direction aura une position différente, mais si c'est bien une décision de la direction, à chacun son domaine de responsabilité. La responsabilité du technicien est de bien donner toutes les informations sur les conséquences du bug, en particulier sur ce qui peut s'être passé avant qu'il soit découvert. On n'est pas ici dans un cas de lanceur d'alerte.
Et dans le cas de la femme enceinte, la responsabilité civile ou pénale est celle de l'entreprise, pas d'un individu dans une chaîne. Et que vient faire le fait que la femme était enceinte ?
Le 14/05/2025 à 13h47
Pour le bug du logiciel critique : on le mentionne dans les rapports de bug (je doute qu'il n'y en ait pas). Toute modification peut entrainer un impact positif ou négatif, donc obliger de l'indiquer quelque part. Quand à informer le client, c'est la personne qui échange avec le client concernant les modifications du logiciel qui s'en charge. C'est à lui de le faire.
Pour la femme enceinte, le fait qu'elle soit enceinte et juste là pour influencer sur la réponse de l'individu au questionnaire : 2 morts pour le pris de 1
Le 14/05/2025 à 13h53
Sinon, le fond reste intéressant, je vais aller jeter un oeil au questionnaire, le premier dilemme relayé dans l'article c'est limite mon autobiographie 😅
Le 14/05/2025 à 13h58
Ma réponse ne passe pas dans les cases : clairement, pour un logiciel critique qui peut tuer des humains, jamais je n'aurais fait un truc qui utilise une IA impossible à certifier.
Le 14/05/2025 à 14h14
Mais quid si c'est dans un an, deux ans, dix ans ? Et qu'entre temps t'en a déployé 100, 1 000 ou 1 000 000 qui tournent sans aucun incident ?
Après, je trouve que c'est la question la plus facile du lot, puisque ça te touche assez directement (il y a eu un mort, c'est ton code source...). Il y en a beaucoup d'autres où ça manque de détails pour trancher sur une décision en pleine conscience.
Dans la vie réelle je pense de toute façon qu'il y a pleiiiiin de trucs que "le gars de l'IT" peut remonter à sa hiérarchie pour satisfaire son éthique, mais qui seront enterrés par un interlocuteur de la chaîne de décision avant d'arriver vers le client. A moins d'être vraiment sur un sujet grave et de décider de devenir lanceur d'alerte, le point restera sous silence.
Le 14/05/2025 à 14h43
Si les données ne comprenaient pas de femme enceinte, le robot ne sait pas gérer/ne reconnait pas.
D'où le terme intelligence galvaudé. C'est juste un algo plein de if/then incompréhensibles/auditables.
Et si le cas n'est pas le cahier des charges, on ne gère pas pour des raisons de coûts.
Le 15/05/2025 à 17h29
Il y a un gros décalage en termes de perception, on est complètement intolérant aux erreurs de ces systèmes alors qu'on en fait en permanence... OK, ça pose des vrais sujets d'éthique et de responsabilité, mais faut-il vraiment chercher le risque 0 de l'IA si on ne sait nous même pas le faire ?
Le 15/05/2025 à 18h47
une "IA" ne commet pas d'erreur, elle retourne des informations qui sont pertinentes selon des critères statistiques inaccessibles fait sur la base de son jeu d'entraînement, d'où le coté non-prédictible problématique.
un humain qui double en ayant mal estimé la distance/vitesse de la voiture qui arrive en face, c'est une erreur
une voiture autonome qui double dans les mêmes conditions, c'est que les capteurs sont défaillants ET qu'il manque des garde-fous dans la conception du véhicule.
si on crée des outils "intelligents", c'est justement pour qu'ils fassent moins de conneries que nous, pas pour accepter qu'ils fassent les mêmes
Le 14/05/2025 à 14h52
Le 15/05/2025 à 17h43
Les "successions d'incidents isolés aux conséquences qui ne pouvaient pas être anticipées" on en a dans tous les domaines : l'aviation, la médecine...
Pour une femme enceinte écrasée par le robot, c'est potentiellement 4 collaborateurs qui ne sont pas morts sur des erreurs d'inattention humaines dans les accidents "ordinaires" d'une activité de ce type.
Évidemment, il faut pas qu'on s'emballe sur le déploiement des IA sans un minimum de sécurité, de supervision et de contrôle. Mais quand une IA fait potentiellement mieux que ce qu'on est capable de faire nous-même (humains en général), il y a un moment où on va forcément basculer dans la "perte acceptable".
Le 15/05/2025 à 19h44
Le 14/05/2025 à 16h05
Problem solved.
Modifié le 14/05/2025 à 14h40
Le 14/05/2025 à 16h47
Les analyses de risque sur les systèmes critiques de l'hopital doivent être faites par l'hopital.
Le 14/05/2025 à 18h29
Si il est vrai que les exemples sont la béquille de la pensée alors 90% des participants se mentent à eux-mêmes.
L'éthique n'est qu'un autre mot pour parler de morale.
L'intégration du tiers est le point faible permanent de ces discours.
En effet, il n'y a pas pire violence que de prendre son prochain pour soi-même.
Modifié le 18/05/2025 à 10h36
Une spec pas à jour (le comportement est bon mais le spec a oublié d'être mise à jour), ou une "anomalie" à laquelle l'utilisateur c'est habitué (workaround, correction manuelle...).
Dans ces deux cas "corriger ce bug" va poser un problème de régression ou d'accompagnement au changement.
Bon, sinon j'ai un doute sur cette "étude" le dev semble être omnipotent. Pour le dieselgate, ce n'est pas un dev dans son coin qui a décidé de "tricher"... quelqu'un a eu une idée, ça a été étudié en réunion (y compris le cout / risque vs avantage), validé, développé, testé et recetté.
Le dev (ou celui qui a eu l'idée en premier), ne sont qu'un maillon de la chaîne, c'est important d'inclure la notion d'éthique, mais ce n'est qu'un critère de décision supplémentaire (en plus du financier, de la sécurité...)
Les devs sont souvent des consultants, notre rôle est le conseil et pas la prise de décision : J'ai déjà codé des certificats qualité "un peu arrondi" ou monté des flux financiers étonnants.
J'ai fait mon rôle de conseil expliqué les risques, puis je me suis couvert par une décharge de responsabilité de mon client. J'aurais pu refusé, au risque de perdre mon emploi et quelqu'un d'autre le fasse à ma place. Même les protections pour les lanceurs d'alerte, c'est très bien que ça existe, mais ça ne rend pas le truc obligatoire, ni n'impose des responsabilités supplémentaires aux dev.
On ne met pas en prison les ouvriers qui fabriquent les armes de guerre...