Méthode · établi
L'IA à l'établi, ancrée dans vos documents.
Déposez un schéma PDF et un boardview dans WrenchBoard et, deux minutes plus tard environ, vous travaillez sur un appareil que le système connaît vraiment : composants inventoriés, nets classifiés, séquence de démarrage cartographiée, règles de panne auditées. Voici ce qui se passe pendant ces deux minutes, et pourquoi rien de ce que l'agent vous dit ensuite n'est laissé au hasard.
Ouvrir une carte sur l'établi01Deux minutes
Deux minutes entre les documents et une connaissance exploitable
Un technicien senior qui a vu une carte cent fois porte son architecture dans sa tête. WrenchBoard construit ce modèle mental explicitement, avant que la première pointe de touche ne se pose sur la carte.
La construction est assurée par une petite fabrique de rôles Claude spécialisés : un Scout rassemble ce qui est connu de l’appareil, un Registry fige l’inventaire des composants, trois Writers travaillent en parallèle (le premier cartographie la carte, le deuxième rédige le tableau clinique des pannes, le troisième compile le vocabulaire), et un Auditor contrôle le résultat avant tout stockage. Depuis un schéma PDF et un boardview, la passe complète prend environ deux minutes.
Le résultat n’est pas de la prose : c’est un corpus interrogeable, sur disque, par appareil. Chaque session de diagnostic qui suit y lit et y écrit : mesures, causes confirmées, questions ouvertes. Rien ne repart de zéro.
02Le graphe
Le schéma devient un graphe qu’on interroge
Un schéma PDF de soixante pages, c’est de la documentation pour des lecteurs qui ont des heures devant eux. WrenchBoard le compile, page par page, avec la vision de Claude, en un graphe électrique : quels nets existent, à quelle classe ils appartiennent, quels composants s’y trouvent, à quoi ressemble la séquence de démarrage, avec un rapport de qualité indiquant quelle part du document a été lue avec confiance.
Cette compilation transforme « chercher dans le PDF » en « poser une question à la carte ». Ce que fait tel composant, ce qui partage son rail, ce qui devrait être alimenté à telle phase de boot : les réponses sortent du graphe en quelques secondes, et elles citent le graphe, pas la mémoire du modèle. Le compilateur a sa propre page.
03Les moteurs
Des moteurs déterministes sous le raisonnement
L’agent ne devine pas les chaînes causales, il les délègue. Deux algorithmes purs forment le cœur de la pile de diagnostic et ne font aucun appel à un modèle de langage au runtime :
- Le simulateur avance la séquence de démarrage de la carte phase par phase et produit une chronologie : quels rails sont morts, quels composants ne sont pas alimentés, ce qui bloque chaque phase.
- Le moteur d’hypothèses prend une observation partielle (la poignée de mesures que vous avez réellement faites) et énumère les candidats à une ou deux pannes qui l’expliqueraient, classés selon leur adéquation.
Déterministe veut dire vérifiable : les mêmes mesures produisent toujours les mêmes candidats, et chaque chaîne causale peut être contrôlée à la main contre le graphe. Le travail de l’agent est de raisonner au-dessus de cet échafaudage en langage clair, au niveau du technicien qui l’utilise, pas d’improviser de l’électronique.
04La session
Une session à l’établi, fer en main
À l’établi, l’agent pilote le boardview pendant que vous travaillez : il surligne la broche à mesurer, trace le net suspect, annote le protocole de mesure sur la carte elle-même. Si son raisonnement a besoin d’yeux, il demande une image à votre microscope USB ; vous pouvez aussi déposer un gros plan d’une puce suspecte dans la conversation.
Vous mesurez, il interprète, la boucle continue. Chaque mesure est journalisée, chaque capture est conservée, et la session entière peut être rejouée ensuite : ce qui a été dit, ce qui a été décidé, ce que l’agent a réellement vu. Le workflow de diagnostic complet est structuré comme un senior le mènerait, mais le fer ne quitte jamais votre main.
La mesure part avec votre prochain message
BAT1FUSED · 0 V · 14:02 Vous ne la retapez pas, et l'agent la lit avant de répondre.
05Les limites
Les limites, honnêtement
WrenchBoard est à son maximum avec un schéma et un boardview en main ; c’est là que les inventaires vérifiés et les chaînes déterministes fonctionnent à pleine capacité. Sans ces documents, il construit quand même un premier pack de connaissances à partir de sources publiques : utile, mais plus mince. Cet écart n’est pas une limite logicielle, c’est un problème d’accès à la documentation, et c’est le vrai sujet derrière « trop complexe à réparer ». La cible de développement canonique est la carte mère du MNT Reform, choisie précisément parce que sa documentation est ouverte sous licence CERN-OHL-S.
Le voir travailler
Le même agent, sur une vraie carte
Ce n'est pas une maquette, c'est l'établi lui-même avec son interface, sur le pack MNT Reform exporté du moteur : 487 composants réels et 2066 pastilles réelles. Chaque étape ci-dessous est ce que le moteur répond sur cette carte, des règles de l'appareil pour le symptôme jusqu'au graphe du schéma derrière le fusible d'entrée F1 et au net qu'il alimente. Voici ce que l'agent fait d'une carte qui ne s'allume pas.
Huit appels d'outils, chacun une vraie réponse du moteur sur cette carte, et pas un seul composant nommé de mémoire.
FAQ
Questions fréquentes
C'est quoi, exactement, un pack de connaissances ?
Un corpus structuré, propre à chaque appareil, que le système construit avant tout diagnostic : inventaire des composants, nets classifiés, séquence de démarrage inférée, règles de panne connues. Il est assemblé par quatre rôles Claude spécialisés (un Scout, un Registry, trois Writers en parallèle, un Auditor) en deux minutes environ, puis stocké sur disque où chaque session ultérieure peut l'interroger et l'enrichir.
Faut-il le schéma et le boardview de mon appareil ?
Le système donne sa pleine mesure avec les deux : c'est là que les moteurs déterministes produisent des chaînes causales vérifiables. Sans ces documents, il ne s'effondre pas ; il construit un premier pack de connaissances à partir de sources publiques. L'écart entre les deux est exactement celui que les lois sur le droit à la réparation doivent combler.
Déterministe, ça veut dire quoi concrètement ?
Deux moteurs travaillent sous le raisonnement de l'agent : un simulateur de séquence de démarrage qui avance phase par phase et produit une chronologie des rails morts et des composants morts, et un moteur d'hypothèses qui énumère les candidats à une ou deux pannes expliquant une observation partielle, classés selon leur adéquation avec vos mesures. Aucun des deux ne fait appel à un modèle de langage au runtime : même entrée, même sortie, chaque chaîne vérifiable à la main.
L'agent peut-il vraiment voir ma carte ?
Oui, à votre initiative. Branchez un microscope USB ou une webcam à l'établi et l'agent demande une image quand son raisonnement en a besoin ; vous pouvez aussi déposer une photo macro dans la conversation à tout moment. Les captures sont conservées avec la réparation : une session peut être rejouée de bout en bout, avec les mots, les décisions et les photos que l'agent a regardées.
Que se passe-t-il si l'agent cite un composant qui n'existe pas ?
Il ne peut pas l'affirmer. Une recherche de référence qui échoue renvoie les correspondances réelles les plus proches, et l'agent doit choisir parmi elles ou vous demander. En seconde couche, un sanitizer côté serveur analyse chaque message sortant et marque visiblement toute référence qu'il ne peut pas vérifier contre la carte parsée, avant que le texte n'atteigne votre écran.
Commencer
Essayez Wrench Board gratuitement, dans votre navigateur.
Plan gratuit, sans carte bancaire. Ouvrez l'app, choisissez un appareil couvert, et lancez une session de diagnostic avec l'agent.