---

Introduction : quand les règles de conception quittent le terminal

Si vous avez déjà passé des heures à débuguer un fichier de règles DRC écrit à la main – une parenthèse mal placée, une condition qui ne s’applique pas, une clearance qui refuse de se propager – vous savez à quel point la gestion des contraintes de conception peut être un casse-tête. Pendant des années, KiCad a reposé sur un système textuel : des fichiers .kicad_dru que l’on éditait avec un éditeur de code, sans retour visuel immédiat. Pour les débutants, la courbe d’apprentissage était raide. Pour les experts, la maintenance de règles complexes devenait un exercice de patience.

Avec la sortie de KiCad 10.0.0 le 30 mars 2026 (confirmée par le blog officiel, Elektor Magazine, CNX Software et electwork.net), l’équipe de développement a introduit un Graphical DRC Rule Editor – un éditeur visuel qui permet de définir les règles de conception par des clics et des menus déroulants plutôt que par du code. L’objectif affiché : rendre la configuration des contraintes plus accessible, plus rapide et moins sujette aux erreurs.

Depuis la sortie initiale, la série 10.x a enchaîné les correctifs. La version stable actuelle est KiCad 10.0.7, publiée le 7 octobre 2026 après deux release candidates (RC1 le 27 septembre, RC2 le 3 octobre, selon les annonces du site officiel). Une 10.0.8 est en release candidate depuis le 22 octobre 2026 : la branche arrive au bout de son cycle de rattrapage. Auparavant, la 10.0.6 (29 août 2026, après une RC1 le 18 août) avait été qualifiée de « critique » par le projet, qui recommandait une mise à niveau dès que possible — elle corrigeait notamment des bugs importants sur le moteur de règles, la gestion des groupes d’instances et le rafraîchissement du canvas. La documentation officielle suit ces versions.

Mais est-ce vraiment la fin des règles en texte ? Cet article propose un décryptage en profondeur : comment fonctionne cet éditeur, ce qu’il apporte concrètement, ses limites, et comment il se positionne face aux outils concurrents. Nous nous appuierons sur les sources disponibles – annonces officielles, articles techniques et retours de la communauté – tout en restant prudents là où les détails manquent.

---

Du fichier texte à l’interface visuelle : pourquoi KiCad a réinventé ses règles

Les limites de l’ancien système

Avant KiCad 10, les règles de conception étaient stockées dans des fichiers texte (souvent au format .kicad_dru ou intégrées directement dans le projet). Pour définir une règle de clearance entre deux classes de net, il fallait écrire une ligne comme :

(rule "CLR_HV" (condition "A.netclass == 'HV' && B.netclass == 'HV'") (clearance 1.0mm))

Cette syntaxe, bien que puissante, présentait plusieurs inconvénients :

• Erreurs de syntaxe fréquentes : une parenthèse manquante ou un opérateur mal orthographié pouvait rendre la règle inopérante sans message d’erreur clair.
• Courbe d’apprentissage raide : les nouveaux utilisateurs devaient apprendre un mini-langage de conditions (opérateurs logiques, accès aux propriétés des nets, etc.).
• Difficulté à exprimer des règles complexes : une règle comme « largeur de piste = 0,5 mm sur la couche Top, sauf pour les nets d’alimentation où elle doit être de 1 mm » nécessitait une combinaison de conditions parfois contre-intuitive.
• Absence de retour visuel : on ne voyait pas l’effet de la règle avant de lancer la DRC, ce qui allongeait les cycles de test.

La genèse du Graphical DRC Editor

Le développement de l’éditeur graphique a été l’un des chantiers majeurs de la version 10. Selon les chiffres publiés par l’équipe, KiCad 10 a impliqué 7 609 commits uniques – un chiffre confirmé par le blog officiel, qui précise qu’il s’agit d’une hausse notable par rapport à la version 9. Bien que les sources ne précisent pas la part exacte consacrée à l’éditeur DRC, cette fonctionnalité a été citée comme l’une des plus attendues par la communauté. Un sujet intitulé « Graphical DRC Editor – Suggestions Wanted » a d’ailleurs été ouvert sur le forum KiCad pour recueillir les retours des utilisateurs avant même la sortie officielle.

