Kicad Master · 5 November 2026

KiCad 10.0.7 boucle la branche : anatomie d’un cycle de maintenance qui ne ralentit pas

On attend d’une nouvelle version qu’elle apporte des fonctionnalités. Mais quand un logiciel de CAO électronique atteint son septième patch de maintenance en sept mois — et que ce patch est enfin publié, le 7 octobre 2026, avec un changelog détaillé à l’appui — la vraie question n’est plus « quoi de neuf ? » mais « peut-on poser un projet de production dessus sans trembler ? ». Plongée dans l’anatomie d’un cycle qui vient de se refermer — et dans ce qu’il révèle, en creux, de la gouvernance du projet.

Un septième patch qui n’a rien d’anodin

Il y a une habitude tenace dans la presse logicielle : traiter chaque incrément de version comme un événement, chercher la nouveauté, la fonctionnalité qui claque, le bouton qui change la vie. C’est un réflexe compréhensible — c’est ce qui fait vendre du papier et cliquer sur des titres. Mais il passe à côté de l’essentiel pour une catégorie de logiciels bien particulière : ceux qu’on utilise pour fabriquer des choses qui coûtent cher et qui ne pardonnent pas l’erreur.

KiCad appartient à cette catégorie. Un logiciel de conception de circuits imprimés n’est pas un éditeur de texte ni un lecteur vidéo : quand un bureau d’études envoie un Gerber chez un fabricant, il engage de l’argent, des délais, parfois la réputation d’un produit entier. Un bug qui fait disparaître une piste, qui déplace un via, ou qui fait planter le routeur interactif au milieu d’une carte à huit couches n’est pas une contrariété — c’est un risque industriel.

C’est pourquoi la publication de la KiCad 10.0.7 Release, le 7 octobre 2026, mérite mieux qu’un haussement d’épaules. Derrière ce numéro anodin se cache une histoire autrement plus intéressante que n’importe quelle nouvelle fonctionnalité : celle d’un projet open source qui a atteint le stade où sa valeur ne se mesure plus à ce qu’il ajoute, mais à ce qu’il tient. Et cette fois, contrairement aux patchs précédents, le projet a livré un changelog circonstancié — nous y reviendrons, car c’est précisément là que se joue la confiance.

Reprenons le fil. KiCad 10.0.0 est sorti en mars 2026. Depuis, six correctifs se sont succédé — 10.0.1 à 10.0.6 — jusqu’à la publication de la 10.0.6 le 29 août 2026, décrite par le projet comme contenant des « critical bug fixes ». Puis la machine de release s’est mise en branle pour le septième : une première Release Candidate le 27 septembre 2026, une seconde le 3 octobre 2026, et enfin la version stable le 7 octobre. Sept mois, sept incréments. Pour un logiciel de CAO utilisé en production, ce rythme n’est ni anodin ni anormal : il est le signe d’un projet vivant qui assume sa maintenance. Encore faut-il savoir lire ce que ces patchs racontent vraiment.

De 10.0.0 à 10.0.7 : radiographie d’un cycle qui s’étire sur sept mois

Posons d’abord les faits, avec leurs limites. La chronologie documentée est la suivante : KiCad 10.0.0 en mars 2026, puis une série de correctifs dont l’existence est confirmée par la liste officielle des releases du miroir GitHub kicad-source-mirror — 10.0.1, 10.0.2, 10.0.3, 10.0.4, 10.0.5, 10.0.6 — sans que les dates précises des versions intermédiaires soient publiquement détaillées dans les sources disponibles. Le seul jalon daté avec certitude avant l’été est la 10.0.6, publiée le 29 août 2026. Viennent ensuite la RC1 du 27 septembre, la RC2 du 3 octobre, et la stable du 7 octobre.

Ce tableau dit déjà quelque chose d’important. Le cycle 10.0.x s’étale sur environ sept mois entre la version majeure et la septième itération, avec une accélération visible en fin de cycle : la 10.0.6 arrive fin août, la RC1 moins d’un mois plus tard, la RC2 six jours après, la stable quatre jours après. C’est le profil classique d’un cycle qui touche à sa fin — on resserre, on stabilise, on prépare le terrain pour la suite. La branche 10.0.x est désormais le terminus : la 10.0.7 en est la version stable officielle, et l’attention se tourne vers la 11.0 dont le rapport d’état 2026 dévoile les contours.

Mais il faut être honnête sur ce qu’on ne sait pas. La comparaison fine avec les cycles 8.0.x et 9.0.x est impossible à mener rigoureusement avec les données publiques disponibles : on sait que les branches 9.0.7, 9.0.8 et 9.0.9 ont existé, ce qui confirme que la politique de maintenance longue n’est pas nouvelle, mais les dates et les contenus ne sont pas documentés dans les sources exploitables. Et surtout, il y a cette réalité longtemps gênante : les notes de release GitHub pour 10.0.1 à 10.0.6 sont des textes génériques, souvent identiques — « bug fixes and other minor improvements » — sans aucune classification CRITICAL / HIGH / MEDIUM / LOW.

Cette opacité méritait qu’on s’y arrête. Pour un projet qui vise l’usage industriel, l’absence de classification publique des sévérités est un angle mort. Un utilisateur qui voyait passer la 10.0.5 ne savait pas s’il devait migrer en urgence parce qu’un crash du routeur avait été corrigé, ou s’il pouvait tranquillement attendre parce qu’il s’agissait d’une faute de frappe dans une infobulle. Cette information existait en interne — elle transite par le jalon GitLab et les issues fermées — mais elle n’était pas exposée. C’est un choix, conscient ou hérité, et il avait des conséquences directes sur la confiance qu’un bureau d’études peut accorder au rythme de publication.

La 10.0.7 marque une inflexion notable sur ce point. L’annonce officielle ne se contente pas du sempiternel « bug fixes and other minor improvements » : elle renvoie vers le jalon 10.0.7 sur GitLab et, surtout, elle publie un changelog structuré par domaine — General, et d’autres sections — avec pour chaque entrée le lien vers l’issue ou le commit correspondant. C’est un progrès réel dans la transparence, même s’il reste partiel : le changelog liste les correctifs sans les classer par sévérité. On sait ce qui a été corrigé ; on ne sait toujours pas à quel point c’était grave. Nuance importante, mais qui change déjà la donne pour qui veut reconstruire l’historique.

Ce qui atterrit vraiment dans un patch : packaging, symboles, et l’art discret du correctif invisible

Que trouve-t-on concrètement dans un cycle de maintenance mature ? La réponse tient en trois familles, et le cas de KiCad 10.0.x les illustre toutes.

La première famille, la plus visible et la plus ingrate : les régressions introduites par la version majeure. C’est la loi du genre. Une version majeure remanie des sous-systèmes entiers, et malgré les tests, des comportements qui fonctionnaient se cassent. Le forum officiel en garde la trace : un fil de discussion documente un problème sérieux de lenteur extrême dans le déplacement de pistes existantes dans l’éditeur PCB en 10.0.4 et 10.0.5, au point que la 10.0.5 est décrite comme « devenue inutilisable » pour cet usage. Voilà le type de régression qui justifie à lui seul un patch — et qui, dans un contexte de production, peut coûter des heures facturées.

La deuxième famille : les bugs de packaging et de distribution. Le cas emblématique du cycle est le correctif étiqueté 10.0.0-1, publié pour corriger un problème de packaging Windows touchant les bibliothèques de symboles. Notez le numéro : ce n’est pas une 10.0.1, c’est un rebuild de la 10.0.0. Autrement dit, le code source était bon, mais l’empaquetage ne l’était pas. Ce genre de correctif est invisible dans les notes de version, échappe à toute classification de sévérité, et pourtant il peut rendre un logiciel inutilisable pour toute une plateforme. C’est le parent pauvre de la communication de release, et c’est précisément là que se joue l’expérience réelle des utilisateurs Windows.

La troisième famille : le durcissement progressif. Des correctifs de coin de table, des cas limites, des comportements erratiques sous conditions rares. Individuellement mineurs, collectivement décisifs : c’est cette accumulation silencieuse qui transforme une version majeure prometteuse en outil de production fiable. Et c’est exactement ce que le changelog de la 10.0.7 rend enfin visible. Prenons quelques entrées de la section « General » pour mesurer la nature de ces correctifs :

• « Fix pasted and newly placed items not appearing until an undo » (#22734) — un bug d’affichage qui, sur le terrain, se traduit par un objet collé qui semble ne pas apparaître : déroutant, voire anxiogène quand on manipule une carte dense.
• « Show the context menu when right clicking a pasted object » (#25287) — une interaction de base qui ne répondait pas dans un cas précis.
• « Keep the search text when the find dialog is reopened » (#25273) — le genre d’ergonomie invisible qui, accumulée, fait la différence entre un outil agréable et un outil irritant.
• « Validate archive file names before extraction » (#25227, #25175) — un correctif de robustesse, sécurité de l’extraction oblige.
• « Don’t automatically close the PCM install from file dialog if plugin extraction fails » — le Plugin and Content Manager, cœur de l’écosystème des extensions, qui échouait silencieusement.
• « Keep embedded fonts when appending a board or importing a sheet » — la préservation des polices embarquées, un détail qui compte pour la cohérence documentaire d’un projet.
• « Reuse a curl handle across HTTP library queries » (#25375) et « Don’t drop HTTP library descriptions » (#25475) — les bibliothèques HTTP, cette infrastructure discrète mais critique pour qui travaille avec des bibliothèques distantes.
• « Guard multiple libraries referencing others during load » (#25420) — la gestion des dépendances entre bibliothèques, zone notoirement fragile.
• « Keep git background work off the shared compute thread pool » (#20703) — un correctif de concurrence qui touche à la réactivité globale de l’application.

Ce florilège dit tout : aucun de ces correctifs ne fera la une. Collectivement, ils font la différence entre un logiciel qu’on subit et un logiciel qu’on utilise. C’est le durcissement progressif en action — et c’est précisément ce que les notes de version génériques des patchs précédents rendaient indiscernable.

Routeur interactif, DRC, tenting PTH, bibliothèques : la carte des zones à risque

Où se situent les zones sensibles d’un cycle de maintenance PCB ? Quatre sous-systèmes concentrent historiquement l’essentiel des risques.

Le routeur interactif d’abord. C’est le cœur battant de l’éditeur PCB, celui qu’on sollicite des centaines de fois par heure. Toute régression de performance y est immédiatement ressentie — le fil du forum sur les lenteurs de déplacement de pistes en 10.0.4/10.0.5 en est la démonstration. Un routeur qui rame, c’est un concepteur qui perd patience, puis des heures. Sur ce front, la 10.0.7 ne promet pas de refonte : elle consolide. Le cycle 10.0.x a surtout fiabilisé un routeur dont la promesse initiale — un push-and-shove fluide — a demandé des mois de réglages.

La vérification des règles de conception (DRC) ensuite. Elle est le filet de sécurité : si elle laisse passer une violation de clearance, c’est la carte fabriquée qui est mauvaise. Les régressions y sont rares mais catastrophiques, car elles sont silencieuses — un DRC qui ne signale plus un problème ne fait pas de bruit. KiCad 10 a par ailleurs introduit un éditeur graphique de règles DRC, qui raisonne désormais en nanosecondes pour les cartes rapides : un changement de paradigme qui rend d’autant plus critique la stabilité de ce sous-système.

Le tenting des pads PTH — cette fine pellicule de masque qui recouvre les vias et les trous métallisés — relève de la même logique : un paramètre mal interprété et c’est toute une série de cartes qui part en fabrication avec un défaut esthétique ou fonctionnel. C’est le genre de détail qui ne se voit qu’à la réception des cartes.

La gestion des bibliothèques, enfin, est probablement la zone la plus exposée de tout l’écosystème — et le cycle 10.0.x le confirme avec le correctif de packaging 10.0.0-1, mais aussi avec les entrées « HTTP library » et « multiple libraries referencing others » du changelog 10.0.7. Les bibliothèques de symboles et d’empreintes sont massives, versionnées séparément (les KiCad Footprints officiels ont d’ailleurs leur propre cycle de tags, jusqu’à 10.0.7-rc1), et leur cohérence entre plateformes est un défi permanent.

Il faut ici être clair sur une limite : les sources publiques disponibles ne documentent pas de régressions spécifiques nommées sur le routeur interactif, le DRC ou le tenting PTH pour ce cycle précis. On peut seulement constater que ces sous-systèmes sont structurellement les plus sensibles, que le correctif de packaging Windows touche bel et bien les bibliothèques, et que le changelog 10.0.7 confirme que les bibliothèques (HTTP, dépendances croisées) restent un chantier actif.

D’où une méthode, plutôt qu’une attente déçue. Puisque la communication officielle ne classe pas les correctifs par sévérité, reconstruisez l’historique vous-même. Le blog officiel fournit un lien vers la liste des issues fermées pour le jalon 10.0.7 sur GitLab : c’est la source la plus proche de la vérité, car elle liste les tickets réellement traités. Croisez-la avec les fils du forum officiel, où les utilisateurs décrivent leurs symptômes en langage naturel — lenteurs, plantages, comportements étranges. Cette veille manuelle prend une heure par cycle, mais elle vaut mieux que n’importe quelle note de version générique. Et avec le changelog détaillé de la 10.0.7, vous avez désormais un point de départ solide : chaque entrée renvoie à une issue, que vous pouvez lire pour juger de la gravité réelle.

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

Un cycle de maintenance ne se juge pas seulement au code : il se juge à la capacité du projet à livrer ce code proprement, partout, au même moment. Et c’est là que les choses deviennent intéressantes.

Les canaux de distribution officiels des Release Candidates incluent, selon l’annonce du projet : Windows x86_64, Windows arm64, macOS, AppImage Linux, le PPA Ubuntu 10.0 testing, la branche beta Flathub, et le COPR Fedora @kicad/kicad-testing. Cette diversité est une force — elle reflète la réalité d’une communauté multi-plateformes — mais elle est aussi une source de complexité redoutable.

Le cas d’Arch Linux est instructif : le paquet kicad 10.0.6-2 est disponible dans le dépôt extra, avec un numéro de build (-2) qui trahit un repackaging local. Autrement dit, le mainteneur Arch a dû retoucher le paquet après sa publication initiale — exactement le même phénomène que le 10.0.0-1 côté Windows, mais à un autre étage de la chaîne. C’est la preuve que la distribution n’est pas un détail logistique : c’est un métier à part entière, exercé par des bénévoles ou des mainteneurs de distribution, avec ses propres délais et ses propres ratés.

Le cas macOS mérite lui aussi un détour. Un guide de validation dédié à l’installation de KiCad 10.0.6 sur Mac Apple Silicon a été publié le 23 septembre 2026 — signe que la plateforme Apple, longtemps parent pauvre de l’écosystème CAO, est désormais traitée avec sérieux, jusqu’à la vérification de l’architecture et des workflows Gerber/3D à distance. La 10.0.7 suit le mouvement avec des paquets macOS annoncés « disponibles ou dans un futur très proche » selon l’annonce officielle.

Ce que révèle ce tableau, c’est une asymétrie structurelle : les canaux de test (PPA, Flathub beta, COPR) reçoivent les RC en avance, tandis que les canaux de production (winget, Arch extra, ALT) accueillent la stable avec un décalage variable. Pour un bureau d’études, cela signifie qu’il faut choisir consciemment son canal : rester sur le stable pour la production, basculer sur un canal de test pour valider une RC avant de la déployer. Et surtout, ne jamais supposer qu’une version est « partout » au même moment — la propagation d’un manifeste winget ou d’un paquet de distribution prend des jours, parfois plus.

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

Un cycle de maintenance n’est jamais un objet isolé. Il baigne dans un écosystème, et celui de KiCad en 2026 a changé d’échelle. Trois signaux récents le confirment.

D’abord, l’IA qui s’invite dans le flux PCB. Un plugin natif nommé Konnect, binaire Rust unique, permet à Claude et à d’autres assistants de concevoir schémas et circuits imprimés via le protocole MCP, avec pas moins de 228 outils exposés — l’information a circulé le 14 octobre 2026 et a été relayée jusqu’à Adafruit le 26 octobre. Ce n’est plus une expérimentation de laboratoire : c’est un pont concret entre un LLM et KiCad 10, qui vient s’ajouter aux briques natives (tuning haute vitesse, variantes de conception, DRC graphique) déjà présentes dans la version majeure. Pour le concepteur, cela redessine le workflow : génération de squelette de schéma, vérification assistée, routage suggéré. Pour le mainteneur, cela pose une nouvelle question : comment garantir qu’un plugin qui parle à un modèle externe ne corrompe pas un projet de production ? La stabilité de la branche 10.0.x devient alors une condition sine qua non de l’écosystème IA.

Ensuite, la communauté qui se retrouve. La quatrième conférence asiatique KiCon se tiendra à Shenzhen du 5 au 7 novembre 2026, au Huaqiang Plaza Hotel — annonce publiée le 16 septembre 2026. C’est un marqueur de maturité : un projet open source qui tient une conférence annuelle sur un continent majeur n’est plus un projet de niche. Et c’est aussi l’occasion, pour les mainteneurs, de recueillir en direct les retours de terrain qui nourriront la 11.0.

Enfin, les outils périphériques qui se professionnalisent. Côté cotation, AIVON a présenté le 15 septembre 2026 un outil de devis de fabrication instantané depuis KiCad — le genre de brique qui rapproche le logiciel du flux industriel complet. Côté scripts, des solutions comme la génération de grilles de vias de stitching reliés à la masse par script (13 septembre 2026) montrent que la communauté comble les manques fonctionnels par l’automatisation. Côté matériel, l’intégration 3Dconnexion (SpaceMouse, CadMouse) est désormais documentée officiellement, ce qui change le confort de routage au quotidien.

Tout cela dessine un KiCad 10 qui n’est plus seulement un logiciel : c’est une plateforme. Et une plateforme se juge à la solidité de ses fondations — c’est-à-dire, précisément, à la qualité de ses cycles de maintenance.

Ce qu’il faut retenir pour votre projet, en cette fin octobre 2026

La 10.0.7 est sortie le 7 octobre 2026. Elle contient, selon l’annonce officielle, « several critical bug fixes » et le projet recommande explicitement de mettre à jour dès que possible. C’est un signal clair : ne restez pas sur 10.0.6 si vous êtes en production.

Trois recommandations concrètes, tirées de l’analyse du cycle :

1. Lisez le changelog 10.0.7, pas seulement le numéro de version. C’est le premier patch du cycle à offrir un changelog structuré avec liens vers les issues. Profitez-en : pour chaque correctif qui touche votre usage (routeur, bibliothèques, PCM, polices embarquées), ouvrez l’issue liée et jugez de la gravité réelle. C’est la seule façon de compenser l’absence de classification CRITICAL/HIGH/MEDIUM/LOW.

2. Choisissez votre canal consciemment. Si vous êtes en production, restez sur le stable (winget, Arch extra, ALT) et attendez la propagation. Si vous voulez tester en avance, basculez sur le PPA Ubuntu testing, la branche beta Flathub ou le COPR Fedora testing — mais jamais sur une machine qui fabrique des cartes.

3. Anticipez la suite. La branche 10.0.x est désormais au terminus : la 10.0.7 en est la version stable officielle, et l’attention se tourne vers la 11.0. Si vous êtes encore sur 9.x, sachez que cette branche a perdu son filet de sécurité depuis mars 2026 — plus de correctifs de maintenance. C’est le moment de planifier la migration, pas de la repousser.

Reste une question de fond, que ce cycle laisse ouverte. KiCad a prouvé qu’il savait tenir une branche sur sept mois, avec sept incréments, deux RC et une stable. Il a même commencé à documenter sérieusement ses correctifs. Mais il n’a pas encore franchi le pas de la classification publique des sévérités — ce qui, pour un outil qui prétend à l’usage industriel, reste un angle mort. La 11.0 sera l’occasion de vérifier si le projet comble cette lacune. En attendant, la 10.0.7 fait le job : elle tient. Et pour un logiciel de CAO électronique, tenir, c’est déjà beaucoup.

Sources

• KiCad 10.0.7 Release — annonce officielle du 7 octobre 2026, avec changelog détaillé et lien vers le jalon GitLab.
• KiCad Version 10.0.7 Release Candidate 2 Available — 3 octobre 2026.
• KiCad Version 10.0.7 Release Candidate 1 Available — 27 septembre 2026.
• KiCad 10.0.6 Release — 29 août 2026.
• Miroir GitHub kicad-source-mirror — releases — liste des versions 10.0.1 à 10.0.6.
• Jalon GitLab 10.0.7 — liste des issues fermées pour la 10.0.7.
• KiCad Footprints — tags GitLab — cycle de versionnement des bibliothèques d’empreintes.
• KiCad Conference Asia 2026 Announcement — KiCon Shenzhen, 5-7 novembre 2026.
• Konnect : conception de PCB assistée par IA pour KiCad 10 — 14 octobre 2026 ; relayé par Adafruit le 26 octobre 2026.
• Comment installer KiCad 10.0.6 sur un Mac Apple Silicon : guide de validation 2026 — 23 septembre 2026.
• Créer une grille de vias de stitching avec un script — 13 septembre 2026.
• Altium → KiCad 10 import : « Symbol pin or wire end off connection grid » — 1er septembre 2026, retour de terrain sur l’import Altium 25.6.2 vers KiCad 10.0.6.
• 3Dconnexion — page officielle dédiée à KiCad — intégration SpaceMouse et CadMouse.

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