Il y a un moment que la plupart des ingénieurs automobiles connaissent bien. Un défaut apparaît lors d’un essai routier : une anomalie thermique, un message inattendu sur le réseau du véhicule, un comportement transitoire du système qui ne devrait pas se produire. L’ingénieur le remarque. L’essai routier prend fin, et le temps que quelqu’un examine les données, la fenêtre temporelle pertinente des signaux a disparu — noyée dans des journaux indifférenciés ou tout simplement jamais enregistrée. L’équipe programme donc un nouvel essai pour reproduire le phénomène.
Il ne s'agit pas d'un problème lié aux données. Les ingénieurs sont rarement confrontés à un manque de données. Il s'agit d'un problème d'architecture — qui se manifeste non seulement dans les laboratoires de validation, mais aussi à chaque étape du cycle de vie du véhicule, depuis les essais sur prototype jusqu'à la gestion de la qualité sur le terrain après le lancement.
J'ai passé des années à travailler à la croisée des domaines des logiciels automobiles et des systèmes intelligents, et la tendance est constante : l'industrie automobile a mis en place une infrastructure de données sophistiquée sans développer la couche d'intelligence qui permettrait de les exploiter. Nous collectons. Nous stockons. Nous analysons plus tard, si nous en avons le temps. Nous considérons l'intelligence comme quelque chose qui intervient après la collecte des données — sous la forme d'un rapport ou d'un tableau de bord — plutôt que comme quelque chose qui émerge en continu du véhicule lui-même.
Le problème de l'intelligence épisodique
Le modèle dominant actuel en matière d'analyse des données automobiles est de nature épisodique : il saisit un instant donné, mais pas sa cause, et nécessite un jugement humain pour établir le lien entre les deux.
Lors de la validation, cela se traduit par le problème de « re-drive ». Une équipe de test soumet un prototype à un scénario complexe — comportement lors d’une insertion sur autoroute, cycles thermiques de démarrage à froid, cas limites des systèmes ADAS dans des conditions de circulation mixte — et un événement anormal se produit. L’enregistreur de données n’était pas configuré pour capturer ce signal. Ou bien il l’était, mais la fenêtre de capture était trop étroite. Ou encore, le contexte inter-domaines approprié n’avait tout simplement pas été collecté en parallèle. L’équipe dispose d’un symptôme, mais ignore la cause profonde ; elle doit donc recommencer les essais. Avec un parc de prototypes limité, où chaque véhicule représente un investissement important et où les calendriers d’essais sont déjà serrés, le coût d’un nouvel essai ne se limite pas au carburant et aux kilomètres parcourus. Il s’agit également du temps d’ingénierie, de la disponibilité des prototypes et du risque de retard par rapport à la date butoir de mise en service opérationnelle (SOP), qu’il est préjudiciable de repousser.
Sur le terrain, ces mêmes contraintes architecturales se manifestent différemment. Un problème de qualité au sein du parc émerge : les réclamations au titre de la garantie commencent à se concentrer autour d’un mode de défaillance spécifique, ou une tendance se dessine dans les données d’exploitation. Au moment où l’équipe d’ingénieurs a rassemblé les éléments nécessaires pour diagnostiquer la cause première, la défaillance a déjà touché un grand nombre de clients. Les informations sont arrivées trop tard pour changer le cours des événements.
Ces deux problèmes ont la même origine : le système a été conçu pour stocker des données, et non pour générer des connaissances. Il existe une différence fondamentale entre avoir accès à des données et avoir accès à des informations exploitables — et combler cet écart, voilà précisément la raison d'être de l'Agentic Loop.
Présentation de l'Agentic Loop
La boucle agentique est une architecture d'intelligence en boucle fermée dans laquelle chaque étape alimente et affine la suivante, de manière continue, sans nécessiter d'intervention manuelle pour déclencher le cycle.
Cinq étapes. Chacune d'entre elles est précise et mûrement réfléchie :
- Détecter — Surveiller en continu les signaux provenant de tous les systèmes du véhicule afin d’identifier en temps réel les anomalies, les écarts et les situations méritant une analyse plus approfondie.
- Collecter — Déclenchez la collecte de données ciblées et riches en contexte exactement au moment et à l’endroit où cela compte — il ne s’agit pas d’un enregistrement en masse, mais d’une collecte intelligente liée aux événements détectés.
- Raison — Appliquer une analyse assistée par l'AI e à des données provenant de sources multiples afin de formuler des hypothèses, d'identifier les facteurs contributifs et de dégager des conclusions causales.
- Agir — Transmettez des informations pertinentes à l'ingénieur concerné, envoyez une mise à jour de configuration ou déclenchez une recommandation de service — de manière autonome et adaptée.
- Apprendre — Réinjecter les résultats dans les modèles de détection et de raisonnement afin que chaque cycle suivant soit plus précis que le précédent.
Le terme « système d’exploitation » est utilisé à dessein. Tout comme un système d’exploitation n’exécute pas les applications — il crée les conditions permettant à celles-ci de fonctionner efficacement —, l’Agentic Loop ne remplace pas le jugement de l’ingénieur. Il abstraie la complexité des données du véhicule afin que les ingénieurs puissent se concentrer sur la prise de décision plutôt que sur le traitement des données. Les ingénieurs de validation, les responsables qualité et les services après-vente peuvent tous s’appuyer sur la même boucle d’intelligence — à l’instar des différentes applications qui s’exécutent sur un système d’exploitation partagé —, chacun tirant ce dont il a besoin d’une infrastructure commune.
Voilà en gros le fil conducteur de l'argumentation. Mais le terme « système d'exploitation » est une métaphore facile à formuler, mais bien plus difficile à justifier. Elle ne tient la route que si chaque étape de la boucle correspond réellement à ce qui est décrit ci-dessus.
Dans la deuxième partie de cet article de blog, nous passons en revue une à une les étapes « Détecter », « Collecter », « Réfléchir », « Agir » et « Apprendre », et nous expliquons ce qui change à chacune d'entre elles.
