Kicad Master · 31 October 2026

KiCad 10 en 2026 : le guide du concepteur PCB pour choisir, installer et exploiter la version qui compte

Il est 8 h 47 un lundi matin. Un projet doit partir en fabrication vendredi. Faut-il installer la 10.0.6, tenter la 10.0.7 Release Candidate, ou rester prudemment sur une branche plus ancienne ? En 2026, la réponse ne tient plus dans une phrase — elle dépend du canal de distribution, de la plateforme et du projet. Voici le panorama complet pour décider sans se tromper.

Lundi matin, 8 h 47 : la question qui fâche

Un concepteur PCB devant sa machine, un projet qui doit partir en fabrication, et une question apparemment simple : « quelle version de KiCad j’installe ? ». Pendant des années, la réponse tenait en une ligne : la dernière version stable. En 2026, cette réponse est devenue insuffisante. Non pas parce que KiCad serait devenu compliqué, mais parce que l’écosystème s’est stratifié : plusieurs canaux de distribution coexistent, plusieurs plateformes ont leurs propres contraintes, et surtout plusieurs versions mineures de la branche 10.x se succèdent à un rythme qu’il faut connaître pour ne pas se tromper.

Ce panorama a un objectif très concret : donner à un concepteur les clés pour décider quoi installer lundi matin, et comment structurer un environnement de travail qui ne s’écroulera pas à la prochaine mise à jour. Nous allons cartographier les canaux de distribution et leur cadence, établir une grille de choix entre stabilité et fonctionnalités, passer en revue les pièges classiques de l’installation et de la migration, expliquer comment faire cohabiter plusieurs versions, et enfin replacer KiCad face aux alternatives dans le paysage 2026.

Une précision méthodologique s’impose d’emblée, car elle conditionne tout le reste. Les sources officielles du projet — kicad.org, downloads.kicad.org, docs.kicad.org — sont bien référencées, mais leurs pages d’accueil affichent un copyright « © 2018-2020 1BitSquared » et ne publient pas de chronologie complète des versions. La documentation française accessible pointe encore vers la version 5.1. Autrement dit : le site officiel n’est pas une source de chronologie fiable, et cet article s’appuie sur les signaux datés disponibles — annonces de release, notes de version, retours de forum — en signalant explicitement les zones d’ombre plutôt qu’en inventant des numéros de version. C’est une discipline utile pour le lecteur : ce que vous ne trouvez pas daté à la source, ne le supposez pas.

Ce que le site officiel dit — et surtout ce qu’il ne dit pas

La page d’accueil de kicad.org est une page marketing. Elle décrit les capacités du logiciel — éditeur de schéma, éditeur PCB avec routeur interactif, visualiseur 3D avec raytracer, simulateur SPICE intégré, vérificateur de règles électriques (ERC) — sans citer un seul numéro de version 9.x ou 10.x. Le copyright « © 2018-2020 1BitSquared » et la mention du projet de démonstration iCEBreaker Bitsy trahissent une page qui n’a pas été remise à jour depuis des années. Ce n’est pas anecdotique : cela signifie que si vous cherchez sur la page d’accueil la réponse à « quelle est la dernière version ? », vous ne la trouverez pas.

La page de téléchargement officielle (kicad.org/download) n’est guère plus bavarde dans sa partie indexée : elle contient surtout un encart de don via The Linux Foundation (CommunityBridge / LFX, organisation 501(c)(6) basée aux États-Unis, en USD uniquement). Aucune liste de plateformes, aucun canal stable/nightly, aucun format de paquet n’y figure dans les extraits disponibles. Il existe bien une page dédiée aux téléchargements Windows et un portail downloads.kicad.org, mais leur contenu détaillé n’est pas accessible dans les sources indexées.

Conséquence pratique, et elle est importante : le site officiel n’est pas une source de chronologie. Pour savoir quoi télécharger, il faut aller vers downloads.kicad.org, les tags du dépôt GitLab, les notes de version et les annonces de release. C’est là que se trouvent les informations datées — et c’est précisément ce que nous avons pu reconstituer pour la branche 10.x.

