---

Le décor : une série 10 qui vit sa vie de correctifs

Posons le cadre avant d’entrer dans le vif. KiCad 10 n’est plus une promesse : c’est une réalité installée, et même une réalité qui se patche. Le projet a publié la 10.0.6 le 29 août 2026, après une release candidate le 18 août. Puis la machine s’est remise en route : 10.0.7 Release Candidate 1 le 27 septembre 2026, et Release Candidate 2 le 3 octobre 2026. Autrement dit, au moment où ces lignes sont écrites, la branche stable la plus aboutie est la 10.0.6, et la 10.0.7 est en fin de cuisson — « elle sortira bientôt sauf si des problèmes critiques sont détectés », dixit le projet.

Cette cadence de correctifs n’est pas un détail cosmétique : elle conditionne directement la fiabilité de vos scripts. Un bug de performance signalé sur le forum à propos de la 10.0.4 / 10.0.5 — déplacement de pistes extrêmement lent dans l’éditeur PCB, la 10.0.5 devenant « inutilisable » pour certains — illustre à quel point une version mineure peut casser le confort de travail. Si l’éditeur lui-même peut régresser, imaginez ce qu’il en est d’une API non stable.

Et l’écosystème suit. La KiCon Asia 2026 se tiendra à Shenzhen du 5 au 7 novembre 2026 — la quatrième édition asiatique. C’est là que se joue, chaque année, une bonne partie de la conversation sur l’outillage et les plugins. Un signe : KiCad n’est plus seulement un logiciel, c’est une communauté qui produit de l’outillage.

---

Trois portes d’entrée, trois philosophies

Quand on parle « d’API Python de KiCad », on confond souvent trois choses qui n’ont ni le même statut, ni le même usage, ni le même risque.

La première porte, c’est pcbnew. Le module historique, celui qui existe depuis des années et que tout le monde connaît sous le nom de son éditeur. Il donne accès au modèle objet du board : pistes, pads, empreintes, zones, et la lecture/écriture du fichier .kicad_pcb. C’est le terrain de jeu des scripts de génération de vias de stitching, de renommage massif de références, de calcul de surfaces de cuivre, de vérifications maison. C’est puissant, c’est documenté par la pratique, et c’est… fragile dans la durée. L’API n’a jamais été conçue comme un contrat de stabilité : elle suit les refontes internes du logiciel.

La deuxième porte, c’est eeschema. Longtemps le parent pauvre : l’accès programmatique au schéma, aux symboles et à la netlist a toujours été plus limité et moins confortable que côté PCB. C’est structurellement plus dur — un schéma, c’est de la connectivité et de la sémantique, pas de la géométrie. En 2026, l’édition de schéma par script reste le maillon faible de la chaîne, et c’est précisément là que les plugins « intelligents » ont dû innover autrement (on y revient).

La troisième porte, c’est la CLI, kicad-cli. C’est la plus jeune, la plus sous-estimée, et probablement la plus solide pour la production. Export Gerber, DRC, BOM, PDF, STEP : tout ce qui est « sortie de fabrication » peut se déclencher en ligne de commande, sans interface graphique, donc dans un conteneur, donc dans une CI. C’est là que se trouve le vrai gain industriel.

Point d’entrée	Ce qu’il manipule	Force	Limite / risque
pcbnew (Python)	Modèle objet du board, I/O .kicad_pcb	Automatisation géométrique fine, traitements par lot	API non contractuelle, casse possible entre versions majeures
eeschema (Python)	Schéma, symboles, netlist	Génération/analyse de connectivité	Périmètre historiquement plus étroit, édition schéma par script immature
kicad-cli	Fichiers de sortie (Gerber, DRC, BOM, PDF, STEP)	Headless, scriptable, intégrable en CI/CD	Ne modifie pas la conception ; dépend de la config du projet

Note de méthode : les détails d’API (liste exacte des sous-commandes, stabilité des bindings) ne sont pas documentés dans les sources officielles que nous avons pu consulter — kicad.org reste une page de présentation qui ne mentionne ni Python, ni pcbnew, ni kicad-cli. Les éléments ci-dessus relèvent donc du fonctionnement connu de l’outil et de la pratique, pas d’une release note citée.

---