L’éditeur graphique est le fruit du travail de plusieurs contributeurs, dont Wayne Stambaugh, qui a présenté les nouveautés de KiCad 10 lors de sa conférence FOSDEM 2026 (disponible sur le site de FOSDEM). Le blog officiel renvoie d’ailleurs à cette conférence ainsi qu’au fil de discussion du forum recensant l’ensemble des nouveautés de la version 10. Les premières versions alpha ont commencé à apparaître fin 2025, et la fonctionnalité a été peaufinée jusqu’à la release candidate.

Un changement de paradigme

Avec le Graphical DRC Editor, KiCad passe d’une approche scriptée à une approche visuelle et déclarative. L’utilisateur n’écrit plus de code : il sélectionne des conditions dans des listes déroulantes, définit des valeurs dans des champs numériques, et voit immédiatement le résultat. C’est un changement comparable à celui qu’a connu le routage manuel lorsqu’on est passé des commandes textuelles aux interfaces graphiques.

---

Sous le capot : comment fonctionne l’éditeur graphique de règles DRC

Types de règles supportés

Bien que les sources disponibles (blog officiel, articles d’Elektor, de CNX Software et d’electwork.net) ne décrivent pas en détail l’interface de l’éditeur, on peut raisonnablement déduire les types de règles qu’il permet de définir, car ils correspondent aux contraintes classiques de la DRC :

Type de règle	Exemple d’application
Clearance (espacement)	Distance minimale entre deux pistes, entre une piste et un plan, etc.
Largeur de piste	Largeur minimale, maximale ou préférée pour une classe de net ou une couche.
Taille de via	Diamètre de perçage, taille du pad annulaire, via en aveugle/enterré.
Contraintes de couche	Largeur autorisée sur une couche spécifique, via autorisé ou non.
Règles de zone	Clearance autour des zones de cuivre, règles de remplissage.
Règles de net class	Appliquer un ensemble de contraintes à une classe de net (ex : « Power », « Differential »).

L’éditeur permet de combiner ces contraintes avec des conditions : par type de via (traversant, micro-via), par couche, par classe de net, ou même par net individuel. L’interface devrait proposer des sélecteurs visuels pour chaque condition, ainsi qu’un aperçu des règles actives.

Stockage et intégration avec le moteur DRC temps réel

Les règles définies graphiquement sont stockées dans le fichier projet .kicad_pcb (ou éventuellement dans un fichier séparé, mais les sources ne le précisent pas). Le format interne reste probablement basé sur des S-expressions, comme le reste de KiCad, mais l’utilisateur n’a plus besoin de le manipuler directement.

Le moteur DRC temps réel, déjà présent dans KiCad 9, a été amélioré pour prendre en compte les modifications de règles en direct. Lorsque l’utilisateur change une valeur dans l’éditeur graphique, les violations sont recalculées instantanément et les marqueurs d’erreur se mettent à jour sur le PCB. Cette réactivité est cruciale pour un workflow fluide. La version 10.0.6 a d’ailleurs corrigé un problème de gestion mémoire du moteur de règles (voir le changelog), confirmant que ce composant reste au cœur des priorités de l’équipe.

Actions de correction suggérées

Une innovation notable de KiCad 10, mentionnée par Elektor Magazine, est l’apparition d’actions de correction suggérées pour les erreurs DRC. Par exemple, si une piste est trop fine, l’éditeur peut proposer d’élargir automatiquement la piste à la valeur minimale autorisée. Cette fonctionnalité, couplée à l’éditeur graphique, réduit encore le temps passé à résoudre les violations.

---

Règles complexes devenues simples : trois cas pratiques qui changent la donne

Les sources fournies ne décrivent pas de cas d’usage concrets avec captures d’écran. Cependant, on peut illustrer le potentiel de l’éditeur graphique à travers des exemples typiques qui étaient auparavant laborieux à configurer en texte.

1. Règles de clearance pour paires différentielles

