Kicad Master · 23 October 2026

KiCad 10 face aux vieux projets : le grand chantier de la migration réelle

Passer à KiCad 10, c’est facile : un clic sur « installer ». Migrer dix ans de bibliothèques maison, de variantes oubliées et de règles DRC bricolées, c’est une autre histoire. Alors que la 10.0.7 s’apprête à sortir et que la 9.0.x reste maintenue, voici le guide de terrain pour ne pas casser la production en changeant de version.

Le vrai sujet de 2026 n’est plus « faut-il passer à KiCad 10 ? »

Il y a un an, la question était simple : la version 10 apporte-t-elle assez de nouveautés pour justifier la bascule ? Aujourd’hui, la réponse est connue et la question a changé de nature. KiCad 10.0.0 est sorti en mars 2026, et la série a depuis enchaîné les correctifs : 10.0.4, 10.0.5, 10.0.6 le 29 août 2026, puis une Release Candidate 1 de la 10.0.7 le 27 septembre et une RC2 le 3 octobre 2026. La 10.0.7 est donc imminente, et la branche 10 est désormais une version de production crédible — pas un terrain d’expérimentation.

Le problème, c’est que cette maturité logicielle ne dit rien de la maturité de vos projets. Un atelier qui a accumulé depuis 2016 des schémas hiérarchiques, des bibliothèques personnelles avec leurs propres conventions de nommage, des tables sym-lib-table et fp-lib-table pointant vers des chemins réseau, et des règles DRC maison écrites à la main, ne migre pas en double-cliquant sur un installeur. Il migre en découvrant, une par une, les hypothèses implicites que son écosystème faisait sur KiCad.

C’est ce chantier-là — concret, ingrat, mais décisif — que ce dossier dissèque. Pas les slides marketing de la 10.0.0, mais ce qui se passe quand on ouvre réellement un projet de 2019 dans la 10.0.6 un lundi matin, avec une deadline de prototype le vendredi.

Chronologie : comment on est arrivés là

Reprenons les faits, parce qu’ils expliquent pourquoi la migration est devenue un sujet et pas seulement une formalité.

La version 10.0.0 a été publiée en mars 2026, avec un lot de nouveautés qui touchent précisément aux zones sensibles des projets hérités : importateurs, variantes et DRC graphique selon les analyses de l’époque. La revue de Tech Explorations insiste sur le tuning haute vitesse et les variantes ; PCB Directory souligne les mises à jour transversales sur les bibliothèques, l’interface et les outils de conception PCB. Autrement dit : la 10.0.0 n’est pas une version « cosmétique ». Elle touche au cœur du flux de travail.

Ensuite, la mécanique de maintenance classique du projet : une série de correctifs rapprochés. La 10.0.6 du 29 août 2026 est présentée par l’équipe comme contenant « critical bug fixes and other minor improvements since the previous release » — comprenez : la 10.0.6 corrige des choses sérieuses. La 10.0.7, en RC au début du mois d’octobre 2026, devrait suivre « soon unless critical issues are found in testing ». C’est le rythme habituel d’une branche qui se stabilise.

Mais la vraie information pour un concepteur, c’est le maintien en parallèle de la branche 9.0.x. La 9.0.9 existe et reste maintenue. Ce détail change tout : il signifie que rester sur KiCad 9 est une option défendable à court terme, et que la migration vers 10 peut se faire sans couteau sous la gorge. C’est une bonne nouvelle — à condition de ne pas confondre « pas urgent » avec « pas nécessaire ».

Un point de méthode, avant d’aller plus loin : les sources publiques du projet (site, blog, notes de version) documentent les versions, les dates et les correctifs, mais ne publient aucune statistique sur le nombre de projets migrés, la taille des bibliothèques personnelles de la communauté, les temps de conversion observés ou la part d’usage 9 vs 10. Tout ce qui suit en termes de chiffres vient donc soit des annonces officielles, soit de retours de forum et de billets tiers — et quand une donnée n’existe pas, nous le dirons plutôt que de l’inventer.

Ce qui change vraiment dans un projet hérité

Les fichiers et les bibliothèques

Le premier contact avec la 10 se fait sur la structure projet : .kicad_pro, .kicad_sch, .kicad_pcb. Le mécanisme de migration au premier enregistrement est réel — il convertit les fichiers dans le nouveau format — mais il faut comprendre ce qu’il fait et ce qu’il ne fait pas. Il ne réécrit pas vos conventions. Il ne devine pas que votre bibliothèque « POWER » contient des symboles dont les noms ont été modifiés à la main depuis huit ans. Il ne répare pas une fp-lib-table qui pointe vers un lecteur réseau débranché.

C’est là que se joue la première vraie difficulté : les tables sym-lib-table et fp-lib-table. Un projet ancien embarque souvent une table locale, avec des chemins absolus hérités d’une machine qui n’existe plus, et parfois des doublons entre table globale et table projet. La 10 tolère ces tables, mais le comportement de résolution peut surprendre : un symbole qui « marchait » parce qu’il tombait sur une version globale peut soudain résoudre vers une version locale différente. La règle empirique : avant toute migration, faire l’inventaire des tables, les comparer, et décider explicitement quelle version de chaque bibliothèque fait foi. C’est fastidieux, c’est la moitié du chantier, et c’est non négociable.

Les variantes de production

Les variantes sont l’une des nouveautés mises en avant dans la 10. Sur un projet neuf, c’est un confort. Sur un projet hérité, c’est un piège potentiel : un schéma ancien qui gérait ses variantes « à la main » (typiquement par des variantes de composants non montés documentées dans un tableur, ou par des feuilles dupliquées) ne se convertit pas automatiquement en variantes natives. Il faut choisir : soit on garde la méthode historique et on ignore la fonctionnalité, soit on reconstruit les variantes proprement — et dans ce cas, il faut revalider la nomenclature et la documentation de production. Pour un atelier qui fabrique en petites séries, ce second choix est souvent le bon, mais il coûte des heures.

Le DRC graphique

La refonte du DRC avec contrôles graphiques est probablement le changement le plus sous-estimé. Un projet hérité porte des règles maison, parfois écrites dans un fichier de règles custom, parfois simplement « dans la tête » du concepteur senior. Le nouveau moteur applique ses contrôles graphiques, et il est très probable que des cartes anciennes — conçues avec des marges implicites, des tolérances de fabrication plus larges, ou des astuces de contournement — génèrent un lot de violations nouvelles. Ce n’est pas un bug : c’est le DRC qui fait mieux son travail. Mais dans la pratique, cela signifie qu’une carte qui « passait » en 9 peut afficher des dizaines d’avertissements en 10, et qu’il faut trier entre vraies erreurs, faux positifs liés à des règles mal exprimées, et cas légitimes à exempter explicitement.

Un retour de forum illustre bien la nature de ces frictions : un utilisateur migrant un projet Altium vers KiCad 10.0.6 signale l’avertissement ERC « Symbol pin or wire end off connection grid » sur presque chaque broche et chaque fil. C’est un cas typique de conversion où la grille d’origine ne correspond pas à celle de KiCad — pas une régression, mais un travail de nettoyage à prévoir.

Les addons et plugins

Le système d’addons est l’angle mort de toute migration. Les plugins qui fonctionnaient en 9 ne fonctionnent pas nécessairement en 10, et les retours de forum sur les plugins « disparus » après mise à jour sont un classique. Il faut donc, avant de basculer, lister les plugins réellement utilisés en production — pas ceux installés « au cas où » — et vérifier leur compatibilité. L’écosystème bouge vite : un plugin natif Rust pour KiCad 10 connectant un assistant IA via MCP a été présenté en septembre 2026, et des tutoriels de plugins (vias de stitching, remplissage de plans de masse) circulent abondamment. Mais l’existence de nouveaux plugins ne garantit pas que les anciens aient été portés.

Le terrain : ce que disent les utilisateurs

Trois signaux reviennent des retours publics, et ils méritent d’être pris au sérieux.

Les performances. Un fil de forum d’août 2026 documente un problème sérieux : dans la 10.0.4 et la 10.0.5, le déplacement de pistes déjà routées dans l’éditeur PCB devient extrêmement lent, au point que « 10.0.5 becomes unusable » pour l’auteur. C’est le genre de régression qui ne se voit pas dans une démo mais qui pourrit une journée de travail. La 10.0.6 est censée corriger des bugs critiques — il faut vérifier, projet en main, que ce type de régression est bien derrière nous avant de basculer une équipe entière.

Les importateurs. L’import Altium existe, mais il n’est pas magique. Le rapport de bug cité plus haut concerne Altium Designer 25.6.2 importé vers KiCad 10.0.6, et il pointe un problème de grille quasi systématique. À noter aussi : l’importateur natif Altium n’était pas présent dans la 10.0.0 — il est arrivé dans la série 10.0.x. Autrement dit, les premiers utilisateurs de la 10.0.0 n’avaient pas cette fonctionnalité. Pour Eagle et CADSTAR, les importateurs existent côté KiCad, mais les pièges classiques demeurent : correspondance des couches, gestion des polygones, règles de conception non transposables.

Les outils tiers. Un rapport public sur Freerouting signale une régression en 2.3.0 : des routes qui, selon le propre scoring de l’outil, présentent des violations de clearance sur des cartes que la version 2.2.4 routait proprement. Cela rappelle que l’écosystème autour de KiCad n’est pas stable par construction, et qu’un workflow qui dépend d’un autorouteur externe doit être revalidé à chaque mise à jour — de KiCad et de l’outil.

Migration interne ou statu quo ? Le calcul économique

C’est la question que tout décideur pose, et elle mérite une réponse chiffrée — au moins partiellement.

Rester sur KiCad 9.0.x maintenu coûte zéro en licence et zéro en formation immédiate. Migrer vers 10 coûte des heures-homme : inventaire des bibliothèques, nettoyage des tables, revalidation DRC, tests de plugins, re-fabrication d’un prototype de contrôle. Pour un atelier de deux à cinq personnes, on parle réalistement de plusieurs jours à quelques semaines de travail non facturé, étalés sur un ou deux projets pilotes. Ce coût est réel mais il est interne et modulable.

Comparons avec la bascule vers un outil commercial. Altium Designer, référence du marché, coûte 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 et pour cinq postes, formation incluse, la facture dépasse 175 000 USD. Et Altium ne tourne que sous Windows. La comparaison n’est pas là pour dire « KiCad est gratuit donc c’est mieux » — ce serait simpliste — mais pour situer l’ordre de grandeur : le chantier de migration interne vers KiCad 10, même mal estimé, reste une fraction de ce que coûte un changement d’outil commercial, avec en prime la réversibilité (les fichiers KiCad restent lisibles, le format est ouvert, on peut revenir en 9 si nécessaire).

La vraie question n’est donc pas « combien coûte la migration » mais « combien coûte le fait de ne pas migrer ». Rester en 9 est tenable tant que la branche est maintenue — mais elle finira par l’être moins, et les nouveaux projets profiteront des variantes et du DRC graphique que les anciens n’auront pas. La stratégie raisonnable est celle du projet pilote : migrer une carte représentative, pas la plus critique, mesurer le temps réel, identifier les blocages, puis décider de la bascule générale.

Méthode de migration par étapes

Voici une méthode éprouvée, pensée pour un atelier ou une petite équipe.

Étape 0 — Geler et sauvegarder. Avant tout, un commit Git (ou une archive) de l’état 9.0.x de tous les projets et bibliothèques. La migration est réversible, mais seulement si l’état d’origine existe encore.

Étape 1 — Inventaire. Lister les projets actifs, les bibliothèques personnelles, les tables sym-lib-table/fp-lib-table, les règles DRC custom, les plugins utilisés. Distinguer l’actif du legacy.

Étape 2 — Projet pilote. Choisir une carte de complexité moyenne, récente mais pas critique. L’ouvrir en 10.0.6 (ou 10.0.7 dès sa sortie), laisser la migration automatique faire son travail, puis tout revalider : ERC, DRC, rendu 3D, génération Gerber. Chronométrer.

Étape 3 — Nettoyage des bibliothèques. Traiter les tables une par une. Fusionner les doublons, fixer les chemins, documenter la convention de nommage. C’est l’étape la plus longue et la plus utile à long terme.

Étape 4 — DRC. Trier les violations nouvelles : vraies erreurs / règles mal exprimées / cas à exempter. Mettre à jour les règles maison, documenter les exemptions.

Étape 5 — Plugins. Tester chaque plugin en production. Remplacer ceux qui ne suivent pas, ou accepter de s’en passer.

Étape 6 — Cohabitation 9/10. Garder la 9 installée pour les projets non migrés. Ne pas mélanger les versions sur un même projet sans précaution : un fichier ouvert et enregistré en 10 ne se rouvrira pas proprement en 9.

Étape 7 — Bascule. Une fois le pilote validé, migrer par lots, en commençant par les projets les moins critiques. Garder la 9.0.x comme filet de sécurité jusqu’à ce que la confiance soit établie.

Perspectives

La trajectoire est claire : la 10.0.x se stabilise (10.0.6 en août, 10.0.7 imminente en octobre 2026), la 9.0.x reste maintenue en parallèle, et l’écosystème — plugins, importateurs, outils tiers — suit avec un temps de retard inévitable. La conférence asiatique KiCon de Shenzhen, du 5 au 7 novembre 2026, sera probablement l’occasion de voir où en est la communauté sur ces questions de migration.

Le message à retenir est simple : KiCad 10 n’est plus une question de « faut-il », c’est une question de « comment, et quand ». Et la réponse dépend moins de la version que de l’état de vos bibliothèques et de vos règles. Un atelier dont les bibliothèques sont propres migrera en quelques jours. Un atelier dont les tables pointent vers un serveur éteint depuis 2021 migrera en plusieurs semaines. La bonne nouvelle, c’est que ce nettoyage est utile quelle que soit la version — et qu’il ne coûte rien d’autre que du temps.

Sources

• KiCad – Schematic Capture & PCB Design Software
• Release Notes – KiCad
• KiCad 10.0.6 Release
• Version 10.0.0 Released | KiCad
• KiCad 10.0 New Features: Importers, Variants, Graphical DRC
• KiCad 10 review: new features, high-speed tuning, variants
• KiCad Releases Version 10.0 with Updates Across Libraries, UI and PCB Design Tools
• KiCad 10.0.4 / 10.0.5 – extremely slow track movement in PCB Editor (forum)
• Altium → KiCad 10 import: "Symbol pin or wire end off connection grid" (forum)
• Freerouting 2.3.0 regression report
• KiCad AI in 2026: Copilots, Plugins, and Generators That Actually Work
• KiCad vs Altium in 2026: Where the Free Tool Actually Competes
• Démarrer avec KiCad | 5.1 | Français | Documentation | KiCad
• KiCad — Wikipédia

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