---

Le jour où l’assistant a proposé un plan de masse à 3 mm du connecteur

La scène se joue dans un atelier, un soir de semaine, sur un projet qui n’a rien de spectaculaire : une carte à microcontrôleur, deux alimentations, un connecteur d’alimentation en bord de carte, un peu de radiofréquence autour d’un module. Le concepteur travaille sous KiCad 10.0.7 — la version stable publiée le 7 octobre 2026 — et il a installé, comme beaucoup en cette fin d’année, un plugin qui relie un assistant conversationnel au moteur de CAO. Il pose une question en langage naturel : « propose un préplacement pour les blocs d’alimentation et un plan de masse cohérent avec le connecteur J1 ». L’assistant répond en quelques secondes, avec un plan de cuivre propre, des zones bien découpées, un rendu visuel convaincant.

Puis le concepteur regarde de plus près. La zone de masse principale s’arrête à trois millimètres du connecteur d’alimentation, et le retour de courant du condensateur de découplage passe à côté d’un via de puissance. Rien de dramatique sur un prototype de bureau. Sur une carte qui doit tenir un courant d’appel et un environnement bruité, c’est le genre de détail qui transforme une belle image en champ de rayonnement. Le plugin n’a pas menti : il a produit une proposition plausible. Il n’a pas produit une proposition vérifiée.

C’est toute la tension de ce dossier, et elle n’est pas technique au premier chef : elle est organisationnelle. En 2026, l’IA générative dans le workflow PCB ne remplace pas le concepteur, elle déplace son travail. Elle produit des propositions à un rythme qu’aucun humain ne peut égaler, et elle les produit avec une assurance qui ne dit rien de leur validité électrique. Le concepteur, lui, reste celui qui appuie sur « envoyer en fabrication ». La question n’est donc pas « l’IA va-t-elle concevoir nos cartes ? » mais « comment organise-t-on la conception pour que des propositions générées restent auditables, révisables et rejetables ? ».

Nous allons croiser trois fils : l’état réel de l’écosystème KiCad 10 (ce que la version apporte, ce que les plugins ajoutent, ce que personne ne documente), les retours terrain disponibles — y compris ceux qui ne sont pas des benchmarks, et il faut le dire clairement —, et les limites vérifiables du côté de la vérification, de la traçabilité et de la responsabilité. Sans mythologie, mais sans déni non plus : l’IA fait déjà gagner du temps, à condition de savoir où.

---

KiCad 10 en 2026 : ce que la version apporte vraiment (et ce qu’elle ne promet pas)

Premier point de méthode, et il est important : la version 10 de KiCad existe, elle est datée, et son rythme de maintenance est documenté. La version 10.0.0 est sortie en mars 2026, et la série de correctifs s’est enchaînée tout l’été et l’automne : 10.0.6 le 29 août 2026, puis une release candidate 1 le 27 septembre, une release candidate 2 le 3 octobre, et enfin la 10.0.7 stable le 7 octobre 2026. La documentation 10.0 est en ligne. Tout discours sur « KiCad 10 et l’IA » qui ne part pas de ces faits-là part de nulle part.

Ce que la version apporte relève du cœur open source, et c’est là qu’il faut être précis. Les revues de la 10.0 — notamment celle de Tech Explorations — mettent en avant trois familles d’évolutions : le réglage de longueur pour les signaux rapides (high-speed tuning), les variantes de cartes (assemblage, composants alternatifs), et le reste de la mécanique habituelle du moteur PCB. Le site officiel continue de décrire KiCad comme un ensemble éditeur de schémas (hiérarchique, jusqu’à des centaines de feuilles), éditeur de PCB avec routeur interactif, visualiseur 3D avec raytracer, simulateur SPICE intégré et vérificateur de règles électriques. Le mot « interactif » n’est pas un détail : il désigne un routage guidé par l’humain, où le logiciel aide à respecter les contraintes pendant que la main trace. Ce n’est pas un autorouteur, et ce n’est certainement pas un générateur.

