Kicad Master · 9 November 2026

KiCad 10 en 2026 : carnet de bord d’un PCB, de la capture schématique au Gerber — ce qui tient, ce qui frotte, ce qui a été patché

KiCad 10.0 est arrivé le 20 mars 2026 avec une promesse simple : faire tenir un projet PCB complet dans un seul flux, du schéma au Gerber, sans les allers-retours qui hantaient les versions précédentes. Sept mois et sept correctifs plus tard — la 10.0.7 est sortie le 7 octobre —, le recul change la lecture : ce qui transforme vraiment une journée de travail n’est pas ce que les articles de sortie ont mis en avant, et certaines frictions n’ont pas disparu. Voici le carnet de bord d’un concepteur, étape par étape, avec ses gains réels, ses pièges et l’état exact de la branche à l’automne 2026.

Octobre 2026 : ce que « KiCad 10 » change vraiment quand on a un PCB à sortir

Ouvrir KiCad 10.0 pour la première fois avec un projet réel sous le bras, c’est d’abord une expérience visuelle. Le mode sombre, la refonte de l’interface, les bibliothèques réorganisées : autant de changements qui sautent aux yeux et dont on parle le plus dans les articles de sortie. Le site kicad.org annonce la version 10.0.0 comme une étape majeure, et plusieurs médias spécialisés (CNX Software, Electwork, PCB Directory) ont insisté sur les mêmes têtes d’affiche : mode sombre, éditeur graphique de règles DRC, variantes de carte, nouveaux importateurs.

Mais ce qui change une journée de travail n’est pas ce qui se voit à l’écran d’accueil. Trois fonctions transforment réellement la donne pour qui doit livrer : l’éditeur graphique de règles DRC (parce qu’il supprime la barrière de la syntaxe texte), les variantes de carte (parce qu’elles éliminent la duplication de projets) et les importateurs (parce qu’ils rendent enfin crédible une migration depuis un outil concurrent). Le reste — mode sombre, ergonomie, refonte des bibliothèques — améliore le confort, mais ne réécrit pas la méthode.

Ce dossier prend un parti pris clair : ni communiqué de version, ni tutoriel pour débutant. C’est un carnet de bord de workflow end-to-end, avec ses frictions et ses angles morts. Méthode assumée : on distingue ce qui est vérifiable dans les sources officielles (notes de version, documentation 10.0) de ce qui relève de la documentation tierce (Sierra Circuits, Tech Explorations), et de ce qui reste à confirmer faute de release notes exhaustives.

Nous sommes fin octobre 2026, et la chronologie de la branche est désormais bien documentée : après la 10.0.0 du 20 mars, la 10.0.6 est sortie le 29 août, puis la 10.0.7 a enchaîné une release candidate le 27 septembre, une deuxième le 3 octobre, et la version stable le 7 octobre 2026. Cette mécanique de patchs rapprochés dit quelque chose d’important : un projet vivant se corrige en continu, et la bonne question n’est pas « quelle est la dernière version ? » mais « quelle version est stable pour mon projet ? ». Nous y revenons plus bas.

Capture schématique : ce que la refonte des bibliothèques change à la première heure

Étape 1 : ouvrir un schéma neuf. La refonte des bibliothèques est la première chose que l’on ressent, et c’est aussi la plus difficile à décrire sans tomber dans le marketing. Concrètement, la nouvelle organisation vise à garantir la cohérence entre symboles et empreintes, à gérer proprement les versions de composants et à réduire les allers-retours lors de la recherche. Sur un projet multi-pages, cela se traduit par une expérience de recherche plus fluide et des associations symbole↔empreinte moins souvent cassées.

Ce qui s’améliore vraiment : la cohérence accrue entre le symbole posé sur le schéma et l’empreinte qui atterrira sur le PCB. C’est précisément là que les anciennes versions faisaient perdre du temps, en obligeant à re-vérifier des correspondances à chaque montée de version. Ce qui reste pénible : les composants exotiques et les bibliothèques maison. Aucune refonte ne règle le problème des références introuvables ou des empreintes propriétaires qu’il faut maintenir à la main.

Les pièges classiques, eux, n’ont pas disparu — ils se sont déplacés. Trois reviennent systématiquement :

Les symboles orphelins après migration : un projet ouvert en v10 qui perd des associations parce qu’une bibliothèque a été renommée ou déplacée.
Les empreintes liées par nom plutôt que par identifiant stable : fragile dès qu’un composant change de référence.
Les projets v8/v9 ouverts en v10 : la conversion n’est pas toujours silencieuse, et certaines associations sautent.

Un cas concret documenté sur le forum KiCad illustre le point le plus épineux de cette étape : la migration d’un projet Altium 25.6.2 vers KiCad 10.0.6 déclenche un avertissement ERC « Symbol pin or wire end off connection grid » sur presque chaque broche et chaque fil (signalement du 1er septembre 2026). Autrement dit, l’importateur fait le gros du travail, mais la grille de connexion héritée de l’outil source ne coïncide pas avec celle de KiCad : il faut repasser sur le schéma pour recaler les connexions. C’est exactement le type de friction que les articles de sortie passent sous silence et qui coûte une demi-journée.

Point annexe mais toujours présent : l’ERC et le simulateur SPICE intégré restent disponibles et fonctionnels. Ils ne sont pas au cœur de cette version, mais ils continuent de rendre service pour vérifier une alimentation ou valider un filtre avant de passer au PCB. Sur ce terrain, rien de révolutionnaire — et c’est très bien ainsi.

Assignation des empreintes et contraintes : le vrai test de la refonte bibliothèques

Étape 2 : passer du schéma au PCB. C’est ici que la refonte des bibliothèques est jugée sur pièces. La cohérence des empreintes se vérifie au moment de l’assignation, et la gestion des variantes de composants (DNP, valeurs alternatives) commence à peser. Mais le vrai sujet de cette étape, c’est la mise en place des contraintes de conception : classes de nets, largeurs de pistes, clairances, règles différentielles. Tout cela doit être structuré avant d’ouvrir le routeur.

KiCad 10 apporte une meilleure intégration schéma↔PCB et une propagation plus fiable des règles. Mais une part du travail reste manuelle et source d’erreurs : on définit encore beaucoup de choses à la main, et un oubli se paie plus tard, au DRC ou pire, chez le fabricant.

L’astuce qui sauve des soirées : figer les contraintes dans le fichier .kicad_pro avant de router, pas après. Une fois le routage entamé, changer une classe de nets ou une clairance revient à retoucher potentiellement des dizaines de pistes. Le projet de règles doit être considéré comme un livrable à part entière, versionné avec le reste.

Étape	Ce que KiCad 10 améliore	Ce qui reste manuel
Assignation empreintes	Cohérence symbole/empreinte renforcée	Composants exotiques, bibliothèques maison
Classes de nets	Propagation schéma→PCB plus fiable	Définition initiale à la main
Règles de clairance	Éditeur graphique (voir section suivante)	Cas complexes, héritage entre règles
Règles différentielles	Meilleure intégration	Paramétrage fin toujours délicat
Variantes de composants	Gestion DNP/valeurs alternatives	Cohérence inter-variantes à surveiller

L’éditeur graphique de règles DRC : écrire ses contraintes sans lire la doc

C’est le gros morceau de KiCad 10 côté PCB, et celui qui justifie à lui seul le saut de version pour beaucoup d’équipes. Jusqu’ici, écrire une règle DRC signifiait se plonger dans une syntaxe texte, avec sa courbe d’apprentissage et ses erreurs de frappe silencieuses. Résultat : beaucoup de concepteurs ne les écrivaient tout simplement pas, se contentant des règles par défaut — et le payant plus tard.

L’éditeur graphique change la donne. On construit une règle de clairance, une règle de zone, une règle conditionnelle par classe de net ou par couche, sans se battre avec la syntaxe. Pour un concepteur qui n’était pas à l’aise avec le texte, c’est un changement de pratique, pas seulement d’interface : on se met enfin à écrire les règles qu’on repoussait.

Ce qui reste perfectible, en revanche, mérite d’être dit clairement :

Les règles complexes restent difficiles à exprimer graphiquement.
L’héritage entre règles n’est pas toujours limpide.
La lisibilité d’un jeu de règles volumineux se dégrade vite quand on empile les conditions.
La cohérence entre l’éditeur graphique et le moteur scriptable sous-jacent n’est pas garantie dans tous les cas.

Le piège classique, celui qui fait perdre une demi-journée : croire qu’une règle graphique est prioritaire sur une règle texte héritée d’un ancien projet. L’ordre de priorité n’est pas toujours celui qu’on imagine, et un projet migré peut conserver des règles texte qui prennent le pas sur ce qu’on vient de dessiner à l’écran. La bonne pratique : auditer le jeu de règles hérité avant d’en ajouter de nouvelles, et ne jamais supposer que le graphique écrase l’ancien.

Routage interactif et tuning : ce qui accélère, ce qui ne change pas

Étape 3 : le cœur du métier. Routage interactif, push-and-shove, routage différentiel, tuning de longueur (single-ended et différentiel), gestion des plans et des zones. Sur ce terrain, KiCad 10 améliore la gestuelle : snapping plus précis, aperçu des contraintes en direct, retour visuel DRC pendant le routage. Le guide Sierra Circuits et les retours communautaires convergent sur ce point : le ressenti est meilleur, notamment sur les cartes denses.

Mais il faut être honnête sur un point : tout n’a pas été refondu, loin de là. Une grande partie du comportement de routage reste identique aux versions 8 et 9. Et surtout — c’est une limite méthodologique qu’il faut assumer — il n’existe pas de benchmarks publics fiables comparant les temps de routage ou de DRC entre versions. On ne peut donc pas écrire « X % plus rapide » sans source. On décrit des ressentis d’usage, on signale explicitement les zones où la mesure manque, et on laisse le lecteur juger sur sa propre configuration.

Un point de friction documenté mérite d’être signalé, car il touche directement le quotidien : des utilisateurs ont rapporté sur le forum KiCad des lenteurs sévères de déplacement de pistes existantes dans l’éditeur PCB sur les versions 10.0.4 et 10.0.5, au point de rendre la 10.0.5 difficilement utilisable pour certains. C’est le genre de régression qui rappelle qu’une version majeure n’est pas un long fleuve tranquille — et qui justifie de rester sur une branche de maintenance stabilisée plutôt que de sauter sur la première release. La sortie de la 10.0.7 le 7 octobre, présentée par le projet comme contenant « des corrections de bugs critiques et d’autres améliorations mineures depuis la version précédente », s’inscrit dans cette logique de consolidation.

L’astuce de routage qui reste valable quelle que soit la version : verrouiller les nets critiques avant le tuning. Une fois les longueurs ajustées, un déplacement de composant peut tout défaire. Verrouiller tôt évite de recommencer.

Variantes de carte : produire trois SKU sans dupliquer le projet

Fonctionnalité emblématique de KiCad 10, les variantes de carte répondent à un besoin très concret : gérer une même base matérielle déclinée en plusieurs versions — composants DNP, valeurs différentes, options de peuplement — sans maintenir trois projets parallèles qui divergent silencieusement. C’est un gain énorme pour qui produit des gammes.

Prenons un exemple simple : une carte capteur déclinée en version filaire et version radio. Sans variantes, on duplique le projet, on modifie l’un, on oublie de reporter sur l’autre, et six mois plus tard on ne sait plus laquelle est la référence. Avec les variantes, la base reste unique et les différences sont déclarées.

Ce que ça change concrètement :

Pour la BOM : une seule nomenclature, filtrée par variante.
Pour les sorties de fabrication : des fichiers de perçage et de placement générés par variante.
Pour la revue croisée schéma/PCB : on vérifie la cohérence variante par variante, pas projet par projet.

Ce qui reste à surveiller, et c’est le revers de la médaille : la cohérence des variantes entre schéma et PCB, la génération correcte des fichiers par variante, et surtout le risque de divergence silencieuse quand une variante est modifiée sans que les autres suivent. La variante est un outil puissant, mais elle ne dispense pas d’une discipline de revue. Les patchs de la branche 10.0.x ont stabilisé le mécanisme, mais n’ont pas fait disparaître cette exigence méthodologique.

DRC graphique, ERC et vérifications finales : la dernière ligne droite avant le Gerber

Étape 4 : la passe de vérification. DRC complet avec le nouveau moteur de règles, ERC côté schéma, vérification des zones, des perçages, des fichiers de fabrication. C’est l’étape où l’on récolte tout ce qui a été mal semé en amont — et où la refonte des règles graphiques montre sa vraie valeur : un jeu de règles lisible se relit vite, un jeu de règles texte se relit mal.

Trois vérifications à ne jamais sauter avant de générer les Gerbers :

Le DRC avec les règles personnalisées activées, pas seulement les règles par défaut. Un DRC qui passe avec les règles par défaut ne dit rien de vos contraintes réelles.
L’ERC côté schéma, en particulier après une migration : c’est là que ressortent les avertissements de grille de connexion hérités d’un import (voir le cas Altium plus haut).
La cohérence des sorties par variante : perçage, placement, BOM. Une variante oubliée dans un export, et c’est un lot de cartes non peuplées qui part chez le fabricant.

C’est aussi le moment de rappeler une réalité de la branche 10.0.x : la mise en fabrication est la ligne de faille historique. Les patchs successifs — 10.0.1 à 10.0.7 — ont surtout consolidé la stabilité du flux schéma→routage et des exports, mais la vigilance reste de mise sur les fichiers de perçage et de placement, en particulier en contexte multi-variantes.

L’écosystème autour de KiCad 10 : IA, plugins, forks et conférence

Un carnet de bord de workflow ne serait pas complet sans un détour par ce qui gravite autour de KiCad 10 — parce que c’est là que l’outil change le plus vite en 2026.

L’assistance IA branche dans le moteur. Le fait marquant de l’automne est l’arrivée de Konnect, un plugin natif KiCad 10 écrit en Rust, distribué sous forme de binaire unique, qui expose 228 outils à Claude et à d’autres assistants via le protocole MCP (Model Context Protocol). Concrètement, on peut demander à un assistant de proposer un schéma, un placement, une route. La démonstration est spectaculaire ; la réalité l’est moins. L’IA aide là où elle excelle — proposer des variantes, dégrossir un placement, suggérer une topologie — et piège là où la vérification est indispensable : un plan de masse proposé à 3 mm d’un connecteur, une route qui viole une contrainte de classe de net. Le mur, c’est la traçabilité : le DRC et l’ERC restent les seuls juges, et l’IA ne les remplace pas. Le métier glisse du dessinateur au réviseur de propositions.

Les forks se ramifient. Le fork chinois porté par Huaqiu Electronics, dont le site kicad.eda.cn publiait le communiqué de la 10.0.2 le 11 mai 2026, continue de mûrir avec ses armes propres : copilote, cloud, commande en un clic. Un second fork, Zeo, mise sur un agent IA et le multi-cartes. Pour l’utilisateur de la version officielle, l’enjeu est de suivre le rythme : le fork doit absorber les patchs de la branche amont, et cette absorption n’est jamais instantanée.

La conférence asiatique. Le projet a annoncé la quatrième édition de la KiCon asiatique à Shenzhen, du 5 au 7 novembre 2026, au Huaqiang Plaza Hotel — un signe de plus que l’écosystème KiCad est désormais mondial et que la communauté chinoise y pèse lourd.

Le navigateur, frontière suivante. Fin octobre 2026, Hackaday relayait une expérience de KiCad compilé en WebAssembly et lancé dans un simple onglet. Derrière l’anecdote, une question concrète : revue à distance, éducation, CI/CD de design. Ce n’est pas encore un outil de production, mais c’est une direction.

Ce que sept mois de patchs nous apprennent sur la bonne version à utiliser

La leçon la plus utile de cet automne n’est pas dans une fonctionnalité : elle est dans le rythme des releases. Entre le 29 août (10.0.6) et le 7 octobre (10.0.7), KiCad a enchaîné une release de correction, deux candidates et une version stable. Cette mécanique dit trois choses.

D’abord, que la branche 10 est activement maintenue : les correctifs arrivent, et ils arrivent vite. Ensuite, que toutes les versions ne se valent pas : les régressions de déplacement de pistes signalées sur 10.0.4 et 10.0.5 rappellent qu’une release intermédiaire peut être moins utilisable que la précédente. Enfin, que la décision de version est un choix de projet, pas un réflexe : pour un projet en cours de routage, rester sur une version dont on connaît les limites vaut souvent mieux que sauter sur la dernière pour « être à jour ».

La règle pragmatique qui se dégage : pour un nouveau projet, partir sur la dernière stable (10.0.7) ; pour un projet en cours de fabrication, ne changer de version qu’entre deux lots, jamais au milieu d’un routage. Et toujours vérifier, avant de migrer, que les règles DRC héritées et les variantes se comportent comme prévu — c’est là que se cachent les demi-journées perdues.

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 au quotidien : le guide du concepteur PCB — workflow complet, de la capture au Gerber en 2026