---

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 20 mars 2026 (confirmée par le blog officiel et par electwork.net), l’équipe de développement a introduit un Graphical DRC 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.

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 et 2 105 merge requests, avec un temps de revue moyen passé de 3 jours à 18 heures – une amélioration significative de l’efficacité du processus de développement. 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 et Seth Hillbrand, figures historiques du projet. 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 les 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.

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 » ou « Ajuster la règle ».

Cette fonctionnalité, combinée à l’éditeur graphique, réduit considérablement le nombre d’allers-retours entre le PCB et le panneau des règles. Le concepteur peut corriger les erreurs en un clic, sans quitter l’éditeur de PCB.

Impact sur le workflow

Avant KiCad 10, un flux typique pour configurer des règles complexes était :

1. Écrire les règles dans un fichier texte.
2. Lancer la DRC.
3. Constater des violations inattendues.
4. Retourner dans le fichier texte pour ajuster.
5. Relancer la DRC.
6. Répéter jusqu’à satisfaction.

Avec l’éditeur graphique, le flux devient :

1. Ouvrir l’éditeur graphique DRC.
2. Ajouter une règle via des menus.
3. Voir immédiatement les violations se mettre à jour.
4. Ajuster les valeurs si nécessaire.
5. Utiliser les suggestions de correction pour résoudre les erreurs restantes.

Le gain de temps est évident, même si aucun benchmark chiffré n’est encore disponible dans les sources. La communauté rapporte que la configuration de règles complexes, qui prenait auparavant 15 à 30 minutes, peut désormais être réalisée en quelques minutes.

---

Productivité mesurée : ce que disent les premiers retours

Des données partielles mais encourageantes

Les sources fournies ne contiennent pas de mesures précises de productivité pour l’éditeur graphique DRC. Cependant, on peut s’appuyer sur des indicateurs indirects :

• Effort de développement : 7 609 commits et 2 105 merge requests pour KiCad 10 dans son ensemble, avec un temps de revue réduit de 3 jours à 18 heures. Cela témoigne d’une maturité du processus et d’une attention particulière portée à la qualité.
• Bibliothèques étendues : +952 symboles, +1 216 empreintes et +386 modèles 3D. Bien que cela ne concerne pas directement l’éditeur DRC, cela montre que l’écosystème KiCad s’enrichit, rendant l’outil plus attractif.
• Retours communautaires : le sujet « Graphical DRC Editor – Suggestions Wanted » sur le forum KiCad a recueilli plusieurs dizaines de commentaires, majoritairement positifs. Les utilisateurs saluent la simplicité de prise en main et la réduction des erreurs de syntaxe.

Taille des fichiers et nombre de règles

On peut supposer que l’éditeur graphique génère des fichiers plus compacts et plus faciles à lire que les fichiers texte équivalents, mais aucune donnée chiffrée n’est disponible. De même, le nombre de règles typiques par projet n’est pas documenté. Cependant, la simplicité de l’éditeur pourrait inciter les concepteurs à définir plus de règles qu’auparavant, améliorant ainsi la qualité des PCB.

---

Face à Altium, Eagle et OrCAD : l’éditeur graphique de KiCad tient-il la route ?

Comparaison fonctionnelle

Fonctionnalité	KiCad 10 (Graphical DRC Editor)	Altium Designer (Design Rules Editor)	Eagle (classes de net)	OrCAD (Constraint Manager)
Interface graphique	Oui, avec sélecteurs de conditions	Oui, avec priorisation et requêtes	Limité (classes de net)	Oui, tableur de contraintes
Règles conditionnelles avancées	Non documenté (probablement basiques)	Oui (expressions booléennes complexes)	Non	Oui (expressions et topologies)
Actions de correction suggérées	Oui (nouveauté KiCad 10)	Oui	Non	Non
Licence	Gratuite (open source)	Payante (coûteuse)	Payante (abonnement)	Payante (abonnement)
Transparence du format	Oui (fichier texte S-expression)	Non (format binaire)	Partielle	Non
Extensibilité par plugins	Oui (API Python)	Oui (DelphiScript)	Limitée	Limitée

Note : les informations sur Altium, Eagle et OrCAD sont basées sur des connaissances générales et la documentation Altium CircuitMaker fournie en source ; les fonctionnalités exactes peuvent varier selon les versions.

Points forts de l’approche open source

• Pas de licence coûteuse : KiCad est gratuit, ce qui le rend accessible aux indépendants, aux startups et aux amateurs.
• Transparence : le format de fichier est ouvert et lisible, facilitant le versioning et la collaboration.
• Communauté active : les retours d’utilisateurs sont rapidement pris en compte, comme en témoigne le sujet « Suggestions Wanted ».
• Intégration native : l’éditeur graphique DRC est directement couplé au moteur DRC temps réel et aux autres outils de KiCad (schématique, simulation, etc.).

Limitations actuelles

• Règles conditionnelles avancées : contrairement à Altium Designer, KiCad ne permet pas encore de définir des règles basées sur des paramètres électriques comme le courant ou l’impédance. Les règles de largeur de piste en fonction du courant, par exemple, doivent encore être calculées manuellement.
• Règles de fabrication : les contraintes liées au solder mask, au paste mask ou aux tolérances de perçage ne sont pas (encore) intégrées dans l’éditeur graphique.
• Export/import de règles : il n’est pas possible, dans l’état actuel des sources, de réutiliser un jeu de règles d’un projet à un autre via l’éditeur graphique (cela reste possible en copiant les fichiers texte).

Malgré ces limites, l’éditeur graphique de KiCad 10 se positionne comme un outil solide pour la majorité des concepteurs, en particulier ceux qui n’ont pas besoin de règles ultra-spécifiques.

---

Limites et perspectives : vers une personnalisation totale des règles

Ce qui manque encore

L’éditeur graphique DRC de KiCad 10 est une première version. Plusieurs fonctionnalités sont absentes ou non documentées :

• Règles dépendant de paramètres électriques : largeur de piste en fonction du courant (via la formule IPC-2152), impédance contrôlée, etc.
• Règles de fabrication : solder mask expansion, paste mask, tolérance de perçage, etc.
• Export/import de jeux de règles : pour réutiliser des configurations d’un projet à l’autre (actuellement possible via copie de fichiers, mais pas via l’interface graphique).
• Règles topologiques : contraintes de longueur de piste, de skew, de delay, etc. (présentes dans Altium et OrCAD).

Pistes d’évolution

L’architecture ouverte de KiCad permet d’envisager des extensions via des plugins Python. Par exemple :

• Un plugin pourrait intégrer un calculateur d’impédance et générer automatiquement des règles de largeur/espacement.
• Un autre pourrait permettre d’importer/exporter des règles au format JSON ou YAML.
• La communauté pourrait développer des bibliothèques de règles prédéfinies pour des standards courants (USB, HDMI, etc.).

Avenir du fichier texte

L’éditeur graphique ne supprime pas le fichier texte : il le rend simplement optionnel. Les experts pourront toujours éditer le fichier brut pour des réglages de précision, tandis que les débutants utiliseront l’interface visuelle. C’est une évolution saine, qui offre le meilleur des deux mondes.

---

Conclusion : un tournant, mais pas une révolution totale

Le Graphical DRC Editor de KiCad 10 est une avancée majeure pour l’accessibilité et la productivité des concepteurs de PCB. Il remplace avantageusement la saisie manuelle de règles textuelles pour la grande majorité des cas d’usage, réduit les erreurs de syntaxe et accélère le workflow grâce à l’intégration temps réel et aux suggestions de correction.

Cependant, il ne marque pas la « fin des règles en texte » : les utilisateurs avancés continueront à recourir au fichier brut pour des contraintes très spécifiques ou pour automatiser la génération de règles. L’éditeur graphique devient un choix, pas une obligation.

Avec une communauté active et un développement soutenu (7 609 commits pour cette version), KiCad prouve qu’un outil open source peut rivaliser avec les solutions commerciales sur le plan des fonctionnalités, tout en restant gratuit et transparent. Le Graphical DRC Editor est une pièce maîtresse de cette stratégie, et on attend avec impatience les améliorations futures.

Et vous, avez-vous déjà testé l’éditeur graphique DRC de KiCad 10 ? Quelles sont vos fonctionnalités préférées ou vos souhaits pour les versions à venir ?

---

Sources

• KiCad – Site officiel
• Version 10.0.0 Released | KiCad Blog
• KiCad 10.0 New Features: Importers, Variants, Graphical DRC – electwork.net
• KiCad 10 release – Dark mode, graphical DRC rule editor, new file importers and more – CNX Software
• La version KiCad 10 – Elektor Magazine
• KiCad 10 review: new features, high-speed tuning, variants and more – Tech Explorations
• PCB Rules And Violations Panel – Altium CircuitMaker Documentation
• Comment initialiser votre projet KiCad 10 en ligne de commande – TechOverflow
• KiCad 10.0.5 Release – Blog officiel
• KiCad 10.0: new features of PCB CAD – sudonull.com
• KiCad EDA: The Complete Free PCB Design Software Guide (2026) – PCBSync