Kevin Lynagh sait concevoir un circuit imprimé. C’est justement le problème.
Il a commencé l’électronique avec Arduino en 2010, dessiné son premier PCB en 2015 et en a fabriqué environ une douzaine depuis, avec une poussée pendant la période où il construisait des claviers mécaniques étranges.1 Il estime avoir accumulé des centaines d’heures d’expérience. Mais ramené à la décennie, son rythme tourne autour d’un PCB par an.
Assez souvent pour ne pas être débutant. Pas assez souvent pour garder toute la procédure fraîche en mémoire.
À chaque nouveau projet, une partie du travail consiste donc à retrouver comment il avait fait la fois précédente : quelle commande exporte quoi, comment remplacer une géométrie DXF, où récupérer les composants JLCPCB, quels contrôles lancer avant fabrication, quels fichiers envoyer à l’assembleur. Lynagh compare lui-même cette sensation aux impôts : on connaît globalement l’exercice, puis l’interface a bougé et les notes de l’année dernière ressemblent soudain à des instructions archéologiques.1
Avec un agent de code, il a transformé ce coût de réorientation en un dépôt de scripts : Kevin’s KiCad Helpers.12
Ce qui est intéressant n’est pas que l’IA dessine un PCB à sa place. Elle ne le fait pas. Les scripts automatisent surtout tout ce qu’il sait déjà faire mais refuse désormais de réapprendre douze mois plus tard.
Une fois par an
Nous avons tendance à imaginer deux états face à un outil : novice ou expert. Il existe une catégorie beaucoup plus agaçante entre les deux, celle du travail expert mais peu fréquent.
On sait pourquoi une étape existe. On reconnaît les bons concepts. On peut juger si un résultat est absurde. Mais les détails opératoires se sont évaporés : nom exact d’une commande, ordre d’export, convention de fichier, option cachée dans une boîte de dialogue, petite vérification que l’on avait juré de ne plus oublier.
Le cerveau est remarquablement mauvais comme système de build.
Dans le cas de Lynagh, l’électronique elle-même n’est pas forcément le goulot. Le temps part dans les frontières entre outils. Il dessine sa mécanique dans Autodesk Inventor parce qu’il y dispose d’un solveur de contraintes et peut référencer d’autres géométries. Il importe ensuite les contours de carte et trous de fixation dans KiCad via DXF.12
KiCad sait importer un DXF, mais son interface graphique ne remplace pas automatiquement une géométrie déjà importée. Pour itérer, il faudrait effacer l’ancienne, réimporter la nouvelle, retrouver la bonne couche, recommencer à chaque changement mécanique.1
Son helper encode la convention dans le nom du fichier : panel_Edge.Cuts.dxf signifie groupe panel, couche Edge.Cuts. À chaque nouvelle version, il supprime le groupe portant le même identifiant, importe la géométrie et surveille le fichier pour recommencer dès qu’il change.2
Avec un watcher équivalent côté CAO mécanique, le pont devient presque vivant.
C’est une forme d’automatisation très différente du bouton « fais-moi une carte électronique ». Le dessin mécanique reste dans Inventor, la conception électrique reste dans KiCad. Le script retire la petite cérémonie répétitive qui relie les deux.
Le build
Le meilleur exemple est kkh build.
Lancé n’importe où dans un dépôt Git, l’outil cherche les projets *.kicad_pro, exécute les contrôles puis produit un dossier de sortie à côté de chaque carte.2 Le nom contient la date, la révision Git et indique si le worktree comporte des modifications non commitées.
À l’intérieur : BOM, positions de composants, netlist, archive Gerber, modèle STEP complet, STEP simplifié, PDFs du schéma et des faces du PCB.2
Ce n’est pas seulement pratique pour retrouver les fichiers. C’est une façon de répondre, six mois plus tard, à une question très physique : quel état exact du dépôt correspond à la carte qui est dans ma main ?
Le script expose même cette version comme variable KiCad afin que ${KKH_VERSION_DATE} puisse être imprimé sur la sérigraphie et se retrouver dans les Gerbers.2
La motivation de Lynagh est moins théorique. Il raconte avoir déjà fait fabriquer une carte après avoir oublié de lancer l’ERC, avec des broches de circuit intégré littéralement non connectées.1
Aujourd’hui, le code actuel lance bien ERC sur le schéma, puis DRC sur le PCB, avec l’option de parité entre schéma et carte, avant de construire les livrables.2 Le README contient à un endroit les acronymes inversés dans sa prose ; l’implémentation, elle, exécute les contrôles dans le bon domaine. Voilà une démonstration involontaire assez parfaite de la différence entre se souvenir d’une règle et la faire exécuter.
Les invariants
Lynagh va plus loin que les vérifications standard de KiCad.
Son analyseur génère une netlist puis charge les composants et leurs propriétés dans une base graphe DataScript.12 Il peut alors formuler des contraintes propres à ses cartes.
Il ajoute par exemple une propriété i2c aux composants concernés. L’analyseur construit la table des adresses du bus et échoue si la même adresse correspond à deux instances distinctes. Une propriété max_mA permet d’additionner des budgets de courant. Le code calcule aussi la capacité explicite reliée aux nets VCC ou VBUS et déclenche une erreur si elle atteint 10 µF, limite qu’il veut surveiller pour ses designs USB.12
Le point subtil est que ces règles ne prétendent pas être universelles. Certaines sont même codées en dur pour son propre workflow. Lynagh imagine éventuellement un petit langage permettant d’écrire des invariants directement dans les zones de texte du schéma, mais ce n’est encore qu’une piste.2
Cette personnalisation est précisément ce qui rend l’approche intéressante. Une checklist générique sait dire « lance l’ERC ». Un système personnel peut dire « sur mes cartes, je finis toujours par ajouter des condensateurs de découplage et oublier que mon budget VBUS est devenu trop élevé, donc bloque-moi avant que cela coûte de l’argent ».
La base locale
La sélection de composants possède le même problème de réorientation.
Lynagh fait assembler ses cartes par JLCPCB. Il a donc besoin de connaître stock, prix, boîtier, caractéristiques et disponibilité des pièces chez ce fabricant au moment de dessiner.1 Une recherche web répétée est lente, et une référence trouvée l’année précédente peut avoir changé de statut.
Son helper transforme une base JLCPCB locale en table SQLite indexée. La version décrite dans sa newsletter de juillet s’appuyait sur la base quotidienne de CDFER.1 Depuis un commit du 21 août, le code actuel télécharge plutôt la base du projet jlcparts, annoncée dans le script comme environ 5,7 Go et plusieurs millions de lignes, puis construit ses propres tables paramétriques.23
Résistances, condensateurs et inductances sont notamment normalisés en unités SI, ce qui permet une requête du genre « capacité = 100 nF et tension ≥ 16 V » sans parser à chaque fois des chaînes 0.1µF, 100nF ou autres variantes.2
Lynagh utilise SQLite directement, mais il montre également comment pointer un agent LLM sur cette base locale pour demander une courte liste de H-bridges répondant à des contraintes de tension, stock et prix.12
C’est peut-être l’usage le moins spectaculaire et le plus raisonnable d’un agent dans tout le projet. Il n’est pas chargé d’inventer la réalité du catalogue. Il aide à interroger rapidement une réalité téléchargée.
Pas un produit
Il serait facile de transformer ce dépôt personnel en « nouvelle suite IA pour l’électronique ». Lynagh fait presque tout pour empêcher cette lecture.
Le README dit sans détour que ces helpers ont été « vibe-coded », qu’ils fonctionnent pour lui, qu’ils sont partagés au cas où ils seraient utiles à d’autres, et qu’ils ciblent très précisément KiCad 10, macOS, un sandbox Debian pour ses agents et une fabrication JLCPCB.2 Le projet est sous licence MIT, mais il n’essaie pas de se présenter comme une couche universelle au-dessus de tous les EDA.
Cette absence d’universalité est une qualité ici.
Un outil personnel peut encoder les bizarreries que personne n’ajouterait à un produit général : ses noms de fichiers DXF, son budget de capacité, son assembleur favori, la manière dont son vieux MacBook Air souffre quand un STEP contient chaque pin de chaque puce comme solide séparé.12 Son export STEP remplace donc les composants par leurs boîtes englobantes lorsqu’il veut seulement vérifier les encombrements mécaniques.
La bonne abstraction n’est pas toujours celle qui sert un million de personnes. Parfois, c’est celle qui permet à une seule personne de reprendre un projet onze mois plus tard sans devoir redevenir elle-même.
Compiler l’oubli
L’usage d’un agent de code compte dans cette histoire, mais pas comme on l’entend habituellement.
Lynagh ne lui a pas demandé de devenir ingénieur électronique à sa place. L’agent a surtout abaissé le coût d’écriture de scripts assez personnels pour qu’il n’aurait peut-être jamais pris le temps de les transformer en logiciel auparavant.1
Le résultat durable n’est pas la conversation avec le modèle. C’est le dépôt.
Une commande qui sait comment fabriquer les livrables. Un watcher qui sait quelle géométrie remplacer. Une base qui sait comment représenter 100 nF. Un check qui sait qu’une collision I²C doit arrêter le build. Ces règles continueront à exister quand le contexte du chat aura disparu et quand Lynagh aura, très normalement, oublié les détails qui lui avaient donné envie de les écrire.
Pour les tâches quotidiennes, notre mémoire procédurale est souvent suffisante. Pour les tâches annuelles, elle est un cache avec une politique d’expiration particulièrement agressive.
L’idée de Kevin’s KiCad Helpers consiste à arrêter de lutter contre cette expiration.
Automatiser la conception aurait retiré des décisions à l’auteur. Automatiser le redémarrage lui rend du temps pour les prendre.