Kicad Master · 11 November 2026

KiCad après la 10.0.7 : ce que la branche de développement nous réserve déjà

La 10.0.7 est sortie le 7 octobre 2026, la 10.0.8 a suivi le 30 octobre, et la série 10.0.x est désormais une base de production solide. Pour un concepteur PCB, la vraie question n’est plus « quelle est la dernière version stable ? » mais « qu’est-ce qui atterrit dans master en ce moment, et quand faudra-t-il y passer ? ». Tour d’horizon de ce que l’on peut réellement vérifier dans les sources publiques — et de ce qu’il faut encore prendre avec des pincettes.

10.0.7 est là, et alors ? Ce que la série stable ne dira plus

Reprenons la chronologie, parce qu’elle est instructive. La 10.0.7 a eu sa Release Candidate 1 le 27 septembre 2026, sa RC2 le 3 octobre, puis sa version finale le 7 octobre 2026 — un cycle RC serré, typique des releases de maintenance. Trois semaines plus tard, le 30 octobre 2026, la 10.0.8 débarquait à son tour, avec la même formule rituelle : « critical bug fixes and other minor improvements since the previous release ». Autrement dit : la branche 10.0.x est en régime de croisière, elle corrige, elle ne raconte plus rien de neuf sur le plan fonctionnel.

C’est précisément là que le sujet se déplace. Une release de maintenance comme la 10.0.7 ou la 10.0.8 ne vous dit rien sur l’avenir de l’outil : elle vous dit qu’il tient debout. Pour savoir ce qui va changer dans votre façon de router, de gérer vos bibliothèques ou d’automatiser vos tâches, il faut regarder ailleurs — du côté du fil officiel « Post-V10 New Features and Development News » sur forum.kicad.info, des dépôts GitLab du projet, et des builds nightly.

Cet article a une promesse simple : trier le confirmé du bruit. Pas de mythologie de version, pas de « KiCad 11 sera révolutionnaire » lancé au hasard. On va regarder ce que les sources publiques disent vraiment, ce qu’elles ne disent pas, et ce qu’un concepteur en production sur 10.0.x peut raisonnablement anticiper pour les prochains mois.

Ce que l’on peut vraiment vérifier (et ce qu’on ne peut pas) dans les sources publiques

Commençons par une mise au point méthodologique, parce qu’elle conditionne tout le reste. Le site officiel kicad.org est une excellente porte d’entrée pour télécharger le logiciel, mais c’est une source catastrophiquement mauvaise pour juger de l’état du développement. La page d’accueil affiche encore un copyright « © 2018-2020 1BitSquared » et décrit les fonctionnalités de manière générique : « powerful interactive router », visionneuse 3D avec raytracer, simulateur SPICE intégré, contrôleur de règles électriques. Aucune mention de la 10.0.x, aucune mention d’une branche de développement, aucun détail technique sur le push-and-shove ou le suivi d’impédance. La page de téléchargement, elle, ne parle que de dons via The Linux Foundation. Bref : le site marketing n’est pas le lieu où l’on apprend ce qui se prépare.

La documentation officielle disponible dans les sources consultées couvre les versions 5.1 (en français) et 9.0 (en anglais) — ce qui confirme l’existence d’une branche 9.0 stable, mais ne dit rien de la 10.0.x ni de master.

Alors, que peut-on affirmer avec certitude ? D’abord, l’existence factuelle de la 10.0.7 (blog officiel daté du 7 octobre 2026, URL /blog/2026/10/KiCad-10.0.7-Release/), de sa RC1 (27 septembre) et de sa RC2 (3 octobre). Ensuite, l’existence d’un fil de forum communautaire dédié à la 10.0.7 et d’un fil « Post-V10 New Features and Development News ». Enfin, la disponibilité de tags de bibliothèques officielles sur GitLab — par exemple 10.0.7-rc1 sur le dépôt KiCad Footprints, tagué le 22 septembre 2026.

Ce qu’on ne peut pas affirmer depuis les sources publiques consultées : aucun numéro de merge request, aucun hash de commit post-tag 10.0.7, aucune date de commit précise, aucun jalon de milestone GitLab. Aucune fonctionnalité n’est explicitement marquée « merged » ou « in progress » dans les extraits disponibles. C’est le fait le plus solide de cet exercice d’honnêteté : les sources publiques grand public ne permettent pas de répondre finement à la question « qu’est-ce qui a été mergé dans master depuis la 10.0.7 ? ». Il faut aller sur GitLab directement, dans les milestones et les merge requests, pour obtenir cette granularité. Nous y reviendrons dans la section sur les métriques.

Dans les entrailles du routeur : push-and-shove, multi-pistes, impédance — ce qui se joue techniquement

Attaquons le cœur du sujet pour un concepteur PCB : le routeur interactif. C’est la fonctionnalité qui, historiquement, a fait basculer KiCad du statut d’« outil gratuit sympathique » à celui d’« alternative sérieuse ». La page officielle parle d’un « powerful interactive router » sans détailler le mécanisme — c’est une formulation marketing, pas une spécification technique. Mais on peut expliquer comment ça marche, et donc ce que les chantiers futurs visent à améliorer.

Le routeur interactif de KiCad repose sur un moteur de routage par contraintes, dont le code vit dans pcbnew/router/ (les fichiers pns_* — pour « push-and-shove » — sont les plus connus). Le principe du push-and-shove : quand vous tracez une piste et qu’elle rencontre un obstacle (une autre piste, un via, un pad), le moteur ne se contente pas de vous signaler un conflit — il déplace les pistes existantes pour faire de la place, en respectant les contraintes de clearance définies dans les règles de conception. C’est un problème d’optimisation sous contraintes, résolu en temps réel pendant que vous bougez la souris.

Les limites concrètes de la 10.0.x sur ce terrain sont bien connues des utilisateurs réguliers : le push-and-shove gère bien les pistes simples, mais devient moins prévisible sur les paires différentielles serrées, les faisceaux multi-pistes (bus routing) et le suivi d’impédance en temps réel. Le suivi d’impédance — calculer la largeur de piste nécessaire pour atteindre une impédance cible en fonction de la stackup — existe sous une forme plus ou moins assistée, mais reste un point où les outils commerciaux comme Altium Designer (avec son Stackup Planner et son Interactive Length Tuning) gardent une longueur d’avance.

C’est précisément là que se situent les chantiers évoqués dans le fil « Post-V10 New Features » : amélioration du push-and-shove sur les géométries complexes, édition multi-pistes (router plusieurs pistes en parallèle avec un espacement maintenu), et meilleure intégration du suivi d’impédance. Mais attention : dans les sources consultées, aucun de ces chantiers n’est explicitement marqué comme mergé. Ce sont des pistes évoquées, discutées, parfois partiellement implémentées — pas des fonctionnalités livrées. Le lecteur qui veut vérifier doit aller voir les commits dans pcbnew/router/ sur GitLab, les merge requests associées, et tester les nightly builds. C’est le seul moyen honnête de savoir où en est réellement le code.

Un point de repère utile : la 10.0 a introduit des fonctionnalités comme les importateurs améliorés, les variantes de composants et le DRC graphique (comme le relève un article tiers d’electwork.net intitulé « KiCad 10.0 New Features: Importers, Variants, Graphical DRC »). Le DRC graphique, en particulier, change la donne pour le routage : au lieu de lire un rapport textuel de violations, vous les voyez surlignées sur le PCB. C’est le genre d’amélioration qui, discrètement, accélère énormément les cycles de correction.

Éditeur, bibliothèques, API : les autres chantiers qui touchent le quotidien

Le routage n’est pas tout. Une journée type de concepteur PCB, c’est aussi : chercher un symbole dans une bibliothèque, créer une empreinte, écrire un script pour automatiser une tâche répétitive, exporter des fichiers de fabrication. Sur ces terrains, les chantiers post-V10 touchent à plusieurs couches.

L’éditeur de symboles et d’empreintes. La refonte de l’éditeur est un serpent de mer du projet. L’objectif : une interface plus cohérente entre l’éditeur de symboles et celui d’empreintes, une meilleure gestion des propriétés, et une édition plus fluide des grands composants (BGA, connecteurs haute densité). Niveau de confiance : en cours, mais sans échéance ferme dans les sources consultées.

La gestion des bibliothèques. C’est un point sensible. Les bibliothèques officielles KiCad sont versionnées sur GitLab, avec des tags synchronisés sur les releases (le tag 10.0.7-rc1 du 22 septembre 2026 sur le dépôt Footprints en est un exemple concret). La tendance de fond : rendre la gestion des bibliothèques personnelles et officielles plus transparente, avec des mécanismes de mise à jour moins intrusifs. Pour le concepteur, cela se traduit par moins de « pourquoi mon empreinte ne se met pas à jour ? » et plus de prévisibilité.

L’API Python et l’intégration externe. C’est probablement le chantier le plus excitant pour les utilisateurs avancés. L’API Python de KiCad permet déjà d’automatiser des tâches (génération de vias de stitching par script, par exemple — un cas d’usage documenté sur scriptedpcb.com). Mais l’écosystème explose littéralement avec l’arrivée de plugins natifs. L’exemple le plus marquant de 2026 : Konnect, un plugin KiCad natif (un binaire Rust unique) qui permet à Claude et à d’autres assistants IA de concevoir schémas et circuits imprimés via le protocole MCP, avec 228 outils exposés. Présenté le 14 octobre 2026 et repris par Adafruit le 26 octobre 2026, Konnect illustre une tendance de fond : KiCad devient une plateforme, pas seulement un logiciel.

Chiffres et cadence : ce que les métriques du projet racontent vraiment

Soyons clairs : les sources publiques consultées ne fournissent aucun chiffre sur le nombre de commits entre 10.0.0 et master, le nombre de contributeurs actifs, la cadence réelle des nightly builds, la taille des merge requests, ou des benchmarks de performance du routeur (temps de chargement de cartes complexes, consommation RAM). Le site officiel ne publie rien de tel — les pages marketing décrivent des fonctionnalités sans métriques.

Est-ce grave ? Pas nécessairement, mais il faut savoir où chercher. Les métriques existent, elles sont publiques, mais elles vivent sur GitLab (gitlab.com/kicad), pas sur kicad.org. Un lecteur motivé peut :

1. Compter les commits entre le tag 10.0.7 et master via l’interface GitLab (onglet « Commits » du dépôt principal, filtre par date).
2. Consulter les milestones GitLab pour voir quelles fonctionnalités sont planifiées pour la prochaine version majeure, et leur statut (ouvert, en cours, fermé).
3. Suivre les merge requests pour évaluer la taille des changements (nombre de lignes, fichiers touchés) et la durée de review.
4. Tester les nightly builds pour mesurer soi-même les performances sur ses propres cartes — c’est le seul benchmark qui compte vraiment pour votre workflow.

Ce qu’on peut dire sans chiffre : la cadence des releases de maintenance est rapide et régulière (10.0.6 le 29 août, 10.0.7 le 7 octobre, 10.0.8 le 30 octobre 2026 — soit environ une release toutes les 4 à 6 semaines), ce qui indique un projet réactif sur les correctifs. C’est un bon signe de maturité : l’équipe ne laisse pas traîner les bugs critiques.

Calendrier réaliste : quand la prochaine majeure, et à quoi s’attendre d’ici là

La question à un million : quand la prochaine version majeure ? Les sources consultées ne donnent aucune date officielle. On peut néanmoins raisonner par la cadence historique et les jalons visibles.

KiCad a longtemps suivi un rythme de versions majeures annuelles ou bisannuelles, avec des séries de maintenance intercalées. La série 10.0.x, avec ses releases rapprochées (10.0.6, 10.0.7, 10.0.8 en trois mois), suggère que la branche stable est bien installée et que l’équipe peut consacrer des ressources à la suivante. Un scénario raisonnable : une prochaine majeure dans une fenêtre de 12 à 18 mois après la 10.0.0, avec des RC précédant la sortie de quelques semaines — le cycle 10.0.7 (RC1 le 27 septembre, RC2 le 3 octobre, release le 7 octobre) donne une idée de la mécanique.

Ce qui atterrira probablement dans la prochaine majeure : les chantiers déjà bien avancés dans master, notamment côté éditeur et bibliothèques. Ce qui risque de glisser : les fonctionnalités de routage les plus ambitieuses (multi-pistes, suivi d’impédance complet), qui demandent une refonte profonde du moteur et beaucoup de tests.

Les signaux à surveiller : les milestones GitLab (quand une milestone « 11.0 » ou équivalent apparaît avec des issues assignées), l’annonce d’un feature freeze, et la publication d’une première RC. Tant que ces signaux ne sont pas là, tout calendrier précis relève de la spéculation.

Nightly, veille et migration : comment se préparer sans casser sa prod en 10.0.x

Volet pratique, celui qui compte pour ne pas se retrouver avec un projet cassé la veille d’un tape-out.

La veille. Trois sources à suivre : le fil « Post-V10 New Features and Development News » sur forum.kicad.info (le plus direct pour les annonces de fonctionnalités), le blog Release Notes (pour les releases officielles), et GitLab (pour les milestones et merge requests). Un rythme de consultation hebdomadaire suffit largement.

Les nightly builds. Elles permettent de tester les fonctionnalités en cours, mais elles sont par nature instables. La règle d’or : jamais sur un projet en production. Installez-les dans un environnement isolé (machine virtuelle, conteneur, ou simplement un second profil utilisateur), et testez sur des projets de recette, pas sur votre carte en cours de routage. Les nightly sont excellentes pour évaluer si une fonctionnalité répond à votre besoin — pas pour livrer.

La migration des bibliothèques. Les bibliothèques officielles sont taguées par release (le tag 10.0.7-rc1 du 22 septembre 2026 en est un exemple). Si vous utilisez les bibliothèques officielles, restez aligné sur votre version stable : ne mélangez pas des empreintes de master avec un projet 10.0.8. Pour vos bibliothèques personnelles, versionnez-les (Git, SVN, ou même un simple dossier daté) avant toute migration — c’est la meilleure assurance contre les mauvaises surprises.

Sauvegardes et formats. Les formats de fichiers KiCad évoluent entre versions majeures. Avant de tester une nightly sur un projet existant, faites une copie. Et gardez en tête que les fichiers ouverts et sauvegardés par une version de développement peuvent ne plus être lisibles par la stable — c’est rare, mais c’est arrivé.

Ce qui vaut le coup d’être testé tôt : les améliorations d’interface et de bibliothèques, qui sont généralement stables et sans risque. Ce qui peut attendre : tout ce qui touche au routage avancé et aux formats de fichiers.

KiCad face à son écosystème : plugins, builds alternatifs et ambition du projet

Terminons par une mise en perspective plus large, parce qu’elle éclaire l’ambition du projet.

Les plugins. L’écosystème KiCad n’a jamais été aussi dynamique. Konnect (228 outils MCP, présenté le 14 octobre 2026) en est l’illustration la plus spectaculaire : un plugin natif en Rust qui branche des assistants IA directement sur la conception de schémas et de PCB. À côté, des outils comme AIVON (cotation instantanée de fabrication depuis KiCad, présenté le 15 septembre 2026) ou les scripts de génération de vias de stitching montrent que KiCad devient une plateforme d’intégration, pas seulement un logiciel de conception.

Les builds alternatifs. Le portage navigateur de KiCad a fait parler de lui (Hackaday, 22 octobre 2026 : « KiCad… In The Browser? »). C’est un signal fort : la communauté ne se contente plus d’utiliser KiCad, elle veut l’étendre, le porter, l’intégrer dans des workflows web. Le portage Android, évoqué dans le cadrage, relève de la même dynamique — une ambition de démocratisation au-delà du poste de travail traditionnel.

Le positionnement face aux outils commerciaux. La comparaison est éclairante. Altium Designer reste la référence sur certains terrains : Interactive Length Tuning, Stackup Planner avec calcul d’impédance, éditeur de règles DRC graphique très avancé. Mais le coût est dissuasif : 3 850 à 5 000 USD par utilisateur et par an, et plus de 175 000 USD sur trois ans pour cinq postes, formation incluse (1 000 à 2 000 € par personne). Face à cela, KiCad propose un routeur interactif solide, un DRC graphique (introduit en 10.0), et un écosystème de plugins en pleine explosion — le tout gratuit et multiplateforme (Windows, macOS, Linux), là où Altium reste Windows uniquement.

Ce que cette effervescence dit de l’ambition de KiCad : le projet ne cherche plus seulement à rattraper les outils commerciaux sur les fonctionnalités de base, il cherche à devenir une plateforme ouverte, extensible, intégrée dans des chaînes d’outils modernes (IA, fabrication, web). Pour le concepteur qui choisit sa chaîne d’outils en 2026-2027, cela change la donne : KiCad n’est plus le « choix par défaut faute de budget », c’est un choix stratégique, avec une communauté active et une feuille de route qui avance.

Reste une incertitude : la vitesse à laquelle les chantiers les plus ambitieux (routage avancé, suivi d’impédance complet) atterriront réellement. Les sources publiques ne permettent pas de le dire avec certitude. La meilleure stratégie reste la veille active et le test en nightly — sans jamais sacrifier la stabilité de vos projets en production sur 10.0.x.

Sources

• KiCad – Schematic Capture & PCB Design Software
• Download – KiCad
• Release Notes – KiCad
• KiCad 10.0.7 Release
• Post-V10 New Features and Development News – forum.kicad.info
• KiCad Footprints – GitLab (tag 10.0.7-rc1)
• KiCad… In The Browser? – Hackaday (22 octobre 2026)
• KiCad – Wikipedia
• Downloads | KiCad EDA
• Démarrer avec KiCad | 5.1 | Documentation
• 10 PCB Design Tips Every KiCad User Should Know – aivon.com

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