Stable, nightly, pré-release : la carte des canaux et leur cadence

La branche 10.x de KiCad, en 2026, suit un cycle de publication qu’on peut reconstituer à partir des annonces officielles. Le fait le plus récent à notre disposition : le 3 octobre 2026, le projet a annoncé la disponibilité de la Release Candidate 2 de la version 10.0.7, précisant que « la version 10.0.7 sera publiée prochainement sauf si des problèmes critiques sont détectés lors des tests de cette release candidate ». Une Release Candidate 1 de cette même 10.0.7 avait été annoncée le 27 septembre 2026. On voit donc se dessiner une cadence : une RC1, une RC2, puis la release stable — un rythme de quelques semaines entre les étapes.

En amont, la version 10.0.6 a été publiée le 29 août 2026, avec sa propre Release Candidate 1 annoncée le 18 août 2026. La 10.0.6 était présentée comme une « bug fix release » contenant « des corrections de bugs critiques et d’autres améliorations mineures depuis la version précédente ». Ce qui confirme la logique du cycle : une majeure ouvre le cycle, les mineures corrigent, et chaque mineure passe par au moins une RC avant publication.

Voici la carte des canaux telle qu’on peut la lire en 2026 :

La logique de cadence est claire : les mineures (10.0.6, 10.0.7) se succèdent à un rythme de quelques semaines, chacune précédée d’une ou plusieurs RC. Les nightlies suivent le trunk en continu. Pour le concepteur, la règle est simple : la stable maintenue pour la production, la RC pour évaluer une bascule, la nightly en environnement isolé pour tester et reporter.

Un point d’attention : les numéros exacts et les dates doivent être vérifiés sur downloads.kicad.org au moment de l’installation. Les extraits disponibles permettent de dater les jalons de la branche 10.x, mais pas de garantir qu’aucune version plus récente n’est sortie depuis. La discipline du concepteur, ici, c’est de vérifier à la source — pas de se fier à un article, même le nôtre.

Windows, macOS Intel/ARM, Linux : la matrice des plateformes et ses angles morts

La question de la plateforme est souvent traitée comme un détail. En 2026, elle est devenue structurante, parce que les voies d’installation ont des propriétés très différentes en termes de mise à jour, d’isolation et d’intégration au bureau.

Windows. C’est la plateforme la mieux servie, avec une page dédiée (kicad.org/download/windows/) et des installeurs officiels. La version 10.0.6 y est disponible, et des sites tiers relaient même des versions localisées (on a ainsi vu circuler une build 10.0.6 en russe pour Windows le 9 septembre 2026). L’avantage : installation simple, mise à jour directe. La limite : pas d’isolation native — si vous mélangez stable et nightly dans le même profil utilisateur, vous prenez le risque d’écraser vos préférences.

macOS Intel et Apple Silicon. La question de la signature et de la notarisation est réelle, et un guide de septembre 2026 (NOVAKVM) documente précisément l’installation de KiCad 10.0.6 sur Mac Apple Silicon, avec vérification de l’architecture, validation des projets, des fichiers Gerber, des bibliothèques, des modèles 3D et des usages à distance. C’est un signal utile : la plateforme Apple Silicon est suffisamment mûre pour qu’un guide de « validation 2026 » existe, ce qui n’était pas le cas il y a quelques années. La limite connue : les chemins macOS diffèrent, et la cohabitation de versions demande des répertoires de configuration distincts.

Linux. La voie la plus riche, et la plus fragmentée : paquets de distribution, Flatpak, AppImage, PPA. Chaque voie a ses avantages — mise à jour automatique via le gestionnaire de paquets, isolation via Flatpak, portabilité via AppImage — et ses limites connues : retard des dépôts distro (une distribution peut proposer une version plus ancienne que la stable officielle), dépendances système, questions Wayland et HiDPI selon l’environnement de bureau. La matrice exacte doit être confirmée sur downloads.kicad.org, les extraits ne fournissant pas le détail par plateforme.