Avant (texte) : il fallait écrire une condition vérifiant que les deux nets appartiennent à une classe « DiffPair », puis définir un gap et une tolérance. La moindre erreur de syntaxe cassait la règle.

Avec l’éditeur graphique : on sélectionne la classe de net « DiffPair » dans le champ « Net class A » et « Net class B », on choisit le type de règle « Clearance », et on entre la valeur du gap (ex : 0,2 mm) et la tolérance (ex : ±0,05 mm). L’éditeur affiche visuellement les nets concernés et met à jour la DRC en temps réel.

2. Règles de via-in-pad

Avant : pour autoriser un via dans un pad BGA, il fallait écrire une règle complexe avec des conditions de couche et de taille de via.

Avec l’éditeur graphique : on crée une règle de type « Via » avec la condition « Pad type = SMD », on définit une taille de via maximale (ex : 0,3 mm de perçage), et on l’applique à une classe de net spécifique (ex : « BGA_Signals »). L’éditeur valide la cohérence des valeurs.

3. Règles de garde pour zones haute tension

Avant : pour créer une zone de keepout autour des nets haute tension (HV), il fallait combiner une règle de clearance avec une règle de zone, souvent en plusieurs étapes.

Avec l’éditeur graphique : on définit une règle de « Clearance » entre la classe de net « HV » et toute autre classe, avec une valeur élevée (ex : 2 mm). On peut aussi ajouter une règle de « Zone » pour empêcher le remplissage de cuivre à moins de 2 mm des nets HV. L’éditeur permet de visualiser la zone de garde directement.

Ces exemples montrent comment l’éditeur graphique transforme des configurations qui prenaient auparavant plusieurs minutes (et plusieurs tentatives) en quelques clics. Bien sûr, les détails précis de l’interface restent à découvrir dans la documentation officielle, mais le principe est clair : la complexité est masquée par une interface intuitive.

---

Intégration temps réel : quand la DRC devient interactive

Un moteur DRC réactif

KiCad 10 hérite du moteur DRC temps réel introduit dans les versions précédentes, mais l’éditeur graphique l’amplifie. Dès qu’une règle est modifiée – ajout, suppression, changement de valeur – le moteur recalcule les violations sur l’ensemble du PCB. Les marqueurs d’erreur (croix rouges, surlignages) apparaissent ou disparaissent instantanément. Fini le cycle « modifier le fichier texte → sauvegarder → relancer la DRC → attendre → constater l’erreur ».

Actions de correction suggérées

Comme mentionné plus haut, KiCad 10 propose des suggestions de correction pour certaines violations. Par exemple :

• Si une piste a une largeur de 0,2 mm alors que la règle impose 0,3 mm, l’éditeur propose « Élargir à 0,3 mm ».
• Si un via est trop petit, il propose « Augmenter le diamètre de perçage à X mm ».
• Si une clearance est insuffisante, il propose « Déplacer la piste de X mm ».

Ces suggestions restent toutefois à valider par l’utilisateur : KiCad ne modifie pas automatiquement le routage sans confirmation, ce qui préserve le contrôle du concepteur.

Les limites à connaître : quand la 10.0.x montre ses faiblesses

Six mois de recul permettent aussi de voir les ratés. Le forum KiCad documente ainsi un problème sérieux de performance dans l’éditeur PCB sur les versions 10.0.4 et 10.0.5 : le déplacement d’une piste déjà routée devenait extrêmement lent, au point de rendre la 10.0.5 « inutilisable » pour certains utilisateurs travaillant sur des cartes existantes (fil de discussion). Ce type de régression illustre que la branche 10.0.x, malgré ses fonctionnalités séduisantes, a connu un cycle de stabilisation mouvementé — d’où l’insistance du projet à migrer vers les correctifs les plus récents.

Autre point de friction relevé par la communauté : l’import Altium, pourtant mis en avant dans la 10.0.0, génère encore des avertissements ERC en série (« Symbol pin or wire end off connection grid ») sur presque chaque broche lors de la migration d’un projet Altium 25.6.2 vers KiCad 10.0.6 (forum KiCad, 1er septembre 2026). L’importateur natif fonctionne, mais demandera un nettoyage manuel sur les projets complexes.

---

L’écosystème autour du DRC : plugins, scripts et automatisation

Le DRC comme brique d’automatisation

L’un des effets les plus intéressants de l’éditeur graphique est indirect : en rendant les règles plus lisibles et mieux structurées, il facilite leur manipulation par script. La branche 10.0.x a justement introduit de nouveaux bindings Python basés sur IPC (en complément des bindings SWIG historiques), qui permettent d’inspecter et de modifier un board par programme. Les cas d’usage typiques incluent les DRC personnalisés, le placement automatique de composants et le nettoyage de pistes — autant de tâches qui s’appuient sur les mêmes règles que celles définies dans l’éditeur graphique.

Stitching vias et scripts prêts à l’emploi

Côté plugins, la communauté a produit des outils directement complémentaires au travail de contrainte. Un article de scriptedpcb.com (13 septembre 2026) détaille ainsi la génération d’une grille complète de vias de stitching reliés à la masse par script, plutôt qu’à la main — un gain de temps considérable sur les cartes à plan de masse, RF ou à gestion thermique. Un tutoriel de SaludPCB (11 août 2026) propose la même approche « en un clic » pour remplir automatiquement les plans de masse. Ces scripts s’appuient sur les règles de clearance et de via définies dans KiCad : autant dire que la qualité de ces règles conditionne directement la qualité du résultat généré.

Autoroutage et validation DRC

L’autoroutage reste le parent pauvre de la CAO, mais 2026 a vu émerger des pistes sérieuses. Le plugin OrthoRoute exploite la puissance du GPU (CUDA) pour paralléliser la recherche de chemins selon l’algorithme PathFinder, avec des benchmarks désormais disponibles. Plus classique, Freerouting reste l’option gratuite de référence, mais un rapport de bug de fin août 2026 signale une régression en version 2.3.0 : les routes produites présentent des violations de clearance auto-déclarées sur des cartes que la 2.2.4 routait proprement (GitHub). La leçon est constante : quel que soit l’outil d’autoroutage, la validation par la DRC de KiCad reste l’étape non négociable — et c’est précisément là que l’éditeur graphique de règles prend tout son sens, puisqu’il permet de vérifier et d’ajuster les contraintes avant de lancer l’autorouteur.

IA et copilotes : où en est-on vraiment ?

L’IA s’invite dans les workflows KiCad, mais avec des résultats inégaux. Un article de DevTrends (7 septembre 2026) présente Konnect, un plugin natif pour KiCad 10 écrit en Rust, qui transforme Claude en assistant de schématique et de routage via le protocole MCP. D’autres expérimentations existent, comme ALT TAB Circuit Copilot, encore au stade expérimental. Une analyse de protoflow.ai (31 juillet 2026) recense trois méthodes réelles pour ajouter de l’IA à un workflow KiCad — un chiffre qui invite à la prudence face aux promesses marketing. L’IA ne remplace pas encore la définition rigoureuse des règles DRC ; elle peut en revanche accélérer certaines tâches répétitives, à condition de valider systématiquement le résultat.

---

Ce que la 10.0.x change vraiment pour le concepteur PCB

Un bilan fonctionnel

Au-delà du DRC graphique, KiCad 10 a apporté un ensemble de nouveautés qui, mises bout à bout, transforment le quotidien :

• Variantes de conception : gérer plusieurs configurations d’un même projet (prototypes, versions régionales, options de production) sans dupliquer le projet.
• Mode sombre sous Windows, barres d’outils personnalisables, sélection au lasso dans les éditeurs de schémas et de PCB, annulation/rétablissement dans les boîtes de dialogue.
• Importateurs natifs pour Allegro, PADS et gEDA/Lepton PCB — un vrai plus pour migrer des projets anciens.
• Côté schéma : croisements de fils avec saut (hop-over), prise en charge des cavaliers, regroupement et échange CSV dans le tableau de broches.
• Côté PCB : réglage en domaine temporel, blocs de conception de PCB, objets de couche interne dans les empreintes, échange de broches et de portes sans contrainte, export PDF 3D, codes-barres, remplissages hachurés, édition de polygones plus précise.
• Bibliothèques : depuis la version 10, les modèles 3D sont livrés exclusivement au format STEP, ce qui réduit fortement la taille d’installation et améliore la précision géométrique (blog officiel).

Le DRC graphique face à la concurrence

Face à Altium Designer — dont l’abonnement annuel se situe entre 3 850 et 5 000 USD par utilisateur, avec un coût total sur trois ans pour cinq postes (formation incluse) dépassant les 175 000 USD — KiCad reste gratuit et multiplateforme (Windows, macOS, Linux), là où Altium reste cantonnée à Windows. Sur la gestion des contraintes, Altium garde une longueur d’avance historique, mais l’éditeur graphique de KiCad 10 comble une partie du retard en rendant les règles accessibles sans expertise en scripting. Pour une équipe qui n’a pas besoin des fonctions de gestion de données d’entreprise d’Altium, l’argument économique est massif.

---

Conclusion : un éditeur qui tient ses promesses, à condition de suivre les correctifs

Six mois après la 10.0.0, le bilan du Graphical DRC Editor est globalement positif. La fonctionnalité fait ce qu’elle promet : rendre la définition des contraintes accessible, réduire les erreurs de syntaxe et accélérer les cycles de test grâce au retour visuel et aux suggestions de correction. Couplée aux variantes de conception, aux importateurs natifs et aux nouveaux bindings Python, elle s’inscrit dans une version 10 réellement charnière.

Mais l’histoire de la branche 10.0.x est aussi celle d’une stabilisation laborieuse : régressions de performance dans l’éditeur PCB sur les 10.0.4/10.0.5, avertissements ERC à l’import Altium, régression de clearance chez Freerouting 2.3.0. La recommandation est donc simple : rester sur la version stable la plus récente (10.0.7, ou la 10.0.8 dès sa sortie), vérifier systématiquement ses règles DRC après migration, et ne jamais faire confiance aveuglément à un autorouteur sans repasser par la DRC.

Pour aller plus loin, la documentation officielle et le forum KiCad restent les meilleures sources, complétées par la conférence FOSDEM 2026 de Wayne Stambaugh. Et pour ceux qui veulent rencontrer la communauté, la KiCad Conference Asia 2026 se tiendra à Shenzhen du 5 au 7 novembre 2026 (annonce officielle) — l’occasion de voir le DRC graphique en action et de discuter des prochaines évolutions.

---

Sources

• KiCad — Version 10.0.0 Released (30 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)
• electwork.net — KiCad 10.0 New Features: Importers, Variants, Graphical DRC
• KiCad — Version 10.0.6 Release (29 août 2026) et RC1 (18 août 2026)
• KiCad — Version 10.0.7 Release Candidate 1 (27 septembre 2026) et RC2 (3 octobre 2026)
• KiCad — KiCad Conference Asia 2026 Announcement (16 septembre 2026)
• KiCad — Documentation officielle
• Forum KiCad — KiCad 10.0.4 / 10.0.5 – extremely slow track movement in PCB Editor (12 août 2026)
• Forum KiCad — Altium → KiCad 10 import: « Symbol pin or wire end off connection grid » (1er septembre 2026)
• GitHub — Freerouting 2.3.0 regression: routes ship self-reported clearance violations (28 août 2026)
• scriptedpcb.com — Créer une grille de vias de stitching avec un script (13 septembre 2026)
• SaludPCB — KiCad Plugin Tutorial 2026: Stitching Vias Made Effortless (11 août 2026)
• DevTrends — Как подключить Claude к KiCad 10 (plugin Konnect) (7 septembre 2026)
• protoflow.ai — The 10 Best PCB Design Software Tools in 2026 (10 août 2026) et KiCad vs Altium in 2026 (9 août 2026)
• FOSDEM 2026 — Wayne Stambaugh, KiCad talk