Point tout aussi important : aucune fonction d’IA générative native n’est documentée dans KiCad 10. Ni génération de schéma intégrée, ni placement automatique par modèle, ni assistant conversationnel dans le menu. Ce que la version offre, c’est une surface d’extension : un système de plugins, des fichiers de projet lisibles, des formats ouverts, et désormais des points d’entrée qui rendent possible le branchement d’un assistant externe. La nuance est capitale : KiCad ne fait pas d’IA, KiCad permet l’IA. Toute la différence entre un logiciel qui promet et un logiciel qui expose.

Élément	Statut en 2026	Source / nature
KiCad 10.0.0	Sortie mars 2026	Annonce officielle kicad.org
KiCad 10.0.6	Sortie 29 août 2026	Annonce officielle kicad.org
KiCad 10.0.7 (stable)	Sortie 7 octobre 2026	Annonce officielle kicad.org
Réglage de longueur, variantes	Fonctionnalités cœur de la 10.0	Revue Tech Explorations
Routeur interactif	Cœur, assisté par contraintes, non autoroutage	Site officiel
IA générative native	Non documentée	Absence dans la doc 10.0
Plugin Konnect (LLM via MCP)	Tiers, binaire Rust, 228 outils	Fellow, DevTrends, Adafruit
Freerouting 2.3.0	Autorouteur classique, régression signalée	Dépôt GitHub, août 2026

Face à cette base, le réflexe de méfiance s’impose devant les annonces de blogs et de dépôts GitHub qui promettent « KiCad 10 + IA » sans dire ce qu’ils branchent, ni sur quel modèle, ni avec quelle licence. Un dépôt communautaire qui décrit un « plugin LLM pour KiCad 10.0 » n’est pas une preuve de maturité ; c’est une preuve d’intérêt. Et l’intérêt, en 2026, est massif.

---

Génération de schémas par LLM : ce que ça produit, ce que ça coûte à vérifier

L’outil qui a fait basculer la conversation s’appelle Konnect. Décrit par Fellow le 14 octobre 2026 comme un « plugin KiCad natif, un binaire Rust unique », il permet à Claude et à d’autres assistants de concevoir schémas et circuits imprimés via MCP (Model Context Protocol), avec 228 outils exposés. Le blog DevTrends en donne une description convergente le 7 septembre 2026, et Adafruit a repris l’information le 26 octobre 2026. Un article de MSN va jusqu’à titrer que « la conception de PCB n’a jamais été aussi facile, grâce à Claude ». Voilà pour le discours ambiant.

Ce que ces outils font réellement, quand on les regarde fonctionner, tient en quatre familles d’usages. D’abord la génération de blocs de schéma : décrire une fonction (« un régulateur buck 5V→3,3V, 2 A, avec enable ») et obtenir une proposition de topologie avec les composants périphériques. Ensuite la conversion et la manipulation de netlists : reformater, renommer, détecter des incohérences de nommage entre feuilles. Puis la suggestion de découplage : proposer un jeu de condensateurs en fonction des broches d’alimentation d’un composant. Enfin la traduction de datasheets en symboles : lire un PDF de constructeur et en extraire une broche, un nom, une fonction — travail ingrat qui consomme des heures et que les LLM attaquent volontiers.

Sur ces quatre terrains, le gain est réel mais inégal. La traduction de datasheet en symbole est probablement l’usage le plus rentable, parce que l’erreur y est détectable : une broche mal nommée se voit à la relecture, et la vérification est mécanique. La génération de topologie est plus risquée, parce que l’erreur y est silencieuse : un schéma qui « a l’air » d’un régulateur fonctionne sur le papier et peut osciller en réalité. Entre les deux, tout un gradient de risque que le concepteur doit apprendre à cartographier.

Les limites sont mesurables, même si personne ne les mesure publiquement. Erreurs de connectique : un net qui relie deux broches qui ne devraient pas l’être, ou qui en oublie une. Confusion de broches : les composants à brochage dense, où les noms se ressemblent, sont un terrain de choix pour les hallucinations. Absence de contraintes électriques : un LLM ne sait pas qu’un condensateur de découplage doit être proche de la broche qu’il découple ; il sait qu’il faut un condensateur. Coût de relecture : c’est le point aveugle. Générer un schéma prend des secondes ; le relire correctement prend le temps qu’on aurait mis à le dessiner. Le gain net n’est positif que si la relecture est plus rapide que la conception — ce qui est vrai pour un bloc connu, faux pour un bloc nouveau.

Et il faut le dire sans détour : il n’existe aucun benchmark public solide, en 2026, sur la qualité des schémas générés par LLM pour KiCad. Pas de jeu de test standardisé, pas de métrique partagée, pas d’étude indépendante comparant un schéma généré à un schéma humain sur un corpus de référence. C’est un problème structurel, pas un détail : sans mesure, les affirmations des uns et des autres — « ça marche », « ça ne marche pas » — sont également invérifiables. Le test de Hackaday du 5 septembre 2026, « Can AI Now Design PCBs That Just Work? », pose exactement la bonne question, et sa valeur est justement d’être un test, pas un benchmark : une expérience documentée, pas une loi générale.

---

Placement et routage assistés : l’IA là où elle aide, l’IA là où elle piège

C’est sur le placement et le routage que la comparaison avec les alternatives établies devient intéressante — et instructive. Le paysage compte quatre familles d’outils, et il faut les distinguer si on veut éviter de tout mettre dans le même sac « automatique ».

Le routage manuel expert reste la référence de qualité. Il est lent, il ne passe pas à l’échelle sur une carte dense sans effort, mais il produit des géométries que le concepteur comprend, donc qu’il peut défendre en revue et corriger en cas de problème.

Les autorouteurs classiques, type Freerouting, sont des algorithmes déterministes : ils optimisent une fonction de coût sous contraintes. Ils ne « comprennent » rien, mais ils sont reproductibles, et leurs échecs sont lisibles. La leçon de la régression signalée en août 2026 sur le dépôt GitHub de Freerouting est précieuse : la version 2.3.0 produisait des routes que son propre scoring signalait comme violant les règles de clearance, là où la 2.2.4 routait proprement. Autrement dit : même un autorouteur classique, éprouvé, peut régresser silencieusement. Si l’outil déterministe régresse, qu’attendre d’un outil probabiliste ?

Les scripts et plugins non-IA — comme les générateurs de grille de vias de stitching évoqués par ScriptedPCB le 13 septembre 2026 — font une chose et la font bien : ils appliquent une règle géométrique. Ils sont auditables ligne par ligne.

Les assistants IA arrivent par-dessus, et leur apport réel se situe à des endroits précis. L’exploration de topologies : proposer trois préplacements différents pour un bloc, que le concepteur compare en quelques minutes au lieu d’en dessiner un seul. Le préplacement grossier : donner une disposition approximative des blocs fonctionnels, que l’humain affine. Les suggestions de contournement : quand une route bloque, proposer un chemin alternatif que le concepteur n’avait pas vu. La génération de contraintes : transformer une intention (« ce bus doit rester apparié en longueur ») en règles paramétriques exploitables par le moteur.

Là où l’IA piège, c’est partout où la proposition est visuellement convaincante et électriquement douteuse. Géométries non fabricables : un angle trop aigu, un espacement sous le minimum du fabricant. Vias hors règles : un via de changement de couche placé sans respecter l’anneau ou la distance au bord. Chemins critiques : une piste d’horloge qui traverse une zone de découpage du plan de masse. EMI : un retour de courant qui fait le tour de la carte. Aucun de ces défauts ne se voit à l’écran sans zoom et sans règle. C’est précisément pourquoi le DRC existe — et pourquoi il devient le point de passage obligé.

Faut-il des chiffres ? On aimerait. Les retours terrain disponibles — forums, billets, expériences de concepteurs — laissent entrevoir des gains sur les tâches périphériques et des reprises fréquentes sur les tâches critiques. Mais aucune donnée chiffrée publique ne permet de dire « l’IA fait gagner X % de temps sur le routage ». Les seules métriques qu’on trouve sont des affirmations de fournisseurs ou des impressions de blogueurs. Dans un magazine d’ingénierie, il faut le dire : ce n’est pas encore mesuré, et l’absence de mesure est en soi une information sur la maturité du domaine.

---

DRC, ERC, traçabilité : le mur de la vérification que l’IA ne franchit pas

Le vrai goulot d’étranglement du PCB assisté par IA n’est pas la génération. C’est la vérification. Et c’est là que KiCad 10, avec son ERC et son DRC, redevient l’outil central — non pas comme frein, mais comme institution.

