Nous avons déjà expliqué comment pense une voiture autonome — transformant un modèle perçu du monde en un plan d’action. Un plan, cependant, n’est pas encore un mouvement : quelque chose doit transformer “freiner maintenant” en une décélération réelle et physique de la voiture, de manière fiable, à chaque fois. Cette dernière étape du pipeline percevoir, penser, agir semble, sur le papier, la plus simple des trois — les voitures ont des accélérateurs électroniques et des directions assistées électriques depuis des décennies — mais elle cache l’unique exigence qui rend le Niveau 4 fondamentalement différent de tout ce qui l’a précédé : il n’y a plus d’être humain pour rattraper une défaillance.
De la liaison mécanique à la commande électronique
Nous avons déjà couvert comment la direction assistée a évolué de l’assistance hydraulique à un système entièrement électrique, et ce changement est précisément ce qui rend possible l’actionnement automatisé : dès lors que direction, freinage et accélération sont commandés électroniquement plutôt que par une liaison mécanique ou hydraulique directe aux actions du conducteur, un ordinateur peut émettre les mêmes commandes qu’un pied ou des mains humaines, sans aucune modification physique de l’architecture de base de la voiture. Cette famille de systèmes est globalement appelée commande par fil (drive-by-wire), et c’est la couche d’actionnement que les sorties du “penser” atteignent réellement.
Le fail-safe ne suffit plus
Dans une voiture de Niveau 2, si un actionneur de direction ou de freinage a un problème, le système peut simplement rendre le contrôle au conducteur, ou amener la voiture à un arrêt en douceur avec les mains du conducteur déjà sur le volant — c’est une conception fail-safe : quand quelque chose casse, on délègue à l’humain. Une voiture de Niveau 4, par définition, peut n’avoir aucun humain attentif disponible au moment précis où quelque chose casse. Ce seul fait impose une norme d’ingénierie complètement différente, appelée fail-operational : la voiture doit continuer à se comporter en sécurité, seule, assez longtemps pour atteindre un arrêt, en utilisant du matériel dégradé mais encore fonctionnel, et non un secours humain. En pratique, cela signifie dupliquer presque tout ce qui pourrait mettre la voiture hors service en cas de défaillance isolée : deux alimentations électriques indépendantes pour qu’une panne électrique n’aveugle pas tous les actionneurs à la fois, des voies d’actionnement redondantes pour la direction et le freinage, et des bus de calcul et de communication redondants faisant tourner le logiciel de contrôle lui-même, de sorte qu’un seul composant défaillant dégrade la capacité de la voiture plutôt que de la supprimer entièrement.
L’architecture compte autant que la redondance
Il ne suffit pas de simplement accoler un second composant au premier si les deux partagent un point de défaillance unique plus en amont — une alimentation partagée, un bug logiciel partagé, un canal de communication compromis partagé. C’est pourquoi l’architecture électronique et logicielle sous-jacente à l’actionnement est devenue un problème de recherche à part entière, pas seulement une nomenclature matérielle : comment les fonctions de contrôle sont partitionnées, avec quelle sécurité un système peut être mis à jour tout au long de sa vie sans introduire de nouvelles défaillances, et à quel point l’ensemble de la chaîne résiste à une cyberattaque qui pourrait autrement transformer la redondance en une faiblesse unique et partagée.
Où va l’état de l’art : la recherche européenne sur l’architecture de contrôle
La démonstration la plus complète à ce jour que perception, prise de décision et contrôle doivent être conçus comme un seul système fail-operational connecté, et non trois problèmes séparés assemblés, est venue de NewControl (2019-2023, 10,91M€, coordonné par AVL List en Autriche, sous l’entreprise commune ECSEL) : il a construit des plateformes virtualisées couvrant ensemble perception, cognition et contrôle pour la conduite hautement automatisée, délibérément centrées sur la “sécurité dès la conception” afin que toute la chaîne, et pas seulement les composants individuels, puisse démontrer une dégradation progressive plutôt qu’une défaillance brutale. Deux autres projets actuellement actifs abordent la question de l’architecture sous des angles opposés. EEA4CCAM (2025-2028, 5,99M€, coordonné par Infineon Technologies en Allemagne, partenariat CCAM Horizon Europe) développe une architecture de contrôle électronique embarquée centralisée et évolutive, intégrant la co-conception matériel-logiciel spécifiquement pour permettre un fonctionnement sûr et cyber-sécurisé ainsi que des flux de données intelligents à travers les systèmes de contrôle d’une voiture. Shift2SDV (2025-2028, 19,24M€ — l’un des plus grands projets uniques cités dans toute cette série Focus — coordonné par Virtual Vehicle Research en Autriche, financé via l’entreprise commune Chips) construit la couche logicielle complémentaire à l’échelle industrielle : un cadre commun de middleware et d’API destiné à permettre à toute la chaîne de valeur automobile européenne — constructeurs, équipementiers de rang 1 et spécialistes logiciels — de développer et de mettre à jour le logiciel de contrôle des véhicules définis par logiciel comme des modules interchangeables, plutôt que chaque entreprise ne maintienne son propre système fermé et monolithique.
Pourquoi cela compte plus qu’une fiche technique
Rien de la perception ou de la décision couvertes dans les parties précédentes de cette série ne compte si les dernières millisecondes — de la commande à l’actionneur, de l’actionneur à la roue — ne peuvent pas être considérées comme fiables lorsque quelque chose d’autre a déjà mal tourné ailleurs dans la voiture. C’est précisément pourquoi “agir” est jugé selon une norme différente du reste du pipeline : non pas la qualité de sa performance quand tout fonctionne, mais la grâce avec laquelle il se dégrade quand quelque chose ne fonctionne pas, sans personne au volant pour s’en apercevoir.
Photo : © Car-Shooters