Le mythe du « tout scriptable »

C’est ici qu’il faut tordre le cou à une idée reçue. L’automatisation PCB n’est pas un interrupteur qu’on bascule : c’est un spectre. Et sur ce spectre, tout n’a pas la même valeur.

Ce qui marche vraiment, ce sont les tâches déterministes, répétitives et vérifiables. Générer une grille de vias de stitching reliés à la masse, comme le montre un tutoriel de septembre 2026 sur ScriptedPCB : c’est le cas d’école. Poser des dizaines de vias à la main sur un plan de masse, c’est long, fastidieux, et source d’oublis. Un script fait le travail en une passe, avec une règle claire. Même chose pour un export de fabrication : lancer kicad-cli pour produire Gerbers, BOM et PDF en une commande, c’est du temps gagné à chaque itération, sans ambiguïté.

Ce qui marche moins bien, c’est l’automatisation de la décision de conception. Un DRC scripté ne remplace pas un DRC interactif : il le complète. Le DRC interactif de l’éditeur vous montre le problème dans son contexte, avec le survol, la localisation, la correction immédiate. Un DRC en ligne de commande vous dit « ça passe ou ça casse », avec un code de retour — parfait pour un garde-fou de CI, inutile pour déboguer. Confondre les deux, c’est croire qu’on a automatisé le diagnostic alors qu’on a seulement automatisé le contrôle.

Et puis il y a le mythe du plugin magique. L’actualité d’octobre 2026 en donne un exemple frappant : Konnect, un plugin natif KiCad (un binaire Rust unique) qui branche Claude et d’autres assistants sur la conception de schémas et de PCB via MCP, avec 228 outils à disposition. Présenté le 14 octobre 2026, repris par Adafruit le 26 octobre 2026. C’est spectaculaire, et c’est réel. Mais il faut être lucide : ce n’est pas « l’API Python de KiCad » qui fait le travail, c’est un pont MCP qui expose des outils. La valeur ajoutée vient de l’orchestration, pas du binding. Et un assistant qui propose 228 outils, c’est aussi 228 occasions de produire quelque chose de plausible et de faux. La relecture humaine reste le seul garde-fou.

---

Là où le temps se gagne vraiment

Soyons concrets. Sur une journée de concepteur PCB, où l’automatisation mord-elle réellement ?

La documentation de fabrication. C’est le gain le plus net et le moins contesté. À chaque itération de board, il faut régénérer les Gerbers, la BOM, les PDF d’assemblage, parfois le STEP pour la mécanique. En interactif, c’est une série de clics et de dialogues, avec le risque d’oublier une couche ou d’exporter avec la mauvaise configuration. En CLI, c’est une commande, reproductible, versionnable. Sur un projet qui part en fabrication trois fois, le gain est déjà tangible ; sur un projet en itération quotidienne, il est structurel.

Les vérifications custom. Le DRC intégré couvre les règles standard, mais chaque entreprise, chaque projet a ses règles maison : espacement particulier sur une zone, largeur de piste minimale sur un net donné, contraintes de sérigraphie. Un script pcbnew qui parcourt le board et vérifie ces règles, c’est un DRC privé qu’on fait tourner à la demande ou en CI. Là encore, le gain est réel — à condition d’accepter que ce script devra être maintenu.

La génération de bibliothèques. C’est le cas d’usage le plus cité et le plus surévalué. Oui, on peut générer des empreintes par script. Non, ce n’est pas toujours plus rapide que de piocher dans une bibliothèque existante ou de dessiner une empreinte dans l’éditeur. Le script brille quand il y a du volume et de la régularité (une famille de connecteurs, des footprints paramétriques). Il devient un piège quand on l’utilise pour un composant unique, dessiné une fois, jamais réutilisé. Le coût d’écriture du script dépasse alors le coût de la saisie manuelle.

L’intégration continue. C’est le vrai changement de paradigme. Avec kicad-cli, un dépôt de conception PCB peut avoir un pipeline : à chaque commit, export des sorties, DRC headless, archivage des artefacts. On rapproche le PCB du logiciel. Mais attention : cela suppose une discipline de projet (fichiers versionnés proprement, configuration de DRC dans le dépôt) que beaucoup de petites équipes n’ont pas encore.

Sur les chiffres : aucune source officielle KiCad ne publie de benchmark de gain de temps — ni sur kicad.org, ni dans la documentation consultée. Les ordres de grandeur ci-dessus sont donc qualitatifs. Méfiez-vous de quiconque vous promet « 80 % de temps gagné » sans protocole de mesure.

---

Le vrai piège : le coût de maintenance

Voici le point que les articles enthousiastes passent sous silence. Un script KiCad n’est pas un investissement one-shot : c’est un actif à maintenir.

La raison est simple : l’API Python de KiCad n’est pas un contrat stable. Elle évolue avec le logiciel. Entre la série 9 (documentée en ligne) et la série 10, puis entre les correctifs 10.0.4, 10.0.5, 10.0.6 et bientôt 10.0.7, le socle bouge. Un script qui marchait peut se mettre à échouer — pas forcément parce que l’API a changé, mais parce qu’un comportement interne a été corrigé, une structure de données ajustée, une valeur par défaut modifiée.

Le forum officiel en donne un écho indirect mais parlant : un utilisateur migrant d’Altium 25.6.2 vers KiCad 10.0.6 se retrouve avec un avertissement ERC « Symbol pin or wire end off connection grid » sur presque chaque broche et chaque fil. Ce n’est pas un bug de l’API, mais c’est exactement le genre de friction qui casse un script de vérification : votre script supposait une grille, l’import a produit autre chose, et votre garde-fou se met à hurler à tort. La maintenance, ce n’est pas seulement réparer quand ça casse : c’est gérer les faux positifs et les changements de contexte.

La conséquence pratique est un arbitrage économique. Un script de 50 lignes qui automatise une tâche hebdomadaire se rentabilise vite. Un script de 500 lignes qui automatise une tâche annuelle et qu’il faut re-tester à chaque version majeure est un mauvais investissement pour un concepteur solo. La règle empirique : plus la tâche est fréquente et plus la logique est simple, plus le script vaut le coup. Plus la tâche est rare et la logique subtile, plus il faut s’en méfier.

Il existe une parade : isoler le script du projet. Un script qui lit le fichier .kicad_pcb en dehors de l’éditeur, avec ses propres dépendances épinglées, est plus robuste qu’un plugin qui s’exécute dans l’environnement de KiCad et hérite de ses changements. C’est le même principe qu’en développement logiciel : plus la surface de couplage est petite, plus la maintenance est légère.

---

La place dans une chaîne CI/CD : le vrai changement de la décennie

Si l’automatisation change quelque chose de profond en 2026, ce n’est pas la génération de bibliothèques — c’est l’entrée du PCB dans le pipeline logiciel.

Historiquement, la conception PCB était un îlot : un fichier binaire ou propriétaire, un outil de bureau, une livraison par email au fabricant. Avec kicad-cli et des fichiers texte versionnables, on peut traiter un projet PCB comme un projet logiciel : commits, branches, revues, tests automatisés. C’est discret, mais c’est structurant.

Concrètement, à quoi ressemble un pipeline réaliste pour une petite équipe ?

1. Commit du .kicad_pcb, du .kicad_sch et de la configuration DRC.
2. Export des sorties via kicad-cli (Gerber, BOM, PDF, STEP).
3. DRC headless en garde-fou : si le board ne passe pas, le pipeline échoue.
4. Archivage des artefacts, avec un identifiant de build.
5. Notification à l’équipe ou au fabricant.

Ce pipeline ne remplace pas le concepteur. Il déplace le point de contrôle : au lieu de vérifier à la main avant chaque envoi, on vérifie automatiquement à chaque commit. C’est un changement de culture autant que d’outillage.

Mais il y a des limites honnêtes. Le DRC headless ne remplace pas la revue visuelle. L’export STEP peut nécessiter un environnement graphique selon les configurations — un détail qui casse plus d’un pipeline naïf. Et surtout, un pipeline PCB exige une discipline de configuration : si les règles DRC ne sont pas dans le dépôt, le pipeline vérifie la mauvaise chose. C’est le piège classique : on automatise, mais on automatise le vide.

---

Stratégie raisonnée : solo vs petite équipe

Tout cela ne vaut pas le même conseil selon la taille de la structure.

Pour un concepteur solo, la stratégie est minimaliste. Trois priorités, dans l’ordre :

• La CLI d’abord. kicad-cli pour les exports et un DRC de garde-fou. C’est le meilleur rapport valeur/risque : peu de code, zéro dépendance à l’API interne, gain immédiat.
• Un ou deux scripts pcbnew ciblés. Vias de stitching, renommage massif, calcul de surface. Des tâches fréquentes, simples, vérifiables.
• Pas de plugin maison. Un plugin, c’est une dépendance à l’écosystème, à ses versions, à ses mainteneurs. Pour un solo, c’est rarement rentable.

Pour une petite équipe, la logique s’inverse partiellement. L’investissement dans un pipeline CI devient rentable dès qu’il y a plusieurs personnes et plusieurs projets. Mais la règle d’or reste : un script = un propriétaire. Un script orphelin dans un dépôt partagé est une dette qui dort. Il faut documenter, versionner, et prévoir sa mort.

Le cas Konnect illustre une troisième voie : ne pas écrire ses scripts, mais orchestrer des outils existants. Un plugin comme Konnect, avec ses 228 outils exposés via MCP, déplace le problème : on ne maintient plus le code, on maintient l’usage. C’est séduisant pour une petite équipe qui veut tester l’assistance IA sans embaucher un développeur. Mais cela introduit une dépendance à un tiers, à un modèle, et à un protocole. À manier comme un accélérateur, pas comme une fondation.

---

Ce qui reste hors de portée (et le restera un moment)

Il faut le dire clairement : tout n’est pas scriptable, et certaines choses ne le seront pas de sitôt.

Le routage interactif. Le routeur push-and-shove, l’ajustement de longueur, la pose de piste au feeling : c’est du geste, du contexte visuel, de la décision en temps réel. Des outils comme Freerouting existent, et l’actualité d’août 2026 montre leurs limites — la version 2.3.0 produisait des routes avec des violations de clearance auto-déclarées, là où la 2.2.4 routait propre. L’autoroutage progresse, mais il reste un point de départ à valider, pas un remplacement.

L’édition de schéma par script. C’est le maillon faible. Générer un schéma entièrement par code reste un exercice de style plus qu’une pratique de production. La connectivité, la sémantique des symboles, la hiérarchie : tout cela résiste à l’automatisation naïve.

La décision de conception. Aucun script ne décide de l’architecture d’un board, du choix d’un composant, de la stratégie de découplage. L’automatisation exécute ; elle ne conçoit pas. C’est peut-être la limite la plus saine : elle rappelle que l’outil reste un outil.

---

Le verdict : un pilier discret, pas une révolution

Alors, que change vraiment l’automatisation par script dans le workflow d’un concepteur PCB en 2026 ?

Elle change la reproductibilité : les sorties de fabrication ne sont plus un artisanat, elles sont un build. Elle change le contrôle : le DRC devient un garde-fou continu, pas une étape finale. Elle change la place du PCB dans la chaîne : le board entre dans le pipeline logiciel, avec ses commits et ses artefacts.

Elle ne change pas la conception elle-même. Le geste, le jugement, l’arbitrage restent humains. Et elle introduit un coût nouveau : la maintenance des scripts, face à des versions qui bougent — 10.0.6 en août, 10.0.7 en octobre, et la suivante déjà en préparation.

La bonne posture est celle de l’artisan outillé : automatiser ce qui est fréquent, simple et vérifiable ; garder la main sur ce qui est rare, subtil et décisif ; et se méfier de toute promesse de gain de temps qui ne vient pas avec un protocole de mesure. KiCad 10 a mis l’outillage à portée de main. À chacun d’en faire bon usage — sans confondre la carte et le territoire.

---

Sources

• KiCad – Schematic Capture & PCB Design Software
• Download – KiCad
• KiCad — Wikipédia
• Démarrer avec KiCad | 5.1 | Français | Documentation | KiCad
• Démarrer avec KiCad | 9.0 | Français | Documentation | KiCad
• Downloads | KiCad EDA
• Windows Downloads – KiCad
• KiCad – Wikipedia
• PCB Design Software in 2026: What Beginners Should Compare
• Python.org