Naviguer dans le futur des systèmes autonomes : sécurité, éthique et responsabilité à l'ère de l'IA
Demandez à une salle remplie d'ingénieurs travaillant sur des piles de perception pour véhicules autonomes ce qu'ils pensent du dilemme du tramway, et vous obtiendrez principalement des expressions lassées. Le problème en soi est certes substantiel. Mais c'est le mauvais modèle pour le véritable problème d'ingénierie auquel ils sont confrontés, et expliquer pourquoi prend plus de temps que ce que la patience de la plupart des conversations lors d'un dîner permet.
La version honnête du défi de sécurité dans les systèmes autonomes est bien moins dramatique sur le plan philosophique et beaucoup plus laborieuse sur le plan mathématique : perception probabiliste sous bruit de capteur, occlusion et latence, alimentant un pipeline de décision qui doit optimiser une fonction de récompense à travers des espaces d'action continus, sans aucun choix binaire clair nulle part dans la boucle. Réussir cette réalité technique, et construire les normes et les cadres de responsabilité autour d'elle correctement, est un problème bien plus difficile et lourd de conséquences que n'importe quelle expérience de pensée, et il mérite d'être traité comme tel.
Partie 1 : Pourquoi le dilemme du tramway échoue en tant que spécification technique
Le dilemme du tramway suppose quelque chose qu'aucun système autonome réel ne possède : un monde déterministe, une connaissance parfaite de l'état, un choix binaire clair et une certitude quant aux résultats. La pile de perception d'un véhicule autonome réel ne possède rien de tout cela. Elle dispose de retours LiDAR bruités, d'images de caméra dégradées par la pluie ou un angle de soleil bas, d'occlusions derrière un camion garé, et d'un état de croyance probabiliste sur ce qui se trouve réellement à l'extérieur, et non d'une vérité de terrain.
Ce qui tourne réellement sous le capot
Les véhicules autonomes réels s'appuient sur des cadres formels tels que les processus de décision markoviens partiellement observables et l'apprentissage par renforcement précisément parce que le monde est réellement partiellement observé. Le système ne choisit pas entre deux destins prédéterminés. Il échantillonne à travers un espace d'action continu, des dizaines de combinaisons plausibles d'angle de braquage et d'accélération, et optimise le résultat attendu par rapport à une fonction de récompense articulée autour de l'évitement des collisions et des seuils de devoir de diligence, sous une incertitude réelle quant à la façon dont le piéton, la voiture venant en sens inverse ou le cycliste se comporteront réellement dans les deux prochaines secondes. Programmer un véhicule autonome pour « résoudre » un dilemme de type tramway n'est pas une version simplifiée de la tâche d'ingénierie réelle. C'est résoudre un problème totalement différent, qui ne se produit pas réellement sous la forme supposée par l'expérience de pensée.
L'expérience de la « Moral Machine » et pourquoi l'éthique participative est un piège
L'expérience « Moral Machine » du MIT a collecté des millions de réponses participatives à des scénarios hypothétiques d'accident de véhicule autonome, et la variation culturelle qu'elle a révélée — différentes préférences au niveau de la population concernant le fait d'épargner les jeunes plutôt que les personnes âgées, par exemple — est réellement intéressante sur le plan sociologique. C'est aussi un signal d'alarme sérieux pour quiconque serait tenté d'entraîner un module d'éthique directement sur ces données.
Le raisonnement moral humain sous pression temporelle tend vers la déontologie ; avec le temps de délibérer, les mêmes personnes tendent vers l'utilitarisme. Ce n'est pas une fonction de préférence stable que vous voulez intégrer dans un système de contrôle critique pour la sécurité. Pire encore, il existe un biais de perspective bien documenté : les gens s'imaginant être le passager du véhicule autonome veulent que la voiture protège le passager avant tout, tandis que ces mêmes personnes s'imaginant être le piéton veulent l'inverse. Entraînez un modèle sur une intuition participative comme celle-là et vous n'encodez pas l'éthique. Vous encodez une incohérence intéressée à grande échelle, ce qui est précisément la raison pour laquelle l'éthique dans ce domaine ne peut être abordée comme un exercice démocratique d'ajustement de données. Elle nécessite une structure constitutionnelle qui ne soit pas simplement une moyenne du sentiment populaire.
Approches descendantes, ascendantes et l'hybride réellement déployé
La codification algorithmique descendante (top-down) intègre des engagements éthiques spécifiques directement dans une logique déterministe, une règle déontologique stricte contre la violation du code de la route, sauf pour éviter une collision imminente, par exemple. C'est auditable et prévisible, mais c'est aussi fragile face à des scénarios que le concepteur de la règle n'a pas anticipés.
L'apprentissage automatique ascendant (bottom-up) permet au système d'inférer des normes comportementales à partir de données d'entraînement, ce qui gère bien mieux la variation complexe du monde réel, au prix direct de l'interprétabilité. Un réseau de politiques « boîte noire » ne peut pas facilement expliquer après coup pourquoi il a choisi une trajectoire spécifique dans un cas limite, ce qui est un problème réel pour l'enquête sur les incidents et la responsabilité réglementaire.
Le modèle qui a réellement émergé dans les déploiements sérieux est hybride : des politiques apprises de manière ascendante gèrent le problème continu et complexe de la perception et de l'optimisation de la trajectoire, opérant à l'intérieur de contraintes descendantes strictes que la politique apprise est architecturalement interdite de violer, indépendamment de ce que la fonction de récompense pourrait suggérer par ailleurs. Cette couche de délimitation, parfois implémentée comme un filtre de sécurité explicite basé sur des règles situé en aval du planificateur appris, est fonctionnellement similaire à la façon dont une limite d'articulation codée en dur ou un verrouillage d'évitement de collision contraint une politique de manipulation robotique apprise dans des environnements industriels. L'apprentissage gère la nuance ; la couche déterministe gère les limites non négociables.
L'importance de la sécurité est intrinsèquement tissée dans le tissu même de la conception du produit, palpable dans les cadres réglementaires qui dictent son développement.
Sécurité fonctionnelle versus SOTIF : deux catégories de défaillance différentes
La norme ISO 26262 régit la sécurité fonctionnelle, la discipline bien établie de gestion des risques liés aux dysfonctionnements matériels ou aux défauts logiciels systématiques. Son cadre ASIL (Automotive Safety Integrity Level) adapte la rigueur de la conception et de l'activité de vérification à la gravité et à la probabilité du danger qu'une défaillance donnée pourrait causer, et la plupart des ingénieurs en électronique automobile ont passé du temps à débattre des stratégies de décomposition ASIL précisément pour cette raison.
La réalisation réellement inconfortable à laquelle l'industrie a dû faire face est qu'un véhicule autonome peut s'écraser alors que chaque composant fonctionne exactement comme prévu. Une caméra capture une image parfaitement nette. Le réseau de perception échoue simplement à classer correctement un piéton portant un costume inhabituel sous une pluie battante, car cette combinaison spécifique se situe en dehors de ce que la distribution d'entraînement couvrait adéquatement. Rien n'a mal fonctionné. Le système était simplement insuffisant pour la complexité de ce moment, et tout le cadre de l'ISO 26262, construit autour du risque de dysfonctionnement, n'a aucun vocabulaire natif pour ce mode de défaillance.
La norme ISO 21448, SOTIF (Safety of the Intended Functionality), existe spécifiquement pour combler cette lacune, en se concentrant sur les dangers découlant de la limitation des performances et des conditions de fonctionnement imprévues plutôt que de la défaillance des composants. Le modèle à quatre quadrants du SOTIF mérite d'être compris en détail car il donne aux équipes d'ingénierie une véritable feuille de route plutôt qu'une simple étiquette pour le problème. La zone 1 est l'état cible connu comme sûr. La zone 2 est connue comme dangereuse, ce sont les risques que l'équipe a déjà identifiés et qu'elle atténue activement par des changements de conception. La zone 3 est inconnue-dangereuse, la catégorie réellement dangereuse car l'équipe n'a même pas encore identifié ces cas limites. La zone 4 est inconnue-sûre.
L'objectif pratique de l'ingénierie SOTIF, de la simulation approfondie, de la validation statistique sur le terrain et de la découverte structurée des cas limites, est de faire migrer les scénarios de la zone 3 vers la zone 2, où ils deviennent des problèmes de conception traitables plutôt que des risques invisibles. Exécuter l'ISO 26262 et le SOTIF en parallèle plutôt que de traiter l'un ou l'autre comme suffisant est ce qui couvre réellement à la fois le risque de dysfonctionnement interne et le risque de complexité externe simultanément, et ignorer l'un ou l'autre laisse une réelle lacune dans l'argumentaire de sécurité.
Robotique collaborative : ISO 10218 et la fusion avec la TS 15066 de 2025
Le même changement fondamental, supprimant l'hypothèse selon laquelle un humain est toujours la sécurité ultime, s'est produit dans la robotique industrielle. Les robots industriels traditionnels fonctionnaient à l'intérieur de cages de sécurité isolées avec des verrouillages stricts : ouvrez la cage, l'alimentation se coupe immédiatement. L'introduction de robots collaboratifs a fondamentalement modifié les configurations traditionnelles des espaces de travail, nécessitant la coexistence homme-robot.
La mise à jour 2025 de l'ISO 10218-2 a formellement absorbé l'ISO/TS 15066 dans une norme unique et unifiée sur la robotique collaborative, et les quatre modes de fonctionnement collaboratifs qu'elle définit méritent d'être connus sur le bout des doigts si vous spécifiez une cellule de cobot. L'arrêt surveillé avec sécurité (Safety-Rated Monitored Stop) arrête complètement le robot lors de l'entrée d'un humain et ne reprend qu'après que la zone est dégagée. Pour garantir un flux de travail sécurisé et efficace, les opérateurs gèrent activement le mouvement du bras robotique, contrôlant précisément la vitesse à des emplacements prédéterminés. En temps réel, le système optimise son rythme en fonction de calculs dynamiques de vitesse relative et de proximité avec les humains, assurant un environnement de travail plus sûr. La limitation des frontières de puissance et de force non seulement restreint le contact mécanique, mais impose également électroniquement des forces de contact sûres pour empêcher les collisions de dépasser les limites de sécurité prédéfinies.
Le détail qui piège le plus souvent les nouveaux intégrateurs : la norme stipule explicitement qu'aucun robot n'est intrinsèquement « sûr » ou « collaboratif » de manière isolée. C'est l'application entière, l'effecteur final spécifique, la géométrie de la pièce, les montages environnants, la tâche réelle, qui doivent être évalués en termes de risques et validés en tant que système complet. Un bras robotique parfaitement conforme à la PFL (Power and Force Limiting) utilisant une pince personnalisée à bords tranchants n'est pas une application collaborative simplement parce que le robot de base porte une certification collaborative.
IEEE P7000 : Là où l'éthique socio-technique est formalisée
La sécurité est la préoccupation principale qui motive les normes ISO, qui privilégient à la fois les aspects physiques et fonctionnels. La suite IEEE P7000, lancée dans le cadre de l'Initiative mondiale de l'IEEE sur l'éthique des systèmes autonomes et intelligents, aborde les dimensions socio-techniques et éthiques que les cadres ISO n'ont jamais été conçus pour couvrir, et elle le fait avec des normes spécifiques et adressables plutôt qu'avec de vagues principes aspirationnels.
L'IEEE P7001 cible la transparence, exigeant que les systèmes autonomes soient auto-évaluables et exposent les voies de décision sous une forme réellement explicable aux humains après coup, ce qui est précisément la capacité que l'apprentissage ascendant en boîte noire pure peine à fournir sans travail architectural supplémentaire. L'IEEE P7003 aborde directement le biais algorithmique, fournissant des cadres structurés pour identifier et prévenir les résultats discriminatoires dans les modèles entraînés avant le déploiement. L'IEEE P7009 couvre spécifiquement la conception à sécurité intégrée (fail-safe), imposant un comportement de dégradation gracieux et sûr plutôt que des modes de défaillance brusques ou imprévisibles lorsqu'un système ne peut réellement pas poursuivre son fonctionnement normal. L'IEEE P7010 va plus loin que la plupart des normes d'ingénierie, introduisant des mesures de bien-être qui évaluent l'impact réel d'un système d'IA sur l'épanouissement humain plutôt que de s'arrêter à des mesures économiques ou d'achèvement de tâches étroites.
Partie 3 : Construire un dossier de sécurité qui tient la route
Les listes de contrôle de conformité aux normes ISO 26262 ou SOTIF sont des bases nécessaires, mais elles ne constituent pas en soi un argument défendable selon lequel un système spécifique est sûr à déployer dans le monde réel. Cet argument est ce qu'un dossier d'assurance de sécurité (Safety Assurance Case) construit formellement : des revendications structurées, soutenues par des chaînes d'arguments logiques, appuyées par des preuves concrètes vérifiables, des journaux de simulation, des résultats de tests sur piste, de la télémétrie sur le terrain.
UL 4600 : Basé sur des objectifs plutôt que prescriptif
La norme ANSI/UL 4600 adopte une approche délibérément différente des normes prescriptives traditionnelles qui dictent des exigences de mise en œuvre exactes. Elle est basée sur des objectifs, fournissant un ensemble étendu d'invites obligatoires, requises et recommandées qui forcent les équipes d'ingénierie à aborder activement des catégories de risques spécifiques plutôt que de simplement cocher une case de mise en œuvre fixe.
L'UL 4600 force une confrontation directe avec la fragilité inhérente à l'apprentissage automatique, la longue traîne réelle des cas limites rares et la réalité complexe de l'interaction homme-machine dans des conditions de fonctionnement réelles. Son exigence d'un domaine de conception opérationnelle (ODD) strictement défini, l'enveloppe environnementale, géographique et temporelle explicite à l'intérieur de laquelle le système est réellement autorisé à fonctionner — « jour, temps clair, routes pavées à moins de 70 km/h » en étant un exemple représentatif — est l'exigence la plus importante de la norme sur le plan opérationnel. Si le véhicule rencontre des conditions en dehors de cette enveloppe, un blizzard soudain, une zone de construction non cartographiée, le dossier de sécurité doit prouver que le système peut réellement détecter cette violation de l'ODD de manière fiable et exécuter une manœuvre de repli réellement sûre, et ne pas simplement espérer que la pile de perception gère cela avec grâce.
SACE et AMLAS : Une méthodologie holistique et consciente de l'environnement
La méthodologie SACE de l'Université de York, « Safety Assurance of autonomous systems in Complex Environments », fonctionne aux côtés d'AMLAS, « Assurance of Machine Learning for use in Autonomous Systems », pour adopter une vision réellement holistique couvrant à la fois le système lui-même et l'environnement opérationnel dans lequel il existe.
Le composant « Out of Context Operation Assurance » de SACE aborde quelque chose que le concept d'ODD de l'UL 4600 implique mais ne formalise pas entièrement par lui-même : le monde réel est infiniment plus complexe que ce que tout modèle de domaine opérationnel défini peut capturer pleinement, de sorte que le système finira inévitablement par s'égarer en dehors de ses limites définies. SACE exige de démontrer explicitement deux capacités distinctes. Premièrement, que le système peut reconnaître avec précision et rapidité qu'il approche ou a déjà franchi la limite de l'ODM, avec des taux de faux positifs et de faux négatifs soigneusement validés sur cette détection de limite elle-même, car un détecteur de limite qui crie au loup constamment est presque aussi dangereux qu'un détecteur qui manque les franchissements de limite réels. Deuxièmement, que le système dispose d'une véritable stratégie de risque minimal prête à être exécutée une fois en dehors de l'ODM, que cela signifie rendre le contrôle à un opérateur humain, exécuter un arrêt sûr contrôlé ou passer dans un mode sûr dégradé délibérément conservateur axé uniquement sur l'auto-préservation plutôt que sur l'achèvement de la tâche.
Pourquoi la simulation porte une si grande part du poids probatoire
Aucune flotte, aussi grande soit-elle, ne peut physiquement parcourir suffisamment de kilomètres dans le monde réel pour rencontrer chaque cas limite dangereux significatif par le seul biais des tests routiers ; la combinatoire de la météo, de l'éclairage, du comportement du trafic et des classes d'objets rares rend cette approche statistiquement sans espoir dans tout calendrier de programme raisonnable. Des cadres de simulation standardisés comme ASAM OpenDRIVE pour la description du réseau routier et OpenSCENARIO pour la spécification des manœuvres dynamiques permettent aux équipes d'ingénierie de construire des environnements virtuels hautement paramétrés où les défauts peuvent être délibérément injectés, les conditions météorologiques et d'éclairage variées systématiquement, et des millions de permutations de scénarios exécutées beaucoup plus rapidement et beaucoup plus exhaustivement que ce que les tests physiques pourraient jamais atteindre, générant la majeure partie de la base probatoire sur laquelle reposent réellement les arguments de sécurité SOTIF et UL 4600 avant même que ce logiciel ne touche le matériel physique.
Partie 4 : Responsabilité — Là où l'ingénierie rencontre la loi
Lorsqu'un système autonome cause un décès, l'instinct public immédiat est souvent de demander ce que la machine a « décidé » de faire, comme si elle avait fait un choix moral. Ce cadrage est une erreur de catégorie, et il est important que les ingénieurs et les cadres juridiques construits autour de cette technologie y résistent délibérément.
Pourquoi les machines ne peuvent pas détenir d'agence morale ou juridique
Un système autonome, quelle que soit sa sophistication architecturale, optimise une fonction de récompense mathématique. Il ne possède pas d'intentionnalité, de libre arbitre ou de compréhension morale authentique dans aucun sens que la loi ou l'éthique classique reconnaît, et lui attribuer une agence obscurcit plutôt qu'il ne clarifie où réside réellement la responsabilité. Parce que les machines manquent de personnalité juridique et de capacité de mens rea, la responsabilité pénale ne peut pas s'attacher au système lui-même.
Ce qui a été observé à la place est la formation d'une « zone de déformation morale », où un humain positionné au plus près de la défaillance, un conducteur de sécurité surveillant un système automatisé par exemple, absorbe un blâme juridique et moral disproportionné par rapport à sa contribution causale réelle, tandis que les décisions d'ingénierie systémique et organisationnelles qui ont réellement produit la condition de défaillance échappent à un examen équivalent. Cette asymétrie est un véritable mode de défaillance de la responsabilité, pas une conséquence acceptable de l'exploitation d'une technologie avancée.
L'accident d'Uber ATG comme étude de cas technique et organisationnelle
L'accident mortel d'Uber ATG en 2018 à Tempe, en Arizona, est fréquemment caractérisé à tort dans le débat public comme un dilemme du tramway réel. L'enquête technique réelle raconte une histoire considérablement moins intéressante sur le plan philosophique et considérablement plus instructive sur le plan pratique : une défaillance de la pile de perception aggravée par une défaillance de la culture de sécurité organisationnelle.
La classification par le système de conduite automatisée d'une femme traversant la route tout en marchant avec un vélo a oscillé à plusieurs reprises entre « véhicule », « vélo » et « autre » à mesure que l'objet se déplaçait dans la scène. Chaque reclassement réinitialisait la prédiction de trajectoire du système pour cet objet, et ce cycle de réinitialisation, et non un choix délibéré de type tramway, est ce qui a retardé la réponse de freinage appropriée jusqu'à ce qu'il soit trop tard. Il s'agit d'un mode de défaillance réellement bien compris dans les pipelines de suivi et de classification multi-objets, où des prédictions de classe instables corrompent la prédiction de mouvement en aval, et c'est exactement le genre de problème qu'une architecture de fusion de capteurs plus mature avec des contraintes de cohérence temporelle plus fortes sur des trames consécutives aurait dû détecter lors des tests de validation bien avant le déploiement sur la voie publique.
Superposée directement à cette défaillance technique, il y avait une défaillance organisationnelle distincte, et sans doute plus condamnable : Uber avait supprimé les notifications d'alerte d'urgence destinées au conducteur de sécurité humain spécifiquement pour réduire la « fatigue des alarmes » due aux fausses alertes fréquentes, et les tâches de sécurité opérationnelle pour ce rôle de conducteur de sécurité n'étaient pas clairement ou rigoureusement définies en premier lieu. Aucune de ces décisions organisationnelles n'apparaît dans une analyse technique des causes profondes de la pile de perception seule, et c'est précisément le point : un cadre de responsabilité complet doit examiner tout le cycle de vie du système, pas seulement le logiciel qui fonctionnait au moment de l'impact.
Définir la responsabilité des rôles sur tout le cycle de vie
Une responsabilité significative doit explicitement retracer chaque étape du développement et de l'exploitation du système : les organisations et les processus responsables de la collecte et de la conservation des données d'entraînement, les ingénieurs qui ont conçu et validé les architectures de réseaux neuronaux, les ingénieurs de sécurité qui ont compilé et signé le dossier de sécurité UL 4600, les dirigeants qui ont fixé les délais de déploiement et la tolérance au risque sous pression commerciale, et les opérateurs de terrain gérant réellement le système dans des conditions réelles au quotidien.
Cette traçabilité sur tout le cycle de vie est exactement la raison pour laquelle les normes imposant des voies de décision transparentes et reconstructibles, l'IEEE P7001 étant l'exemple direct le plus clair, comptent au-delà du pur intérêt technique. Sans cet enregistrement reconstructible, l'enquête post-incident ne peut pas retracer avec précision la responsabilité causale à travers les étapes du cycle de vie où les conditions de défaillance réelles ont pris naissance, et la responsabilité s'effondre sur l'individu qui se trouvait physiquement le plus proche de la défaillance au moment où elle s'est produite, ce qui est rarement là où la véritable responsabilité technique résidait réellement.
Où cela doit réellement aller à partir d'ici
Déployer des systèmes autonomes critiques pour la sécurité de manière responsable n'est pas un problème qui se résout en résolvant plus intelligemment une expérience de pensée philosophique. Il se résout par le travail ingrat, rigoureux et réellement difficile de l'analyse de sécurité fonctionnelle au niveau des composants selon l'ISO 26262, de la couverture des limitations environnementales et de performance selon le SOTIF, de l'évaluation des risques au niveau de l'application selon le cadre de robotique collaborative unifié ISO 10218, de la structure de responsabilité socio-technique selon l'IEEE P7000, et de l'argumentation de sécurité structurée et étayée par des preuves selon des cadres comme l'UL 4600 et SACE.
Aucun de ces cadres ne résout individuellement tout le problème, et c'est exactement pourquoi les organisations d'ingénierie sérieuses les utilisent en combinaison plutôt que de traiter une norme unique comme une couverture suffisante. La conclusion honnête de l'affaire Uber ATG et de chaque incident ultérieur étudié avec ce niveau de rigueur est la même : la responsabilité de ce que font ces systèmes ne se transfère pas à la machine simplement parce que la machine prend les décisions au moment opportun. Elle reste fermement entre les mains des humains qui ont conçu le pipeline de perception, défini les limites opérationnelles, signé le dossier de sécurité et fixé les priorités organisationnelles sous lesquelles toute cette ingénierie a réellement eu lieu. Intégrer cette responsabilité dans le processus dès le départ, plutôt que de découvrir son absence après un décès, est le travail réel que ce domaine a encore devant lui.