Kicad Master · 3 September 2026

KiCad 10.0.6 : l’automatisation Python devient le cœur du 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 KiCad 10.0.6, 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.6 : 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é le 20 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 version 10.0.5, annoncée le 22 juillet 2026, puis la 10.0.6, sortie en août 2026, constituent aujourd’hui les points d’orgue d’une série qui a tenu ses promesses. La 10.0.6 apporte son lot de correctifs critiques — notamment sur la gestion mémoire du rule check, l’affichage des courbes de Bézier, l’import Eagle et la fluidité du rafraîchissement du canvas — mais elle marque surtout l’aboutissement d’une refonte en profondeur de l’API Python. 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 PCB Auto Router, 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. »

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.

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. 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 personnalisés, le gain est tout aussi net. Les utilisateurs de la communauté rapportent des gains de l’ordre de 10 à 50 fois sur les opérations répétitives, selon la complexité. Et avec l’intégration de l’IA — par exemple via le KiCad MCP Server de Seeed-Studio qui permet à des assistants IA d’analyser les schémas, d’inspecter les PCB et de valider les designs — l’automatisation par code devient le socle d’une nouvelle génération d’outils.

L’écosystème s’emballe : autoroutage GPU, importateurs natifs et plugins IA

La série 10.0 ne se contente pas de stabiliser l’API Python. L’écosystème autour de KiCad n’a jamais été aussi actif, et plusieurs tendances méritent l’attention.

L’autoroutage GPU d’abord. Des plugins comme PCB Auto Router ou OrthoRoute exploitent la puissance des cartes graphiques pour router des designs monstres. Le backplane de référence d’OrthoRoute compte 16 connecteurs de 1 100 broches chacun, soit 17 600 pads et 8 192 airwires — un design qui bloquait les routeurs traditionnels et qui est désormais traité en quelques minutes grâce à la parallélisation CUDA. Les benchmarks publiés en juillet 2026 montrent des temps de routage passant de plusieurs heures à moins de 10 minutes sur des cartes complexes. Attention toutefois : ces outils restent limités pour les designs mixtes ou les contraintes DFM avancées, et la vérification DRC finale reste indispensable.

Les importateurs natifs ensuite. KiCad 10.0 a ajouté des importateurs pour Allegro, PADS et gEDA/Lepton PCB, une avancée majeure pour la migration depuis des outils propriétaires. L’importateur Allegro relève un défi technique considérable, l’importateur PADS promet une migration complète schéma + PCB, et l’importateur gEDA/Lepton est un ajout discret mais utile pour l’open source. Le grand absent reste Altium Designer, dont le format propriétaire n’est toujours pas supporté nativement.

Les plugins IA enfin. En 2026, trois approches se distinguent : les plugins in-éditeur (comme les copilotes de routage), les outils generate-then-export (qui génèrent un schéma puis l’exportent vers KiCad), et la génération de composants par IA. Le KiCad MCP Server de Seeed-Studio s’inscrit dans cette mouvance : il permet à des assistants IA de tracer des connexions, de valider des designs et même de générer du code embarqué. L’enquête Weidmuller 2026 montre que 91 % des ingénieurs nord-américains déclarent utiliser l’IA dans leur flux de conception PCB, mais les usages réels restent concentrés sur l’aide à la décision et la vérification, loin des promesses d’automatisation complète.

Les limites à connaître avant de se lancer

Automatiser, oui, mais en connaissance de cause. Plusieurs limites doivent être intégrées dès le départ.

La documentation encore parcellaire. La documentation officielle de kicad-python liste les types et méthodes, mais manque cruellement d’exemples complets pour les cas avancés. Les développeurs doivent souvent fouiller les dépôts GitLab, les forums et les projets open source pour trouver des patterns fonctionnels. La communauté compense en partie avec des ressources comme le guide Git with KiCad ou les tutoriels d’autoroutage, mais l’effort d’apprentissage reste non négligeable.

La dépendance à l’instance graphique. L’API IPC nécessite une instance de KiCad en cours d’exécution avec le serveur API activé. Pour l’intégration continue (CI/CD), cela implique de lancer KiCad en mode serveur dans l’environnement de build, ce qui n’est pas trivial dans tous les contextes. Les scripts SWIG en mode autonome avaient l’avantage de fonctionner sans interface ; cette possibilité disparaît avec la nouvelle API.

La performance sur les très gros designs. Si les scripts Python sont rapides pour des opérations ciblées, ils peuvent devenir lents sur des cartes de plusieurs milliers de composants. L’itération sur tous les objets d’un board de 17 600 pads peut prendre plusieurs secondes, voire plus, selon la complexité. Pour des opérations massives, il faut parfois combiner Python avec des appels natifs ou utiliser des bibliothèques optimisées.

La migration des scripts existants. Les scripts SWIG basés sur pcbnew ne fonctionneront plus à partir de KiCad 11.0. La migration vers kicad-python demande un travail de réécriture, même si les concepts sont proches. Les développeurs qui ont investi dans des plugins doivent planifier cette transition dès maintenant, sous peine de se retrouver bloqués lors de la prochaine mise à jour majeure.

Conclusion : l’automatisation Python, nouveau standard du workflow KiCad

Avec la série 10.0, KiCad a franchi un cap décisif. L’API Python n’est plus un à-côté expérimental : elle devient un pilier du workflow de conception, au même titre que le routeur interactif ou le DRC. Les bindings kicad-python basés sur l’API IPC offrent une stabilité et une propreté que l’ancien module SWIG n’a jamais eues, et l’écosystème s’emballe : autoroutage GPU, importateurs natifs, plugins IA, serveurs MCP — tout converge vers une automatisation toujours plus poussée.

Bien sûr, des limites subsistent : documentation encore jeune, dépendance à l’instance graphique, performance sur les très gros designs. Mais la direction est claire, et les concepteurs qui investissent dès maintenant dans l’automatisation Python prendront une longueur d’avance. Dans un contexte où les cycles de conception se compressent et où l’IA s’invite dans les flux de travail, la capacité à piloter KiCad par code devient un atout stratégique — et la série 10.0 en pose les fondations.

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 10 sous stéroïdes : dompter la conception PCB avec les bindings Python