Kicad Master · 7 November 2026

KiCad 10.0.6 → 10.0.7 : anatomie d’un cycle de patchs qui dit tout de la santé de la branche 10

Entre le 29 août et le 7 octobre 2026, KiCad a enchaîné une release de correction, deux candidates et une version stable. Derrière cette mécanique apparemment banale se cache une radiographie complète du processus de release du projet — et quelques signaux très concrets pour quiconque a un PCB en production.

Un cycle de patchs qui n’a rien d’anodin : pourquoi 10.0.6 → 10.0.7 mérite votre attention

Il y a une tentation naturelle, quand on suit un projet open source comme KiCad, de traiter les releases de correction comme du bruit de fond. Une version sort, elle corrige « des bugs critiques et d’autres améliorations mineures », on met à jour, on passe à autre chose. Sauf que dans l’écosystème KiCad, la cadence et la nature des patchs ne sont pas du bruit : ce sont les indicateurs les plus fiables de la santé réelle d’une branche majeure.

Reprenons la chronologie telle qu’elle ressort des sources officielles. La version 10.0.6 a été annoncée le 29 août 2026 par le projet, avec la formule rituelle : « The 10.0.6 stable version contains critical bug fixes and other minor improvements since the previous release. » Une première Release Candidate pour cette même 10.0.6 était apparue le 18 août 2026, soit onze jours plus tôt. Puis, le 27 septembre 2026, la Release Candidate 1 de la 10.0.7 débarque — moins d’un mois après la sortie stable de la 10.0.6. Le 3 octobre 2026, la Release Candidate 2 de cette même 10.0.7 est publiée, avec un message limpide : « Version 10.0.7 will be released soon unless critical issues are found in testing this release candidate. » Et le 7 octobre 2026, la version 10.0.7 stable est officiellement annoncée : « The 10.0.7 stable version contains critical bug fixes and other minor improvements since the previous release. »

Voilà donc un cycle qui s’étale sur environ six semaines entre deux stables (29 août → 7 octobre), avec deux RC successives et un intervalle très court entre une release stable et la première RC de la suivante. Ce rythme, à lui seul, raconte quelque chose. Il dit qu’à la fin septembre 2026, l’équipe KiCad considérait la branche 10.x suffisamment mûre pour ne plus avoir besoin de longs cycles de stabilisation, mais suffisamment active pour que des correctifs continuent d’affluer. C’est exactement la zone où l’on veut se trouver quand on conçoit des cartes : pas une branche figée qu’on abandonne, pas une branche instable qu’on ne peut pas utiliser en production.

Ce que cet article propose, c’est de prendre ce cycle 10.0.6 → 10.0.7 au sérieux comme objet d’analyse. Pas pour lister des correctifs — les sources publiques ne les détaillent pas — mais pour comprendre ce que la structure même de ce cycle révèle : la nature probable des bugs corrigés, leur distribution entre les sous-modules, la qualité du processus de release, et surtout, ce que vous devez en faire concrètement pour votre prochain PCB.

Ce que les sources officielles disent vraiment (et ce qu’elles taisent)

Commençons par un exercice d’honnêteté documentaire, parce qu’il conditionne tout le reste. Ce que l’on peut affirmer avec certitude, sur la base du miroir GitHub officiel KiCad/kicad-source-mirror et du blog du projet, tient en quelques points nets.

D’abord, la séquence des releases 10.0.x est continue et documentée : 10.0.0, puis 10.0.0-1, puis 10.0.1, 10.0.2, 10.0.3, 10.0.4, 10.0.5, 10.0.6, et désormais 10.0.7 — toutes étiquetées comme releases de correction de bugs. Ensuite, la politique de release stable est explicite et a été annoncée avec la 10.0.0 : « KiCad 9.x will no longer be actively maintained, and we will release bug fix versions of KiCad 10.x over the next year as we develop new features for KiCad 11. » Autrement dit, la branche 9.x est sortie du support actif, et la branche 10.x vit une fenêtre de maintenance d’environ un an, en parallèle du développement de KiCad 11.

Un détail mérite qu’on s’y arrête : le correctif 10.0.0-1. Publié sous la release 10.0.0, il corrige un « packaging issue with symbol libraries » — un problème d’empaquetage des bibliothèques de symboles, spécifiquement sous Windows. Ce petit numéro suffixé n’est pas cosmétique : il signale qu’au moment de la sortie majeure, le binaire lui-même était correct mais que l’assemblage des bibliothèques qui l’accompagne ne l’était pas. C’est un précédent précieux pour lire la suite.

