Electrosens R&D

KiCad 10 en 2026 : ce que les concepteurs PCB attendaient vraiment (et ce qui reste à prouver)

Electrosens Kicad Master · 11 October 2026

KiCad 10 en 2026 : ce que les concepteurs PCB attendaient vraiment (et ce qui reste à prouver)

KiCad 10.0.6 est sorti le 29 août 2026, la 10.0.7 pointe déjà le bout de son nez en release candidate. Derrière la mécanique de versions, une vraie question : la dixième mouture a-t-elle tenu ses promesses dans le quotidien du concepteur PCB ? Bilan sans complaisance, entre avancées réelles, trous dans la raquette et signaux pour la suite.

Il y a une manière paresseuse d’écrire sur une nouvelle version de KiCad : recopier le changelog et l’appeler un article. Ce n’est pas ce qu’on va faire. Parce que la vraie information, en 2026, ne se trouve pas dans la liste des correctifs de la 10.0.6 — elle se trouve dans les fils de discussion où des concepteurs expliquent que déplacer une piste déjà routée est devenu « extrêmement lent », dans les rapports d’import ratés depuis Altium, dans les plugins qui poussent l’IA au cœur du flux de travail. Voilà le matériau d’un bilan honnête.

Ce que la 10 promettait, ce que le forum attendait : radiographie d’une release sous pression

Commençons par un constat qui fâche : sur le papier, la matière documentaire officielle autour de KiCad 10 est mince. Le site historique du projet affiche encore un copyright « © 2018-2020 1BitSquared » — indice têtu que certaines pages n’ont pas bougé depuis des années. Ce qui est solidement établi, en revanche, c’est la cadence de maintenance : KiCad 10.0.6 est annoncée le 29 août 2026 comme version stable de correction de bugs, après une release candidate 1 le 18 août. Puis 10.0.7 RC1 le 27 septembre, RC2 le 3 octobre. Autrement dit, une branche 10.x qui vit, qui corrige, et qui ne se contente pas d’un coup d’éclat marketing.

Ce rythme raconte quelque chose d’important sur le projet : KiCad ne se développe plus comme un logiciel qui sort une grosse version tous les deux ans et disparaît dans la nature. Il fonctionne comme une plateforme maintenue en continu, avec des points de correction réguliers. C’est exactement ce qu’attend un concepteur professionnel : pas des promesses, des correctifs.

Les attentes, elles, se lisent en creux dans ce que la communauté a fini par obtenir — et dans ce qu’elle réclame encore. Le projet est financé via The Linux Foundation (une organisation à but non lucratif 501(c)(6) américaine), avec des dons par carte de crédit ou bon de commande en USD. Ce modèle a une conséquence directe : KiCad avance au rythme de ses contributeurs et de son financement, pas au rythme d’un roadmap trimestriel d’éditeur commercial. Ça explique à la fois l’ampleur de certaines avancées et la persistance de trous béants.

Un dernier élément de contexte : l’écosystème se structure. La quatrième conférence asiatique KiCon se tiendra à Shenzhen du 5 au 7 novembre 2026, au Huaqiang Plaza Hotel. Une conférence annuelle en Asie, sur le sol de l’électronique mondiale, ce n’est plus un projet confidentiel — c’est une communauté qui a pignon sur rue.

Saisie de schéma : la hiérarchie qui tient enfin, la simulation qui reste un chantier

L’éditeur de schéma de KiCad supporte depuis longtemps des conceptions hiérarchiques avec des centaines de feuilles, des symboles personnalisés ou issus de la bibliothèque officielle, ainsi qu’un simulateur SPICE intégré couplé à un vérificateur de règles électriques (ERC). Sur ce socle, la 10.x n’a pas réinventé la roue — elle a consolidé.

Source : en.wikipedia.org

Là où le quotidien du schématiste change vraiment, c’est dans les détails d’ergonomie. Un exemple concret, discuté sur le forum en août 2026 : les « local power labels », une nouveauté de KiCad 10 qui permet de rendre local un label d’alimentation. Sauf que la documentation manque, et les utilisateurs cherchent encore comment activer le réglage — un fil de discussion du 3 août 2026 montre des concepteurs qui tâtonnent, essayant d’éditer un label existant sans trouver l’option. Voilà le genre de friction qui ne figure dans aucun communiqué : une fonctionnalité existe, mais son découvrabilité laisse à désirer.

