Electrosens R&D

KiCad 10 et la simulation : un an après, entre promesses tenues et chantiers ouverts

Electrosens Kicad Master · 4 November 2026

KiCad 10 et la simulation SPICE : six mois de terrain, de Sim.Pins aux correctifs — le bilan honnête

En mars 2026, KiCad 10.0.0 débarquait avec son lot d’annonces ambitieuses pour la simulation : Sim.Pins, intégration ngspice améliorée, nouvelles directives SPICE. Sept mois et sept correctifs plus tard — la 10.0.7, publiée le 7 octobre 2026 après deux release candidates les 27 septembre et 3 octobre, referme désormais le cycle 10.0.x — le bilan est plus nuancé que l’enthousiasme des premiers jours. Plongée dans les coulisses d’une fonctionnalité qui cristallise les attentes des concepteurs, entre bugs persistants, workarounds ingénieux et feuille de route prometteuse.

Sept mois après : la simulation dans KiCad 10, entre promesses et réalité du terrain

Souvenez-vous. Le 20 mars 2026, le projet KiCad publie la version 10.0.0, saluée comme une étape majeure pour l’EDA open source. Parmi les nouveautés les plus attendues, la simulation SPICE occupe une place de choix. Les notes de version officielles évoquent des améliorations significatives de l’intégration de ngspice, le moteur de simulation open source qui équipe KiCad depuis plusieurs versions. La communauté, déjà nombreuse à utiliser Eeschema comme interface graphique pour ngspice, espère des flux de travail plus fluides, des modèles mieux gérés et une expérience utilisateur enfin à la hauteur des outils commerciaux.

Sept mois plus tard, le constat est plus contrasté. Les versions 10.0.1 à 10.0.7 se sont succédé à un rythme soutenu — la dernière stable, la 10.0.7, est parue le 7 octobre 2026, après une première release candidate le 27 septembre et une seconde le 3 octobre — témoignant d’une volonté réelle de corriger les défauts. Mais les forums — EEVblog, KiCad.info, AllAboutCircuits — font remonter des problèmes concrets : modèles .subckt incompatibles, directives .lib mal interprétées, lenteurs dans l’éditeur PCB, erreurs de simulation sur des circuits pourtant simples. La fonctionnalité Sim.Pins, pourtant présentée comme une avancée majeure, reste mal documentée et source de confusion pour de nombreux utilisateurs.

Ce dossier propose un état des lieux honnête et pratique. Nous avons épluché les changelogs des versions 10.0.x, analysé les retours des forums et compilé les bonnes pratiques publiées par la communauté — notamment le récent guide pratique d’Element14, « KiCad 10 and SPICE: Practical Tips for Working with Circuit Simulations ». Objectif : vous donner une vision claire de ce qui fonctionne, de ce qui coince, et des contournements qui vous feront gagner un temps précieux.

Ce que la feuille de route avait promis (et ce qui a vraiment été livré)

Les annonces officielles accompagnant la sortie de KiCad 10.0.0 mettaient en avant plusieurs axes pour la simulation. Le billet de blog officiel, publié en mars 2026, promettait notamment une meilleure intégration de ngspice, avec une gestion plus fine des modèles et des directives SPICE. La fonctionnalité Sim.Pins était présentée comme une révolution : la possibilité d’affecter des nœuds de simulation directement sur les symboles, sans passer par des étiquettes globales ou des connexions explicites.

Versions correctives KiCad 10.0.x (2026)10.0.00version10.0.11version10.0.22version10.0.33version10.0.44version10.0.55version10.0.66version

Qu’en est-il réellement dans les versions 10.0.0 à 10.0.7 ? Les notes de version officielles, disponibles sur le dépôt GitLab du projet, confirment la présence de Sim.Pins dans l’éditeur de schémas. La fonctionnalité est bien là, accessible via le dialogue de simulation. Cependant, les promesses d’une intégration transparente avec la génération de netlist et la gestion des hiérarchies restent partiellement tenues. Plusieurs utilisateurs signalent des comportements inattendus lors de l’utilisation de Sim.Pins avec des sous-feuilles ou des symboles hiérarchiques, et la documentation officielle n’a pas été mise à jour de manière exhaustive.

Côté ngspice, l’intégration a été améliorée, mais pas sans heurts. La version 10.0.0 nécessitait une version récente de ngspice (>= 28) pour compiler correctement, comme l’a documenté le bug Gentoo #973022. Les versions ultérieures ont corrigé certains problèmes de compilation, mais des incompatibilités persistent avec certaines distributions de ngspice, notamment la version 46 utilisée par certains utilisateurs sous Linux.

Il faut aussi replacer KiCad 10 dans son contexte global, car la simulation n’est qu’un chantier parmi d’autres. La version 10 a enregistré plus de 7 609 validations uniques depuis la sortie de son prédécesseur en février 2025, avec l’ajout de 952 nouveaux symboles, 1 216 nouvelles empreintes et 386 nouveaux modèles 3D, comme le rappelle RaspberryMe. Le mode sombre Windows, les variantes de conception, l’éditeur graphique de règles DRC ou encore les importateurs Allegro/PADS/gEDA ont monopolisé une bonne partie de l’attention médiatique — Elektor en a fait ses gros titres. La simulation, elle, a progressé plus discrètement, et c’est précisément ce décalage qui nourrit la frustration.

En résumé, la feuille de route a été globalement respectée sur le papier, mais la réalité du terrain révèle des écarts significatifs entre les promesses et l’expérience vécue. Les fonctionnalités sont présentes, mais leur robustesse laisse à désirer, et la documentation n’a pas suivi le rythme des développements.

Sim.Pins décortiqué : comment ça marche dans l’éditeur de schémas

Sim.Pins est une fonctionnalité qui permet d’associer un nœud de simulation à un symbole directement dans l’éditeur de schémas. Concrètement, au lieu de définir des étiquettes globales ou des connexions explicites pour chaque nœud d’intérêt, l’utilisateur peut attribuer une propriété de simulation à une broche ou à un symbole. Cette propriété est ensuite utilisée lors de la génération de la netlist pour créer les nœuds SPICE correspondants.

L’idée est séduisante : elle simplifie la préparation d’un schéma pour la simulation, en évitant de polluer le schéma avec des éléments purement simulatoires. Dans la pratique, l’implémentation dans KiCad 10.0.x est fonctionnelle mais perfectible. Les utilisateurs rapportent que l’affectation des nœuds fonctionne bien pour les circuits simples, mais devient capricieuse dès que l’on aborde des schémas hiérarchiques. Les sous-feuilles et les symboles hiérarchiques ne sont pas toujours correctement pris en compte, ce qui conduit à des netlists incomplètes ou erronées.

Le dialogue de simulation a également été remanié par rapport à KiCad 9. De nouveaux onglets font leur apparition, notamment pour la gestion des courbes et des directives SPICE. La gestion des courbes est plus intuitive, avec la possibilité de visualiser plusieurs signaux simultanément et d’exporter les données au format CSV. Les directives SPICE (.tran, .ac, .dc, etc.) sont désormais gérées via un éditeur dédié, plus ergonomique que le simple champ de texte de KiCad 9.

Un point noir demeure : la documentation. Le forum KiCad.info regorge de questions sur Sim.Pins, et les réponses sont souvent vagues ou renvoient à des fils de discussion anciens. Un fil récent, « Sim.Pins – Globally Hiding and Problem w/ Capacitors », illustre les difficultés de prise en main : l’utilisateur ne comprend pas comment masquer globalement les Sim.Pins sur un schéma, et rencontre des problèmes avec les condensateurs polarisés. Les réponses, bien que fournies par des membres expérimentés, manquent de clarté et renvoient souvent à des solutions de contournement plutôt qu’à une explication pédagogique. La fonctionnalité est puissante, mais son apprentissage est rendu difficile par le manque de tutoriels clairs et d’exemples concrets. C’est un frein majeur pour les nouveaux utilisateurs, et même pour les vétérans qui n’ont pas suivi l’évolution pas à pas.

À noter que cette complexité de prise en main s’inscrit dans un contexte plus large : comme le souligne notre guide « KiCad 10 face aux débutants », la 10.0.x corrige encore des bugs critiques plusieurs mois après sa sortie, ce qui complique l’apprentissage pour qui découvre l’outil. La simulation n’échappe pas à cette règle.

10.0.0 → 10.0.7 : le marathon des correctifs, quels bugs de simulation ont été réglés ?

Depuis la sortie de la 10.0.0 le 20 mars 2026, sept versions correctives stables se sont succédé : 10.0.1, 10.0.2, 10.0.3, 10.0.4, 10.0.5, 10.0.6 (29 août 2026) et 10.0.7 (7 octobre 2026). Cette dernière a été précédée de deux release candidates, les 27 septembre et 3 octobre 2026. Chacune a apporté son lot de corrections, mais toutes n’ont pas concerné la simulation. Voici un panorama chronologique des correctifs liés à la simulation, basé sur les changelogs officiels et les retours de la communauté.

Source : youtube.com
Version Date Corrections liées à la simulation
10.0.0 20 mars 2026 Sortie initiale. Intégration de Sim.Pins, améliorations ngspice. Problèmes de compilation avec poppler et ngspice < 28.
10.0.1 Avril 2026 Correctifs de bugs génériques. Aucune correction majeure spécifique à la simulation signalée.
10.0.2 Mai-juin 2026 Corrections de stabilité. Améliorations de la gestion des directives SPICE.
10.0.3 Juin-juillet 2026 Correctifs pour les modèles ngspice cassés. Problèmes de convergence sur certains circuits.
10.0.4 Juillet 2026 Corrections de régressions de l’API Python. Améliorations de la génération de netlist.
10.0.5 22 juillet 2026 Correctifs critiques, notamment pour les lenteurs dans l’éditeur PCB. Améliorations de la simulation transitoire.
10.0.6 29 août 2026 Correctifs supplémentaires, notamment pour la compatibilité avec ngspice 46. Stabilisation générale.
10.0.7 7 octobre 2026 Dernière version stable de la branche 10.0.x. Correctifs critiques et améliorations mineures ; clôture du cycle avant la 11.0.

Ce tableau, établi à partir des sources disponibles, montre que les corrections ont été progressives et ciblées. La version 10.0.3 a notamment résolu un problème récurrent de modèles cassés pour certains composants, comme le LM358, qui ne simulait pas correctement avec ngspice-46. La version 10.0.5, publiée le 22 juillet 2026, a apporté des correctifs critiques pour les lenteurs extrêmes dans l’éditeur PCB, un problème signalé par de nombreux utilisateurs sur les versions 10.0.4 et 10.0.5. La 10.0.6 a poursuivi la stabilisation et consolidé la compatibilité avec ngspice 46. Enfin, la 10.0.7 — dont le billet officiel précise qu’elle « contient des correctifs critiques et d’autres améliorations mineures depuis la version précédente » — referme la branche 10.0.x, comme l’analyse notre dossier « KiCad 10.0.7 boucle la branche, la 11.0 se dévoile ».

Cependant, certains bugs restent en suspens. Les problèmes de convergence sur des circuits non linéaires, comme les convertisseurs DC-DC, ne sont pas entièrement résolus. Les régressions de l’API Python, qui permettent de scriptiser la simulation, ont été partiellement corrigées mais des incohérences subsistent entre les versions. Enfin, la compatibilité avec les modèles propriétaires de fabricants (TI, AD) reste un chantier ouvert, comme nous le verrons plus loin.

Ce qui coince encore : les remontées concrètes de la communauté

Les forums sont une mine d’or pour comprendre les difficultés réelles rencontrées par les utilisateurs. Sur EEVblog, un fil intitulé « KiCad 10.0.2 + ngspice-46 : warning no job defined » illustre un problème récurrent : la simulation ne démarre pas, ou se termine avec des messages d’erreur cryptiques. L’utilisateur explique avoir suivi les tutoriels à la lettre, mais le moteur de simulation refuse de lancer l’analyse demandée. La réponse des autres membres pointe vers une incompatibilité entre la version de ngspice embarquée et les directives générées par KiCad.

Sur AllAboutCircuits, un fil consacré à la simulation d’un compteur 74HC163 avec KiCad 10.0.4 relate une autre mésaventure : le circuit, pourtant simple, produit des résultats aberrants. Après investigation, il s’avère que le modèle SPICE du 74HC163, fourni par le fabricant, utilise des constructions .subckt que KiCad interprète mal — un problème de compatibilité qui n’a pas été entièrement corrigé dans les versions ultérieures. La parade consiste à éditer manuellement le modèle pour le rendre compatible, ou à utiliser un modèle alternatif issu de la bibliothèque ngspice standard.

Autre point de friction récurrent : les directives .lib. KiCad 10 a introduit une gestion plus fine de ces directives, mais certains utilisateurs rapportent que les chemins relatifs ne sont pas toujours résolus correctement, surtout lorsque le projet est déplacé d’une machine à l’autre. La solution consiste à utiliser des chemins absolus ou à placer les modèles dans le répertoire du projet, mais cela nuit à la portabilité.

Enfin, la question des modèles propriétaires reste épineuse. Les fabricants comme TI ou Analog Devices fournissent des modèles SPICE souvent encryptés ou dans des formats propriétaires que ngspice ne peut pas lire directement. KiCad 10 n’a pas résolu ce problème, et les utilisateurs doivent recourir à des convertisseurs ou à des modèles équivalents disponibles dans les bibliothèques open source.

Les bonnes pratiques qui marchent vraiment (et que la doc ne dit pas)

Malgré ces écueils, la communauté a développé un ensemble de pratiques éprouvées qui permettent de tirer le meilleur de la simulation dans KiCad 10. Le guide publié par Element14 en octobre 2026 en compile plusieurs, que nous avons recoupées avec les retours des forums.

Source : github.com

Première règle : toujours vérifier la version de ngspice. KiCad 10 embarque une version spécifique de ngspice, mais il est possible d’utiliser une version externe. Pour éviter les surprises, il est recommandé de vérifier la version via le dialogue de simulation et de s’assurer qu’elle correspond à celle attendue par les modèles utilisés. La commande ngspice --version en ligne de commande permet de vérifier la version système.

Deuxième règle : préférer les modèles .model aux .subckt lorsque c’est possible. Les modèles .model sont plus simples à gérer et moins sujets aux problèmes de compatibilité. Pour les composants qui n’existent qu’en .subckt, il est conseillé de tester le modèle dans ngspice en ligne de commande avant de l’intégrer à KiCad, afin d’isoler les problèmes.

Troisième règle : utiliser des étiquettes globales plutôt que Sim.Pins pour les schémas hiérarchiques. Tant que Sim.Pins n’est pas pleinement stabilisé pour les hiérarchies, les étiquettes globales restent plus fiables. C’est un contournement, mais il permet de travailler sans surprises.

Quatrième règle : sauvegarder les directives SPICE dans un fichier séparé. KiCad 10 permet de gérer les directives via l’éditeur dédié, mais il est souvent plus pratique de les conserver dans un fichier .sp séparé, référencé par une directive .include. Cela facilite la réutilisation et le versionnement.

Cinquième règle : tester la convergence avec des paramètres adaptés. Les problèmes de convergence sont fréquents avec les circuits non linéaires. L’ajout de directives .options comme reltol=0.01, abstol=1e-6 ou vntol=1e-6 peut aider. La directive .ic permet également de fixer des conditions initiales pour faciliter la convergence.

Ces pratiques, bien que non documentées officiellement, sont largement partagées sur les forums et permettent de contourner la plupart des problèmes rencontrés. Elles ne remplacent pas une correction des bugs, mais elles permettent de travailler efficacement en attendant.

L’écosystème qui change la donne : MCP, IA et plugins

Si la simulation elle-même progresse lentement, l’écosystème autour de KiCad 10 connaît une effervescence remarquable. La nouveauté la plus marquante de cette fin 2026 est sans conteste l’arrivée de Konnect, un plugin natif pour KiCad 10 qui permet à des assistants IA — Claude en tête — de concevoir schémas et circuits imprimés via le protocole MCP (Model Context Protocol). Développé en Rust sous forme d’un binaire unique, Konnect expose 228 outils couvrant la création de symboles, le placement, le routage et la vérification. Le blog Fellow en a détaillé le fonctionnement le 14 octobre 2026, et Adafruit a relayé l’information le 26 octobre 2026. La presse spécialisée russe (DevTrends) a également consacré un article à ce plugin le 7 septembre 2026, soulignant son potentiel pour automatiser les tâches répétitives.

Cette évolution s’inscrit dans un mouvement plus large : l’IA devient un assistant de conception à part entière, et KiCad 10 est la première version à offrir une intégration native via MCP. Pour les concepteurs, cela ouvre des perspectives intéressantes, notamment pour la génération de netlists, la vérification des règles de conception ou la suggestion de modèles SPICE. Mais cela pose aussi des questions de fiabilité : un modèle généré par IA n’est pas nécessairement correct, et la validation reste indispensable.

Autre évolution notable : l’intégration native de la SpaceMouse de 3Dconnexion, enfin stable dans KiCad 10. Cette fonctionnalité, longtemps attendue, facilite la navigation dans les schémas et les PCB. Elle est documentée sur le site de 3Dconnexion, qui propose également des vidéos de démonstration pour la CadMouse et la SpaceMouse.

Enfin, le projet KiCad continue de croître. Le rapport d’état 2026, évoqué dans notre dossier « KiCad 10.0.7 boucle la branche, la 11.0 se dévoile », révèle une armée de bénévoles et un budget en hausse, signe d’une communauté active et d’une gouvernance solide. La KiCon Asia 2026, qui se tiendra à Shenzhen du 5 au 7 novembre 2026, sera l’occasion de faire le point sur les avancées et de découvrir les projets de la version 11.0.

Vers la 11.0 : ce que l’on peut attendre pour la simulation

La version 10.0.7 marque la fin du cycle 10.0.x. Les yeux sont désormais tournés vers la 11.0, dont les premières esquisses ont été dévoilées dans le rapport d’état 2026. Si les détails restent flous, plusieurs pistes se dessinent pour la simulation.

Source : forum.kicad.info

Premièrement, la stabilisation de Sim.Pins devrait être une priorité. Les développeurs ont conscience des problèmes rencontrés et travaillent à une meilleure gestion des hiérarchies. Une documentation enrichie est également attendue, avec des exemples concrets et des tutoriels.

Deuxièmement, l’intégration de ngspice devrait être améliorée, avec un support plus large des versions et une meilleure gestion des modèles propriétaires. L’objectif est de rendre la simulation plus fiable et plus prévisible, en réduisant les messages d’erreur cryptiques.

Troisièmement, l’IA pourrait jouer un rôle croissant, via MCP et des plugins comme Konnect. L’idée est de faciliter la génération de modèles, la vérification des circuits et l’optimisation des paramètres. Mais cela pose des questions de validation et de confiance, qui devront être adressées.

Enfin, l’expérience utilisateur devrait être au cœur des préoccupations, avec une interface plus intuitive et des workflows plus fluides. La simulation ne doit plus être un obstacle pour les nouveaux utilisateurs, mais un outil accessible et puissant.

En attendant, la version 10.0.7 reste la référence pour les utilisateurs de KiCad 10. Elle corrige les bugs critiques et offre une base stable pour la simulation, à condition de connaître les bonnes pratiques et les contournements. C’est le prix de l’open source : une communauté active, des progrès réels, mais aussi des imperfections qui persistent.

Sources

Article recherché et rédigé automatiquement · Magazine Electrosens
📬 Restez à la pointe
Recevez chaque semaine les nouveautés de ce magazine par email.
💬 Une remarque, une correction ?
Aidez-nous à améliorer cet article. Nous prenons en compte vos retours.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *