Electrosens R&D

KiCad 10 sous stéroïdes : dompter la conception PCB avec les bindings Python

Electrosens Kicad Master · 26 October 2026

KiCad 10.0.x et l’automatisation Python : des bindings IPC aux scripts qui changent le workflow PCB

Fini le temps où l’on déplaçait des centaines de pads à la souris ou où l’on vérifiait à l’œil nu la conformité d’une sérigraphie. Avec la branche KiCad 10.0.x — dont la 10.0.7 est sortie le 7 octobre 2026 et une 10.0.8 déjà en release candidate depuis le 22 octobre — l’automatisation Python n’est plus un gadget de développeur : c’est une brique centrale du workflow de conception. Plongée dans les nouveaux bindings officiels, leurs promesses, leurs limites, et ce qu’ils changent concrètement pour les concepteurs de cartes électroniques.

KiCad 10.0.x : le socle d’une nouvelle ère pour l’automatisation Python

Il y a encore quelques années, automatiser KiCad relevait de la magie noire. Les scripts Python existaient, certes, via le module pcbnew généré par SWIG, mais ils étaient fragiles, mal documentés, et chaque mise à jour majeure cassait des dizaines de scripts. Les concepteurs PCB qui souhaitaient gagner du temps sur des tâches répétitives — placement de matrices de connecteurs, renommage systématique, vérifications personnalisées — devaient soit bricoler des plugins C++ natifs, soit passer par des outils externes comme KiKit, soit accepter des heures de travail manuel.

Le paysage a radicalement changé avec KiCad 10.0, publié en mars 2026 après un an de développement depuis KiCad 9.0. La série 10.0 a depuis enchaîné les correctifs : la 10.0.5 annoncée le 22 juillet 2026, la 10.0.6 le 29 août 2026, puis la 10.0.7 le 7 octobre 2026, tandis qu’une 10.0.8 est déjà en release candidate depuis le 22 octobre. Huit mois après la 10.0.0, la branche arrive au bout de son cycle de rattrapage — mais c’est bien la refonte de l’API Python qui constitue le changement de fond.

La 10.0.6, en particulier, illustre le rythme de ces correctifs. Son changelog officiel mentionne notamment la récupération de mémoire inutilisée lors de la reconstruction du modèle du rule check (« Compact rule check handle vector during model rebuild to recover unused memory »), le dessin correct des styles de ligne sur les courbes de Bézier, un correctif sur l’échappement des tildes à l’import Eagle, ou encore la réduction des saccades lors du rafraîchissement du canvas. Autant de détails qui, mis bout à bout, expliquent pourquoi l’équipe invite à mettre à jour sans tarder : « This release contains several critical bug fixes so please consider upgrading as soon as possible. »

Mais au-delà des correctifs, c’est l’aboutissement d’une refonte en profondeur de l’API Python qui compte. L’équipe de développement a officialisé une nouvelle bibliothèque, kicad-python, construite non plus sur SWIG mais sur l’API IPC (Inter-Process Communication), une interface stable et multi-langages. C’est un changement de paradigme : l’automatisation n’est plus un à-côté expérimental, elle devient un citoyen de première classe dans l’écosystème KiCad.

Pourquoi cet engouement soudain pour l’automatisation ? Parce que les cartes modernes sont de plus en plus denses, avec des milliers de pistes, des contraintes d’espacement serrées, et des cycles de conception qui se compressent. Un concepteur qui passe trois heures à aligner des footprints ou à vérifier des règles métier non couvertes par le DRC intégré perd un temps précieux. Les bindings Python promettent de transformer ces corvées en scripts de quelques dizaines de lignes, exécutables en quelques secondes. Et avec la montée en puissance de l’IA dans le domaine — des outils comme OrthoRoute ou des assistants de conception font leur apparition — la capacité à piloter KiCad par code devient un atout stratégique. L’enquête Weidmuller 2026 révèle d’ailleurs que 91 % des ingénieurs nord-américains déclarent utiliser l’IA dans leur flux de conception PCB, même si l’écart reste grand entre les promesses marketing et les usages réels.

SWIG ou IPC ? Décryptage de la nouvelle architecture des bindings

Pour comprendre le tournant, il faut revenir un instant sur l’architecture. L’ancien module pcbnew, nommé d’après le nom interne de l’éditeur de PCB, était généré par SWIG (Simplified Wrapper and Interface Generator). Cet outil permettait d’exposer les classes C++ de KiCad vers Python, mais avec des défauts structurels : l’interface était instable, changeait entre les versions majeures sans garantie de compatibilité, et son fonctionnement était opaque pour les développeurs. La documentation officielle le reconnaît sans détour : « Since this interface is a raw binding layer over KiCad rather than a true API, it is unstable and will generally change between KiCad major versions. »

Source : github.com

