Electrosens R&D
Electrosens Kicad Master · 10 November 2026

KiCad 10.0.7 : huit mois après la 10.0.0, ce qui tient vraiment dans l’atelier PCB

La 10.0.0 est arrivée le 20 mars 2026 avec sa cohorte de promesses — high-speed tuning, variantes de carte, Graphical DRC, importateurs revus. Sept correctifs plus tard, une 10.0.7 publiée le 7 octobre 2026 et une KiCon Asie annoncée à Shenzhen, le recul est enfin suffisant pour trier ce qui a tenu dans l’atelier de ce qui est resté sur la plaquette marketing. Décryptage praticien, sans complaisance.


10.0.0, mars 2026 : ce que le blog officiel annonce (et ce qu’il tait)

Commençons par poser le cadre factuel, car il conditionne tout le reste. KiCad 10.0.0 a été annoncé comme publié dans un billet de blog daté de mars 2026 sur kicad.org, à l’adresse /blog/2026/03/Version-10.0.0-Released/. La date précise qui revient dans nos sources est le 20 mars 2026. C’est la source officielle, et — il faut le dire d’emblée — c’est à peu près la seule dont nous disposons pour les chiffres bruts de cette mouture. Aucune source tierce indépendante ne vient corroborer les données que le projet avance lui-même. C’est une limite méthodologique qu’il vaut mieux assumer que masquer : dans cet article, chaque fois qu’un chiffre provient d’une auto-déclaration, nous le signalerons.

Que dit ce billet ? Le projet met en avant 7 609 commits uniques (code et traductions confondus), présentés comme « une augmentation notable par rapport à la version 9 ». Notons que le chiffre de comparaison pour la V9 n’est pas fourni dans la matière collectée : l’affirmation « augmentation notable » reste donc, en l’état, non vérifiable. Côté bibliothèques, la V10 embarque 952 nouveaux symboles, 1 216 nouveaux footprints et 386 nouveaux modèles 3D. Là encore : auto-déclaré, non recoupé.

Le changement le plus structurant annoncé n’est d’ailleurs pas une fonctionnalité, mais une politique : à partir de KiCad 10, seuls les fichiers STEP sont livrés pour les modèles 3D, les autres formats étant abandonnés par défaut. Le blog officiel le confirme explicitement : « starting with KiCad version 10 we are shipping STEP files only — this dramatically reduces the install size of the 3D models and gives better geometric accuracy and fewer differences between visualization and export ». Objectif affiché : réduire la taille d’installation et gagner en précision géométrique. C’est une décision qui a des conséquences concrètes pour les ateliers mécaniques et les chaînes de validation 3D — nous y reviendrons dans la section migration.

Enfin, une statistique discrète mais lourde de sens : plus de 78 % des footprints de la bibliothèque sont désormais générés à partir de données plutôt que dessinés manuellement. Derrière ce pourcentage se cache un basculement culturel du projet vers la génération automatisée — un mouvement qui, à terme, change la manière dont les bibliothèques évoluent et dont les contributeurs y travaillent.

Ce qu’il faut retenir de ce cadrage : nous avons une date de sortie (20 mars 2026), une poignée de chiffres auto-déclarés, et aucun jalon de cycle documenté — ni date de feature freeze, ni numéro de RC1 pour la 10.0.0, ni débat communautaire tracé dans la matière collectée. Le blog renvoie bien vers un fil du forum KiCad et vers la page de jalons GitLab, mais leur contenu n’est pas résumé dans nos extraits. La méthode de cet article sera donc constante : confronter les annonces officielles aux retours de terrain disponibles, et dire clairement quand une zone reste dans l’ombre.


High-speed tuning : la promesse d’un routeur qui parle enfin aux contraintes

C’est la fonctionnalité qui a fait couler le plus d’encre dans les annonces. Le « high-speed tuning » recouvre, dans l’intention affichée, un ensemble cohérent : routage différentiel, accord de longueur, tuning de vias, contraintes d’impédance, et intégration avec le gestionnaire de stackup. Autrement dit, tout ce que réclame une carte rapide — DDR, USB, PCIe, SerDes — là où KiCad a longtemps été perçu comme un outil de prototypage sérieux mais pas un outil de signal integrity.

KiCad 10.0.0 — chiffres auto-déclarés et contexte marchéCommits uniques (V10)7609valeurNouveaux symboles952valeurNouveaux footprints1216valeurNouveaux modèles 3D386valeurFootprints générés (%)78valeurAltium, coût/utilisate3850valeurAltium, coût/utilisate5000valeur

