Electrosens R&D

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

Electrosens Kicad Master · 22 October 2026

KiCad 10.0.x : six correctifs, deux release candidates et une maturité qui se gagne sur le terrain

Le 20 mars 2026, KiCad 10.0.0 marquait un tournant : nouveau moteur de rendu 3D, refonte de l’éditeur de schéma, variantes de conception, importateurs commerciaux. Six mois plus tard, la branche 10.0.x a enchaîné six correctifs — jusqu’à la 10.0.6 du 29 août — et la 10.0.7 se fait attendre : deux release candidates plus tard (27 septembre, 3 octobre), elle n’est toujours pas publiée. 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 correctifs en cinq mois : 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 le 29 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, 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 le 29 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. Entre les deux, un release candidate (RC1) avait été mis à disposition le 18 août pour permettre à la communauté de tester avant la publication finale.

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. Mais c’est surtout le contenu de la 10.0.6 qui éclaire la nature des problèmes traités. Le changelog officiel — dont la liste complète des correctifs est consignée sur la milestone GitLab 10.0.6 — dessine un profil assez clair : peu de refontes, beaucoup de corrections ciblées, et un spectre qui va du moteur de rendu à la gestion de projet.

Correctifs KiCad 10.0.x (mars–août 2026)10.0.0 (20 mars)1versions10.0.11versions10.0.21versions10.0.31versions10.0.41versions10.0.5 (22 juillet)1versions10.0.6 (29 août)1versions

Côté performances et mémoire, on note un correctif sur le « compact rule check handle vector during model rebuild to recover unused memory » — autrement dit, la gestion mémoire du moteur de vérification des règles, un point sensible sur les gros projets. La 10.0.6 corrige aussi un « studder » (saccade) lors du rafraîchissement du canevas, et un problème de grille dans la barre d’état pour l’assistant d’empreintes et les visionneuses.

Côté gestion de projet et de bibliothèques, plusieurs correctifs concernent la synchronisation schéma ↔ PCB : « enforce per instance group transfer for shared sheets when update between schematic and board » (les feuilles partagées entre instances), l’affichage d’une nouvelle bibliothèque de projet sans redémarrer KiCad, ou encore la possibilité d’ajouter des éléments à un sous-groupe. Autant de détails qui, mis bout à bout, expliquent pourquoi les équipes qui travaillent en hiérarchie et en bibliothèques partagées ont été les plus exposées aux régressions.

Côté rendu et import, on relève la correction des styles de ligne sur les courbes de Bézier, du remplissage des formes hachurées à l’export, et — détail révélateur de la maturité des importateurs — un correctif sur l’échappement des tildes lors de l’import de fichiers Eagle (« only escape tildes when they could be interpreted as markup »). La 10.0.6 corrige également les infobulles du panneau de propriétés qui répétaient le nom du champ, et un garde-fou de réentrance mort dans la vérification des mises à jour.

Ce que ce changelog dit en creux : la 10.0.6 n’est pas une version qui ajoute des fonctionnalités, c’est une version qui rabote. Et c’est exactement ce qu’on attend d’une branche stable.

10.0.7 : deux release candidates, toujours pas de version finale

C’est peut-être le fait le plus important de cet automne, et il contredit la lecture naïve d’un cycle qui s’achèverait proprement. La 10.0.6 n’est pas le point final de la branche. Depuis fin septembre, l’équipe prépare la 10.0.7 — et le processus traîne.

Le 27 septembre 2026, un premier release candidate (RC1) de la 10.0.7 était mis à disposition pour tests, avec la formule rituelle : « Version 10.0.7 will be released soon unless critical issues are found in testing this release candidate. » Puis, le 3 octobre 2026, un second release candidate (RC2) était publié, avec exactement la même mise en garde. À la date où nous écrivons ces lignes, la 10.0.7 n’est donc toujours pas sortie en version stable.

Deux RC pour un simple correctif, c’est un signal. Cela signifie que le premier candidat a révélé des problèmes suffisamment sérieux pour justifier une seconde passe — ou que l’équipe a choisi la prudence plutôt que la vitesse. Dans les deux cas, la leçon pour l’utilisateur est simple : la branche 10.0.x n’a pas fini de bouger, et ceux qui ont migré doivent surveiller les annonces. La bonne nouvelle, c’est que le processus est transparent : chaque RC est public, testable, et l’équipe indique explicitement que des changements supplémentaires peuvent être ajoutés avant la finale.

Le vrai point noir : les performances de l’éditeur PCB

Si l’on veut comprendre pourquoi certains utilisateurs grincent des dents, il faut quitter les changelogs et aller sur le forum officiel. Un fil du 12 août 2026 est particulièrement éclairant : un utilisateur y rapporte que, dans les versions 10.0.4 et 10.0.5, le déplacement d’une piste déjà routée dans l’éditeur PCB est « extrêmement lent », au point que « 10.0.5 becomes unusable ». Le geste en question — attraper un segment de piste existant pour le déplacer — est l’un des plus fréquents du routage manuel. Quand il devient poussif, c’est tout le workflow qui s’effondre.

Source : electwork.net

Ce témoignage recoupe une réalité plus large : la refonte du moteur de rendu et du routeur interactif de la 10 a apporté des gains considérables sur les projets complexes, mais elle a aussi introduit des régressions de performance sur certains cas d’usage. C’est le prix classique d’une réécriture. Et c’est précisément le genre de problème que les correctifs successifs doivent résorber — d’où l’insistance de l’équipe sur les « critical bug fixes ».

Autre point de friction documenté : l’import Altium. Un fil du 1er septembre 2026 rapporte qu’en migrant un projet Altium (version 25.6.2) vers KiCad 10.0.6, l’ERC déclenche l’avertissement « Symbol pin or wire end off connection grid » sur presque chaque broche et chaque extrémité de fil. Le problème n’est pas bloquant — c’est un avertissement, pas une erreur — mais il noie l’utilisateur sous le bruit et l’oblige à un nettoyage manuel. L’importateur fonctionne, donc ; il n’est simplement pas encore silencieux. Nuance importante pour quiconque envisage une migration : prévoyez du temps de vérification.

L’écosystème 2026 : ce qui a changé d’échelle autour de KiCad 10

La maturité d’un outil ne se mesure pas seulement à ses correctifs. Elle se mesure aussi à ce qui gravite autour. Et de ce point de vue, 2026 est une année charnière.

La bibliothèque du CERN. 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, avec une réserve de taille : la bibliothèque fournit symboles et empreintes, mais pas les modèles 3D. Un détail à garder en tête quand on assemble une BOM et qu’on prépare une visualisation mécanique.

Les variantes de conception. Avec KiCad 10, les variantes de composants changent la donne : gérer trois configurations d’une même carte ne signifie plus trois projets clonés, mais un schéma unique comme source de vérité, décliné en variantes synchronisées vers le PCB, la BOM et le pick-and-place. C’est l’une des fonctionnalités les plus structurantes de la version 10 pour les équipes de production.

Le via stitching automatisé. La couture de masse — parsemer les plans de cuivre de micro-vias de liaison — reste l’une des techniques les plus rentables pour l’intégrité électromagnétique. KiCad nu propose des méthodes manuelles chronophages ; l’écosystème de plugins, dont kicad-action-scripts, automatise désormais la génération de grilles de vias reliés à la masse. Un article dédié de scriptedpcb.com (13 septembre 2026) détaille même la génération par script d’une grille complète, et un tutoriel de SaludPCB (11 août 2026) montre le remplissage automatique des plans de masse en un clic. Le sujet est devenu un marqueur de maturité de l’écosystème.

L’IA s’installe, prudemment. Une analyse de protoflow.ai du 31 juillet 2026 recense trois manières réelles d’ajouter de l’IA à un workflow KiCad : les plugins in-editor, les outils « generate-then-export » de schémas, et la génération de composants par IA. Chacune a ses limites, et l’article est honnête sur ce qu’elles ne savent pas faire. Plus spectaculaire : 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. À prendre pour ce que c’est — une expérimentation prometteuse, pas encore un outil de production.

Le routage automatique. Un guide de rottenwifi.com (13 août 2026) rappelle la bonne pratique : configurer les règles, placer les composants, utiliser Walk Around et Shove, intégrer Freerouting, puis valider chaque carte par DRC et contrôles de fabrication. La validation reste le maillon indispensable — d’autant que Freerouting 2.3.0 a connu une régression documentée (28 août 2026) : des routes signalées comme portant des violations de clearance sur des cartes que la 2.2.4 routait proprement. Un rappel que l’automatisation ne dispense jamais de vérification.

Le rendez-vous de Shenzhen. La quatrième conférence asiatique KiCad (KiCon Asia) se tiendra du 5 au 7 novembre 2026 à l’hôtel Huaqiang Plaza de Shenzhen. Un signe de plus que la communauté KiCad a changé d’échelle — et l’occasion d’entendre directement les développeurs sur l’état de la branche 10.0.x.

Faut-il migrer maintenant ? La réponse honnête

Reprenons la question de départ. KiCad 10.0.0 était-il prêt pour la production en mars 2026 ? Assurément non — aucune version majeure ne l’est. La 10.0.6 l’est-elle ? Beaucoup plus, oui, mais avec des réserves documentées : les performances de déplacement de pistes ont posé problème jusqu’à la 10.0.5 au moins, et la 10.0.7 n’est pas encore sortie malgré deux release candidates.

Source : forum.kicad.info

Notre recommandation, en cet automne 2026, tient en trois points.

Premier point : attendez la 10.0.7 si vous êtes en production. Deux RC successifs indiquent que l’équipe elle-même considère la branche comme encore en rodage. La 10.0.7 sera la version à adopter pour un nouveau projet sérieux — et elle ne devrait plus tarder, sauf découverte d’un problème critique en test.

Deuxième point : testez avant de migrer. Les régressions de performance et les avertissements d’import (Altium, Eagle) sont réels. Migrez un projet représentatif, pas votre projet phare, et passez-le au DRC complet avant de vous engager.

Troisième point : profitez de l’écosystème. Bibliothèque CERN, variantes de conception, plugins de stitching, assistants IA expérimentaux : la valeur de KiCad 10 ne réside pas seulement dans son noyau, mais dans ce qui l’entoure. C’est là que le changement d’échelle est le plus visible.

La vérité, c’est que KiCad 10 n’est ni le désastre annoncé par les uns, ni la perfection rêvée par les autres. C’est une version majeure en cours de stabilisation, avec une équipe réactive, un processus transparent et des utilisateurs exigeants. Le meilleur indicateur de sa maturité ? Le fait qu’on en discute — et que l’équipe, elle, continue de corriger.

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 *