Depuis KiCad 9.0, ces bindings SWIG sont officiellement dépréciés. Le plan annoncé est clair : ils seront supprimés dans KiCad 11.0. Les scripts existants basés sur pcbnew ont donc une échéance, et les développeurs sont invités à migrer vers la nouvelle bibliothèque kicad-python, officiellement maintenue par l’équipe KiCad et disponible sur GitLab. Celle-ci repose sur l’API IPC, une interface de communication inter-processus stable, conçue pour être accessible depuis plusieurs langages. En Python, elle se matérialise par la bibliothèque kicad-python, qui expose des modules comme kicad, kipy.common_types, kipy.board_types et kipy.geometry.

Concrètement, la différence est majeure. Avec SWIG, le script Python était compilé en liaison directe avec le code C++ de KiCad, ce qui permettait un fonctionnement autonome (headless) : on pouvait charger un fichier .kicad_pcb sans lancer l’interface graphique. Avec l’API IPC, les choses changent : il faut une instance de KiCad en cours d’exécution avec le serveur API activé. C’est une contrainte, mais aussi une garantie de stabilité : l’API IPC est explicitement décrite comme stable, contrairement à l’interface SWIG. La documentation de développement précise d’ailleurs que « the IPC API, which is a stable interface that is accessible from many languages including Python, should be used for modern plugin development ».

Cette transition a des implications pratiques immédiates. Les scripts SWIG qui fonctionnaient en mode autonome devront être adaptés pour se connecter à une instance de KiCad. Les développeurs qui ont investi dans des plugins pcbnew doivent planifier leur migration avant KiCad 11. En revanche, les nouveaux scripts écrits avec kicad-python bénéficient d’une API plus propre, plus pythonique, et d’une documentation officielle — même si, comme on le verra, celle-ci reste encore parcellaire. Notons qu’il existe aussi des projets communautaires comme kigadgets (fork atait/kicad-python) qui proposent une couche d’abstraction supplémentaire, testée de KiCad 5.0 à KiCad 9.0, avec des motifs plus intuitifs pour les objets, propriétés, unités et couches.

Premiers pas : charger, inspecter et modifier un board en 20 lignes

Assez de théorie, passons à la pratique. L’installation de kicad-python se fait simplement via pip. Une fois la bibliothèque installée, le script typique suit un schéma bien rodé : se connecter au serveur API de KiCad, charger un board, inspecter les objets, les modifier, puis sauvegarder.

Voici un exemple de squelette de script, basé sur la structure documentée et les patterns observés dans la communauté :

from kicad import Board
from kipy.board_types import Footprint, Track, Zone
from kipy.common_types import Layer

# Connexion à l'instance KiCad en cours d'exécution
board = Board.open("ma_carte.kicad_pcb")

# Accéder aux footprints
for fp in board.footprints:
    print(f"Footprint: {fp.reference} sur {fp.layer}")

# Accéder aux pistes
for track in board.tracks:
    print(f"Piste de {track.start} à {track.end}, largeur {track.width}")

# Accéder aux zones
for zone in board.zones:
    print(f"Zone sur {zone.layer}, net {zone.net}")

# Modifier un footprint (par exemple, le déplacer)
fp = board.footprints[0]
fp.position = (100.0, 50.0)  # en mm

# Sauvegarder
board.save()

Les classes fondamentales sont bien celles attendues : Board pour la carte, Footprint pour les composants, Pad pour les pastilles, Track pour les pistes, Zone pour les zones de cuivre. Chacune expose des propriétés et méthodes documentées — la documentation officielle liste ces types dans kipy.board_types. On peut itérer sur les couches, lire les nets, modifier les positions, les rotations, les largeurs de piste, etc. Pour ceux qui préfèrent une approche plus légère, la bibliothèque communautaire kigadgets propose des motifs encore plus pythoniques, comme :

print([track.layer for track in pcb.tracks])
print([track.width for track in pcb.tracks if track.is_selected])

Un point important à noter : contrairement à l’ancien module SWIG qui pouvait fonctionner en mode autonome, l’API IPC nécessite que KiCad soit lancé avec le serveur API activé. C’est une différence de workflow à intégrer dès le départ. Pour les utilisateurs de l’éditeur graphique, cela signifie qu’il faut démarrer KiCad, activer le serveur (via les préférences ou une option de ligne de commande), puis exécuter le script Python. En contrepartie, on a la garantie que le script interagit avec l’état exact de la carte affichée, ce qui peut être un avantage pour des opérations interactives.

Scripts qui valent de l’or : DRC personnalisés, placement automatique, nettoyage de pistes

