Electrosens R&D

KiCad 10 : le nouveau format de fichier PCB décrypté – compatibilité, migration et impact sur votre workflow

Electrosens Kicad Master · 8 October 2026

Le format de fichier .kicad_pcb dans KiCad 10 : ce qui a vraiment changé (et ce que ça change pour votre workflow)

Rumeurs de format binaire, craintes de compatibilité, espoirs de performances… La sortie de KiCad 10 a suscité son lot d’interrogations. Mais derrière les annonces de mode sombre et de DRC graphique, qu’en est-il vraiment du fichier .kicad_pcb ? Plongeons dans les évolutions réelles du format et ce qu’elles changent pour votre workflow quotidien, alors que la branche 10 poursuit sa maturation : après la 10.0.6 du 29 août 2026, la 10.0.7 est en phase de release candidate.

KiCad 10 : le format de fichier PCB a-t-il vraiment changé ?

À l’approche de la version 10, des rumeurs ont circulé sur un possible passage à un format binaire, à l’image d’Altium ou d’EAGLE. Certains redoutaient une rupture de compatibilité avec les outils de versioning (Git) et les scripts Python. La réalité est plus nuancée.

Le format reste du S-expression texte. KiCad n’a pas basculé vers un format binaire propriétaire. Les fichiers .kicad_pcb, .kicad_sch et .kicad_pro sont toujours des fichiers texte lisibles, structurés en arborescences de parenthèses. La documentation officielle des formats de fichiers le confirme : le S-expression est conservé, et c’est une excellente nouvelle pour la gestion de versions — git diff continue de fonctionner, et les outils de comparaison textuelle restent utilisables. Un article d’Anchorpoint sur Git avec KiCad souligne d’ailleurs que ce format texte est « le complément parfait » pour le versioning.

Cependant, des extensions majeures ont été ajoutées à la structure pour supporter les nouvelles fonctionnalités. L’équipe KiCad a dû enrichir le format pour accueillir :

  • Les variantes de conception (design variants) – plusieurs options de montage dans un même fichier.
  • Les blocs de conception PCB (PCB Design Blocks) – sous-circuits réutilisables.
  • L’éditeur de règles DRC graphique – des règles visuelles stockées dans le fichier.
  • Les codes-barres et les remplissages hachurés (hatched fills).
  • Les importateurs Allegro, PADS et gEDA/Lepton – qui nécessitent des champs de métadonnées supplémentaires.

Ces ajouts ne changent pas la nature textuelle du format, mais ils en augmentent la complexité. Un fichier KiCad 10 typique contient désormais des sections dédiées aux variantes, aux blocs et aux règles DRC, absentes dans la version 9. La lisibilité humaine reste bonne, mais la structure s’allonge.

L’article d’Elektor sur KiCad 10 (30 mars 2026) confirme ces points : « la version 10 de KiCad est arrivée, et c’est l’une de ces mises à jour qui semblent utiles dès le premier coup d’œil », avec notamment le mode sombre Windows, les barres d’outils personnalisables, les variantes de conception et le nouvel éditeur de règles graphique. L’article ajoute que les importateurs Allegro, PADS et gEDA/Lepton PCB sont « particulièrement utiles si vous transférez des circuits plus anciens ou des projets mixtes vers un flux de travail plus cohérent ».

À retenir : Pas de format binaire. Le S-expression texte est conservé, enrichi de nouvelles sections. La compatibilité Git est préservée.

Pourquoi le format S-expression historique atteignait ses limites

Le format S-expression de KiCad a fait ses preuves depuis des années : simple, lisible, facile à parser. Mais avec la croissance du logiciel et l’émergence de projets complexes (2000+ composants, 16 couches, contraintes haute fréquence), il montrait ses limites.

Source : electwork.net