Maintenant, ce que les sources taisent, et c’est considérable. Les pages de releases consultées ne fournissent aucune date de publication pour 10.0.0 à 10.0.6, aucun numéro de build (pas de hash Git, pas de tag détaillé), et aucune répartition des correctifs par module. Le contenu granulaire des notes de version se limite à des formules génériques. Pour la 10.0.7, en revanche, on dispose de dates précises — 27 septembre pour la RC1, 3 octobre pour la RC2, 7 octobre pour la stable — parce que le blog officiel les a relayées.

Cette asymétrie est en soi une information. Le projet communique très bien sur le processus (RC disponible, testez, la stable arrive) mais très peu sur le contenu (quels bugs, où, de quel type). Pour le concepteur, cela signifie une chose simple : on ne peut pas décider d’une migration en lisant un changelog, parce qu’il n’y en a pas d’exploitable. Il faut raisonner par structure, par précédents et par tests.

Anatomie d’un patch KiCad : lire entre les lignes

Puisqu’on ne dispose pas du détail des correctifs, adoptons la méthode de l’ingénieur : raisonner sur les catégories possibles et sur ce que la structure du cycle permet d’inférer.

Dans un projet de la taille de KiCad, un correctif publié dans une release de maintenance tombe presque toujours dans l’une de quatre catégories. La régression : une fonctionnalité qui marchait en 10.0.4 et qui casse en 10.0.5 à cause d’un changement introduit dans la branche courante. La régression de régression : un correctif qui, en réparant un bug, en introduit un autre — le scénario classique du fix qui touche une zone de code partagée. La dette technique ancienne : un bug qui existe depuis des années, que personne n’avait signalé ou priorisé, et qui remonte soudain parce qu’un utilisateur le rencontre dans un contexte nouveau. Enfin le crash isolé : un cas limite, souvent lié à une configuration matérielle ou à un fichier particulier.

Le problème, c’est que les sources publiques ne permettent pas de classer les correctifs de 10.0.6 ou de 10.0.7 dans ces cases. Aucun hash de commit, aucune issue liée, aucune répartition chiffrée n’est fournie. On travaille donc par inférence, en s’appuyant sur les précédents documentés.

Et ces précédents sont parlants. Le correctif 10.0.0-1 relève clairement de la catégorie « empaquetage » — ni régression de code, ni dette technique applicative, mais un problème de distribution. À l’inverse, un signal remonté sur le forum officiel évoque des « Design Block Problems » en 10.0.4, et un autre fil documente une régression de performance sévère : « KiCad 10.0.4 / 10.0.5 – extremely slow track movement in PCB Editor, 10.0.5 becomes unusable ». Voilà une régression typique, introduite dans la branche 10.x, qui a rendu une version intermédiaire difficilement utilisable pour certains utilisateurs. Que la 10.0.6 soit présentée comme contenant des « critical bug fixes » quelques semaines plus tard est cohérent avec ce type de scénario : une régression de performance introduite en 10.0.4/10.0.5, corrigée en 10.0.6.

Un autre cas documenté illustre la catégorie « dette/ergonomie » : un utilisateur migrant un projet Altium 25.6.2 vers KiCad 10.0.6 rapporte sur le forum un avertissement ERC massif — « Symbol pin or wire end off connection grid » — sur presque chaque broche et chaque fil. Ce n’est pas un crash, c’est un problème d’importateur qui génère du travail de correction en série. Le type de bug qu’un patch de maintenance peut traiter, mais qui n’apparaît jamais dans un changelog synthétique.

C’est là toute la leçon méthodologique : dans un cycle KiCad, la release de correction n’est pas seulement un polish, c’est souvent la réparation de ce que la release précédente a cassé. Et c’est précisément pour cela que sauter sur la toute dernière version sans réfléchir n’est pas toujours la meilleure stratégie.

eeschema, pcbnew, 3D viewer, kicad-cli : où se concentre le risque ?

Si l’on ne peut pas compter les correctifs par module, on peut en revanche raisonner sur l’exposition structurelle de chaque composant. Et là, la logique est implacable : plus un module concentre d’évolutions fonctionnelles, plus il concentre de régressions potentielles.

pcbnew (l’éditeur de PCB) et eeschema (l’éditeur de schéma) sont, par construction, les deux zones à plus fort risque. Ce sont eux qui absorbent l’essentiel des nouvelles fonctionnalités à chaque version majeure — et KiCad 10 n’a pas fait exception. La présentation de la 10.0.0 par Elektor recense ainsi, côté schéma, les variantes de conception, les croisements de fils avec saut (hop-over), la prise en charge des cavaliers, le regroupement et l’échange CSV dans le tableau de broches ; côté carte, le réglage en domaine temporel, les blocs de conception de PCB, les objets de couche interne dans les empreintes, l’échange de broches et de portes sans contrainte, et l’éditeur de règles DRC graphique. Chaque nouvelle fonctionnalité est une surface de bug supplémentaire. La régression de lenteur sur le déplacement de pistes en 10.0.4/10.0.5 en est l’illustration parfaite : elle touche pcbnew, le module le plus sollicité.

Les bibliothèques de symboles et d’empreintes occupent une position différente. Leur code évolue peu, mais leur distribution est un point de friction récurrent — le correctif 10.0.0-1 sous Windows l’a prouvé. Un problème de bibliothèque ne casse pas l’application, mais il peut rendre un projet impossible à ouvrir correctement, ce qui est tout aussi bloquant en pratique. Les dépôts GitLab officiels des bibliothèques d’empreintes suivent d’ailleurs leur propre rythme de tags (un tag 10.0.7-rc1 y apparaît dès le 22 septembre 2026), indépendamment du binaire.

La visionneuse 3D, le simulateur SPICE, le vérificateur de règles électriques (ERC) et kicad-cli sont structurellement plus stables : moins d’évolutions, donc moins de régressions attendues. Mais kicad-cli, utilisé pour l’automatisation et l’intégration continue, est sensible aux changements d’interface en ligne de commande — un correctif anodin pour l’utilisateur graphique peut casser un script de build.

Enfin, la Python API, dont la documentation CI a été publiée en juillet 2026, constitue un cas à part : c’est une interface publique, et toute modification de son comportement peut casser des plugins tiers. Avec l’écosystème croissant de plugins et de serveurs MCP qui s’est développé autour de KiCad 10 en 2026 — dont le plugin Rust Konnect, qui expose 228 outils à Claude via MCP selon Fellow (14 octobre 2026) et Adafruit (26 octobre 2026) — c’est un point de vigilance réel.

La conclusion pratique de cette distribution : si votre flux de travail repose massivement sur pcbnew et eeschema (le cas de la quasi-totalité des concepteurs), vous êtes exposé au cœur du risque de régression. Si vous dépendez en plus de scripts Python ou de kicad-cli, ajoutez une couche de test supplémentaire avant toute mise à jour.

Le vrai champ de bataille est dans les tuyaux : winget, Arch, Ubuntu, PPA testing

Un point que les notes de version ne disent jamais assez fort : pour KiCad, un patch n’est pas seulement une correction de code, c’est aussi une opération de distribution. Et c’est souvent là que les utilisateurs rencontrent leurs premiers problèmes.

La 10.0.6 a ainsi fait l’objet de guides d’installation dédiés, comme celui du blog NOVAKVM (23 septembre 2026) expliquant comment l’installer sur un Mac Apple Silicon et vérifier l’architecture, les fichiers Gerber, les bibliothèques et les modèles 3D. Le fait qu’un simple patch de maintenance génère un guide de validation complet en dit long sur la complexité de la chaîne de distribution multiplateforme.

Concrètement, selon votre canal d’installation, la 10.0.7 n’arrive pas au même moment : les paquets Windows via winget, les dépôts Arch, l’empaquetage Ubuntu 26.04 et le PPA testing suivent chacun leur propre calendrier. Un utilisateur qui installe depuis le site officiel et un utilisateur qui passe par le gestionnaire de paquets de sa distribution peuvent donc se retrouver sur des versions différentes pendant plusieurs jours, voire plusieurs semaines. Pour une équipe, cela signifie qu’il faut figer la version dans le projet (documenter la version exacte utilisée pour chaque révision de carte) plutôt que de supposer que tout le monde est à jour.

C’est aussi la raison pour laquelle le petit correctif 10.0.0-1 (« packaging issue with symbol libraries » sous Windows) reste un précédent instructif : un binaire correct accompagné de bibliothèques mal assemblées produit une expérience cassée. Avant de valider une mise à jour, vérifiez donc autant le numéro de version de l’application que la cohérence des bibliothèques chargées.

Du changelog brut à la décision : sauter sur 10.0.7, rester sur 10.0.6, ou attendre ?

