Kicad Master · 17 October 2026KiCad 10.0, six mois après : ce qui a réellement changé dans l’atelier du concepteur PCB
Sortie en mars 2026, la dixième version majeure de KiCad a eu le temps de se décanter — et de se patcher, jusqu’à une 10.0.7 en préparation à l’automne. Six mois plus tard, on peut trier ce qui transforme vraiment une journée de travail de ce qui relève du coup de peinture. Verdict d’atelier, sans complaisance.
Six mois avec la 10.0 : ce qui a vraiment changé dans l’atelier
Il y a deux façons de lire une release. La première, c’est le jour J : on télécharge, on ouvre un vieux projet, on clique partout, on s’enthousiasme pour une icône, on rage sur un menu déplacé. La seconde, c’est six mois après : on a routé trois cartes avec, on a migré une bibliothèque maison, on a poussé un DRC jusqu’à l’export Gerber, et là seulement on sait ce qui a tenu la route.
C’est cette seconde lecture que nous proposons ici. KiCad 10.0.0 est sorti en mars 2026, et l’automne 2026 nous offre le recul nécessaire — d’autant que la branche a continué de vivre : la 10.0.6 est sortie le 29 août 2026, et une 10.0.7 Release Candidate 2 était disponible le 3 octobre 2026. Autrement dit, la version que vous installerez aujourd’hui n’est plus tout à fait celle de mars : elle a absorbé une demi-année de correctifs.
Le fil conducteur de ce décryptage est simple : confronter chaque promesse à un projet témoin. Une carte mixte analogique/numérique, avec sa part de contraintes de fabrication et son export de fabrication à produire. Pas un benchmark synthétique, pas une démo marketing — un vrai bout de cuivre qui doit sortir de l’atelier et partir chez le fabricant.
Une précision de méthode, d’emblée. Les sources publiques officielles (le blog kicad.org, la documentation 10.0) confirment l’existence et la trajectoire de la branche, mais ne fournissent pas de métriques chiffrées détaillées sur les performances. Là où un chiffre n’est pas sourcé, nous resterons qualitatifs plutôt que d’inventer un temps de chargement. C’est une discipline de lecture qui vaut aussi pour vous, lecteur : méfiez-vous des « 2x plus rapide » sans protocole.
De la 9.x à la 10.0 : le calendrier, les attentes, et ce que le blog officiel a réellement annoncé
KiCad suit depuis plusieurs cycles un rythme de release annuel, avec une branche stable qui reçoit des correctifs pendant que la branche suivante se développe. La 10.0 s’inscrit dans cette continuité : une version majeure, puis une série de patchs — 10.0.1, 10.0.2, et ainsi de suite — jusqu’à ce que la prochaine majeure prenne le relais.
Ce qui est documenté de façon certaine, c’est la mécanique institutionnelle du projet. KiCad est soutenu financièrement via The Linux Foundation, en tant qu’organisation à but non lucratif 501(c)(6) aux États-Unis, avec des dons collectés par carte de crédit ou bon de commande en USD. Cette structure finance des développeurs, et c’est elle qui explique la régularité des cycles et la présence d’une documentation versionnée par branche — un luxe que peu de projets open source s’offrent.
Ce qui relève en revanche de la reconstitution, et qu’il faut assumer comme tel : le calendrier détaillé de développement de la 10.0 (jalons intermédiaires, date exacte du feature freeze, contenu précis du billet de release) n’est pas accessible dans les sources que nous avons pu consulter. Le billet officiel « Version 10.0.0 Released » existe, son URL est datée de mars 2026, mais son contenu textuel n’est pas repris ici. Nous ne comblerons pas ce vide par des suppositions.
Un point de contexte utile pour situer l’ampleur du travail : la page d’accueil du projet décrit un outil qui gère déjà des designs hiérarchiques à plusieurs centaines de feuilles, un simulateur SPICE intégré, un ERC, un routeur interactif et une visionneuse 3D avec raytracer. La 10.0 n’invente donc pas ces briques — elle les fait évoluer. C’est une nuance importante : on ne juge pas une release majeure sur l’existence de fonctionnalités, mais sur la qualité de leur exécution au quotidien.
L’éditeur de schéma et la hiérarchie : ce qui se ressent dès la première feuille
Sur le projet témoin — une carte mixte avec sa partie analogique sensible et sa partie numérique dense — c’est paradoxalement le schéma qui donne la première impression. Pas parce qu’il aurait été révolutionné, mais parce que les frictions quotidiennes s’y accumulent vite.
La hiérarchie à grande échelle. KiCad gère depuis longtemps des designs hiérarchiques à plusieurs centaines de feuilles. Ce qui change à l’usage en 10.0, c’est la fluidité avec laquelle on navigue dans cette arborescence quand elle grossit : ouvrir une feuille, remonter au parent, retrouver un net à travers les niveaux. Sur un design à feuilles multiples, ces micro-opérations se répètent des centaines de fois par session. Un gain de quelques dixièmes de seconde par opération se transforme en dizaines de minutes sur une journée. C’est là que se joue le vrai confort — pas dans une fonctionnalité spectaculaire, mais dans l’absence de friction.
L’ERC et sa lisibilité. Le vérificateur de règles électriques reste l’outil qui attrape les erreurs bêtes avant qu’elles ne coûtent un respin. Sur un schéma mixte, la difficulté est de distinguer le faux positif du vrai problème. Un ERC trop bavard noie l’information ; un ERC trop discret laisse passer. La qualité d’un ERC se mesure à ce ratio signal/bruit, et c’est un critère qu’aucune fiche produit ne met en avant.
Le simulateur SPICE intégré. C’est probablement l’élément le plus sous-estimé du workflow schéma. Sur une carte mixte, pouvoir vérifier un filtre analogique ou un point de polarisation sans quitter l’éditeur change la nature du travail : on ne « dessine » plus un schéma en espérant qu’il fonctionne, on le vérifie au fur et à mesure. Pour un concepteur analogique, c’est un gain structurel. Pour un concepteur purement numérique, c’est un outil qu’on n’ouvrira jamais — et c’est très bien ainsi.
Un cas concret relevé dans les retours d’utilisateurs de la branche 10.0 : l’apparition des labels d’alimentation locaux, une nouveauté signalée sur le forum officiel en août 2026, avec la confusion que son activation a pu générer chez certains. C’est l’illustration typique d’une fonctionnalité utile mais dont l’ergonomie d’accès mérite d’être apprivoisée — un rappel que la documentation versionnée n’est pas un luxe.
Layout et routage interactif : le gain réel sur une carte mixte analogique/numérique
Passons au cuivre. C’est là que se concentrent les attentes, et là aussi que les désillusions guettent.
Le routeur interactif. KiCad propose historiquement deux modes complémentaires : Walk Around (le tracé contourne les obstacles) et Shove (le tracé pousse les pistes existantes pour se frayer un chemin). Sur une carte mixte, le mode Shove est précieux dans les zones denses, mais il devient contre-productif quand on veut préserver l’intégrité d’un plan de masse ou d’un chemin analogique sensible. La bonne pratique — et elle reste vraie en 10.0 — consiste à configurer finement les règles avant de router, puis à valider systématiquement par DRC. Un guide de routage publié en août 2026 résume bien cette séquence : règles d’abord, placement ensuite, routage assisté, validation DRC et fabrication en dernier.
Le point noir documenté : la fluidité. Il faut le dire sans détour, parce que c’est le genre d’information qu’on ne trouve pas dans un communiqué. Un fil du forum officiel daté du 12 août 2026 rapporte un problème sérieux de performance dans l’éditeur PCB sur les versions 10.0.4 et 10.0.5 : le déplacement d’une piste déjà routée devient extrêmement lent, au point que la 10.0.5 est décrite comme « inutilisable » par l’utilisateur concerné. C’est exactement le type de régression qui justifie notre exercice de recul : sur le papier, tout va bien ; à l’usage, une opération banale — déplacer un segment existant — peut devenir un calvaire. La bonne nouvelle, c’est que la branche a continué de progresser : la 10.0.6 du 29 août puis la 10.0.7 en préparation à l’automne visent précisément ce genre de correctifs.
La visionneuse 3D avec raytracer. Sur une carte à contraintes mécaniques — connecteurs, hauteur de composants, dégagement sous un boîtier — le rendu 3D réaliste n’est pas un gadget. Vérifier qu’un condensateur électrolytique ne tape pas dans le capot, qu’un connecteur s’aligne avec la découpe, cela se fait en 3D, pas sur un dessin 2D. Le raytracer intégré et l’éclairage personnalisable rendent cette vérification plus lisible qu’un rendu filaire. C’est un gain réel, mais uniquement pour ceux qui ont une contrainte mécanique à tenir.
L’autoroutage. Il faut être clair : l’autoroutage n’est pas un substitut au routage manuel sur une carte mixte. Les solutions tierces comme Freerouting existent et s’intègrent, mais un retour de régression daté du 28 août 2026 signale que la version 2.3.0 produit des routes qui violent leurs propres contraintes de clearance sur des cartes que la 2.2.4 routait proprement. Autrement dit : l’autoroutage reste un outil à valider systématiquement, jamais à faire confiance aveuglément.
DRC : le nouveau moteur à l’épreuve des contraintes de fabrication
Le DRC est le cœur de la valeur ajoutée d’un outil EDA. C’est lui qui transforme un dessin en carte fabricable, ou qui vous évite un lot de cartes bonnes à jeter.
Ce qu’on attend d’un DRC en 2026. Trois choses : qu’il connaisse les règles réelles du fabricant (largeur minimale de piste, clearance, diamètre de perçage, anneau d’âme), qu’il les vérifie vite sur une carte dense, et qu’il ne produise pas de faux positifs en série. Le troisième critère est le plus discriminant : un DRC qui crie au loup sur cinquante violations inexistantes est un DRC qu’on finit par ignorer — et un DRC ignoré ne sert à rien.
La confrontation au jeu de règles fabricant. Sur le projet témoin, la démarche est la suivante : on encode les contraintes du fabricant dans les règles de conception, on lance le DRC, on trie. Ce que le DRC attrape désormais, c’est l’ensemble des violations géométriques classiques — pistes trop fines, espacements insuffisants, perçages hors gabarit, anneaux d’âme trop minces. Ce qu’il laisse encore passer relève de l’intention : une piste analogique qui longe une piste numérique sur toute sa longueur ne viole aucune règle géométrique, mais c’est une erreur de conception. Le DRC vérifie la fabricabilité, pas la qualité électrique du routage.
Compatibilité ascendante. Point crucial pour la migration : les règles DRC écrites pour la 9.x doivent continuer de fonctionner. C’est un des points à tester en priorité lors du passage, car une règle silencieusement ignorée est plus dangereuse qu’une règle absente — on croit être protégé alors qu’on ne l’est plus.
Le DRC comme garde-fou d’autoroutage. Avec la montée des outils de routage automatique et des assistants IA, le DRC change de rôle : il devient le filet de sécurité obligatoire. Un article d’août 2026 sur le routage KiCad insiste sur ce point — chaque carte routée automatiquement doit être validée par DRC et par les vérifications de fabrication. Le DRC n’est plus seulement un outil de vérification finale, c’est le contrôle qualité d’un processus partiellement automatisé.
Bibliothèques et API plugins : la refonte qui se voit dans le workflow
C’est l’axe le plus structurant à long terme, et le moins spectaculaire à court terme.
La gestion des bibliothèques. Une bibliothèque, dans un flux de conception professionnel, c’est un actif : symboles, empreintes, modèles 3D, tous versionnés et partagés. La bibliothèque officielle KiCad contient « des milliers » de symboles selon la description du projet — un chiffre volontairement qualitatif, faute de décompte précis dans nos sources. Le vrai enjeu n’est pas la taille de la bibliothèque officielle, mais la robustesse de la vôtre : comment vous migrez vos composants maison, comment vous gérez les variantes, comment vous évitez qu’une empreinte modifiée ne casse silencieusement un design existant.
L’écosystème de plugins. C’est ici que la 10.0 a enclenché quelque chose de visible. Deux exemples datés le montrent.
Le premier est le plugin breadboard, repéré par Hackaday en avril 2026. L’idée : permettre de passer du schéma à une implémentation sur plaque d’essai. C’est révélateur de ce que l’écosystème peut désormais faire — des outils qui ne relèvent pas du flux « schéma → PCB » classique, mais qui adressent des besoins périphériques (prototypage, pédagogie, vérification). Un plugin qui n’aurait probablement jamais vu le jour dans un écosystème fermé.
Le second est plus ambitieux : Konnect, un plugin natif pour KiCad 10 écrit en Rust, qui transforme Claude en assistant de conception via MCP — relevé par DevTrends le 7 septembre 2026. C’est la démonstration que l’API de KiCad 10 est suffisamment ouverte et stable pour qu’on y branche un LLM. Que l’on soit enthousiaste ou sceptique sur l’IA en conception électronique, le fait technique est là : l’écosystème peut désormais construire ce genre d’intégration.
Ce que l’écosystème ne peut pas encore faire. Il faut tempérer. Un état des lieux de l’IA dans KiCad publié 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 schéma-puis-export, et la génération de composants par IA. Trois méthodes, avec chacune leurs limites claires. Les copilotes expérimentaux, comme ALT TAB Circuit Copilot, restent classés « expérimental ». Autrement dit : l’écosystème est vivant, mais il n’est pas encore mature. Les plugins qui tiennent la production restent minoritaires.
Migration depuis la 9.x : coût réel, pièges de compatibilité, stabilité des premiers patchs
C’est la question que tout le monde se pose, et la réponse dépend de votre situation.
Ce que coûte le passage. Trois chantiers principaux : la conversion des bibliothèques, la reprise des règles DRC, et la vérification des scripts et plugins. Le premier est le plus long si vous avez une bibliothèque maison riche. Le deuxième est le plus risqué : une règle mal reprise peut passer inaperçue jusqu’à ce qu’un défaut de fabrication vous la révèle. Le troisième est le plus imprévisible : un plugin qui fonctionnait en 9.x peut nécessiter une mise à jour.
Les pièges documentés. Un cas concret et instructif : un utilisateur migrant un projet Altium vers KiCad 10.0.6 a rapporté sur le forum officiel, le 1er septembre 2026, un avertissement ERC « Symbol pin or wire end off connection grid » sur presque chaque broche et chaque fil. Le projet importé était issu d’Altium Designer 25.6.2. Ce type de problème — décalage de grille après import — est classique et rappelle qu’un import n’est jamais une conversion propre : il faut repasser sur la grille, vérifier les connexions, relancer l’ERC. À noter au passage : KiCad 10.0.0 n’embarque pas d’importateur natif Altium, ce qui rend ces migrations d’autant plus délicates.
La stabilité des premiers patchs. Le rythme est instructif. Après la 10.0.0 de mars 2026, la branche a enchaîné les correctifs : la 10.0.6 est sortie le 29 août 2026, avec sa Release Candidate 1 le 18 août, et la 10.0.7 approchait à l’automne (RC1 le 27 septembre, RC2 le 3 octobre 2026). Cette cadence — environ un correctif tous les mois et demi — est le signe d’une branche active et suivie. Mais elle indique aussi qu’il a fallu plusieurs mois pour stabiliser des points importants, notamment les performances de l’éditeur PCB.
La documentation à relire. La documentation 10.0 est versionnée par branche, ce qui signifie qu’elle décrit précisément la version que vous utilisez. Avant de migrer, c’est le premier réflexe : parcourir les sections qui touchent votre workflow — bibliothèques, règles de conception, export de fabrication. Une heure de lecture en amont évite souvent une journée de débogage en aval.
Verdict nuancé : pour qui la 10.0 est un vrai gain, pour qui elle peut attendre
Tranchons, par profil.
Celui qui gagne immédiatement à sauter le pas. Le concepteur qui travaille sur des cartes mixtes avec simulation analogique, contraintes mécaniques à vérifier en 3D, et qui dépend d’un écosystème de plugins pour automatiser des tâches répétitives. Pour lui, la 10.0 apporte un confort cumulatif réel : simulation intégrée, 3D exploitable, API ouverte. Le gain n’est pas dans une fonctionnalité unique, mais dans la somme des micro-améliorations.
Celui pour qui la 9.x reste suffisante. Le concepteur qui fait des cartes numériques simples, sans contrainte mécanique forte, sans besoin de simulation, sans dépendance à des plugins. Pour lui, la migration représente un coût (bibliothèques, règles) pour un bénéfice marginal. Attendre la prochaine majeure, ou migrer à l’occasion d’un nouveau projet plutôt que sur un projet en cours, est parfaitement raisonnable.
Le cas où le numéro de version masque du vernis. Il faut le dire : toutes les nouveautés d’une release majeure ne se valent pas. Certaines sont cosmétiques, d’autres corrigent des irritants anciens sans transformer le workflow. Le tri se fait à l’usage, sur votre propre projet — pas sur une liste de fonctionnalités.
Les critères concrets de décision. Trois questions à se poser : (1) Ai-je une contrainte de fabrication ou mécanique que la 10.0 adresse mieux ? (2) Est-ce que je dépends de plugins ou de scripts qui nécessitent une vérification de compatibilité ? (3) Quelle est ma tolérance au risque de migration sur un projet en cours ? Si les réponses penchent vers « oui, oui, faible », attendez. Si elles penchent vers « oui, non, élevée », foncez.
Un dernier élément de contexte pour situer KiCad dans le paysage : face à un Altium Designer facturé entre 3 850 et 5 000 USD par utilisateur et par an, avec une formation à 1 000-2 000 EUR par personne et un coût total dépassant 175 000 USD sur trois ans pour cinq postes, KiCad reste gratuit. Ce n’est pas un argument de qualité — c’est un argument de contexte. La question n’est pas « KiCad vaut-il Altium ? », mais « pour mon usage, le delta de fonctionnalités justifie-t-il le delta de prix ? ». Pour beaucoup de concepteurs, la réponse est non.
Ce que la 10.0 change pour la suite : écosystème, documentation, prochaines releases
La vraie réussite d’une release majeure ne se mesure pas à ce qu’elle apporte le jour de sa sortie, mais à ce qu’elle rend possible ensuite. Sur ce plan, la 10.0 a enclenché une dynamique intéressante.
L’écosystème. Des plugins comme le breadboard ou Konnect montrent qu’une communauté construit sur l’API de KiCad. Cette dynamique est cumulative : plus l’API est stable, plus les plugins sont nombreux, plus l’outil devient attractif, plus la communauté grandit. Le signal le plus encourageant est la diversité des usages — du prototypage pédagogique à l’assistance IA, en passant par l’automatisation de tâches de layout comme la génération de grilles de vias de stitching, documentée dans plusieurs tutoriels de 2026.
La documentation versionnée. La documentation 10.0 est un actif sous-estimé. Elle permet à chaque utilisateur de consulter la documentation exacte de sa version, sans ambiguïté. C’est un investissement du projet dans la qualité de l’expérience utilisateur, et c’est ce qui distingue un outil professionnel d’un projet amateur.
La trajectoire. Le projet est soutenu par la Linux Foundation, ce qui lui donne une stabilité institutionnelle rare dans l’open source. Le rythme de release est régulier, les correctifs suivent, la documentation est versionnée. Tout indique que la branche 10.x continuera de recevoir des correctifs jusqu’à la prochaine majeure.
Ce qu’il faut surveiller. Trois choses : la résolution des problèmes de performance de l’éditeur PCB (le point noir documenté cet été), la maturation des plugins IA (encore expérimentaux), et l’arrivée de la prochaine majeure. Pour se préparer, le meilleur investissement reste le même : lire la documentation versionnée, tester la migration sur un projet secondaire avant de la faire sur un projet critique, et valider systématiquement par DRC.
Six mois après, le verdict est nuancé mais clair : la 10.0 n’est pas une révolution, c’est une maturation. Et dans un outil de conception, la maturation vaut souvent mieux qu’une révolution.
Sources
- Version 10.0.0 Released | KiCad
- KiCad | 10.0 | English | Documentation | KiCad
- KiCad – Schematic Capture & PCB Design Software
- Download – KiCad
- Downloads | KiCad EDA
- Windows Downloads – KiCad
- KiCad – Wikipedia
- This KiCAD Plugin Enables Breadboarding — Hackaday
- KiCad 10.0.4 / 10.0.5 – extremely slow track movement in PCB Editor (forum.kicad.info)
- Altium → KiCad 10 import: "Symbol pin or wire end off connection grid" (forum.kicad.info)
- Local power labels – how? (forum.kicad.info)
- KiCad Autorouting Made Easy: Walk Around, Shove, and Freerouting — rottenwifi.com
- KiCad AI in 2026: Copilots, Plugins, and Generators That Actually Work — protoflow.ai
- Как подключить Claude к KiCad 10 — DevTrends
- 2.3.0 regression: routes ship self-reported clearance violations (github.com)
- The 2026 PCB Design Software List: KiCad, Altium, and EasyEDA Compared — electricalflux.com
- KiCad vs Altium in 2026: Where the Free Tool Actually Competes — protoflow.ai
- PCB Design Software in 2026: What Beginners Should Compare — engineering.com
Article recherché et rédigé automatiquement · Magazine Electrosens