Soyons honnêtes sur la matière. La collecte documentaire ne fournit aucune donnée technique chiffrée sur cette fonctionnalité : ni benchmark de routage différentiel, ni mesure d’accord de longueur, ni test de tuning de vias, ni comparaison d’impédance ou de stackup manager dans KiCad 10. Aucun cas d’usage (DDR, USB, PCIe, SerDes) n’est documenté avec des chiffres dans les extraits, et aucune comparaison quantifiée avec Altium ou Cadence n’apparaît. L’analyse qui suit repose donc sur les annonces officielles et sur ce que l’on peut raisonnablement inférer des usages — pas sur des benchmarks que nous n’avons pas.

Ce que l’on peut dire avec prudence : l’ambition est claire et elle répond à un manque réel. Historiquement, le concepteur de carte rapide sous KiCad jonglait entre le routeur interactif, des scripts maison pour l’accord de longueur, et une vérification manuelle des impédances via le stackup. Si la V10 intègre réellement ces briques dans le flux natif, le gain n’est pas marginal : c’est le passage d’un travail « à la main + script » à un travail « contraint et vérifié ». Pour une carte DDR, cela peut représenter des heures de vérification en moins par interface.

Mais la prudence reste de mise sur trois points. D’abord, l’intégration avec le stackup manager conditionne tout : sans une définition d’impédance fiable et par couche, le tuning reste un exercice décoratif. Ensuite, la question des limites face à Altium ou Cadence n’est pas documentée dans notre matière — et il serait malhonnête d’inventer un verdict. Altium Designer, rappelons-le pour situer l’écart de marché, coûte entre 3 850 et 5 000 USD par utilisateur et par an en 2026, avec une formation à 1 000–2 000 € par personne ; sur trois ans et cinq postes, formation incluse, la facture dépasse 175 000 USD. C’est le contexte économique dans lequel KiCad joue — et c’est précisément pourquoi la question « le high-speed tuning est-il au niveau ? » mérite mieux qu’un chiffre inventé.

Enfin, un signal de terrain à surveiller : la lenteur extrême de déplacement de pistes déjà routées signalée sur les versions 10.0.4 et 10.0.5, au point qu’un utilisateur du forum qualifie la 10.0.5 d’« inutilisable » pour ce cas d’usage. Sur une carte rapide, où l’on ajuste sans cesse des longueurs, ce type de régression pèse lourd. À garder en tête avant de basculer une carte SerDes en production sur la branche 10.0.x — même si, comme nous le verrons, la 10.0.7 a depuis corrigé un certain nombre de choses.


Board variants : enfin des produits dérivés sans copier-coller de projet

Deuxième promesse phare : les variantes de carte. Le principe est connu de quiconque a travaillé sur des gammes : une même base matérielle, plusieurs déclinaisons (composants non montés, substitutions, options de connectique), sans dupliquer le projet. L’intention affichée couvre la gestion des DNP (Do Not Populate), les substitutions de composants, la BOM par variante, l’articulation schéma/PCB et les exports de fabrication différenciés.

Bonne nouvelle sur ce front : contrairement à ce que laissait entendre la première version de cet article, la fonctionnalité est bel et bien documentée dans nos sources. Le magazine Elektor, dans un article daté du 30 mars 2026 consacré à la sortie de KiCad 10, la cite explicitement parmi les points forts : « Du côté des schémas, la version 10 ajoute des variantes de design, des croisements de fils avec saut (hop-over), la prise en charge des cavaliers, ainsi que le regroupement et l’échange CSV dans le tableau de broches de l’éditeur de symboles. » Le même article confirme aussi, côté PCB, « des blocs de design de PCB dans l’éditeur de PCB, des objets de couche interne dans les empreintes, un échange de broches et de portes sans contrainte, et un éditeur de règles DRC graphique ». Les variantes de design sont donc une réalité de la V10, pas une rumeur.

Ce que l’on peut affirmer, c’est le workflow débloqué. Jusqu’ici, gérer une gamme sous KiCad impliquait souvent de dupliquer le projet, de maintenir des BOM parallèles et de prier pour que les corrections de fond ne désynchronisent pas les variantes. C’est un coût caché énorme : chaque dérivée devient une dette de maintenance. Un système de variantes natif transforme cette dette en configuration. Pour un fabricant qui décline une carte en trois versions (entrée de gamme, standard, étendue), l’économie n’est pas en heures de saisie — elle est en risque d’erreur.

