Le résultat de sortie de certains logiciels embarqués est souvent considéré comme une « décision », en particulier le cas des véhicules autonomes ou des robots pour lesquels les résultats du logiciel conduisent quasi-directement, à la mise en oeuvre des actionneurs.
Mais qui est responsable lorsqu’un outil intelligent ou un robot « prend une décision » inadéquate qui est à l’origine d’un accident ?
La question s’avère délicate surtout quand les dédommagements financiers sont importants. Avant de poursuivre, rappelons que les logiciels d’apprentissage profond ont tendance à devenir de véritables boîtes noires, car ils réutilisent des programmes écrits, améliorés et validés par des équipes de concepteurs et programmeurs auxquelles succèdent d’autres programmeurs qui utilisent des packages intermédiaires puis d’autres qui intègrent ces derniers dans l’outil final.
Il convient donc de bien comprendre comment s’opère l’empilement de ces différentes couches. On voit que pour chaque logiciel, il y a un grand nombre de parties prenantes qui communiquent entre elles, mais qui souvent s’ignorent. Etant supposé que les précautions concernant la conception et l’initialisation des logiciels sont respectées, qui donc va être responsable d’une erreur ou d’un accident son opérateur, son concepteur, ceux qui ont fourni les données, celui qui a configuré le robot, etc… ?
Pour contourner la difficulté, certains ont proposé un concept nouveau, celui de la « personnalité juridique des robots ». Les tenants de cette position notent que les robots sont aujourd’hui conçus pour apprendre de leur expérience ; et ils postulent que les capacités d’adaptation et d’apprentissage « entraînent une certaine part d’imprévisibilité dans leur comportement [… et que, pour la prochaine génération], les robots tireront, de manière autonome, des enseignements de leurs expériences, variables de l’un à l’autre, et interagiront avec leur environnement de manière unique et imprévisible » (Cf. la résolution « concernant des règles de droit civil sur la robotique » adoptée en février 2017 par Parlement européen, heureusement rejetée par la Commission Européenne). Ils considèrent que :
« Dans l’hypothèse où un robot puisse prendre des décisions de manière autonome, les règles habituelles ne suffiraient pas à établir la responsabilité du robot, puisqu’elles ne permettraient pas de déterminer quelle est la partie responsable, [ce qui est nécessaire] pour le versement des dommages et intérêts ».
Ainsi, en cas de défaillance ou en cas d’accident causé par un robot, il faudrait désigner le robot lui-même comme responsable et faire payer l’indemnisation par l’assurance de ce robot ; celle-ci aurait été prise par exemple au moment de sa vente par exemple par un consortium incluant son concepteur et son data intégrateur (mais les Etats pourraient être mis à contribution !!).
Le problème est le suivant : quand il y a un accident ou un défaut, c’est parce qu’il y a eu une défaillance soit de l’utilisateur, soit du programmeur, soit de celui qui a fait l’interface entre la machine et l’environnement, soit de celui qui a fabriqué le capteur ou qui l’a installé, etc. En fait, les promoteurs du concept évoqué ci-dessus veulent évacuer le problème. Pour eux, si on disait que le robot est responsable, cela éviterait de départager les responsabilités des différents intervenants ; et la mise en place d’un système d’assurance collective des robots permettrait de lever des réticences des utilisateurs face à une utilisation massive (et cela favoriserait aussi l’industrie robotique).
Mais cette solution de facilité évacuerait la responsabilité des individus et relâcherait tous les travaux de validation des logiciels et les étapes – forcément fastidieuses – de vérification de l’utilisation des logiciels. Cela reviendrait à généraliser à des domaines sensibles et vitaux pour les individus la pratique courante de mise à disposition de version test de logiciel grand public qui n’ont pas encore été testés dans toutes leurs configurations. Certes il peut être acceptable de proposer à un utilisateur averti d’utiliser un logiciel non encore validé quand ce dernier est la seule victime potentielle de l’erreur du logiciel, mais une telle pratique n’est plus acceptable quand il peut y avoir des victimes extérieures qui ne sont pas utilisateur averti du logiciel.
En fait, c’est le postulat de base de ce raisonnement qui est faux : à savoir que le comportement du robot est « imprévisible » et le « logiciel peut se modifier de lui-même ».
Certes la réponse du logiciel à un flux d’entrée de données peut dépendre des données issues de l’environnement ou des résultats du logiciel obtenus antérieurement ; mais comme nous l’avons noté plus haut, une bonne politique de qualité logiciel doit prendre en compte ces éléments. C’est ladite imprévisibilité de l’algorithme qu’il convient de maîtriser. Et si le concepteur, le data intégrateur et l’utilisateur ne la maitrisent pas, ce sont eux les responsables.
Rémi Sentis
Association des Scientifiques Chretiens 