Tesla Autopilot: quelle sécurité?

Tesla Autopilot: conçu comme un logiciel de bureautique

Le mode “Autopilot” des voitures Tesla est celui où la voiture est autonome, ou presque autonome (officiellement, le conducteur est censé tenir le volant et être attentif à la route, comme s'il conduisait réellement, afin de reprendre la main si le pilotage automatique faisait une erreur). C'est donc un logiciel extrêmement critique, capable de provoquer la mort de personnes dans et autour de la voiture s'il prend une mauvaise décision. Mais il ne semble pas avoir été conçu avec le bon niveau d'exigence en tête: l'argument principal de Tesla est: “selon nos statistiques, il y a peu d'accidents”.

Pour comprendre les problèmes de sécurité du logiciel Autopilot (et du matériel associé), il faut d'abord comprendre la logique derrière les logiciels destinés au public, tels que les logiciels de bureautique (comme Microsoft Word) ou les logiciels embarqués dans des équipements (comme les caméras de surveillance).

Ces logiciels ne sont pas conçus comme des biens industriels, dont le client est en droit d'attendre une performance conforme aux spécifications du produit qu'il a acheté, mais comme une production intellectuelle, comme un livre ou un tableau. Si le logiciel est intégré dans un produit (par exemple une caméra), alors ce produit doit fonctionner, mais sans exigence particulière sur le logiciel lui-même, à quelques détails près (nous y reviendrons).

Si vous achetez un roman et qu'il ne vous plaît pas, vous n'avez aucun droit à vous faire rembourser sous prétexte qu'il n'est pas conforme aux promesses indiquées en 4^e de couverture. Tout au plus, vous pouvez le jeter, ne pas acheter le prochain roman du même auteur, et dissuader vos amis de le lire.
Il en est de même si vous trouvez que les logiciels de Microsoft ne répondent pas à vos besoins:

• Votre document Word a été corrompu par le logiciel et vous avez tout perdu?
  ⇒ Il fallait faire une sauvegarde
• La numérotation des paragraphes est pleine de bugs et vous avez perdu des heures?
  ⇒ Il existe des formations pour apprendre à contourner ces bugs
  
• Vous avez mal géré votre entreprise parce que certaines dates ont été modifiées de 4 ans dans un tableau Excel?
  ⇒ C'est indiqué sur le site de Microsoft
• Votre base de données Access est devenue inutilisable depuis la dernière mise à jour?
  ⇒ La documentation vous explique comment créer une base de données avec la dernière version
• Windows est conçu pour rendre inutilisable tout PC âgé de quelques années?
  ⇒ Voici les spécifications pour votre prochain PC. Vous repaierez pour la nouvelle version de Windows.
  

En Europe, il existe toutefois des règles, mais elles sont centrées sur le respect de la vie privée, et depuis peu sur la sécurité informatique, mais ne concernent pas vraiment les fonctionnalités du logiciel. Ces règles sont presque inexistantes aux USA, pays d'origine de Tesla, et celles qui y existaient ont été démantelées par Donald Trump n°2. En Europe, ces règles, concernant les logiciels reliés à des réseaux informatiques (comme Internet, le WiFi, ou la 5G), imposent notamment:

• Respect des données personnelles (RGPD: Règlement général sur la protection des données): ne pas voler les données personnelles des utilisateurs, sans raison valable (intérêt légitime), ou sans l'accord de l'utilisateur (information éclairée et consentement); ne pas faire de traitements automatisés de ces données personnelles au-delà de ce qui est strictement nécessaire pour assurer le service; ne pas conserver ces données personnelles au-delà d'une durée raisonnable.
  
• Sécurité informatique, protection contre le piratage, sécurité par conception: ces règles plus récentes, rendues urgentes par la multiplication des ingérences russes (mais pas uniquement), se retrouvent notamment dans la loi européenne CRA (Cyber Resilience Act), votée en 2024, et qui complète des lois existantes comme DORA (Digital Operational Resilience Act) ou NIS 2 (Network and Information Security #2). L'objectif est par exemple d'empêcher que le système Linux intégré dans de nombreuses caméras de surveillance vendues au grand public puisse être détourné, faute de mot de passe dans les outils de prise de contrôle à distance comme FTP et TELNET, par n'importe quel pirate qui peut les utiliser pour vous espionner, ou comme passerelle pour attaquer d'autres systèmes tout en se protégeant derrière vous.
  

De nombreuses grandes entreprises américaines (ou autres) ne respectent absolument pas ces règles.

La conception d'un logiciel “sûr”

De très nombreux logiciels sont utilisés pour faire voler des avions, rouler des trains, soigner des patients, ou faire fonctionner des machines industrielles dangereuses. Très souvent, un mauvais fonctionnement du logiciel pourrait avoir des conséquences graves, parfois mortelles, et il existe des règlementations qui imposent des règles de sécurité à ces logiciels, et au matériel sur lequel ils tournent.

Ces règles dépendent du secteur d'activité (médical, aérien, ferroviaire, automobile, machines industrielles...), et aussi du niveau de risque. Ainsi, la norme de l'industrie concernant les logiciels utilisés dans les équipements médicaux prévoit plusieurs classes de risque en cas de défaillance du logiciel:

• classe A: situation non dangereuse (ex: la musique d'ambiance s'arrête), ou sans risque inacceptable dans le système (ex: le logiciel provoque un mouvement anormal du système, mais qui s'arrête dès que l'opérateur relâche le bouton)
• classe B: risque inacceptable de blessure légère (ex: l'échographe envoie des ultrasons trop puissants, mais incapables de détruire les tissus)
  
• classe C: risque inacceptable de blessure grave ou de décès (ex: le pousse-seringue envoie 10 fois la dose programmée, le défibrillateur automatique envoie l'impulsion électrique au mauvais moment, l'appareil de radiothérapie envoie un faisceau trop puissant ou mal dirigé, l'appareil de monitoring ne signale pas que le patient est en train de s'asphyxier).
  

En plus des normes de l'industrie, les États imposent leurs propres règles. Ainsi, les logiciels utilisés dans les systèmes médicaux sont soumis à des règles plus ou moins sévères en fonction de leur classification selon le risque de blessure ou de mort en cas de défaillance logicielle: classes de risque I, IIa, IIb ou III pour la règlementation européenne, classes de niveau de préoccupation “mineur”, “modéré” ou “majeur” pour la règlementation américaine (FDA).

Il est essentiel que la sévérité des règles dépende de la gravité des risques: dans l'aérien, une défaillance sur le système de contrôle de la gouverne de profondeur est catastrophique (comme on l'a vu avec le logiciel MCAS sur le Boeing 737 Max), tandis qu'un bug sur l'écran qui sert à distraire le passager n'a pas de conséquence sérieuse.

Un logiciel “sans risque” n'est pas forcément complexe, ni même fiable. Il peut également:

• assurer une fonction non critique: le logiciel qui affiche une vidéo YouTube est extrêmement complexe et peu fiable, mais il n'y a aucun drame s'il s'arrête.
• être sous le contrôle permanent de l'utilisateur: la machine ne fonctionne que tant qu'on appuie sur un bouton. En cas de défaillance logicielle, l'opérateur relâche le bouton et tout s'arrête avant qu'il n'y ait eu d'accident.
• être sous le contrôle d'un système de supervision indépendant, simple et fiable: dès que la machine sort de sa zone autorisée (position, vitesse, risque de collision, température, tension électrique...), le système de supervision l'arrête, quoi que fasse le logiciel.
  

Mais chaque solution n'est pas applicable à chaque cas: il est pertinent pour un train d'activer l'arrêt d'urgence s'il semble y avoir une anomalie, mais pour un avion mieux vaut prévenir le pilote que le système de pilotage automatique va se déconnecter, et pour une voiture autonome il est inacceptable que le système de guidage arrête soudainement de contrôler la direction à l'entrée d'un virage.

• que peut-il arriver? (si une tension est absente, un capteur est débranché ou défaillant, le microcontrôleur fait des erreurs)
• est-ce que ce serait grave? (pas du tout, ..., catastrophique)
  
• comment peut-on éviter ou réduire ce risque? (on ajoute un 2e capteur ou une 2e carte, une alimentation de secours)
• la sécurité repose-t-elle sur le bon fonctionnement du logiciel?
  
• le risque résiduel est-il acceptable? (l'anesthésiste n'a pas bien lu le mode d'emploi, va-t-il comprendre la signification de la sonnerie et de la lumière clignotante, et savoir comment réagir)

Lorsqu'un élément critique de la sécurité repose sur un logiciel, il faut s'interroger,:

• le logiciel fonctionne-t-il? (test fonctionnel)
• chaque élément du logiciel fonctionne-t-il? (test unitaire)
• a-t-on vérifié le fonctionnement de chaque condition (commande “if”) ou de chaque ligne de code? (taux de couverture)
• tout le code est-il utilisé? (si non, il faut retirer les parties inutiles)
• maîtrise-t-on chaque élément du logiciel? (on ne voudrait pas d'un avion qui se crashe parce qu'il utilisait Windows, qui s'est subitement figé)
• dans certains domaines, pour empêcher que le logiciel ne puisse manquer de mémoire, on interdit toute allocation dynamique de mémoire (commandes “new” ou “malloc”), voire toute mémoire allouée en pile (variable locale dans une fonction), et on n'utilise que des informations stockées à une adresse fixe (variables “statiques” ou “globales”). Une telle règle limite très fortement les logiciels utilisables, mais elle apporte une grande reproductibilité du comportement.

Le résultat est que, même si cela peut sembler surprenant, les systèmes les plus critiques ont les logiciels les plus simples:

• aviation: logiciels très simples car une défaillance risque de provoquer un crash catastrophique
• automobile: logiciels simples dans les organes de sécurité, car une défaillance risque d'être difficile à gérer par le conducteur (perte d'efficacité des freins, accélération inefficace ou trop violente)
• smartphone: logiciels extrêmement complexes, car une défaillance est très habituelle et ne provoque que des désagréments pour l'utilisateur.
  

C'est grâce à ces règles que, contrairement aux ordinateurs, aux smartphones, et aux divers gadgets numériques, fréquemment bourrés de bugs bloquants, les avions et les trains sont très rarement victimes d'accidents dûs à des erreurs logicielles. Lorsque cela se produit, les conséquences peuvent être dramatiques pour les entreprises responsables: Boeing a perdu environ 20 milliards de dollars pour ses erreurs et mensonges inexcusables sur un logiciel destiné à améliorer la stabilité du contrôle d'assiette sur le Boeing 737 Max, fautes qui ont directement provoqué 2 crashs (vols Ethiopian Airlines 302 et Lion Air 610, ce dernier avec un avion qui avait déjà miraculeusement échappé à un crash la veille sur le vol Lion Air 43).

Les promesses de Tesla: une “boîte noire” magique

Attention au vocabulaire: on ne parle pas ici de la “boîte noire” des avions, cet enregistreur de couleur orange qui permet d'identifier les causes en cas d'accident.

On parle d'un dispositif informatique qui est une “boîte noire” parce qu'on ne peut pas étudier et expliquer le fonctionnement interne. C'est habituel dans les logiciels grand public, mais très préoccupant pour des logiciels remplissant une fonction de sécurité.

Tesla indique que le logiciel Autopilot, censé permettre aux voitures de conduire seules, est basé sur un “réseau de neurones”, c'est-à-dire un logiciel inspiré un peu du fonctionnement du cerveau, mais qui peut aussi ressembler à des logiciels de filtres d'image par convolution ou par ondelettes. Dans ce modèle, on met des données d'un côté, on fait des additions et d'autres opérations, et il en ressort des décisions prises par le système.

Réseaux de neurones traitant des informations pour prendre des décisions

La promesse est séduisante: le cerveau va se comporter comme un cerveau humain. Mais c'est trompeur.

Un premier problème est l'aspect “boîte noire”: non seulement l'utilisateur ne sait pas pourtant le logiciel prend telle ou telle décision, mais le constructeur non plus ne le sait pas forcément. L'apprentissage se fait sur la base d'exemples et de diverses stratégies, mais le comportement du logiciel peut surprendre même son concepteur, et ne peut pas être clairement décrit.

Un aspect trompeur est que le réseau de neurones ne traite certainement pas toutes ces informations. Par exemple pour les images, il peut y avoir un pré-traitement (comme une régularisation de la luminosité des images, une détection des objets en mouvements, ou un algorithme de vision en relief à partir de deux caméras). Il peut aussi y avoir des règles codées “en dur”, par exemple sur la manière d'atteindre et de conserver une certaine vitesse, ou sur le rayon de virage acceptable en fonction de la vitesse. Le réseau de neurones utilisé pour traiter les images n'est peut-être pas le même que celui qui est utilisé pour décider s'il faut accélérer ou freiner. Tout ceci n'est pas dévoilé par le constructeur.

Il faut ensuite faire “l'apprentissage” de ce réseau de neurones, c'est-à-dire ajuster les paramètres de calcul afin que, lorsqu'on lui fournit les données d'entrées, ils produisent les sorties les plus proches possibles du résultat attendu. Cette étape est globalement complexe et très consommatrice en calculs informatiques.

• en terme de volume de données à transmettre, à stocker, et à traiter lors de l'apprentissage: il n'est pas sûr que Tesla récupère, stocke et utilise réellement toutes ces données.
  
• mais aussi sur les sorties optimales: si la voiture est conduite par un humain, on sait ce que le conducteur a fait, mais ce choix était-il optimal? Était-il motivé par une autre raison (le conducteur a oublié quelque chose chez lui)? Si deux conducteurs font des choix différents, par exemple aller sur la file de gauche ou de droite au péage, l'algorithme va-t-il fait un choix intermédiaire qui serait catastrophique?
• le logiciel ne se comporte pas comme un humain. Pour l'améliorer, il faut donc corriger ses erreurs. Mais comment identifier ces erreurs? On peut certes récupérer les cas où le logiciel a produit un accident, et lui interdire de prendre la même décision dans le même cas, mais on ne sait pas si cela évitera tous les accidents possibles, et cela suppose d'abord qu'il y ait un grand nombre d'accidents, ce qui n'est pas acceptable. Et dans les cas où il n'y a pas eu d'accident, il est très difficile de savoir si les décisions ont été correctes ou erronées: c'est possible pour quelques voitures (avec un conducteur professionnel, parfaitement attentif, qui signale le moindre problème et reprend la main si nécessaire), mais c'est irréaliste s'il s'agit d'exploiter les données issues de millions de voitures.

Enfin, le postulat est que, plus on met de données dans un réseau de neurones, plus le résultat sera bon. En réalité ce n'est pas toujours le cas, et il y a bien des cas où le système ne fonctionnera jamais correctement, tout simplement parce qu'il n'en est pas capable. Il y a aussi des cas de “surapprentissage”: le logiciel n'a pas intégré des règles, il a juste mémorisé les cas qui lui ont été fournis, son comportement sera donc erratique dans une situation réelle. Au final, on aboutit à des “hallucinations”: le logiciel fournit une réponse avec un haut niveau de certitude, mais complètement erronée. Ceci peut aboutir à ce qu'un semi-remorque en travers de la route soit pris à tort pour un panneau indicateur au-dessus de la route (scénario de l'un des premiers accidents mortels largement médiatisés avec une Tesla en mode Autopilot).

Une piste plus pragmatique: programmer des règles, lorsque c'est pertinent

D'autres constructeurs, voulant développer des voitures autonomes (ce qui est intrinsèquement dangereux), choisissent d'autres pistes, qui reposent moins sur la “magie” des réseaux de neurones, même s'ils sont utilisés pour certaines tâches.

Notamment, pour identifier l'environnement de la voiture, ils utilisent des capteurs LIDAR (caméras infrarouges spéciales qui mesurent les distances en chronomètrant le temps de retour d'un flash), ce qui leur permet de modéliser de façon plus fiable les voitures, piétons, et autres obstacles présents sur la route. Tesla n'utilise que des caméras classiques, ce qui demande au réseau de neurones de “deviner” bien plus de choses, avec le risque d'halluciner.

D'autres règles peuvent être programmées: comment reconnaître une voie de circulation, à quel emplacement se positionner, les règles du code de la route, etc... Si les ingénieurs savent programmer de façon exacte la meilleure manière de résoudre le problème, il serait absurde de le demander à un réseau de neurones.

L'analyse de risques: réelle, ou statistique?

Dans une analyse de risques réelles, on examine chaque évènement possible (la caméra est masquée par une feuille morte, il y a de la neige sur la route, le capteur de vitesse est déconnecté, le microprocesseur fait des erreurs), et on évalue les conséquences possibles.

Si Tesla fait ce genre d'analyse de risques, il ne le dit pas. Au contraire, il base son discours sur la statistique: avec un taux d'accident de 1 accident pour 10 millions de km, le mode Autopilot est moins dangereux qu'un conducteur humain (1 accident pour 1,5 millions de km pour les voitures Tesla sans Autopilot). Cet argument pose intrinsèquement problème:

• Si cette statistique est basée sur les versions précédentes du logiciel, qu'est-ce qui certifie qu'elle est encore valable avec la dernière version? Qui n'a pas vu une application smartphone se mettre à bugguer après une mise à jour?
  
• On a peu d'éléments pour vérifier la sécurité en cas de défaillance matérielle, ou de conditions inhabituelles (par exemple une pluie boueuse ayant obscurci la caméra)
• On a très peu d'éléments sur le comportement lors du vieillissement de la voiture, par exemple avec l'apparition de mauvais contacts
• On ignore comment se comportera le logiciel si les conditions évoluent: par exemple l'apparition de trottinettes ou d'autres engins, ou de voitures ayant une nouvelle forme, ou de camions avec 2 remorques au lieu d'une seule.
• On peut penser que le mode Autopilot est plus souvent utilisé dans des conditions optimales: trajet sur autoroute avec une bonne visibilité.
  

Dans n'importe quel domaine où la sécurité (avec un risque de décès) dépend du logiciel, l'argument statistique n'est jamais recevable à lui seul: il sert en complément, pour détecter des problèmes que l'analyse de risques n'aurait pas identifiés. On ne demande pas seulement de démontrer qu'une presse industrielle ne broie habituellement pas les bras des opérateurs, on exige de démontrer pourquoi ceci ne devrait jamais se produire.

L'argument statistique est d'autant moins recevable qu'il ignore certains risques susceptibles de provoquer des séries d'accidents. Par exemple si la Russie découvre comment pirater les voitures Tesla, et comment faire pour qu'elles provoquent une collision frontale ou se transforment en voitures-béliers un jour à une heure précise, on pourrait parfaitement avoir 1 million de morts pour un défaut qui n'avait jusque là produit aucun incident.

Les mensonges de Tesla

Tout ceci serait déjà inquiétant, mais il y a pire encore: l'argument statistique est basé sur les seules données de Tesla, analysé par eux-mêmes, et dont ils tirent eux-mêmes les conclusions. Et on connaît le goût d'Elon Musk pour contrôler l'information et la manipuler à son avantage y compris en publiant des informations totalement fausses, comme avec le rachat de Twitter (devenu X) pour 43 milliards de dollars, et son dénigrement pour les “anciens médias” (legacy medias), c'est-à-dire pour les vrais médias qui publient de vraies informations grâce à de vrais journalistes.

Mais un article de The Guardian du 5 juillet 2025 donne des informations beaucoup plus effrayantes encore. Des données fuitées de Tesla en 2022 révèlent des milliers de signalements d'anomalies par des utilisateurs du mode Autopilot, dont des accélérations dangereuses, des collisions évitées de peu (et plus de 1000 accidents), et des freinages impromptus au milieu d'une autoroute. L'article cite également une vidéo de Mark Rober (un YouTuber américain), qui montre qu'une Tesla évite beaucoup moins d'obstacles que d'autres voitures, équipées d'un freinage d'urgence grâce à une caméra LIDAR, ce dont les voitures de Tesla sont dépourvues.

Il s'avère que les accidents sont bien enregistrés, mais souvent non étudiés. L'affaire est juste marquée “résolue”, sans plus d'information (comme sur les forums d'aide, où votre question est indiquée comme “résolue” une fois que personne n'a été capable d'y répondre).

