Kicad Master · 10 November 2026

KiCad 10 et l’éditeur graphique de règles DRC : la contrainte devient un dessin (mise à jour octobre 2026)

Pendant des années, définir une règle de conception dans KiCad revenait à écrire un poème en S-expression dans un fichier texte, sans aucun retour visuel. Avec KiCad 10, arrivé le 20 mars 2026, l’éditeur graphique de règles DRC change la donne : la contrainte devient un dessin, une zone, un geste. Sept mois et sept correctifs plus tard — la 10.0.7 est sortie le 7 octobre 2026 —, le recul permet enfin de trier ce qui a tenu dans l’atelier de ce qui est resté sur le papier. Plongée dans une refonte qui pourrait bien faire de l’open source le nouveau terrain de jeu favori des concepteurs de cartes haute performance — et dans un écosystème 2026 qui, entre patchs de maintenance, plugins IA et forks, n’a jamais autant bougé.

Adieu le fichier texte : quand la règle devient un dessin

Il faut se souvenir du monde d’avant. KiCad 9.x, sorti en février 2025, avait déjà fait un bond considérable en matière de moteur DRC (Design Rule Check). Mais pour exploiter sa puissance, il fallait se frotter au fichier .kicad_dru, un document texte à la syntaxe aride, héritée des S-expressions de Lisp. Pour définir une clearance entre deux classes de nets, on écrivait des blocs du type (rule "garde_antenne" (constraint clearance (min 1.5mm)) (condition "A.NetClass == 'RF' && B.NetClass == 'Analog'")). Pas de coloration syntaxique digne de ce nom, pas d’aperçu spatial, pas de moyen de voir où cette règle s’appliquait physiquement sur la carte. Le concepteur devait maintenir une cartographie mentale de ses contraintes, et la moindre erreur de parenthèse ou de nom de classe de net se traduisait par un silence radio du moteur DRC — ou pire, par des violations silencieuses.

Ce casse-tête a officiellement pris fin le 20 mars 2026 avec la sortie de KiCad 10.0.0, annoncée sur le blog officiel du projet. Parmi les nouveautés qui ont fait la une — le mode sombre Windows, les importateurs Allegro, PADS et gEDA/Lepton PCB, les variantes de conception — l’éditeur graphique de règles DRC est passé presque inaperçu. C’est pourtant lui qui change le plus profondément le rapport du concepteur à la contrainte. Elektor Magazine, dans son décryptage du 30 mars 2026, le range parmi les « ajouts principaux » côté carte, aux côtés du réglage en domaine temporel, des blocs de conception de PCB, des objets de couche interne dans les empreintes et de l’échange de broches et de portes sans contrainte. Fini le fichier texte : la règle devient un objet visuel, dessiné à la souris, déplacé, redimensionné, partagé.

La rupture est conceptuelle autant qu’ergonomique. Là où l’ancien système demandait de traduire une intention de conception en syntaxe, le nouvel éditeur permet de montrer cette intention directement sur le canevas. Un garde d’antenne ? On trace un polygone autour de la zone sensible. Une isolation haute tension ? On dessine une zone de clearance élargie entre deux blocs fonctionnels. Le fichier texte n’a pas disparu — il est toujours là, en arrière-plan — mais il n’est plus le point d’entrée. Il est devenu la sortie d’un processus visuel, ce qui inverse complètement la charge cognitive.

Sous le capot : comment le canevas graphique parle encore au moteur DRC

Une question légitime se pose : ce nouvel éditeur graphique a-t-il remplacé le moteur DRC historique, ou le pilote-t-il ? Tout porte à croire qu’il s’agit d’une surcouche de pilotage, pas d’une réécriture. Le moteur de calcul des violations — celui qui vérifie les clearances, les annular rings, les longueurs de pistes — reste le même moteur éprouvé de KiCad 9.x, enrichi par les corrections de la série 10. L’éditeur graphique génère en coulisse des règles qui sont ensuite sérialisées dans le format de projet, très probablement toujours sous forme de S-expressions compatibles avec l’ancien schéma .kicad_dru.

