Kicad Master · 18 October 2026

KiCad 10.0.7 : ce que huit mois de patchs ont vraiment changé dans le quotidien du concepteur PCB

Six mises à jour correctives en huit mois, un septième patch arrivé en octobre 2026 : la branche 10.0.x de KiCad a vécu une année de rattrapage intense. Derrière les notes de version laconiques se cache une réalité plus contrastée — des correctifs qui débloquent des projets, des régressions qui font perdre des journées, et un écosystème qui encaisse. Voici ce que ce cycle a réellement livré, et ce qu’il faut en retenir avant de lancer votre prochaine carte.

10.0.7, ou la fin d’une année de rattrapage : pourquoi ce numéro de patch compte plus que les autres

Un septième patch, huit mois après une version majeure. À première vue, rien d’exceptionnel : KiCad a l’habitude de faire vivre ses branches stables par une série de correctifs avant de basculer vers la suivante. Mais quand on regarde le calendrier de près, 10.0.7 n’est pas un patch comme les autres. Il clôt une séquence qui a démarré en mars 2026 avec la publication de KiCad 10.0.0, et qui s’est étalée jusqu’à l’automne avec une régularité presque mécanique : 10.0.6 le 29 août 2026, une release candidate 1 le 18 août, puis 10.0.7 dont les deux candidates ont été publiées les 27 septembre et 3 octobre 2026 avant la sortie finale d’octobre.

Cette cadence raconte quelque chose. Une version majeure de KiCad, c’est un choc pour l’écosystème : de nouvelles fonctionnalités (variants, DRC graphique, importateurs retravaillés, refonte de l’UI sur plusieurs écrans), des bibliothèques mises à jour, des formats de fichiers qui évoluent. Les premiers mois d’une branche .0.x sont toujours les plus agités — c’est là que remontent les régressions que personne n’avait vues en bêta, parce que les bêtas sont testées par une poignée de volontaires et que la stable est testée par des milliers de projets réels. La question que tout concepteur PCB s’est posée en septembre 2026 était simple : est-ce que cette branche est enfin sûre pour de la production, ou est-ce qu’on attend encore un peu ?

La réponse, on va la construire ensemble. Pas en récitant les notes de version — elles sont volontairement sobres, presque austères, du genre « contient des corrections de bugs critiques et d’autres améliorations mineures depuis la version précédente ». Mais en croisant ces annonces avec ce que la communauté a réellement vécu : les fils du forum KiCad, les tickets GitLab, les plugins qui ont dû s’adapter, les retours de ceux qui ont migré un projet de production en 10.0.4 et qui ont déchanté, puis en 10.0.6 et qui ont respiré. C’est cette confrontation entre le discours officiel et le terrain qui donne la vraie mesure du cycle.

Anatomie d’une série de patchs : qui décide quoi, à quelle cadence, et selon quels critères de backport

Comprendre un cycle de patchs, c’est d’abord comprendre sa mécanique. KiCad fonctionne avec une branche stable (ici 10.0.x) et une branche de développement qui prépare la version suivante. Chaque correctif doit théoriquement être poussé sur la branche de développement, puis backporté vers la stable s’il remplit certains critères. Ces critères ne sont pas publics sous forme de document unique, mais la pratique est constante : un correctif est backporté s’il corrige un crash, une régression par rapport à la version précédente, une corruption de fichier, un faux positif de DRC/ERC qui bloque la fabrication, ou un problème de sécurité. Les améliorations de confort, les nouvelles fonctionnalités, les refontes d’interface — tout cela reste sur la branche de développement et attend la version majeure suivante.

Le calendrier suit une logique de release candidate avant chaque patch : 10.0.6 a eu sa RC1 le 18 août pour une sortie stable le 29 août ; 10.0.7 a eu sa RC1 le 27 septembre, sa RC2 le 3 octobre, pour une sortie finale en octobre. Ce délai de quelques semaines entre RC et stable n’est pas décoratif : c’est la fenêtre pendant laquelle les utilisateurs les plus prudents testent, remontent, et où l’équipe peut encore corriger. La phrase rituelle des annonces — « la version sera publiée prochainement sauf si des problèmes critiques sont détectés lors des tests » — n’est pas une clause de style. Elle signifie qu’une RC peut être retardée, voire remplacée, si un bug bloquant apparaît.

Ce qu’il faut retenir côté utilisateur : quand vous voyez passer une RC, ce n’est pas encore le moment de migrer votre projet de production. Quand vous voyez la stable sortir, vous avez en général affaire à un état testé par une communauté élargie, mais pas nécessairement exempt de régressions découvertes à l’usage. Le vrai signal de maturité, c’est plutôt le patch suivant : si 10.0.7 sort sans qu’une vague de tickets critiques ne déferle dans les jours qui suivent, c’est que 10.0.6 était solide. C’est exactement ce qui s’est passé.

Ce que les notes de version disent, ce que les tickets GitLab racontent : la classification des correctifs de 10.0.1 à 10.0.7

Les notes de version officielles de KiCad sont délibérément minimalistes. « Corrections de bugs critiques et autres améliorations mineures » — voilà pour l’essentiel du texte. Ce n’est pas de la paresse : c’est un choix éditorial assumé, qui renvoie aux milestones GitLab pour le détail. Le problème, c’est que ce détail est éparpillé sur des dizaines de tickets, et que personne ne fait la synthèse pour le concepteur pressé.

En croisant les retours terrain, une classification grossière se dégage néanmoins. Les patchs 10.0.1 à 10.0.3 ont surtout absorbé les régressions classiques post-majeure : crashes à l’ouverture de projets anciens, problèmes d’affichage dans l’éditeur PCB, instabilités du visualiseur 3D. Les patchs 10.0.4 et 10.0.5 ont introduit puis corrigé une régression notable sur la manipulation des pistes existantes (on y revient). 10.0.6 a consolidé, et 10.0.7 a fermé les derniers trous. Cette répartition n’est pas propre à KiCad : c’est le schéma quasi universel des branches .0.x de logiciels complexes.

Ce qui frappe, c’est le déséquilibre entre la discrétion des annonces et l’impact réel de certains correctifs. Un ticket qui corrige un faux positif de DRC peut sembler mineur dans une note de version ; dans la vraie vie, il débloque une génération de Gerbers et permet à une carte de partir en fabrication. À l’inverse, un changement d’icône dans une barre d’outils occupe parfois plus de place dans les discussions de forum qu’un correctif de corruption de fichier. La perception communautaire et la criticité technique ne coïncident pas toujours.

Les bugs qui font vraiment mal : pertes de données, faux positifs DRC et corruptions de fichiers

C’est la partie de l’article où l’on quitte les généralités. Trois familles de bugs méritent une attention particulière dans ce cycle, parce qu’elles sont celles qui coûtent cher — en argent, en délais, en nuits blanches.

Les faux positifs de DRC/ERC. Un faux positif de DRC n’est pas un bug cosmétique : c’est un bug qui vous empêche de générer vos fichiers de fabrication, ou qui vous pousse à ignorer des avertissements légitimes par lassitude. Le cas le plus documenté du cycle concerne l’import Altium. Un utilisateur rapporte sur le forum KiCad le 1er septembre 2026, en migrant un projet Altium 25.6.2 vers KiCad 10.0.6, un avertissement ERC « Symbol pin or wire end off connection grid » qui se déclenche sur presque chaque broche et chaque extrémité de fil. Le symptôme est classique des imports : le convertisseur a décalé les coordonnées d’une fraction de grille, et l’ERC, qui vérifie l’alignement, proteste en masse. La correction n’est pas nécessairement dans un patch — c’est parfois un réglage de tolérance ou une manipulation dans l’importateur — mais elle illustre la fragilité de la chaîne import → ERC → fabrication.

Les corruptions de fichier. Aucun cycle de patchs n’est exempt de ce risque, et c’est celui qui fait le plus peur. Un fichier .kicad_pcb corrompu après un crash pendant une sauvegarde, c’est un projet qui peut être perdu si les sauvegardes automatiques n’ont pas été activées. Les patchs de la série 10.0.x ont traité plusieurs cas de ce type, généralement liés à des écritures interrompues ou à des formats de fichiers anciens mal relus. La règle de prudence reste la même : activer les sauvegardes automatiques, versionner ses projets (Git, SVN, peu importe), et ne jamais migrer un projet de production sans avoir fait une copie de l’original dans son format d’origine.

Les régressions introduites puis corrigées en cours de série. C’est le cas le plus instructif. Un fil du forum du 12 août 2026 documente un problème sérieux : dans KiCad 10.0.4 et 10.0.5, le déplacement d’une piste existante dans l’éditeur PCB devient extrêmement lent, au point que 10.0.5 est décrit comme « inutilisable » par l’utilisateur qui rapporte le bug. Pour un concepteur qui travaille sur un routage dense, c’est une régression qui coûte des heures. La correction est arrivée dans 10.0.6. La leçon : entre deux patchs, il peut y avoir une régression pire que le bug corrigé. Migrer systématiquement vers le dernier patch n’est pas toujours la bonne stratégie — parfois, rester sur 10.0.4 en attendant 10.0.6 est plus sage.

Interface et ergonomie : le cosmétique qui agace et le gain qui se mesure

Les changements d’interface dans un cycle de patchs sont toujours un sujet délicat. Par définition, la branche stable ne devrait recevoir que des correctifs — pas de nouvelles fonctionnalités, pas de refontes. Mais un correctif peut modifier l’ergonomie : un dialogue qui s’ouvre différemment, un raccourci qui change de comportement, un panneau qui mémorise mal sa position. Et là, les réactions sont imprévisibles.

Le cas le plus intéressant du cycle 10.0.x concerne une nouveauté de KiCad 10 qui a mis du temps à être comprise : les labels d’alimentation locaux. Un fil du forum du 3 août 2026 montre un utilisateur qui a vu la fonctionnalité annoncée, qui cherche désespérément comment l’activer, et qui ne trouve aucun réglage pour rendre un label d’alimentation « local ». La réponse est probablement dans la documentation ou dans une manipulation non évidente — mais le fait que la question se pose indique un déficit d’affordance. Une fonctionnalité présente mais introuvable est, du point de vue de l’utilisateur, une fonctionnalité absente. Ce n’est pas un bug au sens strict ; c’est un problème d’ergonomie qui mérite d’être corrigé dans la version suivante.

À l’inverse, certains ajustements d’UI passent inaperçus mais changent la journée. La gestion des panneaux, la persistance des préférences entre sessions, la stabilité des dialogues lors de manipulations répétées : ce sont des gains qui ne se voient pas dans une note de version mais qui se ressentent après quelques heures de travail. Le tri entre cosmétique et gain réel n’est pas dans les annonces — il est dans l’usage. Et c’est là que les retours du forum sont irremplaçables : un changement d’icône fait râler pendant deux jours puis s’oublie ; un dialogue qui perd le focus à chaque validation fait perdre des heures et remonte en boucle.

Bibliothèques, importateurs et 3D : les évolutions silencieuses qui touchent la production

C’est la partie la plus sous-estimée d’un cycle de patchs. Les bibliothèques officielles de KiCad évoluent en continu, indépendamment des versions de l’éditeur, et un projet qui compile en 10.0.4 peut se retrouver avec des empreintes mises à jour en 10.0.6 — parfois pour le meilleur, parfois avec des surprises. La reproductibilité d’un projet existant dépend donc de la version des bibliothèques utilisées, pas seulement de la version de KiCad. C’est une nuance que beaucoup de concepteurs découvrent à leurs dépens.

Les importateurs, eux, sont un chantier permanent. L’import Altium reste l’un des points de friction majeurs du cycle. Le rapport du 1er septembre 2026 mentionne Altium 25.6.2 comme version source, et le problème d’ERC en masse sur les broches décalées montre que la conversion n’est pas encore transparente. Pour ceux qui migrent des projets Altium, la recommandation est de valider l’import sur un petit projet avant de s’attaquer à un gros, et de vérifier systématiquement l’ERC après conversion — pas seulement le DRC.

Le visualiseur 3D, enfin, a connu son lot de corrections. Les problèmes d’affichage de modèles 3D, de rendu raytracer ou de performance sur des cartes complexes sont récurrents dans les retours. Rien de dramatique dans le cycle 10.0.x, mais assez pour rappeler que le visualiseur 3D n’est pas qu’un gadget : c’est un outil de vérification mécanique, et un modèle 3D mal rendu peut cacher une collision avec un boîtier.

Du schéma à la carte fabriquée : ce que le cycle 10.0.x change dans le workflow PCB réel

Prenons un projet type : un schéma hiérarchique, un routage dense, une génération de Gerbers et de BOM, un envoi au fabricant. Où en est-on en 10.0.7 ?

Saisie schématique : fiable. Les problèmes d’ERC sur les imports Altium restent un point d’attention, mais pour un schéma créé nativement, le cycle n’a pas introduit de régression majeure. La fonctionnalité de labels d’alimentation locaux est là, mais son ergonomie mérite un coup d’œil à la documentation.

Routage interactif : c’est le point le plus sensible du cycle. La régression de lenteur sur le déplacement de pistes existantes en 10.0.4 et 10.0.5 a été corrigée en 10.0.6, mais elle rappelle que le routeur interactif est un composant critique qui peut casser d’un patch à l’autre. En 10.0.7, le comportement est revenu à la normale — mais pour un projet en cours, il vaut mieux tester sur une copie avant de basculer.

Vérification DRC : globalement fiable, avec la réserve des faux positifs sur imports. Le DRC graphique introduit en 10.0.0 est un vrai gain pour le diagnostic, et le cycle l’a stabilisé.

Génération de Gerbers et BOM : c’est l’étape où un faux positif DRC fait le plus de dégâts, puisqu’il bloque la génération. En 10.0.7, la situation est assainie, mais la précaution reste : générer les fichiers de fabrication tôt, les inspecter dans un viewer externe, et ne jamais envoyer au fabricant sans une vérification visuelle.

Échanges avec le fabricant : rien de spécifique au cycle, mais la stabilité des formats de fichiers est un enjeu. Un projet conçu en 10.0.4 et rouvert en 10.0.7 doit produire des Gerbers identiques — c’est le test de non-régression le plus simple à faire, et il vaut la peine d’être systématisé.

L’écosystème à l’épreuve : plugins, scripts et outils tiers face à une branche 10.0.x mouvante

Un cycle de patchs n’est pas neutre pour l’écosystème. Les plugins qui s’appuient sur l’API de KiCad doivent suivre les évolutions, et un patch qui modifie un comportement interne peut casser une extension non maintenue. Le cycle 10.0.x a été marqué par une effervescence particulière autour de l’IA : un plugin natif en Rust, Konnect, présenté le 7 septembre 2026 comme un assistant Claude pour la conception schématique et le routage via MCP, illustre la vitalité de l’écosystème — et sa dépendance à la stabilité de l’API.

Les plugins plus anciens, eux, ont connu des sorts variables. Certains ont été mis à jour au fil des patchs, d’autres sont restés bloqués sur des versions antérieures. Pour un concepteur qui dépend d’une extension non maintenue, la question est simple : est-ce que je peux me permettre de migrer vers 10.0.7 si mon plugin préféré n’a pas été testé ? La réponse dépend de la criticité du plugin dans le workflow. Un plugin de génération de vias de stitching, par exemple, peut être remplacé par un script maison ; un plugin d’import d’un format propriétaire, beaucoup moins facilement.

Le cycle a aussi révélé une fracture entre les utilisateurs qui suivent les patchs au jour le jour et ceux qui restent sur une version stable pendant des mois. Les premiers essuient les plâtres et font avancer le projet ; les seconds bénéficient d’une expérience plus lisse mais ratent parfois des correctifs importants. Il n’y a pas de bonne réponse universelle — juste des profils différents.

Faut-il migrer maintenant ? Matrice de décision et cap sur la prochaine version majeure

La question que tout le monde se pose, formulée sans détour : est-ce que 10.0.7 est le bon moment pour migrer ?

Concepteur occasionnel, projets simples : oui, 10.0.7 est un bon choix. La branche a absorbé ses régressions majeures, les correctifs critiques sont là, et le risque résiduel est faible pour des projets peu denses. Activez les sauvegardes automatiques, versionnez vos projets, et vous êtes paré.

Bureau d’études, projets de production : prudence, mais pas d’immobilisme. 10.0.7 est le meilleur candidat de la branche, mais la migration doit être testée sur un projet représentatif avant d’être généralisée. La régression de lenteur de 10.0.4/10.0.5 rappelle qu’un patch peut introduire un problème pire que celui qu’il corrige. Testez sur une copie, vérifiez la génération de Gerbers, et gardez la possibilité de revenir en arrière.

Production critique, délais serrés : restez sur la version qui fonctionne pour vous, et migrez entre deux projets, jamais au milieu d’un. La stabilité prime sur la nouveauté.

Quant à la prochaine version majeure, elle se prépare déjà. Les signaux à surveiller : les annonces de feuille de route, les milestones GitLab de la branche de développement, et les premiers échos de la bêta. L’expérience du cycle 10.0.x enseigne une chose : les premiers patchs d’une majeure sont toujours agités, et la vraie maturité arrive vers le troisième ou quatrième patch. Planifier une migration vers la prochaine majeure, c’est prévoir un délai de quelques mois après sa sortie avant de l’utiliser en production — pas l’inverse.

Ce cycle de patchs laisse finalement une impression mitigée mais globalement positive. KiCad 10.0.7 n’est pas une révolution ; c’est une consolidation. Mais dans le quotidien du concepteur PCB, une consolidation bien faite vaut souvent mieux qu’une fonctionnalité spectaculaire. Les cartes partent en fabrication, les projets ne se corrompent plus, les régressions sont corrigées — c’est exactement ce qu’on demande à une branche stable. Et c’est ce qui permet d’attendre la suite avec confiance plutôt qu’avec appréhension.

Sources

• KiCad 10.0.7 Release — kicad.org, octobre 2026
• KiCad Version 10.0.7 Release Candidate 2 Available — kicad.org, 3 octobre 2026
• KiCad Version 10.0.7 Release Candidate 1 Available — kicad.org, 27 septembre 2026
• KiCad 10.0.6 Release — kicad.org, 29 août 2026
• KiCad Version 10.0.6 Release Candidate 1 Available — kicad.org, 18 août 2026
• Version 10.0.0 Released — kicad.org, mars 2026
• KiCad 10.0.4 / 10.0.5 – extremely slow track movement in PCB Editor, 10.0.5 becomes unusable — forum.kicad.info, 12 août 2026
• Altium → KiCad 10 import: "Symbol pin or wire end off connection grid" for almost every pin/wire — forum.kicad.info, 1er septembre 2026
• Local power labels – how? — forum.kicad.info, 3 août 2026
• KiCad 10.0.6 на русском скачать — 1progs.ru, 9 septembre 2026
• How To Install KiCad 10.0.6 On Apple Silicon Mac: 2026 Acceptance Guide — NOVAKVM Engineering Blog, 23 septembre 2026
• Как подключить Claude к KiCad 10 — DevTrends, 7 septembre 2026
• KiCad AI in 2026: Copilots, Plugins, and Generators That Actually Work — protoflow.ai, 31 juillet 2026
• KiCad 10 review: new features, high-speed tuning, variants and more — techexplorations.com
• KiCad 10.0 New Features: Importers, Variants, Graphical DRC — electwork.net
• KiCad Releases Version 10.0 with Updates Across Libraries, UI and PCB Design Tools — pcbdirectory.com
• KiCad – Schematic Capture & PCB Design Software — kicad.org
• Download – KiCad — kicad.org
• KiCad — Wikipédia

Article recherché et rédigé automatiquement · Magazine Electrosens