Kicad Master · 29 October 2026

KiCad 10.0.x : sept correctifs en six mois, une 10.0.7 en RC2 — anatomie d’une branche qui ne dort jamais

Sept versions de maintenance en six mois, une 10.0.7 désormais en deuxième release candidate à l’automne 2026, et un changelog qui, contre toute attente, existe bel et bien : la branche 10.0.x de KiCad raconte l’histoire d’un logiciel passé dans la cour des grands — et celle d’une communication qui s’est discrètement professionnalisée. Pour un concepteur PCB, la vraie question n’est plus « KiCad est-il mature ? » mais « quand migrer, et sur quelle version ? ».

Sept correctifs en six mois : anatomie d’une branche qui ne dort jamais

Il y a une manière très simple de mesurer la santé d’un projet open source : regarder à quelle fréquence il publie des correctifs. Sur ce critère, KiCad 10 ne laisse aucun doute. La 10.0.0 est sortie en mars 2026 (l’annonce officielle est datée du 30 mars 2026), et six mois plus tard, la branche en est déjà à sa septième itération : les point-releases 10.0.1 à 10.0.6 sont toutes publiées, et la 10.0.7 a franchi une étape de plus depuis notre dernière édition.

Le calendrier des release candidates de cette 10.0.7 est désormais précis. La RC1 est apparue le 27 septembre 2026, et la RC2 le 3 octobre 2026. L’annonce officielle est sans ambiguïté sur la suite : « Version 10.0.7 will be released soon unless critical issues are found in testing this release candidate. » Autrement dit, à l’heure où ces lignes sont écrites, la 10.0.7 n’est pas encore la version stable de référence — la 10.0.6 reste, pour un déploiement en production, le choix par défaut.

Le rythme est soutenu et régulier. On peut le reconstituer à partir des annonces officielles : la 10.0.5 a été publiée le 22 juillet 2026, la RC1 de la 10.0.6 le 18 août, sa RC2 le 24 août, et la 10.0.6 finale le 29 août 2026. Soit environ un point-release par mois depuis le printemps. Cette cadence n’est pas un accident : elle traduit une politique de release stable assumée, dans laquelle le projet publie des versions correctives 10.x « sur l’année suivante pendant le développement de KiCad 11 ».

Pour situer ce rythme, un tableau s’impose — avec une réserve méthodologique importante : les sources publiques ne permettent pas de dater précisément chaque point-release des branches 8.x et 9.x, ni de compter leurs itérations avec certitude. On raisonne donc sur ce qui est documenté.

Branche	Version majeure	Point-releases documentés	Statut du support
9.x	2025	9.0.7, 9.0.8, 9.0.9 (visibles sur GitHub)	Plus activement maintenue depuis 10.0.0
10.x	mars 2026	10.0.1 → 10.0.6 publiées + 10.0.7 en RC2 (3 oct. 2026)	Support actif, correctifs prévus sur un an

Ce que ce calendrier dit de la maturité du projet, c’est d’abord une chose : KiCad ne se contente plus de livrer des fonctionnalités, il assume le coût de les maintenir. Une branche qui publie sept correctifs en six mois est une branche qui a des utilisateurs en production — des utilisateurs dont les plantages remontent, sont triés, et finissent en release. La contrepartie, c’est une communication qu’il faut regarder en face : longtemps réduite à une phrase générique, elle s’est récemment enrichie — mais de façon inégale selon les versions.

Ce que les notes de version disent (vraiment) : la fin de la boîte noire

Ouvrez la page des releases de KiCad 10.0.1, puis 10.0.2, puis 10.0.3. Vous lirez, à chaque fois, la même phrase : « This release contains bug fixes and other minor improvements since the previous release. » Pas un numéro de bug GitLab, pas un composant cité, pas un symptôme décrit. La 10.0.6, elle, ajoute une nuance — « critical bug fixes and other minor improvements » — mais sans plus de détail dans le corps de l’annonce.

Pourtant, une lecture plus attentive de l’annonce de la 10.0.5 révèle une réalité plus nuancée que ce que laissait entendre notre précédente édition : le changelog détaillé existe bel et bien, sous la forme d’une section « Changelog » listant chaque correctif avec son numéro d’issue GitLab. On y lit par exemple :