Problèmes rencontrés avec l’ancien format :

  • Absence de métadonnées de conception : impossible de stocker des variantes de montage (populate / DNP) dans un seul fichier. Les concepteurs devaient dupliquer les projets ou utiliser des scripts externes. Comme le détaille notre article dédié aux variantes de cartes dans KiCad 10, la gestion des séries multiples relevait de l’acrobatie : champs personnalisés, scripts Python, exports BOM séparés.
  • Gestion des contraintes : les règles DRC étaient définies globalement, sans possibilité de les associer à des zones ou des objets spécifiques de manière graphique. L’éditeur graphique de règles DRC de KiCad 10, analysé dans notre article dédié, change la donne : « Pendant des années, définir une règle de conception dans KiCad revenait à écrire un poème en S-expression dans un fichier texte, sans aucun retour visuel. »
  • Collaboration en équipe : le format ne permettait pas de gérer finement les différences entre versions. Les outils de review (CADLAB.io, BoardRepo) devaient parser le fichier brut, sans sémantique claire pour les variantes.
  • Taille et performances : pour les très gros projets, les fichiers S-expression pouvaient atteindre plusieurs dizaines de mégaoctets, ralentissant l’ouverture et la sauvegarde. Bien que KiCad 10 n’ait pas publié de benchmarks officiels, des retours d’utilisateurs sur les forums évoquent des améliorations sensibles, notamment grâce à une meilleure gestion mémoire.

Face à ces limitations, l’équipe KiCad a choisi d’étendre le format existant plutôt que de le réécrire. Une décision pragmatique qui préserve la compatibilité ascendante tout en ouvrant la voie à des fonctionnalités modernes.

Contexte concurrentiel : Altium Designer (abonnement annuel de 3 850 à 5 000 USD par utilisateur, formation facturée 1 000 à 2 000 EUR par personne) et Autodesk EAGLE (fin de vie annoncée dès 2023) poussent de nombreux utilisateurs vers KiCad. Le nouveau format devait répondre aux attentes des professionnels sans sacrifier la simplicité qui a fait le succès de l’outil open source. Les comparatifs 2026 (ToolsInfo, Technology Tools, protoflow.ai) confirment que KiCad est désormais un concurrent sérieux sur le plan des fonctionnalités — même si Altium garde l’avantage sur la simulation SPICE avancée et la gestion de données d’équipe, et reste Windows uniquement.

Ce que le nouveau fichier .kicad_pcb contient désormais

Prenons un fichier .kicad_pcb typique de KiCad 10 et examinons les ajouts structurels documentés.

Variantes de conception

Les variantes permettent de définir plusieurs configurations de montage dans un même projet. Par exemple, une carte avec une version « standard » et une version « premium » avec des composants supplémentaires. Dans le fichier, une nouvelle section (design_variants ...) liste les variantes et associe chaque composant à un état (monté / non monté / alternative). Cela évite de dupliquer les fichiers et simplifie la gestion des nomenclatures (BOM). Notre décryptage complet du workflow variantes détaille le mécanisme : de la définition dans le schéma à l’export BOM, en passant par les cas d’usage réels (options de fabrication, configurations, gestion des stocks). Altium propose une granularité plus fine (valeurs, textes, zones de cuivre, règles), mais KiCad 10 couvre l’essentiel des besoins.

Blocs de conception PCB

Les blocs sont des sous-circuits réutilisables (alimentation, connecteur, etc.) qui peuvent être instanciés plusieurs fois. Le format stocke désormais une section (blocks ...) contenant la définition de chaque bloc, et des références dans la section (board ...). Cela rappelle le concept de « sheet » dans les schémas, mais appliqué au PCB.

Règles DRC graphiques

L’éditeur de règles DRC graphique permet de définir des contraintes visuellement (ex. : espacement minimum entre deux nets spécifiques). Ces règles sont stockées dans une section (graphical_drc_rules ...) du fichier PCB, ce qui les rend portables avec le projet. Comme le souligne notre analyse de l’éditeur DRC, « le canevas graphique parle encore au moteur DRC » : les classes de net et les zones dessinées forment la nouvelle grammaire des contraintes, avec un retour visuel en temps réel.

Codes-barres et remplissages hachurés

Deux fonctionnalités mineures mais utiles : les codes-barres (pour le marquage automatique) et les remplissages hachurés (pour les zones de cuivre). Le format a été étendu pour supporter ces nouveaux types de graphiques.

Impact sur la lisibilité humaine