Par exemple, l'enregistreur présent dans les voitures Tesla (donc une “boîte noire”, comme dans les avions), n'enregistre pas nécessairement les accidents: s'il n'y avait pas de connexion internet mobile, les données ne sont pas transmises en temps réel. Et en cas d'incendie, l'enregistreur est détruit avec les données qu'il contient.

Il s'avère également que le système Autopilot se déconnecte souvent une fraction de seconde avant l'accident. Donc bien trop tard pour que le conducteur puisse réagir: un conducteur normal peut mettre une seconde à réagir, mais s'il était peu attentif parce qu'il avait activé le mode Autopilot, il peut mettre plusieurs secondes pour se rendre compte de la situation et de ce qu'il doit faire. Par conséquent, lorsque l'Autopilot se déconnecte parce qu'il ne sait plus quoi faire, le conducteur n'a aucune chance d'éviter l'accident. The Guardian suggère que Tesla utilise ce comportement pour considérer que l'accident a eu lieu avec le mode Autopilot non activé, mais Tesla n'a pas donné d'informations suffisantes pour le savoir clairement. Tesla affirme dans son rapport sur la sécurité que les accidents “avec Autopilot activé” incluent ceux où l'Autopilot a été désactivé dans les 5 secondes précédant l'accident. Ils affirment aussi ignorer les accidents où les airbags et les prétensionneurs de ceinture de sécurité ne se sont pas activés, et avoir ainsi réduit les statistiques d'accidents. Enfin, ils disent ignorer les accidents survenus à moins de 20 km/h (pourtant, on peut parfaitement tuer un piéton ou un cycliste à cette vitesse).

