Un développeur connecte une IA au diagnostic d'une Jeep de 1994 avec un kit à 15 $

Un vieil équipement peut disposer d'une électronique fonctionnelle, mais d'un accès aux données peu pratique. Pour y connecter un agent IA, il faut d'abord un pont entre le connecteur physique et le programme. Le développeur MZULALI a présenté un tel pont sur une Jeep Cherokee de 1994 : le projet xj-scanner permet à un agent d'obtenir des données de diagnostic via un Arduino et Python. Pour les développeurs, c'est le schéma d'intégration lui-même qui est utile : donner au modèle un ensemble limité de commandes compréhensibles et obtenir des résultats vérifiables.

Comment le moteur devient accessible à l'agent

Le dépôt xj-scanner décrit un assemblage composé de trois fils, d'un Arduino Nano et d'un ordinateur portable. La carte se branche au connecteur de diagnostic situé sous le capot et se connecte à l'ordinateur en USB. L'auteur estime le coût approximatif du kit à 15 $, hors ordinateur portable.

Chaque maillon a sa tâche. L'Arduino assure l'échange avec l'électronique du véhicule, le programme sur l'ordinateur expose les commandes de diagnostic, et l'agent choisit lesquelles appeler selon la demande de l'utilisateur. C'est une séparation des responsabilités utile : le travail sur le protocole peut être vérifié indépendamment du raisonnement du modèle.

Un scénario possible : le propriétaire se plaint d'un fonctionnement instable du moteur après la montée en température. On charge l'agent de collecter les relevés et de les comparer dans le temps. Ensuite, une personne examine le journal obtenu et les explications proposées. Il s'agit d'un exemple d'usage, et non d'un résultat de réparation publié : disposer d'un accès aux capteurs ne confirme pas à lui seul que le diagnostic est correct.

Dans ce type de travail, c'est la chaîne de preuves qui compte. Quelles données ont été demandées ? Qu'a réellement renvoyé la voiture ? Sur quelle observation repose l'hypothèse ? Si la réponse de l'agent ne peut pas être reliée à des mesures précises, une belle explication n'est pas d'une grande aide dans un garage.

Ce que les développeurs peuvent retenir

Le projet montre comment étendre les capacités d'un agent via la ligne de commande. Le dépôt contient un scanner, des outils auxiliaires et des instructions pour l'agent. Un mode DEMO simulant une voiture est également prévu : on peut essayer la partie logicielle avant de se connecter à un véhicule. Ces fonctionnalités sont décrites dans le README du projet.

On en tire une conclusion d'ingénierie pratique : pour une telle intégration, il est raisonnable de commencer par un outil autonome. Il doit fonctionner sur commande explicite et renvoyer un résultat clair. Il est alors plus facile d'analyser le comportement de l'ensemble du système : l'erreur est-elle survenue lors de l'échange avec l'appareil, lors du traitement de la réponse ou dans les conclusions du modèle ?

La manière de présenter le résultat à l'utilisateur est également importante pour un produit. Une mesure, une hypothèse et une proposition de vérification suivante méritent des libellés distincts. La phrase « le capteur a indiqué telle valeur » n'a pas le même poids que « la cause est peut-être ici ». Mélanger ces niveaux crée une fausse assurance, même si le matériel fonctionne parfaitement.

Enfin, il est utile de conserver la possibilité de refaire l'action manuellement. Lorsque l'utilisateur voit la commande exécutée et la réponse brute, il peut vérifier le travail de l'agent ou transmettre les éléments à un spécialiste. Une telle interface rend l'automatisation plus compréhensible et facilite la recherche d'erreurs.

Où s'arrête la démonstration

L'auteur a testé le système sur une seule Jeep Cherokee XJ de 1994 équipée d'un moteur de 4,0 litres. La compatibilité avec d'autres calculateurs de la famille SBEC de Jeep et Chrysler de 1991 à 1995 est supposée, mais n'a pas été confirmée par des essais. Le code est publié sous licence GPLv3 ; les conditions et les limites du projet sont indiquées dans le dépôt.

Il existe aussi une différence importante entre observer et agir : le scanner prend en charge des tests intégrés des actionneurs. C'est pourquoi, dans son propre produit, il convient de définir séparément l'accès à la lecture et l'accès aux commandes qui modifient l'état de l'équipement. C'est déjà une question de conception de l'interface et des permissions de l'agent.

Pour l'instant, il s'agit d'un développement amateur dont la compatibilité vérifiée reste étroite. Il offre aux développeurs un matériau concret à étudier : un pont matériel, des commandes de diagnostic, un mode de démonstration et des instructions. Pour les product managers, c'est l'occasion de tester leur idée sur un petit périmètre : quelles mesures l'agent aide réellement à obtenir et à comprendre, combien d'actions il fait économiser et où l'humain doit encore revérifier la conclusion.