Le pipeline est connu de quiconque a mis les mains dans un projet : l’ERC vérifie la cohérence électrique du schéma (broches non connectées, conflits de sortance, alimentations mal déclarées), le DRC vérifie la géométrie du PCB contre un jeu de règles (clearance, largeur de piste, anneau de via, masque). Ces vérifications sont déterministes, reproductibles, et — c’est essentiel — elles ne dépendent pas de qui a produit le design. Un DRC passe ou ne passe pas, que la piste ait été tracée par un humain ou proposée par un modèle.

Le problème commence quand on veut auditer une suggestion. Le DRC dit « cette géométrie viole la règle R ». Il ne dit pas « cette géométrie a été proposée par tel modèle, dans telle version de plugin, à partir de tel prompt, et voici pourquoi elle a été acceptée ». C’est la question de la traçabilité, et elle est beaucoup plus difficile qu’elle n’y paraît. Un design généré sans piste d’audit est un passif, pas un actif : le jour où la carte tombe en panne, personne ne peut reconstituer le raisonnement. Le concepteur se retrouve avec un objet qu’il a signé mais qu’il ne peut pas expliquer.

La responsabilité, elle, ne se dilue pas. Le concepteur reste signataire du design, au sens industriel et juridique. Un fabricant qui reçoit un Gerber ne demande pas quel LLM a proposé le plan de masse ; il demande qui a validé. Les normes de conception, les exigences de sécurité fonctionnelle, les procédures qualité internes pointent toutes vers un humain identifié. Aucun plugin ne signe à votre place, et aucun ne l’a jamais prétendu — mais l’ergonomie conversationnelle crée une illusion de délégation qu’il faut activement combattre.

D’où une conclusion pratique : la valeur d’un workflow IA se mesure à sa capacité à produire de la preuve. Journaliser les prompts, versionner les plugins, conserver les états intermédiaires, attacher à chaque décision de design la trace de la proposition et du motif d’acceptation ou de rejet. Ce n’est pas de la bureaucratie : c’est ce qui permet de dire, six mois plus tard, pourquoi cette piste passe là. Et c’est aussi ce qui permet de mesurer, enfin, les gains réels.

---

Ce que l’IA change aux compétences : du dessinateur au réviseur de propositions

Il y a un glissement de métier qui s’opère, et il ne faut pas le sous-estimer sous prétexte que les outils sont encore jeunes. Le concepteur PCB a longtemps été jugé sur son geste : la qualité de son placement, l’élégance de son routage, sa capacité à faire passer une carte dense. Ce geste reste précieux, mais il cesse d’être le cœur du métier. Ce qui monte, c’est la capacité à évaluer une proposition : la lire, la contredire, la rejeter.

Cela suppose des compétences nouvelles, et elles ne s’improvisent pas. Formuler des contraintes : un prompt utile n’est pas « route cette carte », c’est « route ce bus différentiel en respectant 100 Ω ± 10 %, en gardant les paires appariées sur toute la longueur, en évitant la zone sous l’antenne ». La qualité de la sortie dépend de la qualité de la spécification — ce qui est une bonne nouvelle pour les ingénieurs, dont c’est le métier. Construire des jeux de test : avoir un projet de référence dont on connaît la réponse, pour vérifier qu’un plugin ne régresse pas. Instrumenter la vérification : ne pas se contenter du DRC par défaut, écrire des règles qui attrapent les erreurs que l’IA commet. Documenter les décisions : tenir le journal qui rend le design défendable.

Le risque, symétrique, est celui de la dépendance et de l’atrophie du geste. Si le concepteur ne route plus jamais manuellement, il perd la capacité à juger un routage. C’est un phénomène connu ailleurs : on ne détecte bien les erreurs d’un outil que si on sait faire ce que fait l’outil. La revue de design en présence d’IA doit donc organiser la résistance : revue par échantillonnage (on re-vérifie à la main une partie des propositions acceptées), tests différentiels (on compare la sortie de deux approches sur un même bloc), double vérification sur les signaux critiques.

Cela change aussi la manière de concevoir la revue elle-même. Une revue de design classique examine un objet fini. Une revue de design assistée par IA doit examiner un processus : quels prompts, quels outils, quelles versions, quelles décisions. C’est plus exigeant, et c’est probablement le vrai coût caché de l’IA dans le workflow — un coût qui ne se voit pas dans la démo, mais qui se voit dans le planning.

