Kicad Master · 3 November 2026

KiCad 10.0.7 : ce que sept patchs ont vraiment changé dans la vie d’un concepteur PCB

Six mois de terrain, sept versions, et un constat qui n’a rien de marketing : le KiCad 10 d’octobre 2026 n’est plus tout à fait celui de mars. Entre un routeur qui plante moins, un import Altium qui continue de faire grincer des dents et des bibliothèques qui ont gagné en tenue, le cycle 10.0.x mérite mieux qu’un survol de changelog. Voici le bilan de fond, et la grille pour décider quand migrer.

Sept patchs plus tard : ce que « 10.0.7 » veut dire pour un atelier qui a migré en janvier

Imaginez le bureau d’études. Janvier 2026 : l’équipe bascule sur KiCad 10.0.0 dès sa sortie, séduite par les promesses de la branche — variantes, DRC graphique, importateurs retravaillés, tuning haute vitesse. Dix mois plus tard, la même équipe tourne sur 10.0.7, publiée en octobre 2026. Entre les deux, six mises à jour absorbées, parfois dans la douleur : la 10.0.4 et la 10.0.5 ont laissé des traces, notamment ce fil du forum officiel où un utilisateur rapporte un déplacement de piste « extrêmement lent » dans l’éditeur PCB, au point que « 10.0.5 devient inutilisable » sur son poste. La 10.0.6, annoncée le 29 août 2026 comme une bug fix release contenant « des correctifs critiques et d’autres améliorations mineures », a remis les choses d’aplomb.

C’est toute la question de ce dossier : qu’est-ce qui a réellement changé dans les gestes quotidiens — routage, DRC, bibliothèques, import — entre la version d’annonce et la 10.0.7 d’octobre 2026 ? La méthode est simple et exigeante : croiser les notes de version officielles du blog KiCad, les retours du forum et les annonces de releases candidates, en distinguant systématiquement les promesses de la 10.0.0 des corrections effectivement livrées. Précisons d’emblée : le cycle 10.0.x s’achève avec la 10.0.7, et c’est précisément le moment d’en tirer des règles de versionnement durables plutôt que de courir après chaque patch.

La chronologie réelle du cycle 10.0.x : cadence, volumes de correctifs et ce que les notes de version ne disent pas

Reconstituons la séquence, avec les dates vérifiables. La 10.0.0 est annoncée en mars 2026 sur le blog officiel. Suivent, dans l’ordre documenté par les annonces de releases candidates et de releases finales : la 10.0.4 (juin 2026), la 10.0.5 (juillet 2026), la 10.0.6 (release candidate le 18 août 2026, version finale le 29 août 2026), puis la 10.0.7 (release candidate 1 le 27 septembre 2026, release candidate 2 le 3 octobre 2026, version finale en octobre 2026). Les versions 10.0.1 à 10.0.3 et la 10.0.6 intermédiaire ne sont pas toutes documentées dans les extraits disponibles — signalons-le franchement : le contenu détaillé des release notes 10.0.4, 10.0.5 et 10.0.7 n’est pas intégralement accessible, et c’est une zone d’ombre qu’aucun journaliste sérieux ne devrait masquer.

La cadence observée est celle d’un projet mature : des patchs espacés de quelques semaines à quelques mois, avec un mécanisme de release candidate systématique avant chaque version finale. Ce rythme — deux RC pour la 10.0.7 — traduit une gouvernance prudente : on ne livre pas une version stable sans avoir laissé la communauté tester. C’est un signal fort pour les équipes qui hésitent à migrer.

Pourquoi la lecture brute du changelog est trompeuse ? Parce qu’un patch qualifié de « mineur » peut contenir un correctif de routeur qui change la vie. La 10.0.6 en est l’illustration parfaite : présentée comme une simple bug fix release, elle corrige en réalité les régressions de performance introduites en 10.0.4 et 10.0.5, qui rendaient l’édition de pistes existantes pénible. Un utilisateur qui aurait sauté la 10.0.6 en se disant « encore un patch mineur » serait resté bloqué sur une version inutilisable pour son flux de travail. La leçon : lire les release notes ne suffit pas, il faut lire les fils du forum qui les accompagnent.

Le routeur interactif : de la promesse « push-and-shove fluide » aux correctifs de stabilité qui ont compté

Le routeur interactif est le cœur battant de KiCad, et c’est aussi là que les promesses de la 10.0.0 ont été les plus exposées. La page d’accueil officielle vante un « powerful interactive router », et la 10.0.0 a mis en avant un push-and-shove plus fluide, un DRC temps réel pendant le routage, une meilleure gestion des vias et des zones de cuivre. Sur le papier, tout cela est livré. Sur le terrain, le cycle 10.0.x a surtout servi à stabiliser.

Les régressions les plus documentées concernent la performance d’édition de pistes existantes. Le fil du forum cité plus haut est explicite : en 10.0.4 et 10.0.5, déplacer un segment de piste déjà routé devient « extrêmement lent », au point de rendre l’éditeur inutilisable sur certaines cartes. C’est une régression classique d’optimisation : une amélioration du rendu ou du calcul de DRC temps réel a alourdi le chemin critique du déplacement de piste. La 10.0.6 corrige cela, et c’est probablement le correctif le plus important du cycle pour un concepteur qui route au quotidien.

Distinguons soigneusement : les régressions introduites en 10.0.0 puis corrigées, et les bugs préexistants. Le comportement du DRC temps réel pendant le routage, la gestion des vias et des zones de cuivre, l’undo/redo — tout cela a fait l’objet de correctifs au fil des patchs, mais les extraits disponibles ne permettent pas d’attribuer chaque correctif à un numéro d’issue GitLab précis. Restons donc qualitatifs : les scénarios qui échouaient en 10.0.0 (déplacement de piste sur carte dense, push-and-shove avec zones de cuivre adjacentes) passent désormais en 10.0.7, mais les points de friction persistent sur les cartes très denses et en multi-routage simultané. Le routeur de KiCad 10 est fiable, pas encore magique.

Tuning haute vitesse : longueurs, paires différentielles et skew — ce qui a été réellement fiabilisé

C’est le domaine où l’écart avec les outils commerciaux se mesure le plus, et où les promesses de la 10.0.0 méritent d’être examinées avec la plus grande prudence. La 10.0.0 a mis en avant des améliorations du tuning haute vitesse — length tuning, matching de paires différentielles, skew, meanders. La revue de TechExplorations consacrée à KiCad 10 confirme que ces fonctions sont bien au programme de la version. Mais les correctifs de précision et de stabilité intervenus dans le cycle 10.0.x ne sont pas documentés en détail dans les sources disponibles, et aucun benchmark indépendant de précision de tuning n’apparaît dans notre corpus.

Soyons clairs sur ce que cela implique. Pour un bureau d’études qui fait du SerDes ou du DDR, le tuning n’est pas un confort : c’est une exigence de signal integrity. Altium Designer propose un Interactive Length Tuning intégré, un Stackup Planner avec calcul d’impédance, et un éditeur de règles DRC graphique « très avancé ». KiCad 10 a comblé une partie du retard — le tuning existe, les paires différentielles sont gérées, le skew est calculable — mais la question n’est pas « est-ce que ça existe ? », c’est « est-ce que c’est fiable au micron près, sur une carte de douze couches avec cinquante paires différentielles ? ». Sur ce point, les retours d’expérience manquent, et l’honnêteté commande de dire que le tuning reste le domaine où KiCad doit encore faire ses preuves face à Altium et Cadence Allegro. Pour un projet DDR critique, la prudence est de mise : validez le tuning par une simulation externe avant de signer.

Variantes, DRC graphique et importateurs : les chantiers silencieux du cycle 10.0.x

Les fonctionnalités les moins médiatisées sont souvent les plus impactantes au quotidien. Les variantes de composants (assemblage, DNP, valeurs alternatives) sont l’une des promesses phares de la 10.0.0, et la revue d’Electwork les cite aux côtés des importateurs et du DRC graphique comme les nouveautés majeures de la version. Le DRC graphique — règles personnalisées, violations custom, rapports — est également livré. Les patchs 10.0.x ont corrigé des bugs sur ces fonctions, mais les extraits disponibles ne permettent pas de détailler lesquels. Ce que l’on sait, c’est que ces chantiers avancent : la 10.0.0 les a posés, le cycle 10.0.x les a consolidés.

Les importateurs méritent une attention particulière, car c’est là que les déceptions sont les plus visibles. Un fil du forum de septembre 2026 documente un import Altium 25.6.2 vers KiCad 10.0.6 qui génère un avertissement ERC « Symbol pin or wire end off connection grid » sur presque chaque broche et chaque fil. Ce n’est pas un bug bloquant — le projet s’ouvre, les nets sont là — mais c’est exactement le genre de friction qui pourrit une migration : des heures de vérification manuelle, des symboles orphelins à traquer, des couches mal mappées à corriger. Les importateurs Eagle, CADSTAR et les formats de fabrication ont également fait l’objet de correctifs dans le cycle, mais l’import reste imparfait. Le conseil de vérification post-import est simple : ne faites jamais confiance à un import sans passer par une passe de DRC complète, une vérification des nets critiques et un contrôle visuel des couches. Et documentez chaque écart : c’est votre meilleure défense contre les régressions futures.

Bibliothèques et gestion des symboles/empreintes : la stabilité par les correctifs, pas par la refonte

C’est le point aveugle des comparatifs, et pourtant c’est souvent le vrai critère de migration pour une équipe. La gestion des bibliothèques dans KiCad 10 n’a pas fait l’objet d’une refonte spectaculaire ; elle a été stabilisée par les correctifs du cycle 10.0.x. Synchronisation des tables de symboles et d’empreintes, cache, conflits de versions, comportement en équipe avec des dépôts Git et des bibliothèques partagées : tout cela a été traité au fil des patchs, sans tambour ni trompette.

Pourquoi est-ce si important ? Parce qu’une bibliothèque corrompue ou lente bloque toute l’équipe, alors qu’un routeur imparfait ne bloque qu’un concepteur. Les correctifs de corruption et de lenteur intervenus dans le cycle 10.0.x sont donc, pour un atelier, plus critiques que n’importe quelle amélioration de routage. Le problème, c’est que ces correctifs sont les moins documentés : les release notes les mentionnent en une ligne, et il faut lire entre les lignes pour comprendre leur portée.

D’où quelques réflexes de gouvernance adaptés au rythme des patchs. Premièrement, versionnez vos bibliothèques dans un dépôt Git dédié, avec des tags alignés sur les versions de KiCad utilisées. Deuxièmement, verrouillez les tables de symboles et d’empreintes en production : un fp-lib-table qui change sous les pieds d’un concepteur est une source de bugs silencieux. Troisièmement, instaurez une revue systématique des modifications de bibliothèque, comme vous le feriez pour du code. Quatrièmement, testez chaque patch sur une copie de la bibliothèque avant de le déployer sur le dépôt partagé. Ces règles coûtent peu et évitent les mauvaises surprises.

Régressions corrigées vs promesses de la 10.0.0 : la grille de lecture pour trier le vrai du marketing

Construisons la grille d’évaluation promise. Trois colonnes : promesse annoncée en 10.0.0, statut réel en 10.0.7, impact concret pour le concepteur.

Comment lire une release note sans se faire piéger par le bruit des correctifs mineurs ? Le signal à surveiller n’est pas le nombre de lignes du changelog, c’est la nature des correctifs : une release qui corrige des crashs ou des régressions de performance est plus importante qu’une release qui ajoute dix améliorations cosmétiques. Les signaux qui doivent déclencher une migration : issues critiques fermées, régressions signalées par la communauté et corrigées, releases candidates testées sans incident majeur. Les signaux qui doivent la retarder : fils de forum signalant des régressions non résolues, absence de release candidate, changements dans les bibliothèques sans documentation.

Migrer, figer, ou attendre la 10.1 : stratégie de versionnement pour les équipes PCB

Passons aux règles opérationnelles. Quand migrer vers 10.0.7 ? Si vous êtes encore sur 10.0.0 à 10.0.5, migrez sans hésiter : la 10.0.6 a corrigé les régressions de performance qui rendaient l’édition de pistes pénible, et la 10.0.7 est la version la plus stable du cycle. Si vous êtes sur une version antérieure à la branche 10, attendez la fin du cycle — c’est maintenant — et planifiez une migration testée sur un projet représentatif avant de basculer toute l’équipe.

Comment figer une version en production ? Trois approches. Premièrement, le gel de version : installez la 10.0.7 sur tous les postes et interdisez les mises à jour automatiques. Deuxièmement, l’image de conteneur ou le paquet verrouillé : sur Linux, des paquets comme kicad-10.0.6-alt2 (ALT Linux) illustrent la voie du paquet versionné ; sur Windows et macOS, verrouillez l’installateur. Troisièmement, la documentation interne : notez la version exacte, les patchs appliqués, les plugins installés (comme Konnect, le plugin IA pour KiCad 10 cité par Fellow en octobre 2026) et les configurations de bibliothèques. Cette documentation est votre assurance en cas de problème.

Comment gérer les postes hétérogènes et les fichiers partagés entre versions ? La compatibilité des fichiers entre 10.0.x est généralement assurée dans le sens montant, mais pas toujours dans le sens descendant. La règle : un fichier créé en 10.0.7 doit être ouvert en 10.0.7 minimum. Pour les équipes mixtes, imposez une version plancher et documentez-la. Quant à la politique de support de la branche 10.0, elle s’achèvera avec l’arrivée de la prochaine branche majeure ; les critères pour sauter directement à la 10.1 plutôt que de courir après chaque patch sont simples : si votre flux de travail est stable en 10.0.7 et que la 10.1 n’apporte pas de fonction critique, attendez la première ou la deuxième release candidate de la 10.1 avant de migrer massivement.

Ce que la maturité du cycle 10.0.x dit de l’écosystème KiCad — et ce qu’il faut surveiller ensuite

Que révèle un cycle de sept patchs sur la maturité du projet ? D’abord, une gouvernance solide : le mécanisme de release candidate systématique, la réactivité des mainteneurs face aux régressions (la 10.0.6 corrige en quelques semaines des problèmes signalés en 10.0.4 et 10.0.5), et la qualité des tests communautaires. Ensuite, une communauté active : les fils du forum officiel sont le meilleur baromètre de la santé du projet, et ils ont joué leur rôle d’alerte. Enfin, un écosystème qui se densifie : plugins IA comme Konnect, conférences comme KiCon Asia 2026 à Shenzhen (5-7 novembre 2026), outils de fabrication comme AIVON qui propose une cotation instantanée depuis KiCad.

Comparé à la trajectoire des versions précédentes, le cycle 10.0.x montre un projet qui a appris de ses erreurs : les régressions de performance de 10.0.4 et 10.0.5 rappellent celles des cycles antérieurs, mais la correction a été plus rapide et mieux documentée. Face à la concurrence commerciale, KiCad reste en retrait sur la fiabilité des fonctions avancées — le tuning haute vitesse et l’import Altium en sont les exemples les plus criants — mais l’écart se resserre, et le coût d’Altium (3 850 à 5 000 USD par utilisateur et par an, plus de 175 000 USD sur trois ans pour cinq postes avec formation) rend la comparaison de plus en plus favorable à l’open source pour les équipes qui n’ont pas besoin du dernier micron de précision.

Ce qu’il faut surveiller ensuite : les nouvelles fonctions de la prochaine branche majeure, la dette technique accumulée (les régressions de performance suggèrent que le code du routeur mérite une attention continue), et l’écosystème de plugins qui devient un critère de choix à part entière. Les indicateurs à suivre pour anticiper la prochaine migration sans subir le calendrier : la date de la première release candidate de la 10.1, les fils du forum signalant des régressions, et la publication des notes de version détaillées. Le cycle 10.0.x s’achève ; le suivant commence, et les équipes qui ont appris à lire les patchs sauront quand migrer.

Sources

• KiCad – Schematic Capture & PCB Design Software
• Download – KiCad
• Release Notes – KiCad
• Downloads | KiCad EDA
• KiCad – Wikipedia
• Windows Downloads – KiCad
• KiCad 10.0.7 Release | KiCad
• Démarrer avec KiCad | 5.1 | Français | Documentation | KiCad
• Version 10.0.0 Released | KiCad
• KiCad 10 review: new features, high-speed tuning, variants, and more
• KiCad 10.0 New Features: Importers, Variants, Graphical DRC
• KiCad — Wikipédia
• KiCad Releases Version 10.0 with Updates Across Libraries, UI, and PCB Design Tools
• KiCad Ecosystem Explained: Tools, Libraries, Plugins, and PCB Manufacturing Resources
• Forum KiCad : « KiCad 10.0.4 / 10.0.5 – extremely slow track movement in PCB Editor, 10.0.5 becomes unusable » (12 août 2026)
• Forum KiCad : « Altium → KiCad 10 import: "Symbol pin or wire end off connection grid" for almost every pin/wire » (1er septembre 2026)
• KiCad.org : « KiCad 10.0.6 Release » (29 août 2026) ; « KiCad Version 10.0.6 Release Candidate 1 Available » (18 août 2026) ; « KiCad Version 10.0.7 Release Candidate 1 Available » (27 septembre 2026) ; « KiCad Version 10.0.7 Release Candidate 2 Available » (3 octobre 2026)
• KiCad.org : « KiCad Conference Asia 2026 Announcement » (16 septembre 2026)

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