Persist visibility flag for design block libraries (#24588) ;
Drop backlogged key auto-repeat events after release (#24540) ;
Bound drawing dashed lines on huge geometry to prevent hang (#23824) ;
Prevent crash migrating a nested library table row (#23291) ;
Fix crash on exit (#23102) ;
Recover from 3Dconnexion driver initialization crash (#22609) ;
Don’t add stock libraries during migration if user had none (#24594) ;
Fix "Project Template Selector" dialog preview layout issue (#23656) ;
Disable commit dialog OK button until a file is selected (#24771) ;
Center a dialog when its title bar lands off-screen (#24759).

C’est une correction importante par rapport à l’idée d’une « boîte noire » totale : la matière est là, agrégée au moment de la release, avec des liens directs vers les jalons GitLab (la 10.0.5 renvoie à son milestone #59). La réserve qui subsiste est ailleurs : l’annonce elle-même (le billet de blog) reste avare de détails, et c’est en descendant dans la page, ou en suivant le lien du milestone, qu’on trouve l’information. Pour un décideur pressé, le réflexe reste donc le même — aller chercher le changelog — mais il n’est plus question de fouiller l’historique des commits : le travail de synthèse est fait.

La bonne nouvelle, c’est que cette matière est désormais fiable et datée. La mauvaise, c’est l’inégalité : toutes les annonces ne se valent pas, et certaines point-releases restent plus discrètes que d’autres. Pour qualifier une version — « puis-je la déployer sur un projet client ? » —, la méthode reste artisanale, mais elle dispose maintenant d’une base documentaire solide.

Crashs du PCB editor : ce que la maintenance documente désormais

C’est ici que le changelog de la 10.0.5 change la donne. Contrairement à ce qu’affirmait notre précédente édition, les sources officielles documentent désormais des crashs et des blocages, avec leurs numéros d’issue. On y trouve :

un crash à la sortie du logiciel (#23102) ;
un crash lors de la migration d’une ligne de table de bibliothèque imbriquée (#23291) — un problème qui touche directement les utilisateurs qui migrent depuis une version antérieure ;
un gel (hang) au dessin de lignes pointillées sur une géométrie volumineuse (#23824) — un correctif de performance qui borne le rendu pour éviter le blocage ;
et surtout, la récupération après un crash d’initialisation du pilote 3Dconnexion (#22609).

Ce dernier point mérite qu’on s’y arrête : il documente officiellement le lien entre la branche 10.0.x et l’intégration native des SpaceMouse 3Dconnexion, un sujet que nous avons traité en détail par ailleurs. La 10.0.5 ne se contente pas de corriger un crash : elle stabilise une fonctionnalité (le support natif des périphériques 3Dconnexion) dont l’arrivée dans KiCad 10 est désormais attestée par les notes de release elles-mêmes.

Côté PCB editor à proprement parler, les indices communautaires restent précieux. Un fil du forum documenté intitulé « Kicad 10.0.2rc1 crashes when I start the PCB editor » montre qu’un crash au démarrage de l’éditeur PCB a bien été observé sur une release candidate de la série 10.0.2. Et un signal de performance, pas de plantage mais tout aussi gênant, vient d’un fil du 12 août 2026 : « KiCad 10.0.4 / 10.0.5 – extremely slow track movement in PCB Editor, 10.0.5 becomes unusable ». Déplacer un segment de piste déjà routé devient extrêmement lent, au point de rendre la 10.0.5 inutilisable pour cet utilisateur.

Ce dernier cas est emblématique de ce que la maintenance révèle : une régression de performance introduite dans une version de maintenance, à corriger dans une suivante. C’est le lot de toute branche vivante, mais c’est aussi ce qui justifie la prudence. Des rapports GitLab comme #9484 (jonctions), #8344 (largeur de ligne des couches Courtyard) ou #21530 (centrage du curseur au zoom) circulent également, sans qu’on puisse les rattacher avec certitude à une version 10.0.x précise ni à un statut ouvert/fermé.

Pour un concepteur, la méthodologie est donc simple mais non négociable : avant de migrer, reproduire son propre workflow sur la version candidate, tester les gestes critiques (routage interactif, édition de footprint, undo/redo, changement de couches), et croiser avec les fils du forum et le changelog officiel. La maintenance de KiCad ne vous mâche plus entièrement le travail — mais elle vous fournit désormais les numéros d’issue pour le faire vous-même.

Importateurs : la zone d’ombre la plus critique pour les migrations

Si un point mérite une attention particulière, c’est bien celui-là. KiCad 10 a enrichi sa panoplie d’importateurs — on cite notamment l’arrivée de formats comme Allegro, PADS ou gEDA/Lepton PCB, même si cette information provient d’une source secondaire (raspberryme.com citant cnx-software) et n’est pas confirmée par la documentation officielle dans nos sources. Or, dans les notes de release 10.0.1 à 10.0.6, aucune mention d’une régression d’importateur, d’un correctif Altium, Eagle, OrCAD, LTspice, STEP ou DXF. Silence total.

Ce silence est problématique à plus d’un titre. D’abord parce que l’import est, historiquement, la partie la plus fragile d’un EDA : les formats propriétaires sont mal spécifiés, les cas limites légion, et chaque nouvelle version d’un importateur peut casser des projets qui fonctionnaient. Ensuite parce que la migration vers KiCad 10 se fait souvent depuis un outil legacy — et qu’un import raté peut coûter des jours de reprise manuelle. Enfin parce que le contexte 2026 rend ce sujet brûlant : la fin de vie d’Autodesk EAGLE, effective depuis le 7 juin 2026 (fermeture des serveurs de licences), pousse mécaniquement des utilisateurs vers KiCad. Pour eux, l’importateur n’est pas un détail : c’est la porte d’entrée.

Un cas concret, documenté sur le forum le 1er septembre 2026, illustre la réalité de ces migrations : un utilisateur migrant un projet Altium (version 25.6.2) vers KiCad 10.0.6 rapporte un avertissement ERC récurrent — « Symbol pin or wire end off connection grid » — sur presque chaque broche de symbole et chaque extrémité de fil. Ce n’est pas un crash, mais c’est exactement le genre de friction qui transforme un import « réussi » en plusieurs heures de reprise manuelle. Et cela confirme, s’il en était besoin, que l’import Altium vers KiCad 10.0.6 est un chemin réellement emprunté en production.

Faute de documentation officielle, la communauté joue son rôle. Les problèmes d’import se signalent sur le forum, dans les issues GitLab, parfois avec des projets de test joints. La précaution, pour qui migre un projet legacy, tient en trois réflexes : importer d’abord sur une version stable et récente (10.0.6 plutôt qu’une RC), vérifier visuellement chaque couche et chaque net après import, et ne jamais considérer un import comme validé avant un DRC complet. Le silence des notes de release ne signifie pas « pas de problème » — il signifie « pas d’information ». Nuance capitale.

DRC graphique, variantes de carte : les nouveaux outils passent leur examen de stabilité

KiCad 10 a introduit deux fonctionnalités très attendues : un éditeur graphique de règles DRC et la gestion des variantes de carte (board variants). Six mois plus tard, que disent les point-releases de leur stabilité ? Là encore, pas de documentation spécifique : aucune note ne détaille un correctif de faux positif DRC, un plantage de l’éditeur de variantes ou une incohérence de règles.

Mais on peut lire la maintenance autrement. Le fait que ces outils n’aient fait l’objet d’aucun rollback — aucune suppression, aucun retour en arrière — sur six versions de maintenance est un signal positif : le projet les considère comme viables et les corrige au fil de l’eau plutôt que de les retirer. Le fait que la branche publie des correctifs réguliers suggère que les retours utilisateurs sont traités. Et le fait que ces fonctionnalités continuent d’être mises en avant dans les revues de la 10 (comme chez TechExplorations ou CNX Software) indique qu’elles sont au cœur de l’adoption.

Cela dit, « pas de rollback » ne veut pas dire « zéro bug ». Un outil jeune comme l’éditeur graphique de règles DRC, qui manipule de la logique de contraintes, est typiquement le genre de composant où les cas limites (règles conditionnelles, priorités, interactions entre règles) se révèlent à l’usage. Pour un projet client en 2026, la prudence recommande de valider ces outils sur un projet pilote avant de les inscrire dans un flux de production — non pas parce qu’ils seraient instables, mais parce que leur jeunesse relative mérite une vérification empirique.

Arch, winget, Ubuntu 26.04, Apple Silicon : la disponibilité réelle dans les dépôts

Un logiciel n’existe, pour beaucoup d’équipes, que par son paquet. Et sur ce plan, KiCad 10.0.x est bien distribué. Arch Linux propose kicad 10.0.6-2 dans ses dépôts extra — un numéro de build (-2) qui trahit d’ailleurs un correctif de packaging propre à la distribution. Côté Windows, winget référence KiCad 10.0.6. Côté Ubuntu, des guides d’installation couvrent Ubuntu 26.04, 24.04 et 22.04. Et côté distributions alternatives, ALT Linux référence le paquet kicad-10.0.6-alt2 dans son dépôt Sisyphus.

Un ajout notable depuis notre dernière édition : la disponibilité macOS sur Apple Silicon est désormais documentée par un guide dédié, publié le 23 septembre 2026 par le blog d’ingénierie NOVAKVM. Il détaille l’installation de KiCad 10.0.6 sur un Mac à processeur ARM, la vérification de l’architecture, et la validation des workflows PCB, Gerber, 3D et à distance. C’est un signal utile pour les équipes mixtes : la plateforme Apple Silicon n’est plus un angle mort de la documentation communautaire.

Ce panorama révèle une réalité que connaissent bien les équipes IT : le décalage entre la sortie officielle et la disponibilité packagée. Entre la publication d’une 10.0.6 par le projet et son apparition dans un dépôt système, il peut s’écouler des jours ou des semaines — le temps du packaging, des tests, de la signature. Pour une équipe qui dépend des dépôts système (par politique de sécurité, par gestion de parc), ce décalage est un paramètre à intégrer dans la planification. Et le correctif 10.0.0-1 pour Windows, publié pour réparer un problème de bibliothèques de symboles, rappelle que les ratés de la 10.0.0 ne furent pas seulement logiciels, mais aussi de distribution.

L’écosystème 2026 : ce qui gravite autour de la branche 10.0.x

Une branche de maintenance ne vit pas en vase clos. Autour de KiCad 10.0.x, l’écosystème a continué de s’étoffer, et plusieurs fils récents méritent d’être raccrochés à cette chronique de version.

L’IA, toujours à la porte mais jamais dedans. À l’automne 2026, KiCad reste obstinément sans IA native. En revanche, les ponts se multiplient : le plugin Konnect, un binaire Rust unique qui expose 228 outils à Claude et à d’autres assistants via le Model Context Protocol (MCP), est documenté depuis le 14 octobre 2026, et un article d’Adafruit daté du 26 octobre 2026 traite de l’IA PCB dans KiCad 10 via MCP. La nuance reste la même : l’IA n’est pas dans KiCad, elle l’encercle via des serveurs MCP et des plugins tiers. Rien dans les notes de release 10.0.x ne suggère une intégration native.

Le versioning et le cloud. Le plugin kicad-git reste le cœur du réacteur pour la gestion de versions, et CADLAB.io est passé en version officielle — des sujets que nous avons traités en détail et qui s’appuient tous sur la stabilité de la branche 10.0.x.

L’ECAD-MCAD. Le pont avec FreeCAD, via l’atelier KiCad StepUp, continue de s’appuyer sur l’export STEP — et KiCad 10 a franchi un cap en ce domaine : depuis la version 10, les bibliothèques officielles ne livrent plus que des fichiers STEP (et non plus les anciens formats de modèles 3D), ce qui réduit fortement la taille d’installation et améliore la précision géométrique. C’est un changement de fond, documenté dans l’annonce de la 10.0.0, qui bénéficie directement aux workflows de boîtier.

Le routage. Freerouting 2.3.0 a connu une régression documentée le 28 août 2026 : des routes auto-déclarées comme portant des violations de clearance sur des cartes que la 2.2.4 routait proprement. Un rappel que l’écosystème de l’autoroutage — y compris les outils tiers — doit être validé par DRC, jamais pris pour argent comptant.

La communauté. KiCon Asia 2026 se tiendra à Shenzhen du 5 au 7 novembre 2026 (annonce du 16 septembre 2026), au Huaqiang Plaza Hotel. C’est la quatrième édition asiatique de la conférence — l’occasion, pour qui suit la branche 10.0.x, de croiser les mainteneurs et de poser directement les questions que les notes de release laissent en suspens.

Le mot de la fin : quelle version pour quel usage ?

Six mois après la 10.0.0, le bilan de la branche 10.0.x est celui d’une maturité opérationnelle. Sept itérations, un changelog qui existe (même s’il faut aller le chercher), des correctifs de crash documentés avec leurs numéros d’issue, une distribution packagée sur les principales plateformes — Linux, Windows, macOS Apple Silicon. La 10.0.7, en RC2 depuis le 3 octobre 2026, ne devrait plus tarder, mais tant qu’elle n’est pas stable, la 10.0.6 reste la référence de production.

Pour un concepteur, la recommandation tient en trois lignes : rester sur la 10.0.6 pour tout projet client ; tester la 10.0.7 en RC sur un projet pilote, en surveillant les régressions de performance (le cas du déplacement de piste lent reste un signal à garder en tête) ; et ne jamais migrer un projet legacy sans DRC complet après import, en particulier depuis Altium, où les avertissements ERC de grille restent fréquents. La maintenance de KiCad ne vous mâche pas tout le travail — mais elle vous fournit désormais les outils pour le faire vous-même.

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 après : ce que la maintenance d’une branche qui ne dort jamais nous dit vraiment