Le vrai intérêt des bindings Python, c’est de dépasser ce que le DRC intégré sait faire. Le DRC de KiCad est excellent pour les règles géométriques standards — espacements, largeurs, anneaux de via — mais il ne connaît pas vos règles métier. C’est là que les scripts entrent en jeu. KiCad 10.0 a d’ailleurs considérablement enrichi son système de configuration des pistes : algorithmes améliorés pour la cohérence du routeur et du DRC, contraintes de délai temporel au lieu de longueur uniquement, profils de routage par couche. Mais rien ne remplace une vérification personnalisée.

Source : github.com

Prenons un exemple concret : vérifier que tous les composants d’une certaine catégorie (par exemple, les condensateurs de découplage) sont placés à moins de 5 mm de leur IC associé. Le DRC ne sait pas faire ça. Avec Python, c’est un script de 30 lignes :

from kicad import Board
from kipy.geometry import distance

board = Board.open("carte.kicad_pcb")
ics = [fp for fp in board.footprints if fp.reference.startswith("U")]
caps = [fp for fp in board.footprints if fp.reference.startswith("C")]

for ic in ics:
    for cap in caps:
        if distance(ic.position, cap.position) < 5.0:
            print(f"OK: {cap.reference} près de {ic.reference}")
        else:
            print(f"WARNING: {cap.reference} trop loin de {ic.reference}")

Autre cas classique : la conformité des sérigraphies. On veut vérifier que les références des composants ne sont pas inversées, que les textes ne débordent pas des empreintes, ou que les logos sont présents sur la bonne couche. Tout cela est accessible via les propriétés des footprints et des textes.

Le placement automatique est un autre terrain de jeu. Imaginez une carte avec 32 connecteurs identiques disposés en matrice. Au lieu de les placer un par un, un script peut calculer les positions et appliquer les rotations en une fraction de seconde :

for i, fp in enumerate(board.footprints):
    if fp.reference.startswith("J"):
        row = i // 8
        col = i % 8
        fp.position = (10.0 + col * 2.54, 10.0 + row * 2.54)
        fp.rotation = 90.0 if row % 2 else 0.0

Enfin, le nettoyage de pistes : supprimer les segments redondants, normaliser les largeurs selon les netclasses, ou réorganiser l’ordre des nets. Ces opérations, fastidieuses à la main, deviennent triviales en script. Un cas d’usage très concret circule d’ailleurs dans la communauté : la génération automatique de grilles de vias de stitching reliés à la masse, plutôt que de les placer un par un — un besoin récurrent dès qu’on travaille avec des plans de masse, du blindage RF ou de la gestion thermique. La documentation officielle de kicad-python liste les types et méthodes disponibles, même si elle manque encore d’exemples complets pour les cas avancés — un point que nous aborderons plus loin.

Combien de temps gagne-t-on vraiment ? Benchmarks et retours terrain

La question que tout le monde se pose : est-ce que ça vaut vraiment le coup ? Les données chiffrées précises manquent encore — aucun benchmark officiel n’a été publié par l’équipe KiCad pour comparer les performances de l’API Python face aux opérations manuelles. Mais les retours terrain et les tests informels de la communauté convergent.

Pour une opération massive comme le déplacement de plusieurs milliers de pads, un script Python s’exécute en quelques secondes, là où une manipulation manuelle prendrait des dizaines de minutes, voire des heures. La différence vient du fait que le script ne souffre pas de la latence de l’interface graphique : chaque clic, chaque drag, chaque rafraîchissement d’écran prend du temps humain. Un script itère sur des milliers d’objets en un temps négligeable.

Pour la modification de netclasses ou l’export de rapports, le gain est moins spectaculaire mais tout aussi réel : ce sont des tâches où l’erreur humaine guette (une netclass oubliée, un rapport incomplet), et où l’automatisation apporte surtout de la fiabilité. C’est d’ailleurs là que se situe le vrai apport : moins la vitesse brute que la reproductibilité. Un script qui s’exécute à l’identique à chaque itération de conception élimine une classe entière d’erreurs.

Il faut toutefois tempérer l’enthousiasme sur un point : la performance de l’interface graphique elle-même a connu des ratés au fil de la série 10.0. Le forum officiel a ainsi documenté, en août 2026, un problème sérieux de lenteur sur le déplacement de pistes existantes dans l’éditeur PCB en 10.0.4 / 10.0.5, au point que la 10.0.5 devenait « inutilisable » pour certains utilisateurs. Ce type de régression rappelle que l’automatisation ne dispense pas de valider la version qu’on utilise sur ses propres cas d’usage — et que la 10.0.6 puis la 10.0.7 ont précisément servi à corriger ce genre de défauts.

L’écosystème autour des bindings : plugins, IA et outils tiers

Les bindings Python ne vivent pas en vase clos. Ils irriguent tout un écosystème de plugins et d’outils qui, en 2026, a changé d’échelle.

Source : prasunbarua.com

Côté autoroutage, Freerouting reste l’option externe la plus utilisée, mais sa dernière version a connu des déboires : la 2.3.0 produit des routes que son propre scoring signale comme portant des violations de clearance, sur des cartes que la 2.2.4 routait proprement. Un rappel utile que l’automatisation, aussi puissante soit-elle, doit toujours être validée par un DRC complet avant fabrication. Côté GPU, le plugin OrthoRoute continue de faire parler de lui en exploitant la parallélisation CUDA pour l’autoroutage — avec des benchmarks désormais disponibles, mais des angles morts persistants sur les règles avancées et les traversants.

Côté IA, les choses bougent vite. Un plugin natif pour KiCad 10 écrit en Rust, Konnect, transforme Claude en assistant de schématique et de routage via le protocole MCP — un exemple parmi d’autres de la manière dont l’API et les points d’extension de KiCad deviennent le socle d’outils agentiques. L’analyse de protoflow.ai (31 juillet 2026) recense trois méthodes réelles pour ajouter de l’IA à un workflow KiCad, ce qui donne la mesure du phénomène : ce n’est plus de la science-fiction, mais ce n’est pas non plus le miracle promis par le marketing. Les copilotes expérimentaux comme ALT TAB Circuit Copilot restent d’ailleurs estampillés « expérimental ».

Côté matériel, l’écosystème périphérique suit : 3Dconnexion consacre une page officielle à KiCad et une vidéo de démonstration à sa SpaceMouse, et la 10.0.5 a même corrigé un crash d’initialisation du pilote 3Dconnexion — preuve que l’intégration matérielle est prise au sérieux.

Enfin, la migration depuis d’autres EDA progresse. KiCad 10.0 a introduit des importateurs natifs pour Allegro, PADS et gEDA/Lepton EDA. Altium, en revanche, n’a pas encore d’importateur natif : les utilisateurs passent par des chemins détournés, avec les frictions que l’on imagine — un fil du forum officiel documente ainsi, en septembre 2026, des avertissements ERC « Symbol pin or wire end off connection grid » sur presque chaque broche lors d’un import Altium 25.6.2 vers KiCad 10.0.6. Un rappel que l’automatisation du workflow commence parfois par l’automatisation de la migration elle-même.

Les limites : documentation parcellaire, contraintes d’exécution et dette de migration

L’enthousiasme ne doit pas masquer les angles morts. Le premier est documentaire : la documentation officielle de kicad-python liste les types et méthodes, mais reste avare en exemples complets pour les cas avancés. Les développeurs doivent souvent lire le code source ou se tourner vers la communauté pour comprendre les patterns idiomatiques.

Le deuxième est la contrainte d’exécution. L’API IPC exige une instance KiCad lancée avec le serveur API activé. Pour les workflows par lots (batch), c’est un changement culturel : là où un script SWIG pouvait tourner dans un conteneur CI sans interface, il faut désormais orchestrer le lancement de KiCad. Des solutions existent (mode headless, automatisation du démarrage), mais elles restent à la charge du développeur.

Le troisième est la dette de migration. Les bindings SWIG seront supprimés dans KiCad 11.0. Les équipes qui ont construit des plugins pcbnew au fil des ans doivent budgéter leur portage vers kicad-python — un investissement non négligeable, surtout pour les plugins complexes qui reposent sur des comportements SWIG non reproduits à l’identique dans l’API IPC.

Le quatrième est la stabilité de la série elle-même. La 10.0.x a enchaîné les correctifs à un rythme soutenu (10.0.4, 10.0.5, 10.0.6, 10.0.7, et une 10.0.8 en RC), ce qui témoigne d’une maturité en cours d’acquisition plutôt que d’une stabilité acquise d’emblée. Pour les équipes en production, la règle de prudence reste de valider chaque version sur ses propres cas d’usage avant de l’adopter.

Ce qu’il faut retenir pour un concepteur KiCad en 2026

Si vous n’avez jamais écrit de script KiCad, le moment est bien choisi : l’API IPC est stable, la bibliothèque kicad-python est officielle, et la communauté fournit des exemples concrets. Commencez par des tâches à faible risque — inspection, rapports, vérifications personnalisées — avant de passer à la modification automatisée de la géométrie.

Si vous avez des plugins pcbnew, planifiez leur migration maintenant : la suppression dans KiCad 11.0 est actée, et plus tôt vous portez, plus tôt vous bénéficiez de l’API stable.

Si vous êtes en production, restez sur la version la plus récente de la branche 10.0.x (10.0.7 au moment d’écrire ces lignes, avec une 10.0.8 en RC), et validez systématiquement vos scripts sur vos propres cartes avant de les intégrer à un flux automatisé.

Et gardez en tête la leçon des benchmarks : l’automatisation ne remplace pas la validation. Un script qui place des milliers de pads en quelques secondes reste un script qu’il faut vérifier — par un DRC complet, et par un œil humain sur les cas limites.

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.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *