Electrosens R&D

Le routeur interactif de KiCad 10 passé au crible : ce qui change vraiment dans le geste de router (10.0.6, 10.0.7 RC2)

Electrosens Kicad Master · 26 October 2026

Le routeur interactif de KiCad 10 passé au crible : ce qui change vraiment dans le geste de router (10.0.6, 10.0.7 RC2)

KiCad 10.0.0 a débarqué en mars 2026, et la branche 10.0.x est aujourd’hui stabilisée autour de la 10.0.6 (29 août 2026) et d’une 10.0.7 en release candidate depuis le 3 octobre 2026. Sur le papier, le routeur interactif n’est pas la star de cette mouture — les projecteurs sont braqués sur les variantes, l’éditeur graphique de règles DRC et les importateurs. Et pourtant, c’est lui qui décide, chaque jour, si une session de layout est un plaisir ou une corvée. Voici ce que la 10 fait réellement à votre geste de router, et où il faut encore garder la main.

Le routeur n’est plus un accessoire : ce que KiCad 10 change dans le geste de router

Prenons une carte réaliste : un microcontrôleur central, deux connecteurs haute densité, un bus différentiel qui traverse la carte de part en part, une zone d’alimentation en cuivre sur deux couches. Dans KiCad 9, ce genre de session se déroulait selon un rythme bien connu : on lance une piste, le moteur pousse ce qu’il peut, on bute sur un obstacle qu’il refuse de déplacer, on annule, on déplace l’obstacle à la main, on relance. La boucle de décision — « est-ce que je pousse, est-ce que je contourne, est-ce que je casse et je refais ? » — se jouait en grande partie dans la tête du concepteur, pas dans le moteur.

La version 10 ne réécrit pas cette boucle de zéro, mais elle déplace le curseur. Le manuel de référence de la branche 10.0 (établi sur la version 10.0.7 du logiciel, révision de documentation efa5960e) décrit un routeur interactif qui articule explicitement trois modes — push-and-shove, walkaround, highlight collisions — et qui prend en charge le routage différentiel ainsi que le tuning de longueur et de skew. Ce ne sont pas des fonctionnalités nouvelles au sens strict : le routeur interactif existe depuis la branche 5.x, où la documentation le présentait déjà comme un outil vérifiant en permanence les règles de conception. Ce qui change en 10, c’est le contexte dans lequel ce moteur opère : un éditeur de règles DRC graphique, des variantes de carte, des règles scriptables plus présentes dans le flux de travail. Autrement dit, le routeur n’est plus évalué isolément, mais comme le point d’application de toute la chaîne de contraintes.

Il faut poser d’emblée une limite de méthode, et elle est importante : la documentation officielle de la 10.0 est encore explicitement en cours de révision, certaines sections ne sont pas complétées, et aucune source publique consultée ne fournit de description algorithmique du moteur de résolution de collisions, ni de benchmark chiffré du push-and-shove. Cet article s’appuie donc sur ce que la documentation confirme, sur les faits datés de l’écosystème 2026 et sur des scénarios de terrain reproductibles — en signalant honnêtement les zones d’ombre plutôt qu’en les comblant par des chiffres inventés.

Push-and-shove, walkaround, highlight collisions : la mécanique réelle des trois modes

La documentation de KiCad 10 est claire sur la taxonomie, sinon sur l’implémentation. Trois modes coexistent dans le PCB Editor :

Source : lebigdata.fr
  • Push-and-shove : le moteur déplace les pistes et les vias existants pour faire de la place à la nouvelle piste en cours de tracé. C’est le mode le plus spectaculaire — et le plus exigeant en configuration.
  • Walkaround : le moteur contourne les obstacles au lieu de les pousser. La piste en cours de tracé longe les éléments existants, quitte à faire des détours, mais ne déplace rien.
  • Highlight collisions : le moteur ne déplace ni ne contourne ; il signale les collisions. C’est le mode « observation », celui qu’on utilise quand on veut garder le contrôle total du tracé et se servir du routeur comme d’un simple vérificateur en temps réel.

Ces trois modes s’articulent avec le DRC, dont la documentation rappelle qu’il détecte automatiquement les violations : connexions incorrectes ou manquantes, violations de clearance cuivre, largeur minimale de piste, entre autres. C’est là que se joue la décision « pousser, contourner ou bloquer » : le moteur ne pousse pas au-delà de ce que les règles autorisent, et le DRC temps réel sert de garde-fou pendant le geste. Un push-and-shove agressif sur une carte où les clearances sont mal réglées ne produit pas un routage propre — il produit un chaos de pistes déplacées qu’il faut ensuite démêler à la main.

Ce que la documentation ne dit pas, en revanche, mérite d’être souligné : elle ne documente ni l’algorithme de résolution de collisions, ni la gestion fine du « hug » (cette tendance du moteur à coller la piste en cours le long des obstacles plutôt qu’à s’en écarter), ni le comportement exact du moteur quand plusieurs solutions de poussée sont possibles. Les présentations de développeurs (Jon Evans, Wayne Stambaugh et Jean-Pierre Charras figurent parmi les contributeurs de la documentation ; Seth Hillbrand, lui, n’apparaît pas dans la liste fournie) ne sont pas non plus accessibles dans les sources consultées pour corroborer ces détails. C’est une zone d’ombre assumée : on sait ce que le moteur fait, on ne sait pas comment il le fait.

Hug, clearance et réglages : la configuration qui évite de se brûler

Le routeur interactif de KiCad 10 se comporte comme un moteur de contraintes : sa qualité dépend presque entièrement de la qualité des règles qu’on lui donne. Trois familles de réglages méritent d’être maîtrisées avant de lancer la première piste.

Les clearances. Elles ne sont plus seulement des valeurs numériques héritées d’un tableau : avec l’éditeur graphique de règles DRC introduit en 10.0, elles peuvent être définies par zone, par classe de net, par type d’objet. Un réglage trop permissif laisse le push-and-shove pousser des pistes jusqu’à des distances que le DRC final refusera ; un réglage trop strict transforme chaque poussée en impasse. La bonne pratique, sur une carte dense, consiste à partir des clearances réelles du fabricant, à les appliquer par classe, puis à n’assouplir localement — via une règle graphique — que là où le routage l’exige.

Le comportement de hug. Le manuel ne détaille pas de paramètre de « tolérance de hug » explicite, mais le comportement observable est bien là : le moteur colle la piste en cours le long des pistes existantes lorsqu’il pousse. Sur une carte peu dense, c’est agréable ; sur une carte où l’on veut garder de l’air pour un futur via ou une zone de cuivre, cela peut produire des tracés trop serrés qu’il faut ensuite écarter. La parade est empirique : router d’abord les nets critiques en mode walkaround ou highlight collisions, puis basculer en push-and-shove pour les nets secondaires.

La priorité entre pistes et vias. La documentation ne formalise pas de mécanisme de priorité explicite. En pratique, les vias sont plus difficiles à pousser que les pistes — un fait corroboré par les tickets GitLab du dépôt kicad/code/kicad, dont le #15840 signalait précisément l’impossibilité de shover les vias pendant le routage. Ce ticket n’est pas daté de la 10 dans les sources consultées, et il faut donc rester prudent : la 10 a probablement amélioré les choses, mais on ne peut pas affirmer que le shove de vias est aujourd’hui pleinement abouti. Le ticket #18550, lui, pointait un problème plus structurel : le shove PNS ne respectait pas les règles de conception personnalisées item-à-item. Là encore, pas de confirmation de résolution en 10 — mais un signal clair que les règles scriptables et le push-and-shove ne font pas toujours bon ménage.

Recommandations par type de carte. Sur une carte faible densité (deux couches, quelques nets), le push-and-shove en mode par défaut est un confort ; inutile de surconfigurer. Sur une carte dense (quatre à huit couches, BGA), il faut au contraire désactiver le shove par défaut, router en walkaround, et n’activer le push-and-shove que sur des zones dégagées. Sur une carte haute vitesse, la règle est différente : le tuning de longueur et de skew impose des contraintes que le push-and-shove peut casser, et il vaut mieux router les paires différentielles en mode contrôlé, puis tuner, puis vérifier.

Paires différentielles : gap, largeur, et l’accord de longueur/skew en conditions réelles

C’est le terrain où KiCad 10 est le plus attendu — et où la documentation est la plus explicite, sinon la plus détaillée. Le manuel confirme que le routeur interactif supporte le routage différentiel ainsi que le tuning de longueur et de skew. La formulation est brève, mais elle acte une chose : le tuning n’est plus un bricolage externe, il fait partie du routeur.

Source : astuces-aide-informatique.info

Concrètement, le flux de travail se décompose en trois temps. D’abord, la définition de la paire : deux nets identifiés comme paire différentielle, avec une largeur de piste et un gap (écart entre les deux pistes) définis dans les règles. Ensuite, le routage : le moteur trace les deux pistes simultanément, en maintenant le gap. Enfin, le tuning : on ajuste la longueur de chaque piste pour respecter une longueur cible, et on gère le skew — le désalignement entre les deux pistes de la paire — en insérant des motifs d’accord (accord en méandre, en accordéon).

Sur le papier, c’est propre. En conditions réelles, c’est plus nuancé. Sur un bus USB ou Ethernet, où les paires sont courtes et peu contraintes, le tuning automatique fait l’essentiel du travail. Sur un bus HDMI ou LVDS, où plusieurs paires doivent être accordées entre elles et où le skew inter-paires compte autant que le skew intra-paire, il faut souvent reprendre la main : le moteur accorde bien une paire, mais l’accord global d’un bus reste une opération largement manuelle, paire par paire, avec vérification des longueurs. Sur de la DDR, la question est encore plus délicate : la documentation ne fournit pas de chiffres précis sur les tolérances de tuning, et il faut donc se référer aux contraintes du composant, pas à un réglage par défaut du logiciel.

L’interaction avec le push-and-shove est le point le plus délicat. Si vous tuné une paire puis repassez en push-and-shove sur un net voisin, le moteur peut déplacer une des pistes de la paire et casser l’accord de longueur. La règle pratique : tuner en dernier, ou verrouiller les paires accordées avant de repasser en shove. La documentation ne formalise pas ce verrouillage comme une fonction du routeur, mais les règles de conception (par classe de net, par zone) permettent de contraindre le moteur à respecter les longueurs.

Règles DRC graphiques et règles scriptables : le routeur sous contrainte

KiCad 10 introduit — c’est l’un des faits saillants de la 10.0.0 — un éditeur graphique de règles DRC. Combiné aux règles scriptables, qui permettent de spécifier des contraintes et conditions complexes, cela change profondément la façon dont le routeur est contraint. Mais cela change aussi la façon dont il peut se bloquer.

Un exemple concret : une règle graphique qui impose une clearance élargie autour d’un connecteur haute tension. Le push-and-shove, en approchant de cette zone, ne poussera pas au-delà de la clearance élargie — il s’arrêtera net, ou contournera. Si la règle est mal placée (par exemple, si elle chevauche une zone de routage dense sans marge), le moteur peut se retrouver dans une impasse : aucune solution de poussée ne satisfait la contrainte, et le routeur refuse d’avancer. C’est un comportement correct, mais déroutant si l’on ne sait pas que la règle graphique en est la cause.

Autre cas : une règle scriptable qui bloque le tuning. Si une règle impose une longueur maximale à un net, et que le tuning tente d’insérer un méandre qui dépasse cette longueur, le moteur peut refuser l’accord. Là encore, c’est le comportement attendu — mais il faut savoir le diagnostiquer. La documentation ne fournit pas de guide de diagnostic des interactions entre règles scriptables et routeur ; c’est un point où l’expérience compte plus que le manuel.

Les variantes de carte, autre nouveauté de la 10.0, ajoutent une couche. Une variante qui active ou désactive des composants change les nets à router, et donc les contraintes que le routeur doit respecter. Router une carte en pensant à une seule variante, puis basculer sur une autre, peut produire des violations DRC inattendues. La bonne pratique : router la variante la plus contrainte en premier, puis vérifier les autres.

Migration depuis KiCad 9 : ce qui casse, ce qui surprend, ce qu’il faut refaire

Le passage de KiCad 9 à 10 n’est pas une simple mise à jour. Les retours de terrain de 2026 — notamment sur le forum officiel — signalent des comportements qui surprennent. Le plus documenté concerne les performances : un fil du forum kicad.info daté du 12 août 2026 rapporte que les versions 10.0.4 et 10.0.5 rendaient le déplacement de pistes existantes dans le PCB Editor « extrêmement lent », la 10.0.5 devenant « inutilisable » pour certains utilisateurs. Ce problème a été corrigé dans les versions ultérieures — la 10.0.6 du 29 août 2026 contient des correctifs critiques — mais il illustre un point essentiel : la branche 10.0.x a connu des régressions de performance sur le routeur, et il faut vérifier sa version avant de router une carte critique.

Source : boulanger.com

Autre point de friction documenté : l’import Altium. Un fil du forum (1er septembre 2026) rapporte que l’import d’un projet Altium 25.6.2 vers KiCad 10.0.6 génère des avertissements ERC « Symbol pin or wire end off connection grid » sur presque chaque broche et chaque fil. Ce n’est pas un problème de routeur à proprement parler, mais cela signifie que les projets importés arrivent avec des nets mal alignés, ce qui complique ensuite le routage.