Les cas d’usage visés sont clairs : produits dérivés d’une même plateforme, séries limitées, prototypage où l’on teste plusieurs options de peuplement sur un même PCB. C’est exactement le terrain où Altium et Cadence ont construit une partie de leur valeur perçue — la gestion de variantes étant, dans ces outils, une fonctionnalité mature et intégrée à la chaîne de données.

La réserve, une fois encore : sans retours d’expérience détaillés sur des projets réels depuis mars 2026, impossible de trancher sur la robustesse fine de l’implémentation KiCad 10, sur la façon dont les variantes se comportent à l’export Gerber/position, ou sur la gestion des substitutions. C’est un point à tester soi-même sur un projet pilote avant tout déploiement industriel.


Graphical DRC : la règle devient un dessin, et ça change tout

Toutes les nouveautés ne font pas les gros titres, et ce sont parfois les plus discrètes qui changent le quotidien. Le Graphical DRC est de celles-là — et il faut ici corriger une lacune de la première version de cet article : la matière collectée le documente désormais, et plutôt bien.

Rappelons le problème qu’il résout. 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, l’éditeur graphique de règles change la donne : la contrainte devient un dessin. Concrètement, l’utilisateur trace des zones, définit des classes de net, et voit ses contraintes s’appliquer avec un retour visuel en temps réel — la DRC qui corrige avant l’erreur, plutôt que de la signaler après coup dans un rapport texte.

Elektor confirme la présence de cet « éditeur de règles graphique » parmi les points forts de la V10, et ajoute un détail qui compte pour le travail quotidien : KiCad 10 introduit « des actions de correction suggérées pour les erreurs DRC ». Autrement dit, l’outil ne se contente pas d’afficher joliment les violations : il propose des remédiations. Pour qui a passé des soirées à faire l’aller-retour entre une liste de violations et le PCB, la promesse est concrète : moins de clics, moins de contexte perdu, un débogage plus rapide.

L’intégration avec les contraintes de classe nette est le point clé : c’est elle qui détermine si l’outil aide vraiment ou s’il se contente d’afficher des erreurs. Sur ce point, la matière reste partielle — nous n’avons pas de benchmark chiffré du gain de temps, ni de comparaison mesurée avec les systèmes de règles d’Altium (dont l’éditeur graphique est décrit comme « très avancé ») ou de Cadence. Nous ne pouvons donc pas affirmer « X % de temps gagné » — ce serait inventer.

Ce que l’on peut dire, en revanche, c’est que cette fonctionnalité s’inscrit dans une tendance de fond : rendre la vérification visuelle et contextuelle plutôt que textuelle et différée. C’est le sens de l’histoire dans tous les EDA modernes, et c’est un vrai levier de productivité sur les gros designs. Les limites attendues — faux positifs, performances sur de grandes cartes, courbe d’apprentissage — sont celles de tout système de règles graphique, mais nous ne disposons pas encore de données de terrain suffisamment quantifiées pour les chiffrer ici.


Importateurs : Allegro, PADS, gEDA en renfort, mais Altium qui frotte

Côté importateurs, le sujet est plus chaud qu’il n’y paraît, et c’est là que la V10 a le plus bougé par rapport à ce que nous écrivions il y a quelques mois.

D’abord, la bonne nouvelle : Elektor rapporte que KiCad 10 « ajoute des importateurs pour Allegro, PADS et gEDA/Lepton PCB, ce qui est particulièrement utile si vous transférez des circuits plus anciens ou des projets mixtes vers un flux de travail plus cohérent ». C’est une extension nette du périmètre d’import — au-delà du duo historique Altium/Eagle, KiCad va désormais chercher les concepteurs sur les outils Cadence (Allegro), Mentor/Siemens (PADS) et l’écosystème open source gEDA. Pour un atelier qui hérite de projets anciens, c’est un vrai levier.

Ensuite, la mauvaise : la migration depuis Altium reste un point sensible. Un fil du forum KiCad daté du 1er septembre 2026 rapporte, lors d’un import Altium 25.6.2 vers KiCad 10.0.6, un avertissement ERC « Symbol pin or wire end off connection grid » sur presque chaque broche et chaque extrémité de fil — un problème de grille de connexion qui peut transformer un import en séance de nettoyage. À noter aussi, dans les faits canoniques : l’importateur natif Altium n’est pas présent dans KiCad 10.0.0. Autrement dit, l’import existe mais avec des frictions documentées, et il faut vérifier au cas par cas la version d’Altium source.

Pour un atelier qui migre un parc de projets Altium, c’est un point de vigilance majeur — et un argument pour tester l’import tôt, sur un projet représentatif, avant de s’engager. La bonne nouvelle, c’est que la correction de ce type de bug est précisément ce que visent les correctifs 10.0.x : la 10.0.7 du 7 octobre 2026 est explicitement une « bug fix release » contenant « critical bug fixes and other minor improvements since the previous release ». Reste à vérifier, projet en main, si le problème de grille Altium a été résorbé.


Le coût réel de la migration depuis KiCad 9 : bibliothèques, projets, scripts

C’est la question que tout le monde se pose en pratique : combien ça coûte de passer de KiCad 9 à KiCad 10 ? Distinguons les migrations triviales des douloureuses.

Triviales : l’ouverture de projets KiCad 9 dans la V10, en général, se fait sans drame — c’est la promesse implicite de compatibilité amont. Un concepteur isolé avec ses propres bibliothèques et un flux simple peut basculer en une soirée.

Douloureuses : trois fronts se dessinent.

  1. Les modèles 3D. Le passage au STEP uniquement est le changement de politique le plus concret, et il est confirmé noir sur blanc par le blog officiel. Si votre chaîne mécanique consommait d’autres formats, il faut la revoir. Le gain (installation plus légère, meilleure précision géométrique, moins d’écarts entre visualisation et export) se paie par une adaptation des outils en aval. Pour un atelier mécanique, c’est un projet en soi.
  2. Les scripts Python et plugins. Toute rupture d’API se paie en heures de portage. Nous n’avons pas, dans la matière, de liste exhaustive des ruptures d’API de la V10 — c’est une zone d’incertitude à assumer. Mais l’écosystème bouge : un plugin natif Konnect, écrit en Rust (binaire unique), est apparu pour connecter Claude à KiCad 10 via MCP, avec 228 outils (article DevTrends du 7 septembre 2026, repris par Fellow le 14 octobre 2026 et par Adafruit le 26 octobre 2026). Des outils comme les générateurs de grille de vias de stitching continuent de prospérer (scriptedpcb.com, 13 septembre 2026). Signe que l’écosystème n’attend pas les correctifs pour innover — mais aussi que la surface d’API à maintenir s’élargit.
  3. Les bibliothèques. La refonte des bibliothèques (78 % de footprints générés, STEP only) est un chantier de fond. Un projet qui pointait vers des modèles 3D non-STEP devra soit migrer, soit accepter une dégradation de la visualisation. À tester tôt.

Un point de méthode pour la migration : automatiser l’initialisation de projet. Un script bash public (TechOverflow, 22 avril 2026) permet de créer en ligne de commande l’arborescence complète d’un projet KiCad 10 — MyProject.kicad_pro, .kicad_sch, .kicad_pcb, sym-lib-table, fp-lib-table, dossiers libraries/footprints et libraries/3D — modélisée d’après la 10.0.1. Utile pour industrialiser un parc de projets ou scripter des tests de migration.


10.0.1 → 10.0.7 : la chronologie des patchs, lue comme une priorisation

Le vrai bilan d’une version ne se lit pas dans son annonce, mais dans ses correctifs. Voici la chronologie documentée de la branche 10.0.x, du plus ancien au plus récent :

  • 10.0.0 — 20 mars 2026 (annonce officielle).
  • 10.0.1 — citée comme base du script d’initialisation de projet (avril 2026).
  • 10.0.2 — 11 mai 2026, également publiée par le fork chinois Huaqiu (kicad.eda.cn).
  • 10.0.4 / 10.0.5 — versions sur lesquelles la lenteur de déplacement de pistes routées est signalée sur le forum (10.0.5 qualifiée d’« inutilisable » pour ce cas d’usage).
  • 10.0.6 — 29 août 2026, « bug fix release » officielle ; c’est la version sur laquelle l’import Altium 25.6.2 produit l’avertissement ERC de grille (signalé le 1er septembre 2026).
  • 10.0.7-rc1 — 27 septembre 2026.
  • 10.0.7-rc2 — 3 octobre 2026.
  • 10.0.7 — 7 octobre 2026, « stable version contains critical bug fixes and other minor improvements since the previous release ».

Ce que cette chronologie dit sans le dire : l’équipe KiCad a maintenu un rythme de correctifs soutenu (sept versions stables en un peu plus de six mois), avec un cycle RC systématique avant chaque stable — signe d’une discipline de release mature. Les versions 10.0.4 et 10.0.5 ont visiblement introduit des régressions (lenteur de déplacement de pistes), corrigées ou atténuées ensuite. La 10.0.7, la plus récente à ce jour, est celle à privilégier pour tout nouveau déploiement.

Côté écosystème, l’activité ne faiblit pas : la KiCad Conference Asia 2026 (quatrième édition annuelle) est annoncée du 5 au 7 novembre 2026 à l’hôtel Huaqiang Plaza de Shenzhen, en Chine. Un signe que la communauté asiatique — et les forks qui y prospèrent — pèse de plus en plus dans l’agenda du projet.


L’écosystème en ébullition : forks, IA, routeurs GPU

Un article sur KiCad 10 qui s’arrêterait aux fonctionnalités officielles passerait à côté de l’essentiel : l’écosystème qui gravite autour. Trois dynamiques méritent d’être signalées.

Les forks. Le fork chinois porté par Huaqiu Electronics a publié sa 10.0.2 le 11 mai 2026, avec des armes propres (Copilot, cloud, commande en un clic). Un second fork, Zeo, ajoute un agent IA et le multi-cartes. Ces ramifications posent une question de fond : jusqu’où le projet officiel peut-il absorber les innovations des forks, et à quel rythme ?

L’IA. Le plugin Konnect (Rust, 228 outils, MCP) branche Claude directement dans le moteur KiCad 10 et propose schémas, placements, routes. Sur le papier, la conception électronique devient une conversation. En pratique, la vérification reste le mur : la DRC, l’ERC et la traçabilité ne se délèguent pas à un LLM sans relecture humaine. L’IA aide là où elle propose, elle piège là où on la croit.

Les routeurs GPU. OrthoRoute, plugin venu de Hackaday, propulse le routage par GPU (PathFinder sous stéroïdes) et bouscule les autorouteurs traditionnels sur des cartes que ceux-ci refusent. Les benchmarks racontent cependant une histoire plus nuancée que la démo — à suivre.

Ces trois dynamiques convergent vers un même constat : KiCad 10 n’est plus seulement un logiciel, c’est une plateforme. Et c’est peut-être là son changement le plus profond depuis mars 2026.


Verdict praticien : ce qui tient, ce qui frotte, ce qu’il faut tester

Huit mois après la 10.0.0, que retenir ?

Ce qui tient : les variantes de design (documentées, Elektor 30 mars 2026), l’éditeur graphique de règles DRC avec corrections suggérées, les nouveaux importateurs Allegro/PADS/gEDA, le mode sombre Windows, la sélection au lasso, l’annulation/rétablissement dans les boîtes de dialogue, l’export PDF 3D, les codes-barres, les remplissages hachurés. Le rythme de correctifs (sept stables en six mois, jusqu’à la 10.0.7 du 7 octobre 2026) témoigne d’une maintenance sérieuse.

Ce qui frotte : l’import Altium (avertissement ERC de grille sur 10.0.6, signalé le 1er septembre 2026), la lenteur de déplacement de pistes routées sur 10.0.4/10.0.5, la migration STEP-only pour les chaînes mécaniques, et l’absence de benchmarks publics sur le high-speed tuning face à Altium.

Ce qu’il faut tester soi-même : l’import d’un projet Altium représentatif vers la 10.0.7 ; le comportement des variantes à l’export Gerber/position ; le high-speed tuning sur une carte DDR ou SerDes réelle ; la robustesse du Graphical DRC sur une grande carte.

Le contexte économique reste, lui, sans ambiguïté : face à Altium à 3 850–5 000 USD par utilisateur et par an (plus de 175 000 USD sur trois ans pour cinq postes, formation incluse), KiCad 10 n’a jamais été aussi crédible pour un atelier qui accepte de tester avant de déployer. Ce n’est plus une question de « est-ce que ça vaut le coup ? » mais de « qu’est-ce que je dois vérifier avant de basculer ? ». Et la réponse, en octobre 2026, tient en un mot : tout.


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 *