Kicad Master · 7 November 2026

KiCad 10.0.6 : ce que six mois de terrain ont vraiment changé dans le quotidien du concepteur PCB

La 10.0.0 est arrivée en mars 2026 avec sa cohorte de promesses. Six mois, six correctifs et une 10.0.7 déjà sortie plus tard, le recul est enfin suffisant pour trier ce qui a tenu dans l’atelier de ce qui est resté sur la slide de lancement. Voici le bilan honnête d’une branche qui a surtout appris à ne plus casser.

Six mois après la 10.0.0 : pourquoi le vrai bilan commence maintenant

Il y a une illusion propre aux sorties majeures de logiciels : celle du jour J. Le 10 mars 2026 — date de la Version 10.0.0 Released — tout le monde a commenté les annonces, les captures d’écran, les promesses de refonte. Puis le silence relatif est retombé, et le logiciel a repris sa vie réelle : celle des projets qui plantent à 23 h, des Gerbers qui sortent avec une couche en trop, des bibliothèques qui ne trouvent pas leur empreinte.

C’est cette vie réelle que raconte la branche 10.0.x. Entre la 10.0.0 de mars et la 10.0.6 du 29 août 2026, l’équipe KiCad a publié six correctifs. Et le cycle ne s’est pas arrêté là : la 10.0.7 est sortie le 7 octobre 2026, précédée de deux release candidates les 27 septembre et 3 octobre — un détail qui a son importance pour la suite de cet article.

La méthode de ce décryptage mérite d’être posée d’emblée, parce qu’elle est contrainte. Les notes de version officielles de KiCad sont, par tradition, extrêmement sobres : la formule « contains critical bug fixes and other minor improvements since the previous release » revient à chaque patch, sans détailler quels bugs, ni de quelle nature. Le détail se trouve dans le dépôt GitLab, dans les rapports de bugs, dans les fils du forum — des sources que nous ne pouvons pas citer exhaustivement ici. Là où les sources publiques restent muettes, nous le dirons explicitement plutôt que de combler les trous par extrapolation. C’est la règle du jeu.

Ce que l’on peut affirmer sans risque, en revanche, c’est la structure du cycle : six patchs en cinq mois et demi, un rythme d’environ un correctif par mois, avec une accélération notable en fin de cycle (10.0.6 fin août, 10.0.7 début octobre). Ce rythme, à lui seul, est un indicateur. Une branche qui publie aussi régulièrement est une branche qui encaisse des retours de terrain et qui les traite — pas une branche qui laisse pourrir ses régressions jusqu’à la version suivante.

10.0.1 → 10.0.6 : la chronologie des patchs, lue comme une priorisation

Posons d’abord ce que l’on sait avec certitude, et ce que l’on ignore. Les dates de la 10.0.0 (mars 2026) et de la 10.0.6 (29 août 2026) sont documentées par les annonces officielles. Les dates intermédiaires des 10.0.1 à 10.0.5 ne sont, elles, pas fournies par les sources dont nous disposons — et nous ne les inventerons pas. Ce que l’on sait, c’est le point d’arrivée : la 10.0.6, décrite par l’équipe comme contenant « critical bug fixes and other minor improvements ».

Cette formule, répétée à chaque release, est plus informative qu’elle n’y paraît. Elle distingue explicitement deux catégories : les critical bug fixes d’un côté, les minor improvements de l’autre. C’est la taxonomie officielle de l’équipe, et elle révèle une hiérarchie claire. Le critique d’abord — plantages, corruptions de fichiers, régressions qui empêchent de travailler. Les finitions ensuite — interface, traductions, messages d’erreur, ces « minor improvements » qui rendent l’outil agréable sans le rendre fonctionnel.

Ce tableau dit une chose essentielle : la branche 10.0 n’est pas une version « à moitié cuite qu’on rattrape ». C’est une version majeure qui a suivi le cycle de maintenance attendu, avec une phase de release candidates pour la 10.0.7 qui montre que l’équipe ne pousse plus de correctifs à l’aveugle. La mention « Version 10.0.7 will be released soon unless critical issues are found in testing this release candidate » est un signal de maturité : on teste avant de diffuser, on ne diffuse pas parce que la date est arrivée.

Là où les sources publiques ne permettent pas de trancher, c’est sur la répartition exacte entre correctifs critiques et finitions dans chaque patch. On sait que la 10.0.6 contient les deux, on ne sait pas dans quelle proportion. On sait que l’équipe qualifie certains correctifs de « critiques », on ne sait pas lesquels. Cette opacité relative n’est pas un défaut de transparence — les rapports de bugs GitLab sont publics — mais un choix de communication : les release notes officielles sont des annonces, pas des journaux de commits.

Du schéma au routage : ce que les patchs ont réellement stabilisé

C’est ici que le terrain parle le plus fort, et paradoxalement, c’est ici que la matière manque le plus. Les sources dont nous disposons ne détaillent pas, fonction par fonction, ce qui a été corrigé sur l’éditeur de règles DRC, le push-and-shove ou la gestion des classes de net au fil des 10.0.x. Nous ne pouvons donc pas dresser le tableau fin « nouvelle fonction en 10.0.0 / corrigée en 10.0.x / encore perfectible » que le sujet mériterait. Mais nous pouvons dire ce que le terrain, lui, a retenu.

Le premier point de friction documenté, et il est révélateur, concerne l’import Altium. Un fil du forum KiCad daté du 1er septembre 2026 — soit trois jours après la 10.0.6 — rapporte un problème très concret : la migration d’un projet Altium 25.6.2 vers KiCad 10.0.6 déclenche un avertissement ERC quasi systématique, « Symbol pin or wire end off connection grid », sur presque chaque broche de symbole et chaque extrémité de fil. Autrement dit : l’import fonctionne, mais il livre un schéma qui échoue au contrôle électrique. Ce n’est pas un crash, ce n’est pas une corruption de fichier — c’est une régression de workflow, la plus insidieuse qui soit, parce qu’elle n’empêche pas de travailler mais impose une passe de nettoyage manuelle sur chaque symbole importé.

Ce cas illustre parfaitement ce que six mois de terrain ont changé — et ce qu’ils n’ont pas changé. La branche 10.0 a rendu l’import Altium utilisable ; elle ne l’a pas rendu transparent. Et la 10.0.6, malgré ses « critical bug fixes », ne corrige pas ce point précis, puisque le rapport date d’après sa sortie. C’est le genre de détail qui compte quand on évalue une migration : l’outil vous dit « import réussi », l’ERC vous dit « pas si vite ».

Sur le routage lui-même, un autre signal mérite l’attention, même s’il ne concerne pas KiCad directement : la régression documentée de Freerouting 2.3.0 le 28 août 2026, qui produit des routes que son propre scoring signale comme violant les clearances, là où la 2.2.4 routait proprement. Pourquoi en parler ? Parce que beaucoup de concepteurs KiCad utilisent Freerouting en complément du routeur interactif. Quand l’écosystème périphérique régresse au moment même où la branche principale se stabilise, le bilan net pour l’utilisateur est plus mitigé que ne le laisse croire la seule lecture des release notes KiCad.

Sur le push-and-shove et les classes de net, en revanche, il faut être honnête : les sources publiques consultées ne documentent pas de correctifs spécifiques au fil des 10.0.x. Cela ne signifie pas qu’il n’y en a pas eu — cela signifie qu’ils n’ont pas fait l’objet d’une communication distincte. La prudence commande de ne pas conclure.

Gerbers, perçage, BOM, placement : la ligne de faille de la mise en fabrication

C’est le chapitre où le silence des sources est le plus assourdissant, et où il faut le dire clairement : nous ne disposons d’aucun retour documenté de JLCPCB, PCBWay, Seeed, Aisler ou d’un assembleur type Macrofab sur des problèmes spécifiques à KiCad 10.0.x. Aucun bug de génération Gerber, drill, BOM ou fichier de placement n’est référencé dans les sources consultées. Ce n’est pas une affirmation d’absence de bug — c’est un constat de lacune documentaire.

Ce que l’on peut affirmer, en revanche, c’est la nature structurelle du risque. La chaîne de sortie fabrication est celle où une régression coûte le plus cher : un Gerber avec une couche mal nommée, un fichier Excellon avec une unité mal interprétée, un BOM dont une colonne a bougé, et c’est un lot de cartes à refaire. Or cette chaîne dépend de deux choses que KiCad ne contrôle pas : les parseurs des fabricants, et la compatibilité des formats.

Le point de vigilance concret, pour un atelier qui envoie en production depuis la 10.0.6, tient en trois vérifications qui restent manuelles quel que soit le numéro de patch :

• Gerber : vérifier la présence et le nommage de toutes les couches attendues, y compris les couches mécaniques et le contour. La compatibilité X2/X3 avec les parseurs des fabricants n’est pas garantie par KiCad — elle dépend du fabricant.
• Perçage (Excellon) : contrôler les unités et le format des coordonnées avant envoi. Un fichier drill qui « passe » chez un fabricant peut être rejeté chez un autre.
• BOM et placement (.pos) : vérifier que les colonnes attendues par l’assembleur sont bien présentes et dans le bon ordre. Un BOM CSV ou XML syntaxiquement valide peut être sémantiquement inutilisable pour une machine de placement.

La bonne nouvelle, c’est que six mois de terrain ont au moins ancré ce réflexe dans la communauté : la vérification manuelle avant envoi n’est plus vue comme un aveu de faiblesse de l’outil, mais comme une étape normale du flux. La mauvaise, c’est qu’aucune source ne permet d’affirmer que la 10.0.6 a réduit le nombre de ces vérifications nécessaires.

Bibliothèques, gros projets, DRC : les trois frictions qui n’ont pas disparu en 10.0.6

Trois zones de friction persistent, et il faut les nommer sans détour.

Les bibliothèques. Le dépôt officiel des footprints KiCad est actif sur GitLab — les tags consultés fin septembre et mi-octobre 2026 montrent une activité continue, y compris des tags liés à la 10.0.7-rc1 le 22 septembre. C’est un bon signe : les bibliothèques suivent le rythme des releases. Mais l’activité du dépôt ne dit rien de la complétude ni de la qualité des symboles et empreintes. Les sources consultées ne documentent pas d’état des lieux chiffré : combien de symboles manquants, combien d’empreintes erronées, combien de composants référencés sans modèle 3D associé. C’est une lacune réelle, et elle est structurelle : la qualité des bibliothèques se mesure dans l’usage, pas dans un changelog.

Les performances sur gros projets. Aucune source consultée ne fournit de chiffres sur le temps d’ouverture d’un projet, le temps de reroutage, la consommation mémoire, ou le nombre de couches et de nets à partir duquel les performances se dégradent. La page d’accueil officielle évoque des schémas hiérarchiques de « centaines de feuilles » et des conceptions PCB « complexes modernes » — un argumentaire marketing daté (le copyright affiché est « © 2018-2020 1BitSquared »), qui ne peut pas servir de référence pour la 10.0.6. On ne peut donc pas trancher sur ce point, et c’est frustrant, car c’est précisément la question que se pose tout concepteur qui hésite à migrer un projet dense.

Le DRC. Là encore, les sources publiques ne documentent ni faux positifs récurrents, ni lenteur sur designs denses, ni régression spécifique au fil des 10.0.x. Le seul signal concret dont on dispose est l’avertissement ERC à l’import Altium mentionné plus haut — un faux positif de fait, puisqu’il porte sur des connexions qui sont électriquement correctes mais géométriquement hors grille. C’est un indice : la chaîne de vérification de KiCad 10.0.6 reste sensible aux géométries importées, et l’utilisateur qui migre d’Altium doit s’attendre à un nettoyage.

Ce tableau n’est pas confortable, et c’est le but. Il dit ce que six mois de terrain ont permis de vérifier — et ce qu’ils n’ont pas permis de trancher, faute de données publiques.

Ce que les patchs disent sans le dire : la philosophie de maintenance de l’équipe KiCad

La lecture de la trajectoire 10.0.x est instructive, même à travers le prisme étroit des release notes. Trois traits se dégagent.

Premier trait : la priorité au flux de production. La formule « critical bug fixes » revient à chaque release, et la 10.0.7 a même attendu deux release candidates avant diffusion. Cela signifie que l’équipe considère comme bloquant tout ce qui empêche de produire — plantages, corruptions, régressions qui cassent un flux — et comme non bloquant tout le reste. Les finitions attendent.

Deuxième trait : la correction des régressions avant l’ajout de fonctionnalités. Sur une branche de maintenance, c’est la norme ; mais le rythme adopté — un patch par mois environ, avec accélération en fin de cycle — montre que l’équipe ne laisse pas s’accumuler une dette de correctifs. La 10.0.7 sortie le 7 octobre, un mois après la 10.0.6, confirme cette dynamique : le cycle ne s’arrête pas à la 10.0.6, il continue.

Troisième trait : la transparence partielle. Les release notes officielles sont sobres ; le détail est dans GitLab. C’est un choix qui a un coût : le concepteur qui veut savoir ce qui a été corrigé doit aller fouiller les rapports de bugs. Mais c’est aussi un choix qui a un avantage : il évite de promettre plus que ce qui a été livré.

Comparé aux cycles de maintenance des branches précédentes, ce rythme est cohérent avec la tradition KiCad : des releases de correctifs régulières, des release candidates pour les versions de maintenance importantes, une communication centrée sur la stabilité plutôt que sur les nouveautés. La branche 10 n’invente pas un nouveau modèle ; elle applique l’ancien avec discipline. C’est précisément ce qu’on attend d’une version majeure arrivée à mi-vie.

Migrer maintenant, attendre 10.0.7 ou viser 10.1 ? Le verdict nuancé

Le verdict dépend du profil, et il serait malhonnête de le rendre uniforme.

Concepteur solo sur petits projets. Migrez. La branche 10.0 est stabilisée, la 10.0.6 a consolidé les flux critiques, et la 10.0.7 est déjà disponible depuis le 7 octobre 2026. Le risque résiduel — bibliothèques, DRC — se gère par la vérification manuelle avant envoi en fabrication, qui reste de toute façon nécessaire. Attendre la 10.1 n’apporterait rien de décisif pour ce profil.

Équipe sur designs multicouches à forte densité. Migrez, mais avec un plan de validation. Les performances sur gros projets ne sont pas documentées dans les sources publiques, ce qui signifie qu’il faut les tester soi-même sur un projet représentatif avant de basculer toute l’équipe. Le point de vigilance n’est pas la stabilité — elle est acquise — mais le comportement sur vos designs les plus denses. Si vous êtes déjà en 10.0.x, la 10.0.7 est un patch de maintenance à appliquer sans hésiter ; si vous êtes encore sur une branche antérieure, la migration mérite un projet pilote.

Atelier qui envoie en fabrication chez des assembleurs. C’est le profil pour lequel la prudence est la plus justifiée — non pas à cause de KiCad, mais à cause du silence des sources sur les retours fabricants. Aucun retour documenté de JLCPCB, PCBWay, Seeed ou d’un assembleur n’est disponible pour la 10.0.x. La conséquence pratique est simple : maintenez la double vérification manuelle des Gerbers, du drill, du BOM et du placement avant chaque envoi, et ne supposez pas que la 10.0.6 a supprimé ce besoin. Ce n’est pas un défaut de KiCad ; c’est la réalité de toute chaîne de fabrication.

Le scénario où attendre est raisonnable, c’est celui d’une équipe qui n’a pas les moyens de faire un projet pilote et qui travaille sur des designs très denses : dans ce cas, attendre la 10.1 — ou au moins un retour d’expérience documenté sur des projets comparables — est une décision défendable. Pour tous les autres, la 10.0.6 (ou la 10.0.7) est un point d’atterrissage solide.

Après la 10.0.6 : ce que la suite change pour l’écosystème KiCad

Six mois de terrain sur la branche 10 laissent entrevoir trois dynamiques pour la suite.

La première est la pression sur les performances et les bibliothèques. C’est là que les sources publiques sont les plus muettes, et c’est donc là que les attentes de la communauté sont les plus fortes. Une 10.1 qui apporterait des chiffres publics sur le comportement en gros projets — temps d’ouverture, mémoire, reroutage — répondrait à une demande réelle. De même, un état des lieux documenté de la qualité des bibliothèques serait un signal fort.

La deuxième est la place croissante de l’écosystème tiers. Konnect, le plugin natif KiCad 10 en Rust qui expose 228 outils via MCP pour piloter Claude dans la conception de schémas et de circuits, illustre une tendance de fond : KiCad devient une plateforme, pas seulement un outil. Les articles d’Adafruit (26 octobre 2026) et de Fellow (14 octobre 2026) sur le sujet montrent que cette dynamique est suivie de près. La branche 10.0.x a stabilisé le socle ; c’est ce socle stabilisé qui rend possible l’écosystème de plugins.

La troisième est le déplacement du regard du concepteur. Jusqu’ici, on surveillait les annonces de lancement. Désormais, l’information utile est dans le cycle de maintenance : les release notes de patch, les release candidates, les rapports de bugs. C’est moins spectaculaire, mais c’est là que se joue la fiabilité au quotidien. La 10.0.7, sortie le 7 octobre 2026 après deux release candidates, en est l’illustration : ce n’est pas une annonce, c’est un correctif — et c’est précisément ce dont un concepteur a besoin.

Reste une question ouverte, et elle est importante : la 10.1. Les sources consultées n’en donnent ni date ni contenu. Tout ce que l’on peut dire, c’est que la branche 10.0 a rempli son contrat de maintenance — six patchs en cinq mois et demi, une 10.0.7 déjà là, un rythme régulier. C’est la base sur laquelle la 10.1 pourra se construire. Et c’est, au fond, la meilleure nouvelle que six mois de terrain pouvaient apporter : une version majeure qui a appris à ne plus casser.

Sources

• KiCad – Schematic Capture & PCB Design Software
• Release Notes | KiCad
• Version 10.0.0 Released – KiCad
• KiCad 10.0.6 Release
• KiCad | 10.0 | English | Documentation | KiCad
• Download – KiCad
• Downloads | KiCad EDA
• KiCad – Wikipedia
• Tags · KiCad / KiCad Libraries / KiCad Footprints · GitLab
• Altium → KiCad 10 import: "Symbol pin or wire end off connection grid" (forum.kicad.info, 1er septembre 2026)
• Konnect : conception de PCB assistée par IA pour KiCad 10 (fellow.news, 14 octobre 2026)
• KiCad vs LibrePCB vs Horizon EDA in 2026 (pistack.xyz, 28 septembre 2026)
• The 2026 PCB Design Software List: KiCad, Altium, and EasyEDA Compared (electricalflux.com, 9 septembre 2026)

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