Kicad Master · 4 September 2026

Le MCP et l’IA s’invitent dans KiCad : état des lieux en septembre 2026

Le Model Context Protocol (MCP) promet de faire dialoguer Claude, GPT et autres assistants avec vos projets KiCad. Lecture des fichiers, exécution de DRC, routage assisté… Derrière la hype, qu’en est-il vraiment ? Enquête sur un écosystème en pleine ébullition, entre promesses séduisantes et fragilités bien réelles.

L’IA s’invite dans le routeur : le MCP, pont entre Claude et KiCad

Il y a des annonces qui passent inaperçues et d’autres qui changent durablement un workflow. Le Model Context Protocol (MCP) fait partie de la seconde catégorie, même si son arrivée dans le monde de la CAO électronique s’est faite discrètement. Conçu à l’origine par Anthropic pour connecter ses assistants aux outils de développement, ce protocole ouvert permet à n’importe quel agent conversationnel de dialoguer avec des applications externes via des serveurs dédiés. En 2026, il a franchi les portes de KiCad — et c’est potentiellement un tournant pour la conception de cartes électroniques.

Concrètement, un serveur MCP agit comme un interprète : il traduit les requêtes en langage naturel de l’IA en commandes compréhensibles par l’application, et lui renvoie les résultats. Pour KiCad, cela signifie qu’un concepteur peut demander à Claude d’« exécuter un DRC complet sur la carte actuelle » ou de « déplacer le condensateur C12 de 5 mm vers la droite » sans quitter son éditeur. Fini l’aller-retour entre l’IDE et un chat : l’assistant devient un collaborateur direct, avec accès aux fichiers du projet.

Le contexte 2026 est favorable. KiCad 10 est sorti le 20 mars 2026, apportant son lot de nouveautés majeures — routage haute vitesse, variantes de conception, mode sombre, importateurs natifs — et la version 10.0.5, publiée le 22 juillet 2026, a corrigé les derniers bugs critiques (annonce officielle). Depuis septembre 2026, la version 10.0.6 est disponible, poursuivant la stabilisation et ajoutant des améliorations ciblées pour la migration et l’écosystème. L’IA générative s’est normalisée dans l’ingénierie : une enquête de Weidmuller publiée en juillet 2026 montre qu’elle est désormais perçue comme un outil courant, même si des écarts subsistent entre les attentes des ingénieurs et la réalité des solutions disponibles (source). Le MCP arrive donc à point nommé pour combler ce fossé — à condition d’être fiable.

Un écosystème en ébullition : qui sont les acteurs du MCP pour KiCad ?

Contrairement à ce que l’on pourrait croire, il n’existe pas de serveur MCP officiel pour KiCad. Le projet KiCad n’a publié aucun serveur sanctionné, et c’est la communauté qui a pris les devants. Résultat : une fragmentation notable, avec plusieurs projets concurrents, chacun avec ses forces et ses faiblesses.

Le plus connu est mixelpixx/KiCAD-MCP-Server, un projet open source (licence MIT) qui propose deux implémentations. La première, en Python/TypeScript, cible KiCad 9.0+ et repose sur l’API de script Python pcbnew (via SWIG). La seconde, nommée Konnect, est une réécriture native en Rust, spécifiquement conçue pour KiCad 10, et s’appuie sur l’API IPC officielle de KiCad. Konnect revendique pas moins de 171 outils, un chiffre impressionnant qui témoigne de l’ambition du projet. Il est distribué sous licence AGPL-3.0 (gratuit pour les particuliers et l’open source, licences commerciales pour les entreprises). Le projet inclut également Nimrod, un serveur MCP de recherche web qui permet de croiser les données de conception avec la disponibilité des composants, les datasheets et les errata en temps réel — une réponse directe au problème des données d’entraînement périmées des LLM.

À côté, KiPilot MCP, publié par l’utilisateur Bela_Szalontai sur le forum officiel KiCad, cible exclusivement KiCad 10.x via l’API IPC. Il est encore en alpha publique, mais il a le mérite d’exister et d’être activement discuté. D’autres projets complètent le paysage : Pablomonte/MCP-KiCad, qui propose 12 outils et fonctionne avec KiCad 9.0+ (installation Flatpak recommandée) via l’API pcbnew, avec un accent sur le placement de composants et l’analyse de netlists (dépôt GitHub) ; Seeed-Studio/kicad-mcp-server, qui permet d’analyser des schémas, inspecter des PCB, tracer des connexions et générer du code embarqué (présentation sur Glama) ; ou encore kicad-mcp-pro, un projet qui donne aux agents IA un accès réel aux workflows de conception PCB (article de présentation).

Serveur	Langage	KiCad cible	API utilisée	Nombre d’outils	Licence
mixelpixx/KiCAD-MCP-Server	Python/TS	9.0+	pcbnew (SWIG)	~100 (build STDIO)	MIT
Konnect (mixelpixx)	Rust natif	10	IPC officielle	171	AGPL-3.0
KiPilot MCP	Non précisé	10.x	IPC officielle	Non précisé	Alpha
Pablomonte/MCP-KiCad	Python	9.0+	pcbnew	12	Non précisée
Seeed-Studio/kicad-mcp-server	Non précisé	Non précisé	Non précisé	Non précisé	Non précisée
kicad-mcp-pro	Non précisé	Non précisé	Non précisé	Non précisé	Non précisée

Cette diversité est à double tranchant. D’un côté, elle prouve l’engouement de la communauté et la vitalité de l’écosystème open source. De l’autre, elle pose un problème majeur pour les professionnels : lequel choisir ? Sans serveur officiel, la pérennité d’un projet dépend de la bonne volonté de son mainteneur. Un dépôt peut être abandonné du jour au lendemain, laissant les utilisateurs sans support. C’est un risque réel à prendre en compte avant d’intégrer le MCP dans un workflow de production.

Sous le capot : S-expressions, SWIG, IPC – comment le serveur parle à KiCad

Pour comprendre ce que peut faire un serveur MCP, il faut d’abord saisir comment il communique avec KiCad. Trois approches techniques coexistent, chacune avec ses avantages et ses limites.

Le parsing direct des fichiers S-expression. KiCad stocke ses projets dans des fichiers texte au format S-expression (.kicad_pcb, .kicad_sch). Un serveur peut donc lire, modifier et réécrire ces fichiers sans passer par l’application elle-même. C’est une approche robuste et indépendante de la version de KiCad, mais elle présente un risque : si le format évolue (ce qui arrive à chaque version majeure), le serveur doit être mis à jour en conséquence. De plus, elle ne permet pas d’interagir avec l’interface graphique en temps réel.

L’API Python pcbnew (SWIG). C’est l’approche utilisée par la version Python/TypeScript de mixelpixx et par Pablomonte/MCP-KiCad. KiCad expose une API de script Python, accessible via le module pcbnew, qui permet de manipuler les objets de la carte (pistes, composants, zones de cuivre) de manière programmatique. Le serveur MCP utilise cette API pour exécuter des commandes. C’est une méthode éprouvée, utilisée depuis des années pour l’automatisation — comme le montre l’article d’electronicsdesign.au sur le scripting pcbnew pour l’intégration CI. Cependant, elle a ses travers : un bug documenté dans KiCad 9 faisait que SWIG retournait F.Cu pour tous les pads SMD, quel que soit le calque réel — un problème corrigé dans route_pad_to_pad, mais qui illustre les pièges de cette approche.

L’API IPC officielle. Introduite avec KiCad 10, cette API permet une communication inter-processus (IPC) avec l’application en cours d’exécution. C’est l’approche choisie par Konnect et KiPilot. Elle offre un accès temps réel à l’état de la carte, y compris les modifications faites dans l’UI, et permet des opérations plus fines. C’est aussi la plus prometteuse pour l’avenir, car elle est officiellement supportée par le projet KiCad. Mais elle est plus jeune et donc moins éprouvée.

Le serveur de mixelpixx combine d’ailleurs plusieurs approches : il utilise à la fois le parsing S-expression pour certaines opérations et une intégration IPC expérimentale pour d’autres. Cette hybridation est intéressante, mais elle complexifie le code et augmente les risques de bugs.

Tous ces serveurs se basent sur la spécification MCP datée du 2025-06-18, ce qui garantit une certaine interopérabilité entre les clients (Claude Desktop, Claude Code, VS Code avec Cline, etc.) et les serveurs.

Boîte à outils : les 100+ commandes qui changent le workflow

Passons aux choses concrètes. Que peut-on réellement faire avec un serveur MCP pour KiCad ? La liste des outils annoncés est impressionnante, et certains noms de commandes donnent le vertige : sync_schematic_to_board, route_pad_to_pad, snapshot_project, add_board_outline, export_gerber, create_project, add_schematic_component, connect_passthrough… Avec 171 outils pour Konnect, on est loin d’un simple gadget.

Pour un concepteur PCB professionnel, voici les cas d’usage les plus pertinents :

1. Exécution de DRC/ERC. C’est probablement l’utilisation la plus immédiate. Au lieu de lancer manuellement la vérification des règles de conception (DRC) et des règles électriques (ERC), on demande à l’IA de le faire et de résumer les erreurs. Gain de temps certain, surtout sur les cartes complexes où les rapports peuvent être longs à parcourir.

2. Placement et routage assistés. Les commandes route_pad_to_pad et move_component (ou équivalent) permettent de déplacer des composants ou de router des connexions de manière ciblée. L’IA peut, par exemple, router automatiquement une paire différentielle ou repositionner un composant pour réduire la longueur d’une piste critique. Attention toutefois : c’est là que la fiabilité est la plus critique, comme nous le verrons plus loin.

3. Synchronisation schéma/carte. La commande sync_schematic_to_board est un outil précieux pour maintenir la cohérence entre le schéma et le PCB, une tâche souvent fastidieuse lorsqu’on travaille sur des projets évolutifs.

4. Génération de fichiers de production. export_gerber, génération de BOM, intégration JLCPCB… Le serveur peut produire les fichiers nécessaires à la fabrication sans intervention manuelle. Combiné à Git — dont l’article d’anchorpoint.app rappelle qu’il est le filet de sécurité ultime pour les layouts matériels, grâce au format texte de KiCad — cela permet d’automatiser une partie de la chaîne de production.

5. Création de projets et de composants. create_project et add_schematic_component permettent de démarrer un nouveau design ou d’ajouter des composants à la volée. Le serveur de mixelpixx va plus loin avec la génération de symboles et d’empreintes personnalisés pour les modules absents des bibliothèques standard, et la gestion de bibliothèques personnelles — un atout majeur quand on sait que la bibliothèque CERN, publiée le 12 mai 2026, a ajouté plus de 17 000 symboles et empreintes validés à l’écosystème (article du magazine).

6. Intégration Freerouting. Le serveur peut faire appel à Freerouting, un routeur automatique open source, pour router des zones complexes. Combiné aux autorouteurs GPU récents — comme celui présenté sur Hackaday en juillet 2026, capable de gérer des cartes monstres de 17 600 pads et 8 192 airwires — cela ouvre des perspectives intéressantes pour les designs très denses. KiCad 10 intègre d’ailleurs nativement des modes d’autoroutage comme Walk Around et Shove, comme le détaille rottenwifi.com : il suffit de configurer les règles, placer les composants, puis lancer l’autoroutage avant de valider avec le DRC.

7. Revue de conception assistée par IA. Konnect embarque des « Claude skills and agents » pour des audits de design et une pipeline de fabrication. L’IA peut relire un projet, identifier des problèmes potentiels et proposer des corrections — une forme de relecture par les pairs automatisée, qui prend de quelques minutes à une heure selon la complexité.

Le tableau suivant résume les principales catégories d’outils :

Catégorie	Exemples de commandes	Cas d’usage
Vérification	`run_drc`, `run_erc`	Contrôle qualité automatisé, résumé des erreurs
Placement/Routage	`route_pad_to_pad`, `move_component`	Routage ciblé, optimisation de placement
Synchronisation	`sync_schematic_to_board`	Cohérence schéma/PCB
Production	`export_gerber`, `generate_bom`	Fichiers de fabrication, BOM
Création	`create_project`, `add_schematic_component`	Nouveaux designs, ajout de composants
Routage avancé	`freerouting_integration`, `autoroute_walk_around`	Routage automatique de zones complexes
Revue IA	`audit_design`, `fabrication_pipeline`	Relecture assistée, vérification de fabricabilité

Limites et risques : quand la hype rencontre la réalité

Si les promesses sont séduisantes, la réalité est plus nuancée. Plusieurs retours d’expérience récents sur le forum KiCad montrent que l’IA peut produire des résultats inattendus. Un utilisateur a ainsi signalé un problème avec OSH Park : après envoi d’un projet KiCad 10.0.3, les pistes de signaux se sont retrouvées fusionnées avec les plans de masse et d’alimentation (discussion). Si ce cas n’est pas directement lié au MCP, il illustre les risques d’une automatisation mal maîtrisée.

La question de la fiabilité est centrale. Un serveur MCP qui déplace un composant de 5 mm peut sembler anodin, mais si l’IA se trompe de direction ou de valeur, les conséquences sur une carte haute vitesse peuvent être désastreuses. Les outils de routage assisté sont particulièrement sensibles : ils doivent respecter les contraintes de conception (largeurs de piste, espacements, impédances) définies dans les règles. Or, les LLM ne « comprennent » pas ces contraintes ; ils se contentent d’exécuter des commandes. La responsabilité finale incombe donc au concepteur.

Autre point de vigilance : la fragmentation de l’écosystème. Avec au moins six serveurs MCP différents, aucun standard ne se dégage. Les API changent d’une version à l’autre, et les serveurs doivent suivre. La version 10.0.6 de KiCad, par exemple, a introduit des changements dans l’API IPC qui ont nécessité des mises à jour côté serveurs. Sans mainteneur dédié, un projet peut rapidement devenir obsolète.

Enfin, la confidentialité est un enjeu majeur. Envoyer des fichiers de conception à un LLM cloud (Claude, GPT) implique de partager des données potentiellement sensibles. Les serveurs MCP locaux (comme ceux basés sur des modèles open source) atténuent ce risque, mais les solutions cloud restent majoritaires. Les entreprises doivent donc évaluer soigneusement ce compromis avant d’adopter le MCP en production.

Perspectives : vers une maturité du MCP dans l’écosystème KiCad

Malgré ces limites, le MCP s’inscrit dans une tendance de fond : l’IA devient un outil courant dans la conception de PCB. L’enquête de Weidmuller le confirme : les ingénieurs attendent des outils qui automatisent les tâches répétitives, et le MCP répond à cette attente. Les plugins open-source comme ceux présentés dans notre article sur l’IA dans la conception PCB montrent que la communauté est prête à expérimenter.

L’avenir passera probablement par une hybridation : des serveurs MCP locaux pour les opérations critiques (DRC, routage) et des services cloud pour les tâches de plus haut niveau (revue de conception, recherche de composants). La bibliothèque CERN, avec ses 17 000 symboles validés, pourrait être intégrée directement dans les serveurs MCP pour améliorer la précision des suggestions de composants. De même, l’embedding des symboles et empreintes dans les fichiers projet (introduit avec KiCad 9 et renforcé dans KiCad 10) facilite le travail des serveurs MCP, qui n’ont plus besoin de chercher des fichiers externes.

Côté technique, l’API IPC de KiCad 10 est appelée à devenir la norme. Elle permet une communication temps réel avec l’application, ce qui ouvre la voie à des assistants véritablement interactifs. Imaginez un agent qui surveille votre routage en direct et vous alerte dès qu’une contrainte est violée — c’est techniquement possible avec l’IPC.

Enfin, la portabilité de KiCad (version portable 10.0.5/10.0.6) et son intégration dans le navigateur (aihealth.fr) pourraient démocratiser l’accès au MCP. Un concepteur pourrait lancer un serveur MCP sur une clé USB, sans installation, et l’utiliser sur n’importe quelle machine. De quoi accélérer l’adoption, y compris dans les environnements professionnels contraints.

En résumé : le MCP, un outil prometteur mais à manier avec précaution

Le MCP pour KiCad est une réalité en 2026. Les serveurs existent, les outils sont nombreux, et les cas d’usage concrets se multiplient. Mais comme toute technologie émergente, il faut l’aborder avec lucidité. La fiabilité n’est pas encore au rendez-vous pour les opérations critiques, la fragmentation de l’écosystème est un frein, et les questions de confidentialité restent entières.

Pour un concepteur individuel ou une petite équipe, le MCP peut déjà apporter un gain de temps significatif sur les tâches de vérification et de génération de fichiers. Pour une entreprise, il est prudent d’attendre une standardisation et des serveurs officiellement supportés. En attendant, la communauté continue d’innover, et c’est peut-être là le plus important : le MCP force KiCad à s’ouvrir à l’IA, et l’IA à s’adapter aux contraintes réelles de la conception électronique.

Sources

Article recherché et rédigé automatiquement · Magazine Electrosens

📬 Restez à la pointe

Recevez chaque semaine les nouveautés de ce magazine par email.

💬 Une remarque, une correction ?

Aidez-nous à améliorer cet article. Nous prenons en compte vos retours.

KiCad + MCP : l’IA entre enfin dans le workflow PCB — le grand décryptage