Sur la simulation intégrée, le chantier reste ouvert. Le SPICE est là, l’ERC aussi, mais l’ergonomie de l’environnement de simulation n’a pas la maturité d’un outil dédié. Pour un concepteur qui simule trois amplis op et un filtre, c’est suffisant. Pour une équipe qui veut faire de la simulation un vrai garde-fou de conception, il faut encore bricoler. C’est le lot commun des fonctions « intégrées mais pas finies » : elles dépannent sans convaincre.

Le point positif, c’est que la hiérarchie tient. Les conceptions à nombreuses feuilles, longtemps source de lenteurs et d’incohérences, sont désormais gérables dans un flux normal. Ce n’est pas spectaculaire, mais c’est exactement le genre de fondation sur laquelle on construit un projet sérieux.

Routage : le push-and-shove entre en scène, mais à quel prix sur les gros boards ?

C’est le cœur du métier, et c’est là que le bilan est le plus contrasté. KiCad 10 propose un routeur interactif avec les modes « Walk Around » et « Shove » — le fameux push-and-shove qui repousse les pistes existantes pour faire de la place à la nouvelle. Un guide de routage publié le 13 août 2026 détaille d’ailleurs la marche à suivre : configurer les règles, placer les composants, utiliser Walk Around et Shove, intégrer Freerouting, puis valider chaque carte par DRC et vérifications de fabricabilité.

Sur le papier, la promesse est tenue. Le push-and-shove fonctionne, et pour un concepteur qui route une carte à quatre couches avec quelques centaines de nets, il change la donne : moins d’allers-retours manuels, moins de re-routage pénible quand on insère un composant tard dans le design. C’est le genre de fonctionnalité qui fait gagner des heures, pas des minutes.

Mais il y a un « mais », et il est sérieux. Un fil du forum daté du 12 août 2026 rapporte un problème de performance majeur : dans KiCad 10.0.4 et 10.0.5, déplacer une piste déjà routée est « extrêmement lent », au point que la 10.0.5 devient « inutilisable » pour l’auteur du message. Ce n’est pas un détail cosmétique : c’est précisément l’opération qu’on répète des dizaines de fois par heure lors d’un routage. Quand le geste de base devient pénible, tout le reste s’effondre.

Ce témoignage doit être lu avec prudence — un bug rapporté n’est pas une généralité, et la 10.0.6, sortie fin août, vise justement à corriger des bugs critiques. Mais il illustre une réalité structurelle : KiCad reste un logiciel dont les performances se dégradent quand la complexité grimpe. Sur un petit board, tout est fluide. Sur un design dense — beaucoup de couches, de nets, de contraintes — le routeur décroche plus vite qu’un outil commercial taillé pour ça.

Pour le tuning de longueur et d’impédance, les paires différentielles et la gestion des plans et des vias, la 10.x reste dans la continuité : fonctionnel, mais sans les automatismes avancés qu’on trouve chez les suites haut de gamme. Le stitching de vias, par exemple, se fait encore largement par script — un article de septembre 2026 explique comment générer une grille complète de vias de masse par script plutôt qu’à la main, et un tutoriel d’août 2026 vante un plugin qui remplit les plans de masse en un clic. Ces contournements communautaires disent tout : là où KiCad ne fournit pas nativement, la communauté comble.

DRC/ERC : des règles enfin scriptables, une couverture encore inégale

Le vérificateur de règles de conception a progressé, mais c’est un domaine où le diable se cache dans les faux positifs. Illustration parfaite : un fil du 1er septembre 2026 où un concepteur migre un projet Altium (version 25.6.2) vers KiCad 10.0.6 et se retrouve submergé d’avertissements ERC « Symbol pin or wire end off connection grid » — sur presque chaque broche et chaque extrémité de fil. Le design est correct ; c’est l’outil qui crie au loup.

Source : fr.wikipedia.org

Ce cas est révélateur de deux choses. D’abord, que l’import depuis Altium reste imparfait — l’importateur natif n’existe pas dans KiCad 10.0.0, et les concepteurs qui migrent doivent accepter une passe de nettoyage manuelle. Ensuite, que la sensibilité du DRC/ERC à la grille de connexion peut transformer une vérification utile en bruit de fond qu’on finit par ignorer. Et un DRC qu’on ignore ne sert à rien.

Côté positif, les règles personnalisées et les contraintes par classe de nets permettent désormais de scripter des vérifications sur mesure — un vrai gain pour les équipes qui ont des exigences de fabricabilité précises. La vérification de fabricabilité s’intègre progressivement au flux, notamment via des plugins et des outils de génération de Gerber. Mais la couverture reste inégale : certaines règles manquent, l’intégration directe avec les contraintes des fabricants n’est pas native, et les équipes continuent de contourner les trous avec des scripts maison.

Bibliothèques : du fichier local à la base de données partagée, la vraie révolution silencieuse

C’est peut-être le changement le plus structurant de ces dernières années, et celui dont on parle le moins. KiCad propose une bibliothèque officielle contenant « des milliers » de symboles — le chiffre reste vague, sans décompte précis ni date de mise à jour, ce qui en dit long sur la difficulté à mesurer cet écosystème. Mais l’enjeu réel n’est pas là.

L’enjeu, c’est le passage d’une gestion par fichiers locaux à une base de données partagée. Pour une équipe, c’est souvent la bascule la plus lourde : on quitte un modèle où chacun a ses fichiers sur son disque pour un modèle où les symboles, empreintes et variantes vivent dans un référentiel commun, synchronisé. Le gain est immense — plus de « quelle version du symbole as-tu ? », plus de divergence silencieuse entre postes. La gestion des variantes et des obsolescences devient possible, ce qui est indispensable dès qu’un produit vit plusieurs années.

Mais la migration est un chantier. Les outils de maintenance restent perfectibles, et une partie de l’écosystème de bibliothèques dépend encore de contributions communautaires dont la qualité est variable. C’est le paradoxe de KiCad : le projet vous donne les moyens de professionnaliser votre gestion de données, mais vous laisse souvent seul face à la mise en œuvre. Pour une petite équipe, c’est un investissement rentable. Pour un indépendant, c’est parfois surdimensionné.

Collaboration : Git dans le flux, revues de design et multi-utilisateurs, mythe ou réalité ?

Soyons clairs : le travail multi-utilisateurs simultané sur un même schéma ou un même PCB reste, en 2026, largement artisanal dans KiCad. La gestion des conflits sur des fichiers de conception n’a pas la robustesse d’un système pensé pour ça dès l’origine. Deux concepteurs qui éditent le même board en parallèle s’exposent à des fusions douloureuses.

Source : gizmodo.com

Cela dit, l’intégration de Git dans le flux de travail a progressé, et des services tiers accompagnent le mouvement — un guide Git dédié à KiCad existe chez Anchorpoint, signe que la demande est là. La logique est simple : versionner ses schémas et ses PCB comme on versionne du code, c’est déjà énorme. On obtient l’historique, les branches, les revues de conception via merge requests. Ce n’est pas du multi-utilisateurs temps réel, mais c’est un workflow d’équipe crédible.

La comparaison avec Altium est éclairante, mais pas forcément là où on l’attend. Altium impose un écosystème intégré, avec une gestion de données d’équipe native — et un prix qui va avec : entre 3 850 et 5 000 USD par utilisateur et par an, avec une formation facturée 1 000 à 2 000 EUR par personne. Sur trois ans, pour cinq postes avec formation, la facture dépasse 175 000 USD. KiCad, lui, est gratuit — mais vous payez en intégration à construire vous-même. C’est un arbitrage économique autant que technique.

Sous le capot : moteur de rendu, GPU, API Python et format de fichier — ce que ça change vraiment

Ici, il faut être honnête sur l’état de l’information. Les sources officielles disponibles ne détaillent pas d’architecture technique spécifique à la 10.x : pas de documentation publique d’un « nouveau moteur de rendu » ou d’une refonte d’UI attribuée à cette version. Ce qu’on sait de solide, c’est ce qui existe et fonctionne : un visualiseur 3D avec raytracer intégré et éclairage personnalisable, un éditeur PCB avec routeur interactif, des outils de visualisation et de sélection améliorés.

Là où le changement est tangible et documenté, c’est du côté de l’API Python. La documentation CI de l’API pcbnew a été publiée en juillet 2026 — un signal fort pour les développeurs de plugins. C’est cette API qui rend possible tout l’écosystème d’extensions, et son maintien actif conditionne la vitalité de l’outil. Un logiciel EDA sans API solide est un logiciel figé ; KiCad a compris que son avenir passait par là.

Sur le format de fichier et la compatibilité, la question de la pérennité des projets existants reste un point de vigilance. La migration depuis d’autres outils est imparfaite — on l’a vu avec Altium — et la compatibilité ascendante/descendante demande une attention constante. Pour un concepteur qui a dix ans de projets archivés, c’est un critère de choix aussi important que le routeur.

L’écosystème en 2026 : plugins, outils IA et la concurrence Altium/LibrePCB

C’est ici que le paysage a le plus bougé. L’IA a fait irruption dans le flux de travail KiCad, et de manière concrète. Une analyse publiée le 31 juillet 2026 recense trois méthodes réelles pour ajouter de l’IA à un workflow KiCad : les plugins in-editor, les outils de génération de schéma puis export, et la génération de composants par IA. Chacune a ses limites — aucune ne remplace un concepteur — mais elles existent et fonctionnent.

L’exemple le plus frappant vient de l’est : un article du 7 septembre 2026 décrit Konnect, un plugin natif pour KiCad 10 écrit en Rust, qui transforme Claude en assistant de conception via le protocole MCP. Autrement dit, on peut désormais brancher un modèle de langage directement dans KiCad pour l’aider à réfléchir schéma et routage. À côté de ça, des outils comme PCB Auto Router proposent un routage automatique accéléré par GPU, avec import KiCad et JLC EDA, routage de paires différentielles et longueurs appariées. Et Freerouting continue de vivre — avec ses ratés : une régression signalée fin août 2026 montre que la version 2.3.0 produit des routages qui violent leurs propres contraintes de clearance, là où la 2.2.4 routait proprement.

Face à ça, le positionnement concurrentiel se clarifie. Altium reste le haut de gamme : Windows uniquement, écosystème intégré, prix dissuasif. LibrePCB joue la carte de la légèreté et de l’open source pour des projets plus simples. Et Autodesk EAGLE a définitivement quitté le jeu : arrêt des ventes et du support le 7 juin 2026, fermeture des serveurs de licences à la même date. Un concurrent historique qui disparaît, c’est mécaniquement des concepteurs à récupérer — et KiCad est bien placé pour ça.

Critère KiCad 10.x Altium Designer LibrePCB
Coût Gratuit 3 850–5 000 USD/utilisateur/an Gratuit
Plateformes Windows, macOS, Linux Windows uniquement Multiplateforme
Formation Communauté, docs 1 000–2 000 EUR/personne Communauté
Import Altium natif Non — Non
Écosystème plugins Riche, via API Python Intégré, commercial Limité
Outils IA Plugins tiers (Konnect, générateurs) En développement Marginal

Ce qui reste à prouver : limites persistantes, dépendance communautaire et signaux pour la suite

Le bilan honnête tient en quelques lignes. KiCad 10 est un excellent outil pour une large majorité de projets : schématique solide, routage interactif crédible, gestion de bibliothèques professionnalisable, écosystème de plugins vivant, IA accessible. Pour un indépendant, une startup ou une PME qui ne peut pas justifier 175 000 USD sur trois ans, c’est un choix rationnel — souvent le seul choix rationnel.

Mais les limites persistent, et il faut les nommer. La performance sur les très gros designs reste le talon d’Achille : les rapports de lenteur sur le déplacement de pistes en 10.0.4/10.0.5 ne sont pas anecdotiques, ils touchent le geste le plus fréquent du métier. La courbe d’apprentissage, ensuite : KiCad n’est pas difficile à prendre en main, mais il devient exigeant quand on veut en tirer le maximum — scripts, API, gestion de bibliothèques partagées. Enfin, la dépendance à une communauté de bénévoles et à un financement fragile via The Linux Foundation reste une réalité structurelle. Ce n’est pas un défaut, c’est un modèle — mais il implique que les priorités de développement ne se décident pas dans une salle de conseil, et que certains chantiers attendent longtemps.

Les signaux pour la suite sont lisibles dans la cadence : une branche 10.x maintenue activement (10.0.7 en RC2 au 3 octobre 2026), une conférence asiatique en novembre, une API Python documentée en juillet, des plugins IA qui arrivent de partout. Le projet ne s’essouffle pas. Mais la question posée à tout concepteur en 2026 n’est pas « KiCad est-il bon ? » — la réponse est oui. La question est : « pour mon design précis, avec mes contraintes de performance et d’équipe, est-ce le bon outil ? » Et là, la réponse dépend entièrement de la taille de votre board et de la patience de votre équipe devant un déplacement de piste qui rame.

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 *