Kicad Master · 2 September 2026

KiCad 10.0.6 : la stabilisation se poursuit, l’écosystème s’emballe — état des lieux de l’EDA open-source en septembre 2026

La série 10.0 vient de livrer son sixième correctif, et l’écosystème n’a jamais été aussi actif. Entre stabilisation du noyau, importateurs natifs enfin opérationnels, autoroutage GPU et bibliothèques générées par scripts, KiCad s’impose comme une alternative crédible aux géants propriétaires. Tour d’horizon de ce que les concepteurs PCB peuvent attendre de la suite — sans spéculation hasardeuse.

10.0.6 : la stabilisation se poursuit, quatre mois après la majeure

Sortie en septembre 2026, la version 10.0.6 de KiCad est, officiellement, une « version de correction de bugs » — la formule rituelle du projet pour désigner les livraisons qui ne comportent ni nouvelle fonctionnalité ni changement d’interface. Mais cette sixième itération de la série 10.0 est surtout un marqueur : elle confirme que la branche 10.x a atteint sa vitesse de croisière, six mois après la sortie de la version majeure 10.0.0 en mars 2026. Le site officiel de téléchargement affiche d’ailleurs « Current Version: 10.0.6 » pour Windows, avec un support des plateformes x86-64 et arm64.

Le bilan de cette série est en effet impressionnant. Selon le blog officiel, la version 10 a été construite avec 7 609 commits uniques — un volume considérable pour un projet open-source qui fonctionne au rythme des contributions volontaires. Les bibliothèques officielles ont été enrichies de 952 symboles, 1 216 empreintes et 386 modèles 3D, portant le catalogue à un niveau jamais atteint. Surtout, la 10.0 a marqué un tournant structurel : plus de 78 % des empreintes de la bibliothèque officielle sont désormais générées par des outils automatisés plutôt que dessinées manuellement, et les modèles 3D sont passés au format STEP exclusivement, réduisant significativement la taille d’installation.

La 10.0.5, livrée le 22 juillet 2026, avait déjà apporté son lot de correctifs critiques : un crash à la fermeture du programme (issue #23102), un crash lors de la migration d’une table de bibliothèque imbriquée (#23291), un crash d’initialisation du driver 3Dconnexion (#22609), ou encore un blocage sur géométrie énorme avec lignes pointillées (#23824). La 10.0.6 poursuit ce travail de stabilisation, confirmant le rythme régulier du projet : une version majeure en mars, puis six correctifs en six mois.

Ce qui frappe, c’est la régularité du rythme : une version majeure en mars, puis six correctifs en six mois. C’est le signe d’un projet qui a trouvé son équilibre entre innovation et stabilité — et c’est précisément ce qui rend la question de la suite si intéressante.

Ce que la 10.0.6 ne dit pas : la feuille de route officielle reste muette

Le point le plus frappant, pour qui observe KiCad depuis quelques cycles, c’est le silence radio sur l’avenir. Aucune annonce ferme pour la 10.1, aucune date pour la 11.0, aucun jalon GitLab public mentionnant des fonctionnalités à venir. Les canaux officiels — le blog, la page des release notes, le dépôt GitHub — ne contiennent, à la date du 2 septembre 2026, aucune feuille de route explicite.

Ce silence est en soi un signal. KiCad fonctionne selon une méthode de développement incrémentale et communautaire : les grandes orientations se décident dans les fils de discussion du forum, se concrétisent dans les merge requests, et ne sont annoncées qu’au moment où elles deviennent des fonctionnalités stables. La politique de maintenance, elle, est claire : la série 9.x n’est plus activement maintenue depuis la sortie de la 10.0.0, et les correctifs pour la 10.x sont prévus pour une durée d’un an avant le développement de la version 11. Cela place le début du travail sur la 11.0 quelque part entre la mi-2026 et la mi-2027 — mais sans date précise.

Il faut aussi rappeler que KiCad a un cycle historique de versions majeures espacées d’environ deux ans : la 9.0 est sortie en 2024, la 10.0 en mars 2026. Si ce rythme se maintient, la 11.0 pourrait arriver en 2028 — mais ce n’est qu’une extrapolation, pas une annonce. Les seuls jalons officiels confirmés sont la 10.0.0 (mars 2026) et la 10.0.6 (septembre 2026), et le projet n’a pas communiqué sur des versions intermédiaires comme une éventuelle 10.1.

Les fonctionnalités qui ont fait la 10.0 : DRC graphique, variantes, routage différentiel

Si la 10.0.x est une série de stabilisation, la majeure 10.0.0 a apporté son lot de nouveautés structurantes. Parmi elles, l’éditeur de règles DRC graphique mérite une mention spéciale : il permet de visualiser et de configurer les règles de conception directement dans l’interface, sans avoir à plonger dans des fichiers de configuration textuels. Pour les concepteurs qui jonglent avec des contraintes de clearance, d’impédance ou d’espacement, c’est un gain de productivité immédiat.

Les variantes de conception sont une autre avancée majeure. Longtemps le cauchemar des révisions — gérer plusieurs déclinaisons d’un même PCB (avec ou sans certains composants, différentes valeurs de résistances, etc.) —, cette fonctionnalité est désormais native. Elle permet de définir des variantes de BOM et de placement sans dupliquer le projet, une fonctionnalité que les utilisateurs d’Altium connaissent bien et qui manquait cruellement à KiCad.

Enfin, le routage différentiel haute vitesse a fait entrer KiCad dans la cour des grands. Avec la prise en charge des paires différentielles, des contraintes d’impédance et des règles de longueur, l’outil open-source peut désormais rivaliser avec des solutions propriétaires sur des designs haute fréquence. C’est un signal fort pour les bureaux d’études qui hésitaient encore à franchir le pas.

Les signaux faibles du forum : ce que les utilisateurs demandent vraiment

Si la feuille de route officielle est muette, la communauté, elle, ne l’est pas. Le fil « Post-V10 New Features and Development News » du forum KiCad.info est le lieu où s’échangent les propositions, les espoirs et les frustrations. Malheureusement, le contenu détaillé de ce fil n’était pas accessible dans le cadre de cet article — une limite à assumer : il serait trompeur de prétendre synthétiser des discussions que nous n’avons pas lues. Ce que nous pouvons observer, en revanche, ce sont les signaux faibles éparpillés dans les fils récents du forum.

Prenons le fil sur les « local power labels » (3 août 2026). KiCad 10 a introduit cette nouvelle fonctionnalité, mais l’utilisateur qui a ouvert le fil avoue ne pas comprendre comment l’activer : « J’ai eu deux idées : modifier une étiquette d’alimentation existante pour la rendre locale, mais je ne trouve pas de paramètre pour cela ». Ce type de confusion est un signal classique : une fonctionnalité existe, mais son ergonomie n’est pas au point. C’est typiquement ce qui alimente les demandes d’amélioration de l’interface dans les cycles suivants.

Autre signal, plus préoccupant : le fil « OSH Park / KiCad snafu » (22 juillet 2026). Un utilisateur sous KiCad 10.0.3 rapporte que ses traces de signaux sont « complètement fusionnées avec les plans de puissance et de masse » après fabrication chez OSH Park. Sans pouvoir trancher sur la cause (un problème d’export Gerber ? de réglage de clearance ? de zone de cuivre ?), ce retour illustre les douleurs récurrentes sur la gestion des zones de cuivre — un sujet qui revient régulièrement dans les discussions communautaires.

Enfin, le fil « KiCad V10 development status (as of 24-Nov-2025) » montre que la communauté anticipe, interroge, et tente de deviner ce que les mainteneurs préparent. C’est le rôle traditionnel de ces fils : recueillir les propositions structurantes (gestion des variantes, amélioration de l’importation, etc.) et les soumettre à l’appréciation des développeurs. Mais sans accès au contenu, il serait malhonnête d’affirmer qu’un consensus s’est dégagé sur telle ou telle fonctionnalité.

Importateurs natifs : Allegro, PADS et gEDA entrent dans la danse

Pendant des années, migrer un projet d’Altium Designer, d’Allegro ou de PADS vers KiCad relevait du parcours du combattant : plugins tiers plus ou moins maintenus, formats binaires fermés, pertes de données en cascade. La 10.0 a changé la donne avec l’introduction d’importateurs natifs pour Allegro, PADS et gEDA/Lepton EDA.

L’importateur Allegro est un défi technique relevé : il gère les fichiers .brd et .dra, avec une couverture impressionnante des éléments de conception — symboles, empreintes, contraintes, zones de cuivre. L’importateur PADS promet une migration complète schéma + PCB, ce qui manquait cruellement aux solutions précédentes. Quant à gEDA/Lepton EDA, son import discret mais utile renforce la position de KiCad comme outil de convergence pour l’open-source.

Le grand absent reste Altium Designer : aucun importateur natif n’est encore disponible pour les fichiers .SchDoc et .PcbDoc. C’est un chantier colossal — le format est propriétaire et complexe — mais la pression communautaire est forte, d’autant que la fin de vie d’EAGLE (7 juin 2026) pousse de nombreux utilisateurs vers KiCad. Pour l’instant, la migration depuis Altium passe encore par des outils tiers, avec des résultats variables selon la complexité du design.

IA, collaboration, automatisation : les pistes qui émergent

C’est le sujet qui électrise la communauté : l’IA va-t-elle transformer la conception de PCB ? Les articles récents se multiplient — « KiCad AI in 2026: Copilots, Plugins, and Generators That Actually Work » (31 juillet 2026), l’étude Weidmuller sur l’impact des outils IA dans le workflow PCB (24 juillet 2026) — et des outils concrets existent déjà.

Le plus notable est le KiCad MCP Server de Seeed-Studio (mentionné sur Glama, 16 juillet 2026) : un serveur MCP (Model Context Protocol) qui permet à des assistants IA d’analyser des schémas, d’inspecter des PCB, de tracer des connexions, de valider des designs et de générer du code embarqué pour des projets KiCad. C’est une passerelle entre les grands modèles de langage et les fichiers de conception — et un exemple frappant de ce que l’écosystème construit en périphérie du logiciel.

L’enquête Weidmuller, publiée le 24 juillet 2026, révèle que 91 % des ingénieurs nord-américains déclarent utiliser l’IA dans leur flux de conception PCB. Un chiffre choc, mais qui cache des réalités nuancées : l’IA est utilisée principalement pour la vérification de règles (DRC), la génération de rapports et l’assistance à la sélection de composants — pas encore pour le placement ou le routage automatique de bout en bout. Les gains de temps annoncés (de 3 heures à moins de 10 minutes pour certaines tâches de routage) sont réels mais concernent des cas d’usage spécifiques.

Il y a aussi les autorouteurs intelligents. Le PCB Auto Router (27 juillet 2026) se présente comme un outil « GPU-accelerated » supportant l’import KiCad et JLC EDA, avec routage automatique de circuits complexes, paires différentielles et correspondance de longueurs. Le projet OrthoRoute, rapporté par Hackaday le 2 juillet 2026, a routé un backplane de 16 connecteurs, 17 600 pads et 8 192 airwires — un design « monstre » qui aurait pris des mois à la main. Ces outils ne sont pas développés par l’équipe KiCad, mais ils s’interfacent avec KiCad et témoignent d’une tendance de fond : l’automatisation du routage progresse vite.

Pourtant, il faut être clair : aucune trace d’IA dans le cœur de KiCad. Ni dans les notes de version, ni dans les annonces officielles, ni dans les correctifs 10.0.x. Les fonctionnalités d’IA (placement automatique, collaboration temps réel, vérification intelligente) sont portées par des tiers — plugins, scripts, serveurs MCP — pas par le projet principal. C’est une distinction cruciale pour les concepteurs : adopter ces outils, c’est accepter une dépendance à des projets plus jeunes, moins éprouvés, et parfois expérimentaux (le statut d’ALT TAB Circuit Copilot, par exemple, est explicitement « expérimental »).

Ce que l’on peut dire, en revanche, c’est que la génération automatisée d’empreintes est un fait établi et officiel (les 78 %), et que l’automatisation des vérifications progresse via les scripts Python pcbnew et kicad-cli. Un article récent (24 juillet 2026) montre comment automatiser des contrôles DRC/ERC personnalisés dans une chaîne d’intégration continue, et générer automatiquement des BOM et des empreintes. C’est une voie pragmatique : plutôt que d’attendre une IA intégrée, les équipes construisent leurs propres pipelines d’automatisation.

Chantiers structurels : le format de fichier, le rendu et les bibliothèques en question

Au-delà des discussions de surface, ce sont les chantiers structurels qui détermineront l’avenir de KiCad. Trois axes méritent l’attention.

Le format de fichier. KiCad utilise depuis longtemps un format texte basé sur la syntaxe S-expression pour ses fichiers de schéma (.sch) et de PCB (.kicad_pcb). Ce choix, documenté dans la documentation officielle (y compris dans la version 5.1), est un atout majeur : il permet le versioning Git, la génération de fichiers par scripts, et l’interopérabilité. Un guide publié en juin 2026 par Anchorpoint rappelle d’ailleurs pourquoi les fichiers texte de KiCad sont « le complément parfait à Git » pour le contrôle de version des designs PCB. Mais aucune évolution de ce format n’a été annoncée pour la suite. Faut-il s’attendre à une refonte ? Rien ne l’indique. Le format S-expr est stable, bien documenté, et les outils tiers (comme les scripts Python pcbnew) s’appuient dessus. Une évolution majeure serait un chantier colossal, et KiCad n’a pas l’habitude de casser la compatibilité sans préavis long.

Le moteur de rendu. Les versions récentes de KiCad ont modernisé leur rendu 3D et leur affichage canvas, mais aucune information officielle ne mentionne de refonte OpenGL/Metal. Ce que l’on sait, c’est que la 10.0 a introduit des améliorations visuelles (thèmes, transparence, etc.) et que les correctifs 10.0.x ont résolu des bugs d’affichage. Mais rien ne permet d’affirmer qu’un nouveau moteur de rendu est en préparation. Les utilisateurs qui espèrent un passage à Vulkan ou à un rendu accéléré par GPU devront probablement attendre la 11.0 — et encore, sans garantie.

Les bibliothèques générées par scripts. C’est le chantier le plus tangible, et de loin. Le chiffre de 78 % d’empreintes générées automatiquement n’est pas anecdotique : il signale un changement de paradigme. Les bibliothèques ne sont plus dessinées à la main, elles sont produites à partir de données structurées (datasheets, fichiers de spécifications) via des générateurs. Cette tendance lourde pourrait s’accélérer : on peut imaginer que les 22 % restants — les cas les plus complexes — seront progressivement convertis, et que les générateurs intégrés produiront aussi davantage de modèles 3D. La publication récente de la bibliothèque CERN pour KiCad (12 mai 2026, 17 000+ symboles et empreintes, compatible v9.x et v10.x) montre d’ailleurs que l’écosystème externe s’engouffre dans cette voie.

Le contexte concurrentiel : EAGLE disparaît, KiCad progresse

Le paysage de l’EDA a été bouleversé en 2026 par un événement majeur : la fin de vie d’Autodesk EAGLE, effective le 7 juin 2026. Après cette date, Autodesk a cessé la vente et le support d’EAGLE et fermé les serveurs de licences. Des milliers d’utilisateurs se sont retrouvés contraints de migrer — et KiCad a été le principal bénéficiaire de cette migration.

Face à Altium Designer, le match est désormais plus équilibré. Altium reste un outil puissant, avec un abonnement annuel de 3 850 à 5 000 USD par utilisateur — un coût total sur 3 ans pour 5 utilisateurs (formation incluse) qui dépasse les 175 000 USD. KiCad, lui, est gratuit et open-source. Pour les petites structures et les indépendants, le choix est vite fait. Pour les grandes équipes, la question est plus nuancée : Altium offre une intégration cloud (Altium 365), une gestion des composants centralisée et un support commercial — des arguments qui pèsent dans les décisions d’entreprise.

Mais KiCad progresse sur tous les fronts : importateurs natifs, routage différentiel, variantes de conception, DRC graphique. Et l’écosystème de plugins et de bibliothèques tierces ne cesse de s’étoffer. Le site awesome-kicad référence désormais une vingtaine d’outils complémentaires, des générateurs de bibliothèques aux autorouteurs GPU.

Conclusion : KiCad, laboratoire de l’EDA augmentée

En septembre 2026, KiCad n’est plus un simple outil open-source pour hobbyistes : c’est une plateforme professionnelle, en constante évolution, portée par une communauté active et un écosystème tiers florissant. La série 10.0.x a démontré la maturité du projet — six correctifs en six mois, une stabilisation exemplaire — et les chantiers structurels (bibliothèques générées, importateurs natifs, automatisation) dessinent les contours de la 11.0.

L’IA, elle, reste en périphérie : portée par des plugins et des services tiers, elle n’a pas encore intégré le cœur de KiCad. Mais les signaux sont là — l’enquête Weidmuller, les serveurs MCP, les autorouteurs GPU — et il serait surprenant que la 11.0 ignore complètement cette tendance. En attendant, les concepteurs peuvent exploiter dès aujourd’hui les outils existants : scripts Python pour l’automatisation, plugins d’IA pour l’assistance, autorouteurs GPU pour les designs complexes.

Une chose est sûre : l’EDA open-source n’a jamais été aussi vivante, et KiCad en est le fer de lance.

Sources

• KiCad 10.0.5 Release — annonce officielle
• KiCad Downloads — version actuelle 10.0.6
• KiCad AI in 2026: Copilots, Plugins, and Generators That Actually Work — 31 juillet 2026
• Weidmuller PCB Design Survey Reveals AI Tool Impacts — 24 juillet 2026
• GPU-Accelerated Autorouter Handles Monstrous PCB Designs — 2 juillet 2026
• KiCad MCP Server by Seeed-Studio — 16 juillet 2026
• PCB Auto Router — 27 juillet 2026
• Local power labels – how? — 3 août 2026
• OSH Park / KiCad snafu — 22 juillet 2026
• Git with KiCad – Version control for PCB design workflows — juin 2026
• EAGLE vs KiCad en 2026 — mai 2026
• KiCad Python Scripting: pcbnew API for CI Automation — 24 juillet 2026
• The 10 Best PCB Design Software Tools in 2026 — 10 août 2026
• KiCad Autorouting Made Easy — 13 août 2026

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