Le fichier reste du texte, mais il est plus long et plus structuré. Un projet simple de 500 composants verra son fichier .kicad_pcb augmenter de 10 à 20 % en taille, principalement à cause des sections de variantes et de blocs. La lecture directe reste possible, mais on préférera l’éditeur graphique pour naviguer.

Gestion de versions

Les git diff sont plus parlants : une modification de variante apparaît comme un changement dans la section (design_variants ...), et non comme un déplacement de tout le fichier. Les outils de review (CADLAB.io, BoardRepo) peuvent désormais interpréter ces sections pour afficher les différences de manière sémantique. BoardRepo propose d’ailleurs un plan gratuit limité, et CADLAB.io également, ce qui facilite l’adoption en équipe.

Tableau récapitulatif des ajouts structurels :

Fonctionnalité Section dans le fichier .kicad_pcb Impact sur la taille Impact sur la lisibilité
Variantes de conception (design_variants ...) Modéré Bonne (section dédiée)
Blocs PCB (blocks ...) Modéré à élevé Bonne (hiérarchie claire)
Règles DRC graphiques (graphical_drc_rules ...) Faible Très bonne (règles nommées)
Codes-barres (barcode ...) Faible Bonne
Remplissages hachurés (filled_zones ...) avec attribut hatch Faible Bonne

Compatibilité ascendante et descendante : ce qui marche, ce qui casse

La question cruciale pour tout utilisateur : puis-je ouvrir un fichier KiCad 10 dans KiCad 9 ? Et inversement ?

Source : elektormagazine.fr

Compatibilité descendante (KiCad 9 → KiCad 10)

Sans problème. KiCad 10 ouvre tous les fichiers créés avec KiCad 9.x. Les nouvelles fonctionnalités (variantes, blocs, etc.) sont simplement absentes du fichier, mais la structure de base est identique. Aucune perte de données n’a été documentée. Les bibliothèques de symboles et d’empreintes sont également compatibles.

Compatibilité ascendante (KiCad 10 → KiCad 9)

Déconseillée. Ouvrir un fichier KiCad 10 dans KiCad 9 entraînera la perte des informations spécifiques à la version 10 : les variantes, les blocs, les règles DRC graphiques, les codes-barres, etc. KiCad 9 ignorera les sections inconnues, mais le fichier restera lisible. En pratique, si vous travaillez en équipe, assurez-vous que tous les membres utilisent KiCad 10 ou une version récente. Notre analyse du cycle de patchs 10.0.6 → 10.0.7 revient en détail sur les scénarios de cohabitation 9/10 en équipe.

Problèmes signalés

  • Champs personnalisés de symboles manquants dans kicad-python 0.7.1 : un utilisateur a rapporté sur le forum que les champs personnalisés des symboles n’étaient pas accessibles via l’API Python avec KiCad 10. Ce bug concerne l’API, pas le format de fichier lui-même, mais il peut affecter les scripts de migration. L’article d’Electronics Design Australia sur le scripting pcbnew recommande de tester vos scripts avec la dernière version de l’API.
  • Crash lors de la migration d’une ligne de table de bibliothèque imbriquée : corrigé dans la version 10.0.5 (issue #23291). Si vous aviez des tables de bibliothèques complexes, la migration pouvait planter.
  • Ajout intempestif de bibliothèques stock : lors de la migration, KiCad 10 ajoutait automatiquement des bibliothèques « stock » même si l’utilisateur n’en avait aucune. Corrigé dans 10.0.5 (issue #24594).
  • Lenteurs signalées dans l’éditeur PCB : un fil du forum KiCad rapporte des problèmes de performance avec 10.0.4 et 10.0.5, notamment lors du déplacement de pistes déjà routées — au point que la 10.0.5 était jugée « inutilisable » par certains utilisateurs. La version 10.0.6, sortie le 29 août 2026, apporte des correctifs critiques et des améliorations mineures (annonce officielle).
  • Import Altium : avertissements ERC en masse : un fil du forum KiCad (1er septembre 2026) documente un cas de migration d’un projet Altium vers KiCad 10.0.6 générant l’avertissement « Symbol pin or wire end off connection grid » sur presque chaque broche et chaque fil — un rappel que les importateurs, aussi bons soient-ils, ne dispensent pas d’une passe de nettoyage sur la grille.

Où en est la branche 10 aujourd’hui ? Le calendrier des versions

Le format de fichier n’évolue pas en vase clos : il suit le rythme des releases. Et sur ce plan, la branche 10 a connu une année 2026 chargée.

  • Mars 2026 : sortie de KiCad 10.0.0, la version majeure qui introduit variantes, blocs, DRC graphique et importateurs revus (annonce officielle).
  • 18 août 2026 : release candidate de la 10.0.6.
  • 29 août 2026 : sortie stable de la 10.0.6, « correctifs critiques et améliorations mineures ».
  • 27 septembre 2026 : première release candidate de la 10.0.7.
  • 3 octobre 2026 : deuxième release candidate de la 10.0.7, « disponible pour tests ; la 10.0.7 sera publiée prochainement sauf problème critique découvert lors des tests » (annonce officielle).

Autrement dit, au moment où nous écrivons, la 10.0.6 est la dernière version stable, et la 10.0.7 est en fin de cycle de test. La documentation de référence est d’ailleurs déjà calée sur cette dynamique : le manuel utilisateur KiCad 10.0 en français précise explicitement être « basé sur KiCad 10.0.7 », signe que la branche est considérée comme mûre.

Ce rythme de patchs n’est pas anodin : il traduit une phase de stabilisation active. Pour le format de fichier, cela signifie concrètement que les sections introduites en 10.0.0 sont désormais figées et corrigées, et qu’il n’y a plus de raison d’attendre pour adopter la branche 10 sur un projet neuf. Notre radiographie du cycle 10.0.6 → 10.0.7 détaille où se concentre le risque (eeschema, pcbnew, 3D viewer, kicad-cli) et aide à décider s’il faut sauter sur 10.0.6 ou attendre 10.0.7.

Conseil pratique : si vous migrez un projet critique, partez de la 10.0.6 (stable, correctifs de migration inclus) et surveillez la sortie de la 10.0.7. Évitez de rester sur 10.0.4/10.0.5 si vous manipulez de longues pistes déjà routées.

Le format et l’écosystème : scripts, plugins, IA

Un format de fichier ne vit pas seul. Ce qui fait sa valeur, c’est ce que l’écosystème peut en faire — et 2026 a été une année faste sur ce front.

Source : elektormagazine.com

Scripting et API

L’API pcbnew reste le point d’entrée pour l’automatisation. La documentation CI de l’API a été publiée en juillet 2026, et les scripts Python continuent de parser le S-expression sans rupture. La génération de grilles de vias de stitching par script (13 septembre 2026) illustre bien la philosophie : plutôt que de placer des dizaines de vias à la main, on génère une grille complète reliée à la masse par script — un usage qui n’aurait aucun sens avec un format binaire opaque. Un tutoriel plugin 2026 (11 août 2026) va dans le même sens : « auto-remplir les plans de masse en un clic ».

Routage assisté et plugins

L’écosystème des routeurs tiers continue de s’appuyer sur le format texte. Freerouting reste l’option d’autoroutage la plus citée, mais attention : la version 2.3.0 (28 août 2026) a introduit une régression — elle produit des routes que son propre scoring signale comme présentant des violations de clearance, là où la 2.2.4 routait proprement. Un rappel utile : validez toujours un routage automatique par une passe DRC, quelle que soit la version.

Côté GPU, le plugin OrthoRoute — né d’un projet Hackaday (23 avril 2026) — montre jusqu’où le format texte permet d’aller : router une carte que les autorouteurs traditionnels refusent, en s’appuyant sur un solveur de type PathFinder accéléré par GPU. Un cas d’usage de niche, mais révélateur de la flexibilité du format.

L’IA s’invite dans le workflow

2026 est aussi l’année où l’IA est devenue un vrai sujet dans l’écosystème KiCad. L’analyse de protoflow.ai sur l’IA dans KiCad (31 juillet 2026) recense trois méthodes concrètes pour ajouter de l’IA à un workflow : plugins in-editor, outils « generate-then-export » de schémas, et génération de composants assistée. Côté francophone, DevTrends documente (7 septembre 2026) Konnect, un plugin natif pour KiCad 10 écrit en Rust, qui transforme Claude en assistant de schématique et de routage via le protocole MCP. Là encore, tout repose sur la lisibilité du format : un LLM ne peut aider que s’il peut lire et écrire le fichier.

Le fork chinois et la gouvernance

Enfin, un phénomène à suivre : le fork chinois de KiCad, porté par Huaqiu Electronics, qui publiait sa 10.0.2 le 11 mai 2026 sur kicad.eda.cn. Ce fork ajoute Copilot, cloud et commande en un clic — et pose une question de fond sur la gouvernance de l’EDA open source. Notre anatomie de cet écosystème parallèle en détaille les ressorts. Pour le format de fichier, l’enjeu est clair : un fork qui divergerait trop finirait par créer des variantes incompatibles — un argument de plus pour la prudence dans l’extension du S-expression.

Le rendez-vous asiatique

Signalons enfin que la quatrième conférence asiatique KiCad (KiCon Asia 2026) se tiendra à Shenzhen, du 5 au 7 novembre 2026, au Huaqiang Plaza Hotel (annonce officielle). C’est là que se dessineront probablement les priorités de la branche 11 — et, avec elles, les prochaines évolutions du format.

Ce que cela change concrètement pour votre workflow

Au-delà de la technique, voici ce que ces évolutions impliquent au quotidien.

1. Vos habitudes Git tiennent. Pas de migration vers un binaire, pas de plugin Git exotique à installer. Le S-expression reste diffable. C’est un avantage compétitif réel face à Altium, dont le format est fermé.

2. Vos scripts Python survivent — avec des précautions. Le bug des champs personnalisés dans kicad-python 0.7.1 montre que l’API peut prendre du retard sur le format. Testez vos scripts sur la 10.0.6 avant de migrer un pipeline de production.

3. La migration depuis KiCad 9 est sûre, mais pas instantanée. Les correctifs de migration (tables de bibliothèques imbriquées, bibliothèques stock) sont arrivés en 10.0.5. Si vous migrez un gros projet, partez de la 10.0.6.

4. Les variantes et blocs changent la donne en production. Produire trois SKU sans dupliquer le projet, c’est un gain de temps réel — et un gain de fiabilité, puisque la source de vérité reste unique.

5. L’IA devient utilisable, mais reste un assistant. Les trois méthodes recensées par protoflow.ai et le plugin Konnect montrent que l’IA peut accélérer la schématique et le routage. Mais un LLM qui écrit dans un fichier S-expression doit être validé par une passe DRC — exactement comme un autoroutage.

6. Surveillez la 10.0.7. En release candidate depuis fin septembre 2026, elle devrait sortir prochainement. Si vous êtes sur 10.0.4/10.0.5 et souffrez des lenteurs de déplacement de pistes, la 10.0.6 est le minimum, la 10.0.7 la cible.

Conclusion : un format qui mûrit sans se trahir

La grande leçon de cette année 2026, c’est que KiCad a étendu son format sans le trahir. Pas de binaire, pas de rupture Git, pas de réécriture : le S-expression a simplement accueilli de nouvelles sections pour les variantes, les blocs, le DRC graphique, les codes-barres et les remplissages hachurés. La compatibilité descendante est totale, la compatibilité ascendante est déconseillée mais non destructrice.

Le vrai chantier de 2026 n’était pas le format, mais la stabilisation. Entre la 10.0.0 de mars et la 10.0.7 en release candidate début octobre, la branche a enchaîné sept correctifs — dont certains critiques pour la migration et les performances. C’est le prix d’une version majeure ambitieuse, et le signe d’un projet qui assume sa maturité.

Pour le concepteur PCB, le message est simple : la branche 10 est prête pour la production, à condition de partir de la 10.0.6 et de valider ses scripts et ses routages. Le format, lui, reste ce qu’il a toujours été : du texte lisible, diffable, scriptable — et c’est précisément ce qui permet à l’écosystème (plugins, IA, forks, outils de review) de prospérer autour de lui.

Sources

Article recherché et rédigé automatiquement · Magazine Electrosens
📬 Restez à la pointe
Recevez chaque semaine les nouveautés de ce magazine par email.
💬 Une remarque, une correction ?
Aidez-nous à améliorer cet article. Nous prenons en compte vos retours.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *