Le logiciel de microsoudure qui raisonne avant de souder.

Ce qu’un logiciel doit apporter à un atelier de microsoudure

Le remplacement d’écran ou de batterie se passe de logiciel. C’est au niveau composant, courts-circuits d’alimentation, rails manquants, BGA en défaut, corrosion après oxydation, que l’outillage logiciel fait la différence entre une réparation d’une heure et une carte qui traîne trois semaines sur l’étagère.

Un bon logiciel de microsoudure doit répondre à quatre besoins concrets :

• Lire la documentation de la carte : boardviews aux formats incompatibles entre eux, schémas PDF de centaines de pages, références croisées entre les deux.
• Localiser physiquement : passer d’un refdes (U7, R49, F1) à sa position réelle sur la face top ou bottom, avec les nets qui y arrivent.
• Structurer le diagnostic : transformer un symptôme (« carte morte, pas de LED ») en une suite ordonnée de mesures, plutôt qu’en sondage au hasard.
• Capitaliser : ce que vous avez trouvé sur une carte doit servir à la suivante.

WrenchBoard a été conçu autour de ces quatre besoins, avec une particularité : un agent IA est branché sur chacun d’eux.

Lire la carte : boardview et schémas dans le même outil

WrenchBoard embarque un lecteur boardview qui ouvre nativement treize formats, du KiCad .kicad_pcb au .brd historique, en passant par .fz, .cad, .bdv, .asc, .tvw et le .pcb chiffré XZZ. La carte s’affiche dans un canvas interactif : recherche par refdes, surbrillance de nets, bascule top/bottom, filtrage par type de composant, au bureau comme au tactile. Un format mérite une mention : l’export .pcb XZZ porte les valeurs de test d’usine, la résistance et la tension attendues sur chaque net, ce qui permet à l’agent de comparer votre mesure à ce que la carte devrait afficher.

Côté schémas, le pipeline d’ingestion transforme un PDF en graphe électrique : chaque page passe dans un modèle de vision (Claude), les composants et liaisons sont extraits, fusionnés, classés en arêtes d’alimentation, de logique et de connectique, puis compilés avec une séquence de démarrage inférée. Le résultat n’est pas une image annotée : c’est une structure de données interrogeable, sur laquelle on peut simuler « que se passe-t-il si F1 est ouvert ? ».

Du symptôme au protocole de mesure

Le cœur du flux de travail : vous décrivez le symptôme en langage naturel, l’agent de diagnostic croise les règles de panne connues de l’appareil avec le graphe électrique, et propose une hypothèse classée par probabilité, puis un protocole de mesure pas-à-pas : continuité aux bornes du fusible, tension sur tel point de test, contrôle diode sur tel rail.

Chaque mesure que vous rapportez est consignée dans le journal de réparation et resserre l’hypothèse. L’agent ne décrit pas la carte : il la pilote. Quand il vous demande de sonder R49, le boardview zoome dessus, met le composant en surbrillance et atténue tout le reste.

Pour structurer la recherche de panne sur les alimentations, voyez aussi la page diagnostic de carte mère, qui détaille la méthode arbre de pannes appliquée par l’agent.

Anti-hallucination : la contrainte qui change tout

Un modèle de langage libre de ses réponses finira par inventer un condensateur. WrenchBoard impose l’inverse : chaque référence de composant citée par l’agent est validée contre la carte réellement parsée. Un refdes inconnu est signalé, jamais affirmé. Les règles de panne viennent d’une base de connaissances par appareil, construite hors-ligne et auditée, pas de la mémoire du modèle.

C’est la différence entre demander conseil à un chatbot généraliste et travailler avec un outil métier : le premier vous répondra toujours quelque chose, le second ne cite que ce qu’il peut prouver sur votre carte.

Capitaliser : la mémoire entre les réparations

Chaque session laisse une trace structurée : mesures, cause confirmée, résumé narratif. Les patterns de panne récurrents et les playbooks de diagnostic sont partagés entre appareils en lecture seule, le carnet de la réparation en cours est en lecture-écriture. Au retour d’une carte similaire, l’agent relit ce qui a déjà fonctionné, comme le ferait le collègue senior à qui on demande « tu l’as déjà vue, cette panne ? ».

Stock de donneuses, microscope, et un établi tactile

Trois surfaces de plus que l’agent sait atteindre. Stock de donneuses : déclarez vos cartes mortes comme donneuses, WrenchBoard indexe leurs pièces récupérables, et quand une réparation a besoin d’un remplaçant l’agent cherche dans votre propre pile par signature électrique (type, valeur, package, MPN) avant que vous ne commandiez quoi que ce soit. Capture microscope : il peut tirer une image fixe de votre microscope USB ou de votre webcam en pleine session pour regarder ce que vous voyez. Et le boardview est entièrement tactile sur téléphone et tablette, avec pinch-zoom, pan et tap-select, pour que l’écran de diagnostic fonctionne sur l’appareil que vous gardez à côté de la station à air chaud.

Dans le navigateur, ou chez vous

WrenchBoard tourne dans le navigateur sans installation, avec un plan gratuit pour commencer sur les appareils couverts. Le moteur de diagnostic est source-available : un atelier qui veut garder schémas et historique en local peut l’auto-héberger pour son propre établi. Le projet a pris la 2ᵉ place au hackathon Anthropic « Built with Opus 4.7 » en avril 2026, et le code se lit sur GitHub.