---

Pourquoi 2026 est l’année de la migration forcée

Il y a une différence entre « envisager » de changer d’outil et « devoir » le faire. En 2026, une bonne partie du monde du PCB est passée dans la seconde catégorie, et ce n’est pas un choix esthétique.

Le déclencheur le plus brutal porte un nom : Autodesk EAGLE. La fin de vie est fixée au 7 juin 2026 — arrêt des ventes, arrêt du support, et surtout fermeture des serveurs de licences. Autrement dit : même si vous avez payé, même si votre poste fonctionne, l’outil cesse d’être activable. Des milliers de projets — cartes de loisir, cartes d’école, cartes de PME qui n’ont jamais migré parce que « ça marchait » — se retrouvent avec un format source que plus personne ne maintient. EAGLE n’est pas le seul outil à disparaître, mais c’est celui dont la disparition est la plus visible, parce qu’il a formé une génération entière de concepteurs.

Le deuxième déclencheur est plus diffus mais tout aussi structurant : les donneurs d’ordre. De plus en plus d’équipes reçoivent des fichiers Altium d’un client, d’un sous-traitant ou d’un partenaire, et doivent les ouvrir, les modifier, les fabriquer. Altium Designer reste l’étalon industriel — mais à 3 850 à 5 000 USD par utilisateur et par an, avec une formation facturée 1 000 à 2 000 € par personne, et un coût total sur trois ans pour cinq postes qui dépasse les 175 000 USD formation incluse. Pour beaucoup de bureaux d’études, la question n’est plus « Altium ou KiCad ? » mais « comment je fais rentrer un fichier Altium dans un flux que je peux payer ? ».

Troisième facteur, moins glamour mais décisif : la fin de support des vieux postes Windows et la bascule des parcs. Un outil qui ne tourne plus proprement sur le matériel disponible, c’est un outil qui sort du flux, quelle que soit sa qualité.

Et KiCad, pendant ce temps, est devenu crédible — et sa cadence de publication s’est accélérée. La branche 10 a été publiée en mars 2026 (annonce officielle Version 10.0.0 Released), avec plus de 7 609 commits uniques rapportés par le projet, 952 nouveaux symboles, 1 216 nouvelles empreintes et 386 nouveaux modèles 3D. Depuis, la branche a enchaîné les correctifs : 10.0.4 en juin, 10.0.5, puis 10.0.6 le 29 août 2026 (annonce officielle), et enfin 10.0.7, passée par deux release candidates les 27 septembre et 3 octobre 2026 (RC1, RC2) avant de devenir la version stable officielle en octobre. Autrement dit : la 10.0.7 est aujourd’hui la référence, et la 10.0.6 la version que la plupart des tutoriels et guides d’installation encore en ligne décrivent.

Le projet a aussi annoncé une KiCad Conference Asia à Shenzhen du 5 au 7 novembre 2026 (annonce), signe d’une communauté qui s’organise au-delà du logiciel.

Bref : l’outil est là, la communauté est là, le coût est imbattable. Le problème a changé de nature. Il n’est plus « quel outil choisir », il est « comment migrer sans casser ».

---

Ce que KiCad 10.x importe vraiment (et ce qu’il n’importe pas)

C’est ici qu’il faut être honnête, parce que c’est le point où les promesses commerciales et la réalité documentaire divergent le plus.

Ce qu’on sait de source officielle : KiCad 10 ajoute des importateurs pour Allegro, PADS et gEDA/Lepton PCB. C’est une extension réelle du périmètre — on ne parle plus seulement des formats grand public, mais de formats de CAO professionnels historiques. Pour les équipes qui traînent des designs Allegro ou PADS depuis quinze ans, c’est une porte de sortie.

Ce qu’on sait aussi : KiCad dispose d’un import de projets Altium via le menu File → Import Non-Kicad Projects → Altium. Mais cette fonction a une limitation documentée, remontée dans un ticket GitLab officiel (issue #20160, build 9.99.0-217, daté du 28 février 2025) : l’impossibilité de sélectionner le « top sheet » pour les schémas hiérarchiques, ce qui dégrade l’import. Autrement dit : un projet Altium plat passe mieux qu’un projet hiérarchique, ce qui est précisément l’inverse de ce qu’on rencontre en industrie.

Il faut ici distinguer deux choses qu’on confond souvent :

Type d’import	Ce que ça donne	Limite typique
Projet complet (ex. .PrjPcb Altium)	Schéma + PCB + liens, dans la mesure du supporté	Échecs sur schémas hiérarchiques (sélection du top sheet) ; avertissements ERC de grille (voir plus bas)
Fichier isolé (ex. .SchDoc/.PcbDoc seuls)	Import partiel, sans contexte projet	Statut incertain, non documenté officiellement
Legacy KiCad (.sch/.brd 5.x-7.x)	Ouverture native, conversion de format	Ruptures de bibliothèques et de règles
EAGLE (.sch/.brd)	Conversion de structure	Flux peu documenté officiellement
EasyEDA	Conversion via outils tiers (ex. Schemalyzer)	Dépendance à un outil externe
Allegro / PADS / gEDA	Nouveaux importateurs KiCad 10	Détails de fidélité non précisés

Un point de méthode : la documentation officielle du manuel KiCad 10.0 est basée sur la version 10.0.6 (révision d350b28a), et elle confirme que tous les fichiers KiCad sont 100 % compatibles entre systèmes d’exploitation. C’est une bonne nouvelle pour les équipes mixtes Windows/macOS/Linux — mais ça ne dit rien de la fidélité des imports depuis des formats tiers.

La zone d’ombre à connaître avant de promettre une date à un client : il n’existe pas, dans les sources disponibles, de documentation officielle détaillée par format listant ce qui se convertit et ce qui se perd. Ni pour EAGLE, ni pour EasyEDA, ni pour OrCAD. Cette absence de documentation n’est pas un détail : elle transforme chaque migration en pari, et chaque pari en risque projet.

---

EAGLE : ce qui meurt avec les serveurs de licences

Voilà le point le plus délicat du dossier, et il faut le dire franchement : aucune source fournie ne documente la conversion EAGLE → KiCad 10 dans le détail. Ni les Design Rules (DRC), ni les classes de nets, ni les paires différentielles, ni les polygones, ni les vias, ni les couches, ni les attributs de composants. La documentation officielle KiCad 5.1 (datée du 17 mars 2014) décrit bien le DRC, le routeur interactif, l’autorouteur et l’export/import SPECCTRA DSN — mais ne mentionne aucune fonction d’import EAGLE ni de traduction des Design Rules EAGLE. Et le manuel KiCad 10.0 fourni ne comble pas ce trou.

Ce que l’on peut dire avec certitude, en revanche, c’est la structure du risque. Une conversion EAGLE → KiCad fait traverser plusieurs familles d’objets, et chacune a un comportement différent :

• Les Design Rules (DRC) : dans EAGLE, ce sont des règles déclaratives stockées dans le fichier .brd. Dans KiCad, les contraintes vivent dans les Design Rules et les Net Classes. Le mapping n’est pas bijectif — une règle EAGLE peut ne pas avoir d’équivalent direct, et une règle KiCad peut ne pas être alimentée.
• Les classes de nets : EAGLE les nomme et les affecte ; KiCad a sa propre notion de netclass. Si le mapping n’est pas explicite, les nets retombent dans la classe par défaut — silencieusement.
• Les paires différentielles : EAGLE les déclare comme paires ; KiCad a un outil dédié. Une paire non reconnue à l’import devient deux nets indépendants, et le routeur différentiel ne les verra plus.
• Les polygones et régions de cuivre : souvent convertis en géométrie, mais la notion de priorité/remplissage peut se perdre.
• Les vias : les diamètres et perçages personnalisés peuvent retomber sur les valeurs par défaut de la bibliothèque KiCad.
• Les couches : un empilement EAGLE nommé peut se retrouver aplati sur la convention KiCad.
• Les attributs de composants : les champs personnalisés (référence fournisseur, tolérance, DNP) peuvent disparaître ou se retrouver dans des champs non mappés.

Le mot important ici est « no-op silencieux » : un élément qui ne provoque ni erreur ni avertissement, mais qui n’est tout simplement pas traduit. C’est le pire des cas, parce qu’il ne se voit qu’au moment où la carte est fabriquée — ou pire, au moment où elle ne fonctionne pas.

Et le fait qu’aucune documentation officielle ne couvre ce flux est en soi un risque projet : vous ne pouvez pas promettre à un client une date de migration EAGLE fiable sans avoir vous-même audité le résultat.

---

Altium : le bug de la grille et les pertes invisibles

Passons à Altium, où l’on dispose cette fois d’un retour d’expérience concret — et peu réjouissant.

Un utilisateur rapporte sur le forum KiCad (fil daté du 1er septembre 2026) un bug d’import Altium → KiCad 10.0.6 : l’avertissement ERC « Symbol pin or wire end off connection grid » frappe presque toutes les broches et tous les fils importés. Le projet de test est précis : Altium Designer 25.6.2, import via .PrjPcb, feuille de 11500 × 7600 mil, grille visible 100 mil, snap 10 mil, distance de snap 4 mil. L’utilisateur a testé en réduisant la grille jusqu’à 1 mil — sans solution. Le bug est reproduit, mais il s’agit d’un rapport utilisateur unique, non confirmé par un ticket officiel ni par un correctif documenté — y compris dans les notes de la 10.0.7.

Ce que ce cas illustre, au-delà du bug lui-même : un import Altium qui « réussit » peut produire un schéma électriquement douteux. L’ERC vous hurle dessus sur des centaines de broches, et vous ne savez pas si c’est un artefact de grille ou une vraie erreur de connexion. C’est exactement le type de faux positif qui fait perdre une journée — ou pire, qui fait ignorer un vrai positif.

Au-delà de ce bug, la question des pertes invisibles est structurelle. Sur les éléments que la matière ne documente pas — variantes de composants, règles de conception avancées, empilements de couches, régions de cuivre, classes de nets, paramètres haute vitesse, modèles 3D — aucune source fournie ne permet d’affirmer ce qui se convertit, ce qui se dégrade et ce qui disparaît. C’est un constat en creux, mais il est essentiel : dans un dossier de migration, l’absence de documentation n’est pas neutre, elle est un risque à provisionner.

Ce que l’on sait de source officielle sur KiCad 10 lui-même, en revanche, est utile : KiCad 10 supporte jusqu’à 32 couches de cuivre, et introduit l’échange non contraint de nets et de Gate/Unit (schéma + PCB), un outil de mesure dans le Footprint Chooser, le support des symboles et empreintes de cavaliers (jumpers), et les groupes dans l’éditeur de schéma. Autant de fonctions qui, paradoxalement, facilitent la reprise manuelle d’un design importé — mais qui ne remplacent pas une conversion fidèle.

Un détail qui a son importance pour les migrations : depuis KiCad 10, les bibliothèques officielles ne livrent plus que des modèles 3D au format STEP. Le passage au STEP comme format par défaut avait été amorcé dès le cycle 9 ; la 10 acte la fin des formats historiques. Concrètement, cela réduit fortement la taille d’installation des modèles 3D et améliore la précision géométrique — mais si votre flux de migration s’appuyait sur d’anciens modèles 3D d’un autre format, il faudra vérifier leur résolution.

---

Legacy KiCad 5/6/7 : le cimetière qu’on n’ose plus ouvrir

Il y a une illusion tenace chez les utilisateurs de longue date : « c’est du KiCad, donc ça s’ouvre ». C’est vrai — et c’est trompeur.

Un projet KiCad 5.1 s’ouvre dans la branche 10.x. La documentation officielle confirme que tous les fichiers KiCad sont 100 % compatibles entre OS. Mais un projet qui s’ouvre n’est pas un projet qui fonctionne. Entre 5.1 et 10.x, il y a des ruptures de format, des ruptures de bibliothèques et des ruptures de règles. Les symboles et empreintes d’une bibliothèque maison de 2014 peuvent avoir changé de convention, de nom, de broche. Les règles DRC peuvent avoir des équivalents partiels. Les propriétés de zones, les classes de nets, les paramètres de perçage — tout cela a évolué.

Le cas typique : une carte conçue en 2016, jamais retouchée, qu’on ressort parce qu’un client en veut une nouvelle série. Le fichier s’ouvre, le rendu 3D s’affiche, on se dit que c’est bon. Puis on lance le DRC et on découvre trente violations qui n’existaient pas à l’époque — non pas parce que la carte est mauvaise, mais parce que les règles ont changé.

La checklist minimale avant de relancer une fabrication sur un design legacy :

1. Vérifier la résolution des empreintes : chaque empreinte du projet pointe-t-elle encore vers une bibliothèque existante, et la version chargée est-elle bien celle d’origine ? Un symbole renommé ou une broche déplacée suffit à casser la netlist.
2. Rejouer le DRC avec les règles d’origine, puis avec les règles courantes, et comparer les deux rapports. Les écarts vous disent ce qui a bougé — pas ce qui est faux.
3. Contrôler les classes de nets et les paires différentielles : sont-elles toujours affectées, ou tout est-il retombé en classe par défaut ?
4. Vérifier l’empilement de couches (nombre de cuivres, épaisseurs, matériaux) : c’est ce qui conditionne l’impédance, et c’est ce qui se perd le plus discrètement.
5. Auditer les zones de cuivre : priorités, remplissages, connexions thermiques.
6. Comparer la BOM générée par la 10.x avec celle archivée à l’époque — c’est le test le plus rapide pour détecter des attributs de composants perdus.
7. Regénérer les Gerbers et les comparer visuellement aux fichiers d’origine avant tout envoi en fabrication.

Aucune de ces étapes n’est glamour. Toutes sont moins coûteuses qu’un lot de cartes fabriqué sur un empilement faux.

---

Le workflow 2026 : ce que la 10.0.7 change vraiment

Une fois la migration faite, il reste à travailler — et là, la branche 10.0.x a apporté des changements concrets qu’il faut connaître, parce qu’ils touchent directement le quotidien du concepteur.

Le SpaceMouse, enfin stable. L’intégration native des contrôleurs 3Dconnexion, longtemps perfectible, a été consolidée au fil des correctifs de la branche 10.0.x. Pour les habitués de la navigation 3D et du routage à la molette, c’est un confort qui change la journée — et un argument de plus face à un Altium qui reste, lui, Windows uniquement.

Les performances du PCB Editor. La série 10.0.4/10.0.5 a connu un problème sérieux rapporté sur le forum KiCad (12 août 2026) : le déplacement d’un segment de piste déjà routé devenait extrêmement lent, au point de rendre la 10.0.5 inutilisable pour certains. Le correctif est arrivé dans la 10.0.6. Si vous aviez sauté la 10.0.6 pour rester sur une 10.0.5 « qui marchait », vous payez probablement encore ce bug.

L’écosystème des plugins. La 10.0.7 a également corrigé des régressions qui affectaient les extensions — un point à ne pas négliger si votre flux repose sur des plugins tiers. Et l’écosystème, justement, a beaucoup bougé.

---

L’écosystème 2026 : IA, MCP et automatisation

C’est le changement le plus visible de l’automne 2026, et il concerne directement les équipes qui migrent : KiCad n’est plus seulement un logiciel, c’est une plateforme qu’on branche.

Le cas le plus commenté est Konnect, un plugin natif pour KiCad 10 écrit en Rust, distribué sous forme d’un binaire unique, qui expose KiCad à Claude et à d’autres assistants via le protocole MCP (Model Context Protocol). Le projet revendique 228 outils permettant à un assistant de concevoir schémas et circuits imprimés (Fellow, 14 octobre 2026 ; couverture également par DevTrends le 7 septembre 2026 et par Adafruit le 26 octobre 2026). Il faut être clair sur ce que cela signifie et ne signifie pas : un assistant branché sur KiCad via MCP peut agir sur le projet — créer, modifier, interroger — mais il ne remplace ni l’audit de migration, ni la validation DRC, ni la relecture. C’est un accélérateur de tâches répétitives, pas un garant de fidélité.

Côté routage, FreeRouting — le routeur Java historique — a entamé une mue profonde vers les API et l’IPC, mais la version 2.3.0 a introduit une régression documentée : elle produit des routes que son propre scoring signale comme portant des violations de clearance, sur des cartes que la 2.2.4 routait proprement (rapport GitHub, 28 août 2026). Si votre flux de migration s’appuie sur FreeRouting pour re-router un design importé, épinglez la version et validez systématiquement au DRC.

Côté script, l’API Python de KiCad continue de progresser, et c’est là que se trouve le gain de temps réel : automatiser la génération de BOM, la vérification de règles, l’export de Gerbers, l’intégration en CI. Un script de stitching de vias, par exemple, remplace une séance de clics par une ligne de commande (scriptedpcb.com, 13 septembre 2026). Mais attention au coût de maintenance : chaque script est une dette, et chaque montée de version peut la révéler.

---

Choisir sa version : la grille de décision

En cette fin octobre 2026, la question n’est plus « 10.0.6 ou 10.0.7 ? » — la 10.0.7 est sortie et devient la référence. La vraie question est : quand basculez-vous ?

• Vous démarrez un projet neuf : 10.0.7, sans hésiter. Vous bénéficiez de tous les correctifs de la branche, y compris ceux de performance et de plugins.
• Vous êtes en cours de migration depuis Altium : testez l’import sur la 10.0.7, mais prévoyez l’audit ERC décrit plus haut. Le bug de grille n’est pas documenté comme corrigé.
• Vous êtes en cours de migration depuis EAGLE : la version compte moins que la méthode. Aucune version ne documente la fidélité de cet import.
• Vous avez un design legacy en production : ne migrez pas « pour migrer ». Restez sur la version qui fabrique correctement, et planifiez la migration comme un projet à part entière, avec sa checklist.
• Vous dépendez de plugins tiers : vérifiez leur compatibilité avec la 10.0.7 avant de sauter le pas — les correctifs d’écosystème de cette version sont justement là pour ça.

---

Ce qu’il faut retenir

Trois choses, et elles tiennent en trois phrases.

EAGLE est mort, et personne ne documente la sortie de secours. Le 7 juin 2026 a fermé les serveurs ; aucune source officielle ne dit ce qu’un import EAGLE vers KiCad 10 convertit réellement. Traitez chaque migration EAGLE comme un audit, pas comme une conversion.

Altium reste cher, et son import a des angles morts. À 3 850–5 000 USD par utilisateur et par an, l’outil se justifie pour ceux qui en vivent ; pour les autres, l’import vers KiCad 10 fonctionne — avec des avertissements ERC massifs sur les schémas hiérarchiques et un bug de grille non corrigé à ce jour.

KiCad 10.0.7 est la version qui compte, et l’écosystème s’ouvre. La branche a bouclé son cycle, le SpaceMouse est stable, les performances sont corrigées, et les plugins IA/MCP comme Konnect changent la nature de l’outil. La migration n’est plus un pari sur l’avenir : c’est un chantier à planifier, avec une checklist et une version épinglée.

---

Sources

• KiCad — Version 10.0.0 Released (mars 2026) : 7 609 commits uniques, 952 nouveaux symboles, 1 216 nouvelles empreintes, 386 nouveaux modèles 3D, passage aux STEP uniquement.
• KiCad — Version 10.0.6 Release (29 août 2026).
• KiCad — Version 10.0.7 Release Candidate 1 Available (27 septembre 2026).
• KiCad — Version 10.0.7 Release Candidate 2 Available (3 octobre 2026).
• KiCad — KiCad Conference Asia 2026 Announcement (16 septembre 2026) : Shenzhen, 5–7 novembre 2026.
• KiCad — Documentation 10.0 (français) : manuel basé sur la 10.0.6 (révision d350b28a), compatibilité 100 % des fichiers entre OS.
• Forum KiCad — Altium → KiCad 10 import : « Symbol pin or wire end off connection grid » (1er septembre 2026) : Altium Designer 25.6.2, import .PrjPcb, feuille 11500 × 7600 mil.
• Forum KiCad — KiCad 10.0.4 / 10.0.5 : extremely slow track movement in PCB Editor (12 août 2026).
• GitHub — FreeRouting 2.3.0 regression (28 août 2026) : violations de clearance auto-signalées, 2.2.4 propre.
• Fellow — Konnect : conception de PCB assistée par IA pour KiCad 10 (14 octobre 2026) : plugin Rust natif, MCP, 228 outils.
• DevTrends — Как подключить Claude к KiCad 10 (7 septembre 2026).
• scriptedpcb.com — Créer une grille de vias de stitching avec un script (13 septembre 2026).
• NOVAKVM — How To Install KiCad 10.0.6 On Apple Silicon Mac (23 septembre 2026).
• Electrical Flux — The 2026 PCB Design Software List: KiCad, Altium, and EasyEDA Compared (9 septembre 2026).
• KiCad — Version 10.0.0 milestone GitLab : liste complète des issues corrigées.