Méthode · établi
L'IA à l'établi, ancrée dans vos documents.
Déposez un schéma PDF et une 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 boot 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.
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 (l’un cartographie la carte, l’autre 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 une 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.
Le schéma devient un graphe qu’on interroge
Un schéma PDF de soixante pages, c’est de la documentation pour humains 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 boot, 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.
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 boot 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.
Une session à l’établi, fer en main
À l’établi, l’agent pilote la 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.
Les limites, honnêtement
WrenchBoard est à son maximum avec un schéma et une 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 knowledge pack à 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.
FAQ
Questions fréquentes
C'est quoi, exactement, un knowledge pack ?
Un corpus structuré, propre à chaque appareil, que le système construit avant tout diagnostic : inventaire des composants, nets classifiés, séquence de boot 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 la boardview de mon appareil ?
Le système est à son meilleur 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 knowledge pack à 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 boot 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.