Kicad Master · 31 August 2026

KiCad 10.0.6 : la stabilisation se poursuit, mais les zones d’ombre persistent

Le 20 mars 2026, KiCad 10.0.0 marquait un tournant : nouveau moteur de rendu 3D, refonte de l’éditeur de schéma, importateurs commerciaux. Mais depuis, l’équipe a enchaîné six correctifs en cinq mois, et les forums bruissent de rapports de bugs et de régressions. Alors, cette version majeure est-elle enfin mûre pour la production, ou faut-il encore patienter ? Plongée dans les coulisses d’une stabilisation sous haute tension.

Six mois de correctifs : la course-poursuite de KiCad 10

Quand KiCad 10.0.0 est sorti le 20 mars 2026, la communauté a retenu son souffle. Une version majeure, c’est toujours un pari : nouvelles fonctionnalités, refontes profondes, et inévitablement, une période de rodage. Mais personne n’avait anticipé un rythme de correctifs aussi soutenu. En à peine cinq mois, pas moins de six versions de correction se sont succédé : 10.0.1, 10.0.2, 10.0.3, 10.0.4, 10.0.5, et enfin 10.0.6, publiée en août 2026. Un rythme d’environ une mise à jour toutes les trois semaines, qui témoigne à la fois de la réactivité de l’équipe de développement et de la pression exercée par les bugs découverts en conditions réelles.

Ce calendrier serré n’est pas anodin. Il révèle une stratégie de stabilisation agressive, presque industrielle. L’équipe KiCad a clairement choisi de multiplier les petites itérations plutôt que d’attendre un correctif « parfait » qui n’arriverait jamais. Chaque version corrige un lot de problèmes critiques, souvent signalés par les utilisateurs sur le forum officiel. Le 22 juillet, l’annonce de la 10.0.5 évoquait explicitement des « correctifs de bugs critiques » — un terme fort, qui en disait long sur l’état de la version à ce moment-là. La 10.0.6, annoncée en août, suit la même logique : « This release contains several critical bug fixes so please consider upgrading as soon as possible », prévient l’équipe dans son annonce officielle.

Ce rythme effréné a un coût : celui de la perception. Pour un concepteur PCB qui hésite à migrer depuis la 9.x, voir six correctifs s’empiler en cinq mois peut être interprété de deux manières. Soit comme un signe d’immaturité — « ils n’arrivent pas à stabiliser » —, soit comme une preuve de dynamisme — « ils corrigent vite et bien ». La réalité est plus nuancée, et c’est ce que nous allons disséquer.

Du 10.0.0 au 10.0.6 : ce qui a été réparé en priorité

Le premier correctif, 10.0.1, est arrivé environ un mois après la sortie initiale. Il a principalement adressé des problèmes de stabilité générale, mais c’est surtout le 10.0.2 qui a marqué les esprits : il corrigeait un crash du Zone Manager, l’outil de gestion des zones de cuivre, qui affectait la 10.0.1. Pour les utilisateurs qui travaillent sur des PCB avec des plans de masse ou des zones de cuivre complexes, ce crash était un vrai blocage — impossible de terminer un layout sans passer par des contournements hasardeux. Sa correction en 10.0.2 a été saluée comme une priorité bien placée.

Les versions suivantes ont poursuivi ce travail de colmatage. La 10.0.3, sortie en juin, a apporté son lot de correctifs, notamment sur des problèmes d’export et de gestion de projets Git, comme le rapporte un article CSDN chinois qui évoque des « crashs, lenteurs, anomalies Git et erreurs d’export ». La 10.0.4, publiée le 21 juin, a continué sur cette lancée, avec des corrections de bugs et des améliorations mineures. La 10.0.5, annoncée le 22 juillet, est décrite comme contenant des « correctifs de bugs critiques » — sans plus de détails dans l’annonce officielle, mais avec une recommandation pressante de mise à jour.

La 10.0.6, publiée en août 2026, poursuit ce travail avec une liste de correctifs plus détaillée. Au menu : un correctif pour le « compact rule check handle vector during model rebuild to recover unused memory », une correction du « grid readout in status bar for footprint wizard and viewers », et un correctif pour « enforce per instance group transfer for shared sheets when update between schematic and board ». On note aussi la résolution d’un problème où un nouveau projet de bibliothèque ne s’affichait pas sans redémarrage, et un correctif pour « reduce studder when refreshing canvas » — un problème de fluidité d’affichage qui pouvait gêner le travail quotidien. Plusieurs correctifs concernent l’import Eagle, notamment l’échappement des tildes interprétés comme du markup, et le tracé des formes hachurées sans motif de remplissage.

Au-delà des correctifs, les notes de version mentionnent des améliorations de performance, notamment dans le traitement des bases de données de composants. Mais c’est précisément là que le bât blesse : un fil du forum officiel daté du 13 août 2026 signale une « lenteur extrême du traitement de base de données (httplib/dblib) » dans la 10.0.5. Autrement dit, la version précédente, censée être stable, souffrait encore de problèmes de performance dans un domaine pourtant critique pour les bibliothèques de composants. Une ironie qui n’a pas échappé aux utilisateurs, et que la 10.0.6 ne semble pas avoir entièrement résolue, même si le correctif sur la gestion mémoire du rule check est un pas dans la bonne direction.

Nouveau moteur 3D, éditeur de schéma, routeur : la stabilité en question

Quatre fonctionnalités phares étaient annoncées pour KiCad 10 : le nouveau moteur de rendu 3D, la refonte de l’éditeur de schéma, les améliorations du routeur interactif, et la gestion des zones de cuivre. Six mois après la sortie, où en est leur stabilité réelle en usage quotidien ?

Commençons par le moteur 3D. C’était l’une des vitrines de la version, avec la promesse d’un rendu plus réaliste et plus performant. Les retours des utilisateurs sont mitigés. Si certains saluent l’amélioration visuelle, d’autres signalent des problèmes de performance sur des cartes complexes, avec des temps de calcul élevés et une consommation mémoire importante. Le fil du forum « High Memory Usage in KiCad – 10.0.0-rc2 » (9 août 2026) témoigne de ces préoccupations, même si le problème a pu être atténué depuis. La 10.0.6 inclut d’ailleurs un correctif visant à « compact rule check handle vector during model rebuild to recover unused memory », ce qui suggère que les problèmes de mémoire restent une préoccupation.

La refonte de l’éditeur de schéma, elle, a introduit des changements d’interface et de workflow qui ont dérouté certains utilisateurs habitués à la 9.x. Des demandes de changements d’interface ont été remontées sur le forum, et certaines fonctionnalités, comme les « local power labels » (étiquettes d’alimentation locales), ont été ajoutées mais restent mal comprises, comme en témoigne un fil du 3 août 2026 où un utilisateur demande comment les utiliser. Ce n’est pas un bug à proprement parler, mais une courbe d’apprentissage qui peut freiner la migration.

Le routeur interactif, lui, n’a pas fait l’objet de plaintes majeures dans les sources disponibles. Les améliorations annoncées semblent tenir la route, même si aucun retour détaillé ne permet de confirmer une stabilité parfaite. En revanche, la gestion des zones de cuivre a clairement été le point noir de cette version : le crash du Zone Manager en 10.0.1, corrigé en 10.0.2, a laissé des traces. Et un fil du 22 juillet 2026, intitulé « OSH Park / KiCad snafu », rapporte un problème inquiétant : sur une carte simple deux couches réalisée avec la 10.0.3, les pistes de signal se sont retrouvées « fusionnées avec les plans de puissance et de masse » après fabrication. Un problème potentiellement lié aux zones de cuivre, qui soulève des questions sur la robustesse de cette fonctionnalité en conditions réelles.

Les ombres au tableau : lenteurs, mémoire, scripts Python

Au-delà des fonctionnalités phares, ce sont les problèmes transversaux qui inquiètent le plus les utilisateurs. Le forum officiel est une mine de rapports, et certains sont préoccupants.

Le plus récent, daté du 13 août 2026, concerne la 10.0.5 elle-même : un utilisateur rapporte une « lenteur extrême du traitement de base de données (httplib/dblib) ». Concrètement, cela signifie que l’ouverture d’une bibliothèque de composants ou la recherche d’un symbole peut prendre un temps déraisonnable, ce qui rend le travail quotidien pénible. Ce fil est d’autant plus inquiétant qu’il touche une version récente, censée être stable. La 10.0.6, sortie quelques jours plus tard, n’apporte pas de correctif explicite sur ce point dans son changelog, même si le correctif sur la mémoire du rule check pourrait indirectement aider.

L’utilisation mémoire élevée est un autre sujet récurrent. Le fil « High Memory Usage in KiCad – 10.0.0-rc2 » (9 août 2026) suggère que le problème existait déjà à l’étape de release candidate, et qu’il persiste peut-être encore. Pour les utilisateurs qui travaillent sur des cartes denses ou avec de nombreux composants, une consommation mémoire excessive peut entraîner des ralentissements, voire des crashs. La 10.0.6 tente d’y remédier avec le correctif mentionné plus haut, mais il est trop tôt pour savoir s’il est efficace.

Côté import, les choses se compliquent. Un fil du 13 août 2026, « Import from Altium project files », signale des échecs d’importation de projets Altium. C’est un point critique pour les utilisateurs qui migrent depuis un outil commercial : si l’import ne fonctionne pas correctement, la migration devient un chemin de croix. Le nouvel importateur Allegro, annoncé pour les fichiers .brd versions 16 à 23, ne couvre d’ailleurs que le layout, pas les schémas — une limitation documentée qui oblige à passer par des formats intermédiaires comme EDIF.

Enfin, l’API Python a subi des changements cassants. Le fil « Python changes in KiCad 10? (script failing to import from kicad-python) » (11 août 2026) rapporte qu’un script existant ne parvient plus à importer depuis le module kicad-python. Pour les utilisateurs qui ont automatisé des tâches de vérification ou de génération de BOM via des scripts, c’est un obstacle sérieux à la migration. Et ce n’est pas un cas isolé : les changements d’API entre versions majeures sont un classique, mais ils sont rarement aussi mal documentés. Un article d’Electronics Design (24 juillet 2026) montre pourtant que l’API Python pcbnew est de plus en plus utilisée pour l’automatisation CI, avec des scripts DRC/ERC personnalisés et la génération de BOM — un signe que la communauté investit massivement dans cette direction, ce qui rend les changements cassants d’autant plus douloureux.

La communauté entre enthousiasme et prudence

Face à ces rapports, comment la communauté réagit-elle ? Les discussions sur le forum officiel, EEVblog et Reddit dessinent un tableau contrasté.

D’un côté, l’enthousiasme reste palpable. Les nouvelles fonctionnalités — importateurs Allegro, PADS et gEDA, bibliothèques étendues — sont saluées comme des avancées majeures. Le fil EEVblog « KiCad V10.0.0 released » (ouvert en mars 2026) a recueilli de nombreux messages positifs, avec des utilisateurs impressionnés par la rapidité de développement et la qualité des nouvelles fonctionnalités. Les statistiques officielles impressionnent : 7 609 commits uniques, 2 105 merge requests, et un temps de revue moyen réduit de 3 jours à 18 heures. L’équipe KiCad n’a jamais été aussi productive.

De l’autre côté, la prudence domine dans les fils de discussion plus récents. Les titres des fils du forum officiel en août 2026 sont éloquents : « extreme slow database handling », « High Memory Usage », « Python changes », « Import from Altium project files ». Autant de signaux d’une communauté qui teste, qui remonte les problèmes, mais qui commence à s’interroger sur la maturité réelle de la version. Un utilisateur résume bien le sentiment général dans un fil sur les changements d’API Python : « Je veux bien migrer, mais pas pour casser mes scripts. »

Le thème dominant est donc celui de la compatibilité : compatibilité avec les scripts existants, avec les plugins tiers, avec les projets hérités. Les utilisateurs qui ont investi des heures dans des automatisations Python ou des bibliothèques personnalisées hésitent à franchir le pas. Et les problèmes signalés ne font que renforcer cette hésitation.

L’écosystème s’étoffe : plugins IA, autorouteurs GPU et bibliothèque CERN

Pendant que l’équipe stabilise le noyau, l’écosystème KiCad continue de s’étendre à un rythme impressionnant. C’est peut-être là le signe le plus tangible de la maturité de la plateforme.

Côté routage automatique, les outils se multiplient. Le 2 juillet 2026, Hackaday rapportait qu’un autorouteur GPU-accéléré, PCB Auto Router, avait réussi à router un backplane de 17 600 pads, 16 connecteurs de 1 100 broches et 8 192 airwires — un design qui aurait pris des mois à la main et qui stoppait net les routeurs traditionnels. L’outil supporte l’import KiCad et JLC EDA, et promet un routage en un clic, y compris pour les paires différentielles et les longueurs appariées. Un article de RottenWifi (13 août 2026) détaille par ailleurs les options d’autoroutage natives de KiCad 10 : Walk Around, Shove, et l’intégration de Freerouting, avec des conseils de configuration des règles et de validation DRC.

Côté IA, le 31 juillet 2026, Protoflow.ai publiait un panorama des outils d’IA réellement utilisables avec KiCad en 2026 : plugins in-éditeur, outils de génération de schémas « generate-then-export », et génération de composants IA. Le 16 juillet, Seeed Studio a publié un serveur MCP (Model Context Protocol) qui permet à des assistants IA d’analyser des schémas, d’inspecter des PCB, de tracer des connexions, de valider des designs et de générer du code embarqué pour les projets KiCad. Une enquête de Weidmuller (24 juillet 2026) confirme que l’IA est désormais perçue comme un élément normalisé du workflow d’ingénierie, même si des écarts subsistent entre les attentes et la réalité.

Enfin, le 12 mai 2026, le CERN a ouvert l’intégralité de sa bibliothèque interne de composants pour KiCad : plus de 17 000 symboles et empreintes, validés par des décennies d’expérience en physique des particules, sous licence CERN-OHL. Un trésor pour les concepteurs, qui s’accompagne d’une promesse d’intégration native dans les futures versions de KiCad.

La distribution chinoise Huaqiu : une fragmentation à surveiller

Un autre sujet émerge dans le paysage KiCad 10 : la distribution chinoise Huaqiu (华秋). Le 23 juin 2026, le site kicad.eda.cn annonçait la sortie de « KiCad 华秋发行版 10.0.2 », une version dédiée au marché chinois. Mais que sait-on réellement de cette distribution ?

Les sources disponibles sont extrêmement limitées. Le lien vers kicad.eda.cn confirme son existence et son alignement sur les versions officielles (10.0.2 en juin 2026), mais aucun détail n’est fourni sur sa nature exacte. S’agit-il d’un fork, d’un simple repackaging avec des bibliothèques locales, ou d’une version enrichie de composants propriétaires ? La question reste ouverte, et c’est précisément ce flou qui inquiète.

Pour un utilisateur international, les risques potentiels sont multiples. D’abord, la compatibilité des fichiers : si la distribution Huaqiu modifie le format des projets ou ajoute des extensions propriétaires, les fichiers créés avec cette version pourraient ne pas être lisibles par la version officielle. Ensuite, la télémétrie : certaines distributions régionales intègrent des mécanismes de collecte de données, ce qui peut poser des problèmes de confidentialité. Enfin, la licence : si la distribution inclut des bibliothèques propriétaires, leur utilisation peut être soumise à des conditions différentes de la licence open source de KiCad.

Mais il faut être honnête : à ce jour, aucune de ces craintes n’est confirmée. Il s’agit de risques hypothétiques, basés sur des précédents observés dans d’autres logiciels. La distribution Huaqiu pourrait très bien être un simple repackaging parfaitement compatible, avec des bibliothèques de composants chinois ajoutées par-dessus. Le fait qu’elle suive le rythme des versions officielles (10.0.2 en juin) est plutôt rassurant.

Verdict : faut-il migrer vers KiCad 10 ?

Six mois après la sortie de la 10.0.0, et avec six correctifs au compteur, la question reste entière : KiCad 10 est-il prêt pour la production ?

La réponse est nuancée. D’un côté, l’équipe a démontré une réactivité exemplaire. Chaque correctif a adressé des problèmes réels, souvent critiques, et la 10.0.6 continue sur cette lancée avec des correctifs ciblés sur la mémoire, l’affichage et l’import. Les fonctionnalités phares — moteur 3D, éditeur de schéma, routeur — sont globalement stables pour un usage standard. L’écosystème, lui, n’a jamais été aussi dynamique : plugins IA, autorouteurs GPU, bibliothèque CERN, serveurs MCP.

De l’autre côté, les problèmes transversaux persistent. La lenteur du traitement des bases de données, signalée dans la 10.0.5, n’a pas de correctif explicite dans la 10.0.6. Les changements cassants de l’API Python continuent de freiner les utilisateurs qui ont automatisé leurs workflows. Et le problème OSH Park, même s’il reste non confirmé, jette un doute sur la robustesse des zones de cuivre en conditions réelles.

Notre recommandation : pour les projets de production critiques, restez sur la 9.x encore quelques mois, le temps que l’équipe stabilise les derniers points chauds. Pour les projets de développement, les prototypes, ou si vous voulez profiter des nouvelles fonctionnalités (variantes de conception, mode sombre, importateurs commerciaux), la 10.0.6 est utilisable — à condition de tester vos scripts Python et vos bibliothèques avant de vous engager. Et surveillez de près les prochains correctifs : l’équipe a prouvé qu’elle savait corriger vite, il ne lui reste plus qu’à corriger juste.

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.

KiCad 10.0.x : six mois de correctifs, où en est vraiment la maturité de la version majeure ?