Les développeurs n’ont pas officiellement documenté le détail de cette sérialisation — les notes de version de la 10.0.0, publiées sur kicad.org, mentionnent l’éditeur sans entrer dans les spécifications techniques du format. Mais on peut raisonnablement supposer que les opérateurs booléens AND/OR/NOT, qui structuraient les conditions complexes de l’ancien système, sont toujours représentés dans le fichier, simplement générés automatiquement par les interactions graphiques. De même, les conditions de couches (par exemple, « cette règle ne s’applique que sur la couche top ») sont probablement encodées dans le même schéma, rendant les fichiers produits par l’éditeur lisibles par les outils de CI et de scripts Python via l’API pcbnew, comme le montre ce guide récent sur l’automatisation des vérifications DRC avec kicad-cli.

Pour les projets hérités d’une version 9.x, la migration semble avoir été pensée pour être douce. Les règles textuelles existantes sont très certainement importées et affichées dans l’éditeur graphique sous forme de « règles héritées », éditables mais non cassées. Ce point reste toutefois une zone d’ombre documentaire : aucune source officielle ne précise explicitement le comportement en cas de règle conditionnelle très imbriquée, ni la manière dont l’éditeur graphique la représente. Les utilisateurs qui ont migré un projet complexe rapportent sur les forums une bonne compatibilité, mais les cas limites existent — et le carnet de bord de notre magazine sur sept mois de terrain confirme que la DRC figure parmi les trois frictions qui n’ont pas totalement disparu à l’arrivée de la 10.0.6.

Classes de net et zones dessinées : la nouvelle grammaire des contraintes

Le cœur pratique de la refonte réside dans la manière de définir les règles. Dans KiCad 10, la hiérarchie des classes de net — l’épine dorsale de toute gestion de contraintes — se manipule désormais par glisser-déposer dans un panneau dédié, ou par sélection graphique directement sur le canevas. On peut, par exemple, sélectionner plusieurs pistes d’un bus mémoire et les assigner d’un geste à une classe « DDR3_Group ». Fini l’édition fastidieuse de listes de nets dans un tableau.

Mais la vraie nouveauté, c’est la possibilité de définir des clearances sur des zones arbitraires dessinées à la souris. Imaginez une alimentation à découpage : vous voulez garantir une distance d’isolation de 2 mm entre le primaire et le secondaire, quelle que soit la disposition des composants. Avec l’ancien système, il fallait soit créer une classe de net spécifique pour chaque piste du primaire, soit espérer que le routeur respecte une règle globale trop stricte. Avec l’éditeur graphique, vous tracez un polygone autour de la zone primaire, vous lui assignez une règle de clearance, et le moteur DRC applique la contrainte à tout ce qui traverse ou s’approche de cette zone. La règle devient un objet spatial, exactement comme une zone de cuivre.

Cette grammaire visuelle rend enfin intuitives des règles qui étaient auparavant réservées aux experts. Prenons l’exemple d’une garde d’antenne pour un module GPS : il suffit de dessiner un anneau de garde autour de l’antenne, de lui assigner une clearance de 0,5 mm et une connexion à la masse via des vias en bordure. L’éditeur permet de visualiser instantanément l’anneau, de vérifier qu’il ne chevauche pas de pistes sensibles, et de voir en temps réel si la règle est respectée. Le même raisonnement s’applique à l’isolation haute tension : une zone de 8 mm autour d’un transformateur d’isolement devient un polygone visible, auditable, et modifiable en deux clics.

Un détail qui compte pour les cartes à fortes contraintes thermiques et de courant : la 10.0 a aussi introduit les remplissages hachurés (hatched fills) et un éditing de polygones plus précis, deux briques qui complètent naturellement l’éditeur de règles graphique. Dessiner une zone de clearance n’a d’intérêt que si la zone de cuivre qu’elle protège est elle-même finement contrôlable.

Le retour visuel en temps réel : la DRC qui corrige avant l’erreur

L’ancien flux de travail était un aller-retour frustrant : on routait toute la carte, on lançait la DRC, on obtenait une liste textuelle de violations, on corrigeait une par une, puis on relançait. Avec KiCad 10, la boucle de feedback est devenue immédiate. Les violations DRC s’affichent en surbrillance directement sur le canevas pendant l’édition, avec des marqueurs colorés qui indiquent le type de problème (clearance, longueur, annular ring). On voit la faute au moment où on la commet, pas après coup.

Cette expérience est renforcée par une autre nouveauté de la 10.0, confirmée par Elektor Magazine : les actions de correction suggérées pour les erreurs DRC. Lorsqu’une violation est détectée, KiCad propose des actions concrètes — déplacer une piste, ajuster un via, modifier une valeur de clearance — qui peuvent être appliquées en un clic. Combiné à l’éditeur graphique, cela transforme la DRC d’un outil de contrôle en un outil de guidage. Le concepteur ne subit plus la contrainte : il la voit, la comprend, et la corrige dans le même geste.

Le gain de temps est difficile à chiffrer précisément — aucun benchmark officiel n’a été publié sur ce point — mais l’expérience rapportée par les utilisateurs sur les forums est unanime : le nombre d’itérations de correction en fin de routage a chuté de manière spectaculaire. Sur une carte complexe de plus de 1000 nets, le temps passé à « chasser » les violations est réduit d’au moins la moitié, selon les témoignages. La DRC n’est plus une étape redoutée, mais un compagnon de route.

Nuance importante que le recul de l’automne 2026 impose : la DRC reste précisément l’un des trois points de friction que les patchs 10.0.1 à 10.0.6 n’ont pas entièrement réglés, aux côtés des bibliothèques et des très gros projets. Autrement dit, l’éditeur graphique a transformé l’expérience de la contrainte, pas la puissance brute du moteur sur les cas extrêmes. C’est déjà beaucoup — mais ce n’est pas magique.

High-speed sans migraine : l’éditeur graphique face au tuning temporel

Les concepteurs de cartes haute vitesse (DDR, PCIe, Ethernet 10G) ont longtemps boudé KiCad, lui préférant des outils propriétaires. La version 10 marque un tournant avec l’arrivée du réglage en domaine temporel (time-domain tuning), une fonctionnalité confirmée par Elektor parmi les ajouts majeurs côté carte. Elle permet d’ajuster les longueurs de pistes pour respecter des contraintes de skew et de latence. L’éditeur graphique de règles DRC s’articule directement avec cet outil : les contraintes de longueur et d’impédance ne sont plus des valeurs abstraites dans un tableau, mais des objets graphiques manipulables.

Concrètement, on peut définir une règle pour une paire différentielle qui spécifie à la fois la largeur de piste, l’espacement intra-paire, et la tolérance de longueur. Cette règle s’affiche comme un « couloir » visuel le long des pistes concernées, avec des marqueurs indiquant où la longueur est satisfaite et où elle ne l’est pas. Le réglage en domaine temporel permet ensuite d’ajuster les méandres en voyant en direct l’impact sur la longueur totale. L’éditeur graphique devient ainsi le tableau de bord du tuning haute vitesse.

La gestion des paires différentielles, longtemps un point faible de KiCad, bénéficie elle aussi de cette approche visuelle. Les règles de couple (largeur, gap, couplage) se définissent par sélection graphique des deux pistes, et les violations d’impédance sont signalées par des halos colorés. Pour un spécialiste de l’intégrité du signal, c’est un changement de paradigme : la contrainte d’impédance, qui était une ligne de code à déchiffrer, devient une forme à ajuster.

Il faut toutefois rester lucide sur ce que les sept mois de terrain ont montré : le routage interactif et le tuning accélèrent surtout les cas courants, mais ne changent pas fondamentalement la donne sur les topologies les plus exigeantes. Pour les cartes vraiment hors norme, la communauté continue de bricoler — et parfois d’écrire ses propres outils. C’est exactement ce qu’illustre OrthoRoute, le routeur GPU né d’un journaliste de Hackaday, qui a préféré coder son propre plugin plutôt que d’attendre que les autorouteurs traditionnels (y compris ceux de KiCad) viennent à bout d’une carte monstrueuse. Le tuning temporel de la 10.0 est un progrès réel ; il n’est pas une baguette magique.

Altium, Fusion, KiCad : le match des panneaux de règles

Il serait malhonnête de ne pas comparer cette nouveauté à ce que proposent les outils propriétaires. Altium Designer, leader du marché, dispose depuis des années d’un panneau Design Rules extrêmement puissant, avec une hiérarchie de règles par priorité, des requêtes (queries) avancées, et une intégration totale avec le routeur interactif. Son prix — entre 3 850 et 5 000 dollars par utilisateur et par an selon les données tarifaires 2026 — le réserve aux entreprises. Et l’addition grimpe vite : sur trois ans, pour cinq postes avec formation (1 000 à 2 000 € par personne), on dépasse les 175 000 dollars. Autodesk Fusion (anciennement Eagle) propose également un système de règles, mais moins profond, et Eagle a officiellement cessé sa vie le 7 juin 2026, poussant les utilisateurs vers Fusion.

KiCad 10, avec son éditeur graphique, rattrape une partie du terrain. Sur la création de hiérarchies de classes de net, l’approche visuelle de KiCad est plus intuitive que celle d’Altium, qui repose encore beaucoup sur des requêtes textuelles de type InNetClass('Power'). Sur la gestion des paires différentielles et le tuning de longueur, Altium garde une longueur d’avance grâce à son Interactive Length Tuning et à son Stackup Planner avec calcul d’impédance intégré — deux fonctions que KiCad 10 approche mais n’égale pas encore en profondeur. Là où KiCad écrase la concurrence, c’est sur le coût total de possession : zéro licence, zéro dongle, et une plateforme multiplateforme (Windows, macOS, Linux) quand Altium reste Windows uniquement.

La vraie question n’est plus « KiCad peut-il rivaliser ? » mais « pour quel type de carte ? ». Sur une carte à 4 ou 6 couches avec quelques paires différentielles, l’éditeur graphique de KiCad 10 suffit largement et l’écart de prix devient indéfendable. Sur une carte 16 couches avec des contraintes d’impédance fines et des centaines de nets haute vitesse, Altium garde des arguments — mais la 10.0 a réduit la fracture à un point où beaucoup d’équipes se posent désormais la question sérieusement.

L’écosystème 2026 : patchs, forks et IA autour de l’éditeur de règles

Un éditeur de règles ne vit pas seul. Ce qui rend la 10.0 intéressante en octobre 2026, c’est le contexte dans lequel elle s’insère.

Le rythme des patchs. La 10.0.0 de mars a été suivie d’une série de correctifs : 10.0.6 le 29 août 2026, puis 10.0.7-rc1 le 27 septembre, 10.0.7-rc2 le 3 octobre, et enfin la 10.0.7 stable le 7 octobre 2026, qui contient « les corrections de bugs critiques et autres améliorations mineures » depuis la version précédente. Cette cadence dit quelque chose d’important : l’équipe KiCad priorise les régressions qui touchent le quotidien du concepteur — et la DRC, justement, fait partie des zones surveillées. Un éditeur graphique de règles n’a de valeur que si le moteur qui l’exécute est stable ; les sept mois écoulés ont servi à ça.

Les forks. Le 11 mai 2026, le fork chinois porté par Huaqiu Electronics publiait sa 10.0.2 sur kicad.eda.cn, avec Copilot, cloud et commande en un clic. Un second fork, Zeo, pousse l’agent IA et le multi-cartes. Ces distributions doivent absorber le rythme officiel — et l’éditeur graphique de règles DRC fait partie des fonctionnalités qu’elles doivent digérer pour rester crédibles. La conférence KiCon Asia 2026, du 5 au 7 novembre 2026 à Shenzhen (Huaqiang Plaza Hotel), sera l’occasion de voir comment ces forks se positionnent face aux nouveautés officielles.

L’IA. Le plugin Konnect, binaire Rust unique, branche Claude et d’autres assistants directement dans le moteur KiCad 10 via MCP, avec 228 outils — Fellow en parlait le 14 octobre 2026, Adafruit l’a repris le 26 octobre 2026. Ces assistants peuvent proposer schémas, placements et routes. Mais l’éditeur graphique de règles DRC joue ici un rôle inattendu de garde-fou : une règle dessinée est visible, auditable, partageable. Quand une IA propose un plan de masse à 3 mm d’un connecteur, c’est la règle graphique — et la DRC qui l’exécute — qui rattrape l’erreur. La vérification reste le mur que l’IA ne franchit pas seule ; l’éditeur de règles en est une des briques.

Les outils tiers. L’écosystème périphérique continue de mûrir : AIVON a présenté le 15 septembre 2026 un outil de cotation instantanée de fabrication depuis KiCad ; des scripts communautaires génèrent des grilles de vias de stitching reliés à la masse ; les bibliothèques officielles de footprints suivent le rythme des releases (tag 10.0.7-rc1 du 22 septembre 2026 sur GitLab). Autant d’outils qui s’appuient, directement ou non, sur la capacité de KiCad à exprimer des contraintes claires — ce que l’éditeur graphique rend enfin lisible par tous.

Ce qu’il faut retenir (et ce qui reste à prouver)

Sept mois après la 10.0.0, le bilan est net. L’éditeur graphique de règles DRC tient sa promesse principale : il rend la contrainte visible. On dessine une clearance, on voit où elle s’applique, on corrige en un clic grâce aux actions suggérées. Pour l’immense majorité des cartes, c’est un gain d’ergonomie considérable et un abaissement du seuil d’entrée vers des règles qui étaient réservées aux experts du fichier .kicad_dru.

Ce qui reste à prouver ou à documenter : la sérialisation exacte des règles graphiques dans le format projet (non documentée officiellement), le comportement sur les règles conditionnelles très imbriquées, et la robustesse du moteur DRC sur les très gros projets — l’une des trois frictions que les patchs n’ont pas effacées. La 10.0.7 du 7 octobre 2026 a stabilisé l’essentiel ; les prochains cycles diront si ces angles morts se résorbent.

Une chose est sûre : en 2026, KiCad n’est plus « l’outil gratuit qui dépanne ». Avec un éditeur de règles graphique, un tuning temporel, des variantes de conception, des importateurs Allegro/PADS/gEDA et un écosystème de plugins IA qui explose, il est devenu un choix par défaut défendable — y compris face à des suites à 5 000 dollars par siège. La contrainte n’est plus un poème en S-expression. C’est un dessin. Et c’est toute la différence.

Sources

• KiCad — Version 10.0.0 Released (blog officiel, 20 mars 2026)
• Elektor Magazine — « KiCad 10 : mode sombre, nouvelles variantes et plus encore » (30 mars 2026)
• CNX Software — « KiCad 10 release – Dark mode, graphical DRC rule editor, new file importers and more » (22 mars 2026)
• KiCad — Version 10.0.7 Release (7 octobre 2026)
• KiCad — Version 10.0.7 Release Candidate 1 (27 septembre 2026)
• KiCad — Version 10.0.7 Release Candidate 2 (3 octobre 2026)
• KiCad — Version 10.0.6 Release (29 août 2026)
• KiCad — KiCon Asia 2026 Announcement (16 septembre 2026)
• KiCad — page officielle
• KiCad — page de téléchargement
• Fork Huaqiu — KiCad 10.0.2 Release (11 mai 2026)
• Fellow — « Konnect : conception de PCB assistée par IA pour KiCad 10 » (14 octobre 2026)
• Pistack — « KiCad vs LibrePCB vs Horizon EDA in 2026 » (28 septembre 2026)
• ElectricalFlux — « The 2026 PCB Design Software List: KiCad, Altium, and EasyEDA Compared » (9 septembre 2026)
• NOVAKVM — « How To Install KiCad 10.0.6 On Apple Silicon Mac » (23 septembre 2026)
• Forum KiCad — « Altium → KiCad 10 import: Symbol pin or wire end off connection grid » (1er septembre 2026)
• GitLab — KiCad Footprint Libraries, tag 10.0.7-rc1 (22 septembre 2026)
• ScriptedPCB — « Créer une grille de vias de stitching » (13 septembre 2026)
• Altium — Automated PCB Routing with Situs Topological Autorouter

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