Un mot sur les performances, car elles conditionnent le choix de plateforme. Un fil de forum de septembre 2026 signale un problème sérieux : KiCad 10.0.4 / 10.0.5 — « extremely slow track movement in PCB Editor, 10.0.5 becomes unusable ». Autrement dit, une version mineure peut introduire une régression bloquante sur une opération courante. C’est exactement pourquoi la grille de choix qui suit n’est pas un luxe.

Choisir sa version : la grille de décision en cinq questions

Plutôt qu’un dogme, voici une grille de décision en cinq questions, à poser dans l’ordre.

1. Le projet est-il en production ou en exploration ? Si le projet doit partir en fabrication, la réponse est la stable maintenue (10.0.6 au moment de la rédaction, 10.0.7 dès sa publication). Si vous explorez, une RC ou une nightly en environnement isolé est acceptable — et même souhaitable pour anticiper.

2. L’équipe partage-t-elle des fichiers ? Si oui, tout le monde doit être sur la même version mineure. Un fichier ouvert par une version plus récente puis rouvert par une plus ancienne peut poser problème. La règle : une version par équipe, documentée.

3. Faut-il des fonctions récentes absentes de la version précédente ? La branche 10.x apporte son lot de nouveautés, et l’écosystème de plugins s’y adapte : le plugin Konnect (un binaire Rust unique, 228 outils, permettant à Claude et à d’autres assistants de concevoir schémas et circuits via MCP) est explicitement un plugin KiCad 10 natif. Si votre workflow dépend d’un plugin récent, la version est dictée par le plugin.

4. La plateforme impose-t-elle un canal ? Si vous dépendez du dépôt de votre distribution Linux, vous subissez son calendrier. Si vous voulez la dernière stable, il faut passer par Flatpak, AppImage ou les paquets officiels.

5. Le support de la branche est-il encore actif ? C’est la question la plus souvent oubliée. Avant de migrer, vérifiez la fin de support de votre branche actuelle. Une branche en fin de support ne reçoit plus de correctifs critiques — et un bug comme celui de la 10.0.5 peut vous bloquer sans recours.

La synthèse tient en trois lignes : production → stable maintenue ; évaluation → nightly ou RC en environnement isolé ; formation → stable + documentation. Et dans tous les cas, vérifier la fin de support avant de migrer.

Les pièges de l’installation et de la migration d’environnement

Les erreurs classiques sont peu nombreuses, mais coûteuses. Les voici, avec les bonnes pratiques associées.

Mélanger stable et nightly dans le même profil utilisateur. C’est le piège numéro un. Les deux versions partagent les mêmes préférences et les mêmes chemins de bibliothèques ; une nightly peut écrire une configuration que la stable ne relira pas correctement. Bonne pratique : profils séparés, répertoires de configuration distincts, ou conteneurs.

Écraser les bibliothèques personnelles lors d’une mise à jour. Une mise à jour peut remplacer les bibliothèques par défaut. Si vos bibliothèques personnelles sont dans le même dossier, elles disparaissent. Bonne pratique : bibliothèques centralisées et versionnées, référencées par variables d’environnement ou symlinks, jamais dans le dossier d’installation.

Oublier de sauvegarder la configuration. Préférences, chemins de bibliothèques, feuilles de style : tout cela se perd si vous ne l’exportez pas. Bonne pratique : export documenté avant chaque mise à jour.

Migrer un projet sans copie de sécurité. Un projet migré vers une version plus récente peut ne plus s’ouvrir correctement dans l’ancienne. Bonne pratique : copie de sécurité, test sur copie, gel des bibliothèques avant migration.

Sous-estimer les régressions de version mineure. Le cas de la 10.0.5 « devenue inutilisable » sur le déplacement de pistes en est l’illustration parfaite. Bonne pratique : ne pas sauter sur une mineure le jour de sa sortie ; attendre les retours, ou tester sur copie.

Un dernier piège, plus subtil : l’import de projets depuis d’autres outils. Un utilisateur rapporte en septembre 2026 la migration d’un projet Altium 25.6.2 vers KiCad 10.0.6, avec un avertissement ERC récurrent : « Symbol pin or wire end off connection grid » sur presque chaque broche et chaque extrémité de fil. Ce n’est pas un bug de KiCad à proprement parler — c’est un problème de grille hérité de l’outil source — mais cela montre qu’une migration d’environnement inclut aussi la migration des projets, avec ses propres pièges.

Structurer un atelier fiable : bibliothèques, préférences, sauvegardes, cohabitation

La méthode d’organisation d’un environnement durable tient en quatre piliers.

Bibliothèques centralisées et versionnées. Le principe : un dossier unique, hors du dossier d’installation, versionné (Git ou autre), référencé par variables d’environnement ou symlinks. Les spécificités plateforme existent — chemins macOS, variables Linux, profils Windows — mais le principe reste le même : ne jamais laisser les bibliothèques personnelles dans le dossier d’installation.

Préférences exportées et documentées. Exportez votre configuration avant chaque mise à jour, et documentez-la (version, date, contenu). C’est ce qui vous permettra de restaurer un environnement fonctionnel en quelques minutes après un incident.

Sauvegardes automatiques et snapshots avant chaque mise à jour. La règle : un snapshot avant chaque changement de version. Pas après — avant.

Cohabitation de plusieurs versions. Répertoires de configuration distincts ou conteneurs. C’est ce qui permet de tester une nightly en parallèle de la stable sans risque pour la production.

Un mot sur l’écosystème matériel, souvent négligé : les pages officielles de 3Dconnexion dédiées à KiCad (CadMouse, SpaceMouse) existent et documentent l’intégration. Si votre atelier repose sur ce type de périphérique, vérifiez la compatibilité avec la version que vous installez — c’est un détail qui peut faire la différence entre un workflow fluide et un workflow pénible.

KiCad face aux alternatives : ce que change le choix de canal

Le débat KiCad vs alternatives ne se joue plus seulement sur les fonctionnalités. Il se joue sur la gouvernance du canal.

Le coût. Altium Designer, l’alternative propriétaire de référence, est à 3 850 à 5 000 USD par utilisateur et par an en 2026, avec une formation à 1 000 à 2 000 EUR par personne. Pour cinq postes sur trois ans, formation incluse, on dépasse 175 000 USD. KiCad, lui, est gratuit. Ce n’est pas un argument nouveau, mais il prend un relief particulier quand on parle d’équipes : le coût d’un environnement KiCad bien structuré (bibliothèques, sauvegardes, formation) reste une fraction de celui d’une licence propriétaire.

L’ouverture des formats. Altium utilise des formats propriétaires (.PrjPcb, .SchDoc, .PcbDoc) et ne tourne que sous Windows. KiCad est multiplateforme et ouvert. La migration Altium → KiCad existe (un utilisateur a migré un projet 25.6.2 vers 10.0.6 en septembre 2026), mais elle n’est pas native dans KiCad 10.0.0 — elle passe par des étapes de conversion, avec les pièges de grille évoqués plus haut.

L’écosystème de plugins. C’est là que KiCad a changé de dimension. Le plugin Konnect (octobre 2026) illustre la vitalité de l’écosystème : un binaire Rust unique, 228 outils, intégration de Claude et d’autres assistants via MCP. Ce type d’innovation arrive d’abord dans l’écosystème ouvert, parce que les nightlies et les canaux de pré-release permettent aux développeurs de plugins d’anticiper.

La qualité du routage interactif. Altium dispose d’outils avancés (accord de longueur intégré, calcul d’impédance, éditeur de règles DRC graphique, routage automatique de paires, via stitching). KiCad a considérablement progressé — le routeur interactif, le push and shove, le walk around sont documentés et utilisés — mais le débat ne se tranche pas sur une liste de cases à cocher. Il se tranche sur le workflow réel, et sur la capacité à isoler l’expérimentation de la production.

Le support. C’est le point où le choix de canal devient un choix de gouvernance. Un projet open source avec nightlies accessibles permet d’anticiper, à condition de savoir isoler l’expérimentation. Un projet propriétaire offre un support contractuel, mais ferme la porte à l’anticipation. Les deux modèles ont leurs vertus ; le concepteur doit savoir lequel correspond à son risque.

Un dernier point, souvent oublié : la communauté. La KiCad Conference Asia 2026 (quatrième édition annuelle, à Shenzhen, du 5 au 7 novembre 2026, au Huaqiang Plaza Hotel) témoigne de la vitalité de l’écosystème asiatique. Ce n’est pas un détail : un écosystème actif, c’est un flux de plugins, de bibliothèques et de retours d’expérience qui compte dans la décision.

Ce qui change pour la suite : signaux à surveiller et plan d’action

Que doit faire un concepteur dès maintenant ? D’abord, choisir un canal et le documenter : stable maintenue pour la production, nightly ou RC en parallèle pour l’évaluation. Ensuite, sauvegarder : bibliothèques, préférences, projets, avant chaque mise à jour. Puis tester une nightly en parallèle de la stable, dans un environnement isolé, pour anticiper la prochaine majeure sans risque.

Quels signaux surveiller ? Les notes de version (annonces de release, comme celle de la 10.0.6 le 29 août 2026 ou de la 10.0.7 RC2 le 3 octobre 2026), les tags GitLab, les annonces de la mailing list développeurs, et la page downloads.kicad.org. C’est là que se trouvent les informations datées — pas sur la page d’accueil du site officiel, dont le copyright « 2018-2020 » trahit l’obsolescence.

Rappelons les limites de cet article : les numéros et dates exacts doivent être vérifiés à la source, les pages officielles indexées étant incomplètes. La branche 10.x est bien vivante en 2026 — la 10.0.6 est sortie, la 10.0.7 est en RC2 — mais la prochaine majeure (11.x ?) n’est pas datée dans nos sources. Ne l’inventez pas ; surveillez.

Checklist « lundi matin » en cinq points :

1. Vérifier la dernière stable sur downloads.kicad.org (au moment de la rédaction : 10.0.6, avec 10.0.7 en RC2).
2. Choisir le canal : stable maintenue pour la production, RC/nightly en environnement isolé pour l’évaluation.
3. Sauvegarder bibliothèques, préférences et projets avant toute mise à jour.
4. Séparer les profils si vous faites cohabiter plusieurs versions (répertoires de configuration distincts, conteneurs).
5. Documenter la version utilisée par l’équipe, et vérifier la fin de support de la branche avant de migrer.

Sources

• KiCad – Schematic Capture & PCB Design Software — page d’accueil officielle (copyright « © 2018-2020 1BitSquared »)
• Download – KiCad — page de téléchargement officielle (encart de don via The Linux Foundation)
• Downloads | KiCad EDA — portail officiel de téléchargements
• Windows Downloads – KiCad — page dédiée aux téléchargements Windows
• Documentation | KiCad — documentation officielle
• Démarrer avec KiCad | 5.1 | Français — documentation française (version 5.1)
• KiCad – Wikipedia et KiCad — Wikipédia
• PCB Design Software in 2026: What Beginners Should Compare — comparatif 2026
• Annonce KiCad 10.0.7 Release Candidate 2 (kicad.org, 3 octobre 2026)
• Annonce KiCad 10.0.7 Release Candidate 1 (kicad.org, 27 septembre 2026)
• Annonce KiCad 10.0.6 Release (kicad.org, 29 août 2026)
• Annonce KiCad 10.0.6 Release Candidate 1 (kicad.org, 18 août 2026)
• Guide d’installation KiCad 10.0.6 sur Mac Apple Silicon (NOVAKVM, 23 septembre 2026)
• Fil de forum « KiCad 10.0.4 / 10.0.5 – extremely slow track movement in PCB Editor » (forum.kicad.info, 12 août 2026)
• Fil de forum « Altium → KiCad 10 import: Symbol pin or wire end off connection grid » (forum.kicad.info, 1er septembre 2026)
• Annonce KiCad Conference Asia 2026 (kicad.org, 16 septembre 2026)
• Plugin Konnect pour KiCad 10 (Fellow, 14 octobre 2026 ; DevTrends, 7 septembre 2026)

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