Guide · l'IA à l'établi
Utiliser l'IA en réparation de cartes, sans réponse inventée.
Un chatbot généraliste répond de la même façon qu'il ait lu votre carte ou non. Voici la méthode qui change cela : chaque nom de composant sort d'une consultation, chaque type de fichier est traité pour ce qu'il sait vraiment, et la réponse prend la forme de la preuve plutôt que celle d'un paragraphe.
Ouvrir une carte et essayer01L'échec
Pourquoi un chatbot généraliste échoue sur une carte
Demandez à n’importe quel modèle généraliste où se trouve le fusible d’entrée sur une carte mère de portable qu’il n’a jamais vue. Il répondra. Il vous donnera un refdes, un emplacement, et exactement le ton qu’il emploie quand il a raison.
Ce n’est pas un défaut qu’on corrige avec un meilleur prompt. Un modèle de langage produit la suite la plus plausible, et sur une carte, le plausible est bon marché : les refdes se ressemblent, les rails d’alimentation portent les mêmes noms d’un fabricant à l’autre, et C29 existe sur presque toutes les cartes jamais produites. Le modèle n’a aucun mécanisme pour dire « je ne l’ai pas trouvé », puisque rien en lui n’est allé regarder.
À l’établi, le coût n’est pas une réponse embarrassante. C’est un composant dessoudé qui allait bien.
02La règle
La règle qui change tout : il ne parle que depuis une consultation
Le correctif est architectural, pas conversationnel. Chaque composant que l’agent nomme doit venir d’un appel d’outil contre votre carte réellement parsée ou le graphe construit depuis votre schéma réel. Pas de son entraînement, pas de son souvenir de la conversation.
Deux couches tiennent cette promesse dans WrenchBoard. Les outils eux-mêmes n’inventent jamais : demandez un refdes inconnu et ils renvoient « non trouvé » avec les correspondances les plus proches, ce qui oblige l’agent à choisir parmi des composants réels ou à vous poser la question. Et à la sortie, tout ce qui a la forme d’un refdes est contrôlé contre la carte parsée, si bien qu’un mot que la carte ne contient pas vous arrive marqué comme en cours de vérification plutôt qu’affirmé.
C’est toute la différence entre un assistant qui aide et un assistant qui se trompe avec assurance, et cela se teste sur n’importe quel outil que vous évaluez : demandez-lui un composant qui n’existe pas sur votre carte. Un outil ancré dit qu’il ne le trouve pas. Un chatbot vous le décrit.
03Les données
Chaque nature de donnée répond à une question différente
C’est le point que presque tout le monde rate, parce qu’il est tentant de traiter chaque fichier comme « du contexte à coller ». Chaque format porte une vérité différente, et perd sa valeur dès qu’on l’aplatit en texte.
- Le boardview connaît la géométrie. Où est la pastille, quelles pastilles partagent un net, ce qui se trouve de l’autre côté de la carte. Il ne sait pas ce que tout cela fait.
- Le schéma connaît la topologie. Qui alimente quoi, quel rail s’effondre quand celui-ci tombe, ce qu’une broche est censée être. Il ne sait pas où poser votre pointe de touche.
- La photo que vous venez de prendre connaît le présent. La corrosion, la puce rebillée, le fil volant du technicien précédent. Rien de tout cela n’est dans un document.
- La datasheet ou le manuel de service connaît l’intention. Ce que la pièce était censée faire, ce que l’usine s’attendait à mesurer.
- Le web connaît le collectif. Que ce modèle a un régulateur qui lâche souvent, qu’un lot avait de mauvaises pastilles. Utile, invérifiable, et à traiter comme une piste plutôt que comme un fait.
Un agent qui traite ces cinq sources comme un seul bloc de texte indifférencié vous rend une réponse moyenne. Un agent qui les garde séparées peut les croiser : le schéma dit que ce net devrait être à 3,3 V, le boardview dit que la pastille la plus proche est ici, votre photo dit que cette pastille est corrodée, et la mesure à prendre devient évidente.
04Regarder
Regarder est un outil, pas un paragraphe
Une planche de schéma n’est pas lisible comme du texte. L’information est dans la mise en page : quelle ligne part de quelle broche, quelle étiquette est posée sur quel fil. L’agent ne reçoit donc pas une transcription de la planche, il a le droit de la regarder, et de cadrer ce qu’il regarde, en zoomant sur une région d’une planche comme vous promèneriez une loupe sur un schéma imprimé. Pareil pour vos photos : il cadre la zone dont il a besoin au lieu de plisser les yeux sur une carte entière.
C’est aussi pour cela que la réponse ne devrait jamais être « quelque part vers le processeur ». Elle devrait être une planche, une région, un composant.
×405À l'établi
Comment travailler avec, concrètement
Donnez-lui le symptôme, pas votre diagnostic. « Morte, pas de LED, adaptateur 20 V branché » vaut mieux que « je pense que le PMIC est mort ». La seconde formulation restreint la recherche à votre hypothèse, qui est précisément ce que vous vouliez faire vérifier.
Mesurez ce qu’il demande, dans l’ordre où il le demande. L’ordre n’est pas arbitraire : chaque mesure est choisie pour éliminer la plus grosse branche de l’arbre de panne. Les prendre dans le désordre vous fait perdre le bénéfice de cette élimination.
Rapportez les échecs aussi précisément que les succès. « 0 V » et « OL » sont deux faits différents, et une étape de protocole qui échoue en dit plus à l’agent qu’une étape qui passe.
Contredisez-le. Un agent ancré peut être contredit par une mesure, et doit revoir son classement quand vous le faites. Si le vôtre défend sa première hypothèse contre votre multimètre, vous n’utilisez pas un outil de diagnostic, vous discutez avec une autocomplétion.
06La boucle
Une lecture n’est pas une réponse, c’est une ligne
La carte et la conversation ne font qu’un. Pointez n’importe quelle broche dans l’inspecteur : elle monte dans votre prochain message sous forme d’étiquette, F2 pin 1 (BAT1FUSED). Vous ne tapez jamais un refdes, l’agent n’a jamais à deviner de quel F2 vous parlez, et quand une de ses vues propose une mesure, le bouton lui renvoie la cible directement. C’est la partie qu’on prend pour un effet de démonstration : les deux moitiés sont câblées ensemble, donc une lecture prise sur la carte entre dans le contexte de l’agent sans passer par votre clavier.
Dites « F2 lit OL » et un agent ancré ne se contente pas d’être d’accord. Il appelle un outil qui écrit la lecture : ce qui a été mesuré, sur quelle pièce ou quelle broche, ce qui était attendu, et un mode de défaut que le moteur classe lui-même (ouvert, court-circuit, mort ou dégradé). La lecture devient une ligne du journal de cette réparation, attachée à ce sur quoi elle a été prise.
Trois choses en découlent, et ensemble elles sont tout l’argument d’un outil contre une fenêtre de chat.
Le classement suivant la lit. Redemandez des hypothèses : les observations rentrent avec elles. L’ordre change parce qu’un fait a changé, pas parce que vous avez insisté. C’est à cela que sert un classement.
La session suivante la lit aussi. Le journal est interrogeable : une carte vue il y a six mois ne repart pas de zéro, et la prochaine carte au même symptôme sur le même modèle non plus.
Et rien n’est retapé. La mesure prise à l’établi est celle qui sort dans le rapport, celle qui coche l’étape du protocole, celle que la base de connaissances garde. Vous ne l’avez saisie qu’une fois.
C’est la partie qui ne se voit pas dans une démonstration, et c’est celle qui décide si un agent sert à quelque chose à l’établi : les outils et les données sont le même objet. Un graphe de schéma qui répond par net, une base de règles qui répond par symptôme, un journal qu’on écrit et qu’on relit, un boardview qu’on peut pointer et sur lequel on peut mesurer. Un modèle privé de tout cela doit deviner. Un modèle relié à tout cela peut mesurer, et peut être contredit.
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.
07Le modèle
Ce qu’il reste au modèle
Regardez ce que le modèle ne fait à aucun moment. Il ne mémorise pas votre carte. Il ne la reconnaît pas sur une photo. Il ne se souvient d’aucune réparation vue pendant son entraînement. Il choisit l’outil à appeler, lit ce qui revient, et décide de la mesure qui vaut la peine d’être prise. Le savoir, lui, vit dans le graphe du schéma, dans la base de règles et dans le journal de la réparation. Le modèle apporte le raisonnement, pas les faits.
C’est aussi pourquoi une réponse ne devrait pas se présenter comme une conversation. Une valeur attendue face à une valeur mesurée, un classement avec ses probabilités, un protocole avec ses étapes : la forme de la preuve, pas celle du bavardage.
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
Je peux coller mon schéma dans ChatGPT, non ?
Vous pouvez, et il répondra. Le problème est qu'il répond de la même façon qu'il ait lu votre carte ou non. Un modèle généraliste n'a aucun moyen de vous dire qu'il n'a pas trouvé C29, alors il produit un C29 plausible. Sur une carte, une réponse plausible vous coûte un composant mort et un après-midi. Ce qui change le résultat n'est pas un meilleur modèle, c'est un modèle qui ne peut parler que depuis une consultation d'outil.
« Ancré », ça veut dire quoi concrètement ?
Que chaque refdes que l'agent vous montre est sorti d'un appel d'outil contre votre carte parsée ou le graphe du schéma, jamais de sa mémoire. Quand un refdes ne peut pas être vérifié, il apparaît comme en cours de vérification au lieu d'être affirmé, et le contrôle se fait sur la phrase entière avant confirmation. Cette garantie est dans le moteur, pas dans le prompt.
Pourquoi la nature du fichier compte-t-elle autant ?
Parce que chacun répond à une question différente. Un boardview sait où est une pastille, pas ce qu'elle fait. Un schéma sait ce qui est relié à quoi, pas où poser la pointe. Une photo sait à quoi ressemble votre carte aujourd'hui, corrosion comprise, ce qu'aucun document ne dit. Une datasheet sait ce qu'une pièce est censée faire. Un agent qui traite les quatre comme « du texte à lire » jette exactement ce qui faisait leur utilité.
Faut-il toujours prendre le niveau de raisonnement le plus profond ?
Non, et ce n'est pas une question d'économie. Un niveau profond sur une question qui demande une seule consultation produit une longue réponse bâtie sur un seul fait, qui se lit comme plus sûre qu'elle ne l'est. La profondeur paie quand la carte résiste : un symptôme à plusieurs causes possibles, un rail qui s'effondre en charge, une réparation qui a déjà échoué une fois.
L'IA remplace-t-elle mon métier ?
Non. Elle remplace les heures passées à chercher dans des pages de PDF le seul net qui compte. Vous sondez toujours, vous lisez toujours le multimètre, vous décidez toujours. Le travail de l'agent est de faire en sorte que la prochaine mesure que vous prenez soit celle qui élimine le plus de branches.
En quoi est-elle encore mauvaise ?
Sur tout ce que la documentation ne contient pas. Une carte sans schéma ni boardview la laisse avec vos photos, vos mesures et une connaissance générale de l'électronique, ce qui est une aide réelle mais bien plus mince. Elle ne voit pas non plus une soudure froide et ne sent pas le brûlé. Et elle ne saura pas que ce lot précis a une pastille fragile connue, sauf si quelqu'un l'a consigné.
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.