C’est la question qui compte vraiment. Voici une grille de décision fondée sur les faits disponibles, pas sur des numéros de version supposés.

Situation	Recommandation	Justification
Projet en production, stable, peu de marge	Rester sur une 10.0.x dont le cycle est éprouvé ; tester 10.0.7 sur une copie	La 10.0.7 contient des correctifs critiques ; on ne veut pas découvrir une régression sur un projet livrable
Projet en développement actif	Adopter 10.0.7	Dernière release de correction stable documentée (7 octobre 2026) ; point d’équilibre actuel de la branche
Besoin de fonctionnalités récentes de la branche 10	10.0.7, avec sauvegarde de projet avant	Les correctifs critiques réparent des régressions connues des versions antérieures
Dépendance forte à des scripts Python / kicad-cli	Tester l’API et les scripts avant de migrer	L’API Python et l’interface CLI sont des surfaces de rupture
Évaluation de KiCad 11	Attendre les premières RC publiques	La branche 11 est en développement ; aucune release stable n’est annoncée dans les sources consultées

Le point crucial : 10.0.7 est désormais stable depuis le 7 octobre 2026, mais elle reste une release de maintenance, pas une version majeure. Toute décision qui traite 10.0.7 comme « la version qui apporte des fonctionnalités » repose sur une erreur de lecture : elle corrige, elle n’innove pas. Les fonctionnalités, c’est la 10.0.0 (20 mars 2026) qui les a apportées, et ce sera la 11.x qui en apportera de nouvelles.

Pour un projet en production, la règle de bon sens est simple : ne jamais migrer un projet livrable sans avoir ouvert une copie dans la nouvelle version, régénéré les Gerber, relancé le DRC et vérifié la BOM. Un patch de maintenance corrige des bugs, mais il peut aussi déplacer subtilement un comportement — c’est précisément ce que la régression de lenteur de pcbnew en 10.0.4/10.0.5 nous a appris.

Ce que le cycle 10.0.x dit de la gouvernance — et de l’écosystème qui pousse autour

Prendre du recul sur ce cycle, c’est aussi comprendre où va le projet. Trois signaux méritent d’être mis côte à côte.

Premier signal : la cadence. Neuf releases en un peu plus de six mois (10.0.0 en mars, 10.0.7 en octobre), avec des RC systématiques et des intervalles courts. C’est le signe d’une équipe de maintenance réactive et d’une base d’utilisateurs qui remonte les bugs assez vite pour que des patchs soient nécessaires si souvent. Ce n’est pas un signe de fragilité, c’est un signe de vitalité — à condition d’accepter que « dernière version » ne veuille pas dire « version sans risque ».

Deuxième signal : l’écosystème. La branche 10.x a vu se développer autour d’elle des outils qui n’existaient pas il y a deux ans : le plugin Konnect pour piloter KiCad depuis un LLM via MCP, des serveurs MCP, des scripts d’automatisation, des services de cotation instantanée comme AIVON (présenté le 15 septembre 2026). Cette couche applicative dépend de la stabilité de l’API Python et de kicad-cli — deux surfaces que les patchs peuvent toucher. La santé de l’écosystème est donc directement corrélée à la qualité du processus de release décrit plus haut.

Troisième signal : la communauté. La KiCon Asia 2026 se tiendra à Shenzhen du 5 au 7 novembre 2026, au Huaqiang Plaza Hotel — quatrième édition asiatique, annoncée le 16 septembre 2026. Un projet qui tient une conférence annuelle sur un continent où se concentre une grande partie de la fabrication électronique mondiale envoie un message clair : KiCad n’est plus seulement un outil d’amateurs éclairés, c’est un outil de production qui dialogue avec son écosystème industriel.

Reste une question ouverte, et il faut la poser honnêtement : les sources consultées ne permettent pas de savoir si la branche 10.x continuera d’être maintenue au-delà de la fenêtre d’un an annoncée, ni à quel rythme KiCad 11 sera publié. Ce sont des inconnues réelles, pas des lacunes de recherche. La seule chose que l’on peut affirmer, c’est que la mécanique observée entre le 29 août et le 7 octobre 2026 — une stable, deux RC, une nouvelle stable en six semaines — est celle d’un projet qui sait ce qu’il fait. Et pour le concepteur, c’est probablement l’information la plus rassurante de tout ce cycle.

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.6 → 10.0.7 RC2 : ce que ce cycle de patchs dit vraiment de la maturité de la branche 10 (et ce que ça change pour votre prochain PCB)