Checklist de migration pratique :

  1. Vérifier la version exacte : la 10.0.6 (29 août 2026) est la référence stable ; la 10.0.7 est en RC2 depuis le 3 octobre 2026 et devrait sortir sous peu sauf problème critique.
  2. Réinitialiser les réglages de routeur : les clearances héritées de KiCad 9 ne se comportent plus pareil avec l’éditeur graphique de règles.
  3. Reconfigurer les paires différentielles : les définitions de paires et les règles de gap/largeur doivent être revérifiées.
  4. Revérifier le tuning : les longueurs accordées en 9 ne sont pas nécessairement valides en 10.
  5. Tester le DRC sur une carte existante avant de router : l’ordre des vérifications a changé, et des violations autrefois tolérées peuvent apparaître.
  6. Router une carte test avant une carte critique : les régressions de performance (10.0.4/10.0.5) montrent que la prudence est de mise.

Ce que le routeur de KiCad 10 ne fait toujours pas — et ce que ça coûte

Il faut le dire clairement : il n’existe pas, dans les sources consultées, de benchmark public chiffré du routeur de KiCad 10. Pas de temps de push-and-shove mesuré sur une carte dense, pas de nombre de couches ou de pistes gérées documenté, pas de comparaison de vitesse avec KiCad 9. Les comparaisons avec Altium, Cadence Allegro, Mentor/Xpedition ou EasyEDA existent sur des critères généraux — prix, plateforme, gestion des contraintes — mais pas sur le push-and-shove ou le tuning haute vitesse. Toute affirmation chiffrée sur ces points serait inventée.

Ce que l’on peut dire, en revanche, c’est où KiCad rattrape et où il reste derrière. Là où il rattrape : le routage différentiel et le tuning longueur/skew sont désormais des fonctions documentées du routeur interactif ; les règles scriptables et l’éditeur graphique de règles DRC donnent un niveau de contrôle qui n’a plus grand-chose à envier aux outils commerciaux sur le papier. Là où il reste derrière : le via stitching avancé, qui reste souvent traité par script ou plugin plutôt que nativement — un article de scriptedpcb.com du 13 septembre 2026 propose encore de générer une grille de vias de stitching par script, et un tutoriel SaludPCB du 11 août 2026 va dans le même sens ; l’autoroutage, qui passe par Freerouting plutôt que par un moteur natif — un guide de rottenwifi.com du 13 août 2026 explique justement comment combiner Walk Around, Shove et Freerouting ; et l’ergonomie du tuning fin, où l’accord manuel reste souvent plus rapide que l’accord automatique sur les bus complexes.

Le coût de ces limites n’est pas financier — KiCad reste gratuit — mais temporel : sur une carte haute densité, le temps passé à reprendre à la main un tuning automatique ou à contourner une limite du shove de vias s’ajoute au temps de routage. C’est le prix de la liberté.

Configurer, router, vérifier : la méthode en trois passes pour tirer parti du moteur

La meilleure façon de ne pas subir le routeur de KiCad 10 est de l’aborder en trois passes.

Passe 1 — Préparer. Avant de router la moindre piste : définir les classes de nets, les clearances par classe, les paires différentielles avec leur gap et leur largeur, les règles graphiques pour les zones sensibles, et les règles scriptables pour les contraintes complexes. Vérifier que le DRC passe sur la carte non routée. C’est fastidieux, mais c’est ce qui détermine si le push-and-shove sera un allié ou un adversaire.

Passe 2 — Router. Commencer par les nets critiques en mode walkaround ou highlight collisions, pour garder le contrôle. Basculer en push-and-shove pour les nets secondaires, zone par zone, en surveillant le hug. Router les paires différentielles en mode contrôlé, puis tuner en dernier. Verrouiller les paires accordées avant de repasser en shove sur les nets voisins.

Passe 3 — Vérifier. Lancer le DRC complet, vérifier les longueurs et les skews, contrôler les variantes. C’est la passe que l’on saute trop souvent — et c’est celle qui révèle les interactions entre règles graphiques, règles scriptables et routeur.

Ce que la suite pourrait changer : la branche 10.0.x continue d’évoluer (10.0.7 en RC2 au 3 octobre 2026), et l’écosystème de plugins autour de KiCad 10 s’étoffe — un plugin natif en Rust, Konnect, propose même de connecter Claude au routage via MCP (DevTrends, 7 septembre 2026), et des outils comme AIVON explorent la cotation instantanée depuis KiCad. L’avenir du routeur passera probablement moins par une refonte du moteur que par une meilleure intégration avec ces assistants et avec les règles. En attendant, la règle est simple : le routeur de KiCad 10 est puissant, mais il ne pense pas à votre place. Configurez-le, guidez-le, vérifiez-le — et il vous le rendra.

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.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *