Kicad Master · 24 October 2026

Importateurs natifs dans KiCad 10.0.x : Allegro, PADS et gEDA à l’épreuve du terrain

Pendant des années, migrer un projet d’Allegro, de PADS ou de gEDA vers KiCad relevait du parcours du combattant : plugins tiers plus ou moins maintenus, formats binaires fermés, pertes de données en cascade. Avec la version 10.0, l’équipe KiCad a fait le pari de briser ces barrières en intégrant trois importeurs natifs. Huit mois plus tard, la branche 10.0.x arrive au bout de son cycle de rattrapage : la 10.0.7 est sortie le 7 octobre 2026, et une 10.0.8 est déjà en release candidate depuis le 22 octobre. Mais ces importeurs tiennent-ils vraiment leurs promesses ? Décryptage technique, limitations et perspectives pour les concepteurs, à l’heure où l’écosystème s’emballe entre plugins IA, autoroutage GPU et bibliothèque CERN.

Le grand saut : pourquoi KiCad 10.0 change la donne pour la migration EDA

Jusqu’à la version 9.x, quiconque souhaitait basculer d’un EDA propriétaire vers KiCad devait se contenter d’outils de contournement. Des plugins comme Altium2KiCad ou Eagle2KiCad existaient, mais leur maintenance était aléatoire, souvent portée par un unique développeur. Les formats propriétaires évoluaient plus vite que les scripts, et les conversions aboutissaient fréquemment à des schémas incomplets, des empreintes décalées ou des règles de conception perdues. Sur les forums, les retours d’expérience parlaient de « migrations partielles » et de « retouches manuelles interminables ». La barrière à l’entrée pour les professionnels était réelle.

L’annonce de KiCad 10.0, publiée le 20 mars 2026 (source : blog officiel KiCad), a marqué un tournant. Pour la première fois, l’équipe de développement intégrait nativement des importeurs pour trois formats majeurs : Cadence Allegro, Mentor PADS et gEDA/Lepton EDA. Fini les dépendances à des scripts externes : le parsing est désormais dans le code source de KiCad, maintenu par la communauté et testé en continu. Une rupture promise par l’équipe, mais qu’en est-il dans les faits ?

Depuis la sortie de la 10.0.0, la série corrective s’est poursuivie à un rythme soutenu : 10.0.1 à 10.0.6 dans un premier temps (la 10.0.6 datant du 29 août 2026, après un release candidate le 18 août), puis 10.0.7, sortie le 7 octobre 2026 après deux release candidates (RC1 le 27 septembre, RC2 le 3 octobre). Une 10.0.8 est déjà en release candidate depuis le 22 octobre 2026. Chaque version corrective contient des correctifs critiques et est recommandée par le projet (sources : annonce 10.0.6, RC1 10.0.7, RC2 10.0.7). Le rythme — sept correctifs en un peu plus de six mois — témoigne de l’engagement de l’équipe à consolider la série 10.x. Au total, ce sont 7 609 commits uniques qui ont été intégrés à la 10.0.0, un chiffre en hausse notable par rapport à la version 9 (source : blog officiel KiCad).

Cette consolidation s’accompagne d’avancées majeures au-delà des importeurs : l’éditeur de règles DRC graphique, les variantes de conception, le routage différentiel haute vitesse, le mode sombre et un nouveau moteur de rendu 3D ont fait de KiCad 10 une version charnière, adoptée par les bureaux d’études en quelques mois (source : Tech Explorations). Côté bibliothèques officielles, KiCad 10 franchit un cap : les modèles 3D ne sont plus livrés qu’au format STEP, ce qui réduit fortement la taille d’installation et améliore la précision géométrique ainsi que la cohérence entre visualisation et export (source : blog officiel KiCad).

Mais la route n’est pas sans embûches. Des utilisateurs ont signalé sur le forum KiCad.info des crashs répétés de la 10.0.6 lors de l’édition d’empreintes dans des bibliothèques utilisateur sous Windows 11, et des problèmes de performance extrême sur les versions 10.0.4 et 10.0.5 lors du déplacement de pistes existantes (source : forum KiCad.info). Ces retours, bien que ponctuels, rappellent que la stabilisation d’une version majeure est un processus continu — et expliquent en partie la cadence des correctifs jusqu’à la 10.0.7.

Trois nouveaux venus : Allegro, PADS et gEDA – que couvrent-ils vraiment ?

Avant de plonger dans les détails, dressons l’inventaire officiel des formats supportés, tel que publié sur le blog de KiCad.

Ce tableau révèle un premier constat : l’importateur Allegro est limité au PCB, tandis que PADS couvre à la fois le schématique et le circuit imprimé. L’importateur gEDA reste le parent pauvre de l’annonce, faute de détails techniques dans les sources officielles. Surtout, aucun import natif pour Altium Designer ni pour Eagle n’est présent dans KiCad 10.0, contrairement à ce que le titre de cet article pourrait laisser penser. Nous y reviendrons.

Plongée dans l’importateur Allegro : un défi technique relevé

L’importateur Allegro est sans doute le plus spectaculaire des trois. Développer un parseur pour le format binaire propriétaire .brd sans utiliser les bibliothèques d’Allegro relève de la rétro-ingénierie pure. L’équipe KiCad a relevé le défi, avec le soutien de Quilter et de la communauté (source : blog KiCad). Concrètement, que préserve-t-il ?

• Empreintes : référence, valeur, position, rotation, couches, formes de pastilles (cercle, carré, rectangle, oblong, rectangle arrondi, rectangle chanfreiné, octogone, polygone personnalisé), diamètres de perçage, paramètres de décharge thermique.
• Pistes et vias : largeur, assignation de net, arcs.
• Zones de cuivre : reconstruites à partir de contours.
• Teardrops : pour Allegro 17.2 et ultérieur, importés comme objets de zone.
• Contraintes physiques : converties en netclasses KiCad (règles de clearance, largeur de piste, gap de paires différentielles). Les surcharges par net sont conservées.

Cependant, tout n’est pas parfait. Les règles de conception spécifiques à Allegro (contraintes haute vitesse, impédances, topologies) ne trouvent pas d’équivalent direct dans KiCad et sont donc ignorées. L’empilement de couches (stackup) n’est pas explicitement mentionné comme préservé dans les sources. Enfin, l’import ne concerne que le PCB : le schéma doit être traité séparément, via une exportation de netlist ou une autre méthode.

Un point fort : les teardrops, souvent utilisés en conception RF, sont correctement importés pour les versions récentes d’Allegro. C’est un gain de temps considérable par rapport à une reconstruction manuelle.

L’importateur PADS : la promesse d’une migration complète schéma + PCB

L’importateur PADS lit les fichiers .asc (export ASCII), un format texte que PADS peut générer. Il couvre à la fois le schématique et le PCB, ce qui en fait l’outil le plus complet des trois pour une migration intégrale.

Côté schéma, sont importés : symboles, segments de fil, jonctions, labels de net, connectivité, symboles multi-unités, hiérarchie multi-feuilles, informations de cartouche, types de broches et annotations textuelles. Côté PCB : empreintes, pistes, vias, zones. La communauté s’interroge encore sur la fiabilité des conversions complexes (designs à haute densité, règles de conception avancées). Un fil de discussion sur le forum KiCad.info pose des questions précises sur le comportement des zones et des netclasses, sans réponse officielle détaillée à ce jour.

Aucun benchmark chiffré (taille maximale testée, temps d’import, taux de réussite) n’est fourni par l’équipe KiCad ni par des sources indépendantes. Il est donc prudent de tester sur des projets de complexité croissante avant de se lancer dans une migration massive.

gEDA/Lepton EDA : un import discret mais utile pour l’open source

L’importateur gEDA/Lepton EDA est le moins documenté des trois. Les sources officielles se contentent de le mentionner sans détailler les formats ni les fonctionnalités. gEDA est un outil historique du monde open source, utilisé par une communauté fidèle mais moins répandue que les EDA commerciaux. Le public cible est donc restreint : les utilisateurs de longue date de gEDA qui souhaitent migrer vers KiCad pour bénéficier d’une interface plus moderne et d’un écosystème plus actif.

Sans informations techniques précises, il est difficile d’évaluer la qualité de cet importeur. Les utilisateurs concernés sont invités à partager leurs retours sur les forums pour documenter les cas d’usage.

Le grand absent : Altium Designer – pourquoi pas encore natif ?

C’est l’éléphant dans la pièce. Alors que de nombreux utilisateurs espéraient un import natif d’Altium Designer (formats .SchDoc / .PcbDoc / projet .PrjPcb), KiCad 10.0 n’en propose pas. Pourtant, la demande est ancienne : un ticket GitLab (issue #2117) réclame cette fonctionnalité depuis des années. Les solutions tierces comme Altium2KiCad existent, mais elles souffrent de limitations chroniques : formats non documentés, maintenance irrégulière, pertes fréquentes de données (empilements, règles de conception, variables).

Le terrain le confirme : un utilisateur migrant un projet Altium (version 25.6.2) vers KiCad 10.0.6 rapporte sur le forum KiCad.info des avertissements ERC « Symbol pin or wire end off connection grid » sur presque chaque broche et extrémité de fil — un symptôme classique d’une conversion qui ne préserve pas parfaitement la grille de connexion. Une page d’import de bibliothèques Altium (source : Innovation IUT Haguenau) montre par ailleurs que la conversion de bibliothèques est possible, mais elle reste manuelle et partielle.

L’absence d’import natif Altium dans KiCad 10.0 s’explique par la complexité technique : le format binaire d’Altium évolue chaque année, et sa rétro-ingénierie est un chantier colossal. L’équipe a choisi de prioriser Allegro et PADS, probablement parce que ces formats sont plus stables ou parce que des partenariats (comme avec Quilter) ont facilité le travail. Rien n’indique qu’un import Altium natif soit en développement pour une version future, mais la pression communautaire reste forte — d’autant que le coût d’Altium Designer, entre 3 850 et 5 000 USD par utilisateur et par an en 2026 (source : ToolsInfo), pousse de plus en plus d’équipes à chercher une alternative. Sur trois ans, pour cinq postes formation incluse, la facture dépasse 175 000 USD — un argument massif en faveur d’une migration, même imparfaite.

Par ailleurs, la fin de vie d’Autodesk EAGLE le 7 juin 2026 a mécaniquement gonflé le flux de migrants vers KiCad. Pour ces utilisateurs, l’import Eagle reste toutefois tributaire des outils existants — la 10.0.6 a d’ailleurs corrigé des problèmes d’import Eagle (source : changelog 10.0.6), signe que le sujet reste vivant dans la branche 10.0.x, sans pour autant constituer un importeur « natif » au sens des trois nouveaux venus.

Ce que les importeurs changent vraiment dans un workflow de migration

Au-delà des listes de fonctionnalités, la question qui intéresse les bureaux d’études est simple : combien de temps gagne-t-on, et où sont les pièges ? Les retours de terrain de 2026 dessinent une méthode raisonnable.

Première étape : auditer avant de convertir. Les importeurs préservent la géométrie et la connectivité, mais pas les règles avancées. Un projet Allegro chargé en contraintes haute vitesse arrivera dans KiCad avec des netclasses génériques : il faut donc réécrire les règles DRC à la main, en s’appuyant sur l’éditeur de règles graphique introduit dans la 10.0.0. C’est plus visuel qu’autrefois, mais ce n’est pas automatique.

Deuxième étape : traiter le schéma séparément pour Allegro. Puisque l’importeur Allegro ne lit que le PCB, la cohérence schéma/PCB doit être reconstruite. La méthode la plus fiable consiste à exporter une netlist depuis l’outil d’origine, à recréer ou importer le schéma, puis à comparer les netlists avant de lancer le DRC.

Troisième étape : valider par le DRC et la fabrication. Les outils d’autoroutage et de vérification de KiCad 10 (routeur interactif avec modes Walk Around et Shove, Freerouting pour l’autoroutage batch) ne dispensent pas d’une passe DRC complète et d’une vérification des fichiers de fabrication (source : rottenwifi.com). Sur un projet importé, c’est même l’étape la plus critique : les géométries reconstruites (zones, teardrops) peuvent générer des violations invisibles à l’œil.

Quatrième étape : documenter les pertes. Stackup, règles d’impédance, topologies différentielles, variantes : tout ce qui n’est pas converti doit être listé et ressaisi. C’est fastidieux, mais c’est la seule façon d’éviter les mauvaises surprises en fabrication.

Un point d’attention supplémentaire : la stabilité. Les rapports de lenteur extrême sur le déplacement de pistes en 10.0.4/10.0.5 et les crashs d’édition d’empreintes en 10.0.6 sous Windows 11 incitent à migrer sur une version corrective récente (10.0.7, voire la 10.0.8 dès sa sortie stable) plutôt que sur une version intermédiaire.

L’écosystème 2026 : ce qui entoure désormais les importeurs

Les importeurs ne sont qu’une pièce d’un écosystème qui a changé d’échelle en 2026. Trois dynamiques méritent d’être signalées, car elles modifient l’économie même de la migration.

Les plugins et l’API. L’API de KiCad a mûri au point que le cœur du logiciel avale désormais des fonctions qu’on allait autrefois chercher dans des add-ons. L’autoroutage GPU porté par Quilter — le même partenaire qui a soutenu l’importeur Allegro — et les plugins de stitching de vias (génération automatique de grilles de vias de masse par script) illustrent cette tendance : ce qui était artisanal devient industrialisé (sources : SaludPCB, ScriptedPCB).

L’IA entre dans l’atelier. L’enquête Weidmuller 2026, menée auprès de 400 ingénieurs nord-américains, indique que 91 % d’entre eux ont utilisé des outils IA dans leur flux de conception PCB, et que 75 % y voient une couche de productivité accélérant l’itération (source : Automation World). Côté KiCad, cela se traduit par des plugins comme Konnect, un plugin natif en Rust qui relie Claude à KiCad 10 via MCP pour assister la conception schématique et le routage (source : DevTrends), ou par des générateurs de schémas comme SpeedUp. Attention toutefois : les ingénieurs interrogés pointent eux-mêmes les limites — absence de détection d’erreurs en temps réel, autonomie complète « du texte au PCB » encore fantasmée. Un importeur reste un outil déterministe ; l’IA, aujourd’hui, assiste mais ne remplace pas la validation.

La bibliothèque CERN. Avec environ 17 000 composants validés, la bibliothèque CERN constitue un argument de poids pour les équipes qui migrent : elle réduit le travail de recréation de bibliothèques, souvent le poste le plus coûteux d’une migration.

Les conférences. L’écosystème se structure aussi physiquement : la quatrième conférence asiatique KiCon se tiendra à Shenzhen du 5 au 7 novembre 2026, au Huaqiang Plaza Hotel (source : annonce KiCon Asia 2026). C’est l’occasion, pour les équipes qui envisagent une migration, de confronter leurs cas d’usage aux développeurs des importeurs.

Verdict : des importeurs utiles, pas encore une baguette magique

Que retenir pour un concepteur qui envisage de basculer vers KiCad 10.0.x en cet automne 2026 ?

Ce qui marche. L’importeur Allegro est une prouesse technique réelle : géométrie, pastilles, vias, zones, teardrops et contraintes physiques de base sont préservés, sans dépendre des bibliothèques Cadence. L’importeur PADS couvre schéma et PCB, ce qui en fait le meilleur candidat à une migration intégrale. Et la cadence des correctifs (10.0.7 le 7 octobre, 10.0.8 en RC le 22 octobre) montre un projet qui répond vite.

Ce qui coince. Pas de schéma pour Allegro, pas de règles haute vitesse ni d’impédances converties, pas de stackup garanti, pas de benchmark public pour PADS, presque rien de documenté pour gEDA. Et toujours pas d’import natif Altium, alors que la demande est ancienne et que les solutions tierces produisent des avertissements ERC en série.

La bonne pratique. Migrer sur la version corrective la plus récente, auditer les règles avant conversion, traiter le schéma séparément quand l’importeur ne le couvre pas, valider systématiquement par DRC et par vérification des fichiers de fabrication, et documenter explicitement tout ce qui n’a pas été converti.

KiCad 10.0.x n’a pas supprimé le travail de migration — il en a supprimé la partie la plus ingrate. C’est déjà beaucoup. Pour les équipes qui hésitent encore, le calcul économique reste implacable : face à un Altium à 3 850–5 000 USD par utilisateur et par an, quelques semaines de reprise manuelle sont vite amorties. La prochaine étape logique, côté projet, serait un importeur Altium natif ; rien, à ce jour, ne permet d’affirmer qu’il est en chantier.

Sources

• KiCad — Version 10.0.0 Released (20 mars 2026)
• KiCad — Three New Importers in KiCad 10: Allegro, PADS, and gEDA (février 2026)
• KiCad — 10.0.6 Release (29 août 2026)
• KiCad — 10.0.6 Release Candidate 1 (18 août 2026)
• KiCad — 10.0.7 Release Candidate 1 (27 septembre 2026)
• KiCad — 10.0.7 Release Candidate 2 (3 octobre 2026)
• KiCad — KiCon Asia 2026 Announcement (16 septembre 2026)
• KiCad — page officielle et page de téléchargement
• Forum KiCad.info — 10.0.6 crashes when editing footprints in user library (Windows 11)
• Forum KiCad.info — 10.0.4 / 10.0.5 extremely slow track movement (12 août 2026)
• Forum KiCad.info — Altium → KiCad 10 import: « Symbol pin or wire end off connection grid » (1er septembre 2026)
• Forum KiCad.info — KiCad 10 PADS import questions
• GitLab KiCad — issue #2117 (import Altium)
• Tech Explorations — KiCad 10 review
• ToolsInfo — Altium Designer vs KiCad comparison 2026
• Innovation IUT Haguenau — Importation de bibliothèques Altium
• Automation World — Weidmuller PCB Design Survey Reveals AI Tool Impacts
• DevTrends — Konnect, plugin Rust pour Claude dans KiCad 10 (7 septembre 2026)
• RottenWifi — KiCad Autorouting Made Easy (13 août 2026)
• SaludPCB — KiCad Plugin Tutorial 2026: Stitching Vias (11 août 2026)
• ScriptedPCB — Créer une grille de vias de stitching par script (13 septembre 2026)
• NOVAKVM — Installer KiCad 10.0.6 sur Mac Apple Silicon (23 septembre 2026)

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