---

Un cadre pratique pour intégrer l’IA sans lâcher la barre

Assez de principes. Voici un protocole opérationnel, calibré pour un concepteur KiCad 10.0.7 en cette fin 2026. Il n’est pas une norme ; c’est une base de discussion, à adapter à votre criticité.

Périmètre d’usage autorisé. Idéation (explorer des topologies), génération de blocs de schéma connus, préplacement grossier, extraction de datasheet en symbole, génération de contraintes à partir d’une intention, reformatage de netlists. Sur ces terrains, l’erreur est détectable et le gain est réel.

Zones interdites. Routage final sans revue manuelle, signaux critiques (horloges, différentiels, RF), alimentation et puissance, tout ce qui touche à la sécurité. Sur ces terrains, la proposition IA peut servir de brouillon à jeter, jamais de base à conserver.

Points de contrôle obligatoires. À chaque étape : un DRC complet après toute proposition acceptée, une revue humaine des blocs critiques, une vérification croisée sur les nets d’alimentation. Et un contrôle de non-régression : le projet de référence doit passer avant et après l’installation d’un plugin.

Journalisation. Version exacte du plugin, version du modèle, prompt, date, décision (accepté / modifié / rejeté) et motif. C’est fastidieux les premières semaines, puis cela devient un réflexe — et cela sauve lors d’un debug six mois plus tard.

Politique de plugins. Origine (dépôt officiel, dépôt communautaire, binaire opaque), licence, fréquence de maintenance, taille de la communauté. Un binaire Rust unique de 228 outils, comme Konnect, est un objet puissant et opaque : il faut savoir ce qu’il fait de vos fichiers avant de le laisser écrire dans un projet.

Décision	Quand accepter	Quand tester	Quand refuser
Suggestion de découplage	Composant connu, topologie standard	Composant nouveau ou haute fréquence	Alimentation critique, sécurité
Préplacement de blocs	Blocs fonctionnels bien séparés	Blocs mixtes analogique/numérique	Contraintes thermiques ou RF fortes
Route proposée	Signal lent, peu de contraintes	Signal apparié, longueur contrainte	Horloge, différentiel, puissance
Symbole depuis datasheet	Brochage simple, PDF lisible	Brochage dense, noms proches	Composant de sécurité, broche unique

La règle de fond qui traverse ce tableau : accepter ce qu’on peut vérifier mécaniquement, tester ce qu’on peut vérifier par échantillon, refuser ce qu’on ne peut vérifier qu’à l’œil.

---

L’écosystème KiCad à l’épreuve de l’IA : plugins, gouvernance, signaux faibles

L’écosystème KiCad a une qualité rare : il est lisible. Les bibliothèques officielles de footprints sont sur GitLab, versionnées, taguées (10.0.7-rc1 le 22 septembre 2026, par exemple). Les annonces de version sont publiques et datées. Cette transparence est un atout considérable face à l’IA : elle permet de savoir exactement sur quoi on branche un assistant.

Mais l’arrivée des intégrations LLM pose des questions de gouvernance que la communauté n’a pas encore tranchées. La fragmentation entre variantes : KiCad 10 introduit les variantes de cartes, et chaque plugin peut avoir sa propre interprétation de ce qu’une variante signifie. Les intégrations propriétaires : un plugin qui dialogue avec un modèle commercial introduit une dépendance externe dans une chaîne jusqu’ici entièrement open source. Que se passe-t-il le jour où l’API change, où le modèle est déprécié, où le fournisseur ferme l’accès ? La maintenance : un dépôt communautaire qui expose 228 outils est un projet ambitieux ; combien de personnes le maintiennent, et pendant combien de temps ?

Les signaux faibles à surveiller sont identifiables. D’abord, la standardisation des interfaces assistant-moteur : MCP est une piste, mais rien ne dit qu’elle deviendra le standard de l’EDA. Ensuite, l’apparition de benchmarks indépendants : c’est la condition sine qua non pour que le domaine sorte de l’ère des impressions. Enfin, l’intégration de règles de traçabilité dans les futurs DRC : si un vérificateur pouvait signaler « cette géométrie provient d’une suggestion non revue », la donne changerait. Rien de tout cela n’est acquis en 2026.

Un mot sur le contexte plus large : l’écosystème open source PCB ne se résume pas à KiCad. Des comparatifs récents — KiCad vs LibrePCB vs Horizon EDA le 28 septembre 2026, ou la liste 2026 des logiciels PCB le 9 septembre — montrent que la concurrence existe, mais que KiCad occupe une place à part, portée par un financement via The Linux Foundation et une communauté de contributeurs. C’est cette base institutionnelle qui rend crédible l’idée d’y brancher des assistants : on ne branche pas un LLM sur un projet qui peut disparaître.

---

Le concepteur garde la main s’il garde la preuve

Revenons à notre plan de masse à trois millimètres. Que fait le concepteur, ce soir-là ? Il rejette la proposition, il documente pourquoi (retour de courant, proximité du connecteur), il ajuste la contrainte dans le plugin (« garde 5 mm autour de J1 »), il relance, il obtient une meilleure proposition, il la vérifie au DRC, il l’accepte. Le lendemain, il note dans son journal : plugin version X, modèle Y, prompt Z, décision motivée. Six mois plus tard, quand la carte revient du fabricant avec un problème de rayonnement, il peut reconstituer la chaîne. C’est ça, garder la main.

L’IA ne remplace pas la décision d’ingénierie. Elle déplace le travail vers trois endroits : la spécification (formuler ce qu’on veut, en contraintes exploitables), la vérification (instrumenter le DRC, construire des jeux de test, échantillonner les revues), et la documentation (tracer les suggestions, les décisions, les versions). Ce déplacement est exigeant, et il est probablement irréversible : une fois qu’on a goûté à la génération de blocs et à l’extraction de datasheets, on ne revient pas en arrière. Mais il est aussi une opportunité : il remet l’ingénieur au centre, là où son jugement compte le plus.

Pour les prochains cycles de KiCad, la question n’est pas de savoir si une fonction d’IA native apparaîtra dans le menu. Elle est de savoir si l’écosystème saura produire les garde-fous qui rendent les propositions auditables : interfaces standardisées, benchmarks indépendants, règles de traçabilité intégrées aux vérificateurs. C’est un chantier collectif, et il est ouvert.

La main, au fond, ne se garde pas en refusant l’IA. Elle se garde en construisant les garde-fous qui rendent ses propositions vérifiables, réversibles et documentées. Le concepteur qui accepte une suggestion sans pouvoir la justifier a déjà lâché la barre — il ne s’en apercevra qu’au premier problème. Celui qui la teste, la trace et la signe en connaissance de cause a, lui, gagné du temps sans rien céder. C’est moins spectaculaire qu’une démo. C’est beaucoup plus solide.

---

Sources

• KiCad — Schematic Capture & PCB Design Software
• KiCad 10.0.7 Release (7 octobre 2026)
• Version 10.0.0 Released (mars 2026)
• Release Notes — KiCad
• Documentation KiCad 10.0
• Documentation KiCad
• Downloads | KiCad EDA
• Download — KiCad
• Windows Downloads — KiCad
• KiCad — Wikipedia
• KiCad 10 review: new features, high-speed tuning, variants, and more — Tech Explorations
• Can AI Now Design PCBs That Just Work? — Hackaday (5 septembre 2026)
• KiCad… In The Browser? — Hackaday (22 octobre 2026)
• PCB design is easier than ever for me, and it’s all thanks to Claude — MSN
• Fellow — « Konnect : conception de PCB assistée par IA pour KiCad 10 » (14 octobre 2026)
• DevTrends — « Comment connecter Claude à KiCad 10 » (7 septembre 2026)
• Adafruit — reprise de l’article Konnect (26 octobre 2026)
• Dépôt GitHub Freerouting — régression 2.3.0 sur les violations de clearance (28 août 2026)
• ScriptedPCB — grille de vias de stitching par script (13 septembre 2026)
• PiStack — « KiCad vs LibrePCB vs Horizon EDA in 2026 » (28 septembre 2026)
• ElectricalFlux — « The 2026 PCB Design Software List » (9 septembre 2026)
• GitLab — Official KiCad Footprint Libraries, tag 10.0.7-rc1 (22 septembre 2026)