Parmi les autres défaillances, on note qu'un conducteur de Tesla, victime d'un accident ayant provoqué un incendie, n'a pas pu être sauvé par les premiers automobilistes ayant tenté de lui porter secours, à cause des poignées de porte qui sont restées enfoncées et donc inutilisables. Défaillance logicielle ou mauvaise analyse de risque sur le système électrique et mécanique? Toujours est-il que si ces voitures avaient des poignées de porte classiques, les premiers intervenants auraient peut-être pu ouvrir les portes avant que le feu ne devienne trop fort pour intervenir, et que le conducteur serait peut-être encore vivant.

Conclusion

La conclusion simple est que, si vous tenez à votre vie, vous ne devriez pas monter dans une voiture Tesla: vous n'avez pas les informations vous permettant d'être certain que la voiture est sûre.

Conçues comme des “ordinateurs sur roues”, ces véhicules devraient inciter à se poser la question: combien de fois avez-vous déjà fait face à un ordinateur ou un smartphone qui fait n'importe quoi ou qui plante? À chaque fois, vous avez survécu, mais qu'en serait-il si le logiciel tenait le volant? Personne ne devrait mettre sa vie dans les mains d'une machine aussi complexe et donc peu fiable qu'un ordinateur ou un smartphone.

Elon Musk est connu pour ses développements rapides et ses prises de risque. C'est contestable lorsqu'il s'agit de fusées (les autres opérateurs préfèrent vérifier tous les calculs, tous les problèmes possibles, et toutes les simulations informatiques, avant de lancer une fusée), mais c'est encore relativement peu grave tant que la fusée ne transporte pas d'astronautes. Mais pour une voiture, surtout avec un pilotage automatique, c'est tout simplement inacceptable. Il est déjà regrettable que les logiciels de bureautique soient conçus ainsi, rapidement et avec une faible fiabilité.

Tesla affirme que le nombre d'accidents est très faible. Vu sa manière de mentir dans d'autres domaines, et les dossiers qui semblent être mis sous le tapis selon The Guardian, on peut vraiment en douter.

C'est en fait toute l'analyse de risque qui semble faite à l'envers, la voiture n'a pas été conçue pour être sûre, c'est l'argumentation qui a été bâtie pour affirmer qu'elle l'est.

Pourquoi avoir mis des poignées de portes qui ne fonctionnent que lorsque l'ordinateur l'a décidé? En cas de défaillance, c'est un danger pour le conducteur.

De même, les systèmes de mise à jour à distance sont intrinsèquement dangereux, à cause du risque de piratage à grande échelle. On connaît les conséquences lorsque tous les ordinateurs sont attaqués le même jour par un ransomware (virus demandant une rançon pour récupérer vos données) dans un hôpital, une mairie ou une entreprise: ce serait infiniment pire en cas de piratage à grande échelle du logiciel des voitures Tesla, par exemple via un point d'accès WiFi qui usurperait le serveur de mise à jour de Tesla.

Il semble vain d'espérer une fiabilité satisfaisante en se basant sur des réseaux de neurones travaillant de façon statistique: il y aura toujours des cas inattendus qui seront mal gérés, soit à cause de la situation sur la route (le type d'obstacle, l'état de la route, la visibilité), soit à cause de l'état de la machine (un capteur en panne ou masqué, un mauvais contact, un processeur défaillant). Si on prétend faire fonctionner de façon sûre une voiture autonome (et c'est une véritable gageüre), il faut trouver une solution technique satisfaisante à tous les problèmes pouvant se produire, sans espérer que le réseau de neurones s'en sorte comme par magie.

Enfin, il semble que Tesla cache beaucoup d'informations, ce qui n'incite décidément pas à monter dans ces voitures.