Kicad Master · 27 October 2026

Embedding dans KiCad 10.0.x : symboles, empreintes et modèles 3D dans le projet, pilier de la portabilité et du versioning

KiCad 9 avait introduit une fonctionnalité discrète mais transformatrice : l’incorporation directe de symboles, empreintes et modèles 3D dans le fichier projet. Avec la branche KiCad 10.0.x — dont la 10.0.6 est sortie le 29 août 2026 et la 10.0.7 est en fin de cycle de validation à l’automne 2026 —, cette capacité est devenue un pilier de l’écosystème, renforçant la portabilité, le versioning et la collaboration. Décryptage d’une évolution qui change la conception PCB open-source, et qui s’articule désormais avec la bibliothèque CERN, les outils de versioning cloud, les plugins d’IA et l’autoroutage GPU.

L’embedding en pratique : comment KiCad 9 a changé la donne

Jusqu’à la version 8, un projet KiCad était un assemblage de fichiers liés à des bibliothèques externes : symboles, empreintes, modèles 3D, tout pointait vers des fichiers situés dans des dossiers système, utilisateur ou projet. Le moindre déplacement de ces dépendances provoquait des liens cassés, des erreurs de chargement et des heures de débogage. Avec KiCad 9.0, sorti en février 2025 (annonce officielle), les développeurs ont introduit une fonctionnalité longtemps attendue : l’embedding (incorporation) des symboles, empreintes et modèles 3D directement dans les fichiers du projet.

Concrètement, lorsque vous activez l’embedding, KiCad copie les données des composants utilisés – leur représentation schématique, leur empreinte PCB, leur modèle 3D – et les stocke dans le fichier projet lui-même. Techniquement, le format reste celui des S-expressions textuelles (le format natif de KiCad) : les données embarquées sont sérialisées et intégrées aux fichiers .kicad_pro (projet), .kicad_sch (schéma) et .kicad_pcb (circuit imprimé). Aucun format binaire propriétaire, tout reste lisible et versionnable. La documentation officielle de la branche 10.0 détaille l’ensemble du mécanisme (manuel de référence KiCad 10.0).

Deux modes sont proposés :

Embedding automatique : lors de l’ajout d’un composant depuis une bibliothèque, KiCad copie automatiquement les données dans le projet. C’est le mode recommandé pour les nouveaux designs.
Embedding manuel : vous conservez des liens vers les bibliothèques externes, mais vous pouvez décider d’incorporer certains composants spécifiques (par exemple, un symbole personnalisé ou une empreinte rare).

L’option se configure dans les préférences du projet (Fichier > Propriétés du projet > Fichiers embarqués). Un simple clic permet de basculer un composant du mode lié au mode embarqué, et vice‑versa. Cette souplesse est cruciale pour adopter la fonctionnalité progressivement, sans casser les projets existants. Les discussions sur le forum officiel confirment que la gestion des fichiers embarqués, notamment pour les modèles 3D, a été affinée au fil des versions correctives (discussion forum).

À noter : KiCad 9.0 a également introduit les ensembles prédéfinis de tâches (Jobsets), les classes de composants et les design blocks (blocs de conception réutilisables), qui viennent compléter l’embedding pour un workflow plus industrialisé (analyse Elektor). Mais c’est bien l’incorporation des données qui constitue le changement le plus profond.

Avec KiCad 10.0, sorti le 20 mars 2026 (annonce officielle), l’embedding a été stabilisé et optimisé. Les performances de sérialisation ont été améliorées, et l’interface utilisateur pour la gestion des fichiers embarqués a été affinée. Le cycle correctif de la branche 10.0.x s’est ensuite déroulé à un rythme soutenu : la 10.0.6, publiée le 29 août 2026, a apporté « des corrections de bugs critiques et d’autres améliorations mineures » par rapport à la version précédente (annonce 10.0.6). Depuis, la 10.0.7 est en phase de validation : une première release candidate a été mise en ligne le 27 septembre 2026, puis une seconde le 3 octobre 2026, la version finale étant annoncée « soon unless critical issues are found in testing » (RC1 10.0.7, RC2 10.0.7). À l’heure où nous écrivons, c’est donc la 10.0.6 qui reste la dernière version stable publiée, la 10.0.7 étant imminente — un signe de maturité et d’une communauté extrêmement active.

Portabilité sans compromis : pourquoi l’embedding révolutionne le partage de designs

Avant KiCad 9, partager un projet complet relevait du parcours du combattant. Il fallait soit :

Fournir l’intégralité des bibliothèques utilisées (souvent volumineuses),
Espérer que le destinataire dispose des mêmes versions,
Ou utiliser un outil externe pour « figer » les dépendances.

Avec l’embedding, le projet devient autonome. Un seul dossier (ou une archive ZIP) contient tout le nécessaire : schémas, PCB, symboles, empreintes, modèles 3D. Plus de chemins absolus, plus de fichiers manquants, plus de « Ça marche chez moi ».

Aspect	Bibliothèques externes (KiCad ≤8)	Fichiers embarqués (KiCad 9/10)
Dépendances	Multiples fichiers externes	Tout dans le projet
Partage	Archive + bibliothèques à joindre	Un seul dossier / dépôt
Risque de liens cassés	Élevé (déplacement, renommage)	Nul
Mise à jour des composants	Automatique si bibliothèque à jour	Manuelle (ré‑embedding)
Taille du projet	Faible (liens)	Plus élevée (données dupliquées)
Compatibilité ascendante	Projets ouverts dans toutes les versions	Projets embarqués non ouvrables dans KiCad ≤8

Cette autonomie change la donne pour le partage par email, les dépôts Git, ou la publication de designs sur des plateformes comme GitHub, GitLab ou les forums. Un designer peut désormais envoyer son projet à un fabricant (JLCPCB, PCBWay) sans craindre qu’un symbole ne se charge pas. Les tutoriels et les exemples de code deviennent reproductibles à l’identique. Le tutoriel de conception PCB de bout en bout pour KiCad 9 illustre parfaitement cette approche : un projet complet, du schéma aux fichiers Gerber, peut être partagé et reproduit sans configuration supplémentaire (tutoriel PCB KiCad 9).

Exemple concret : un projet open‑source de carte d’acquisition utilisant un microcontrôleur STM32 et un capteur Bosch. Sans embedding, le contributeur doit télécharger les bibliothèques STM32 et Bosch, les installer dans le bon dossier, et espérer que les chemins correspondent. Avec l’embedding, il clone le dépôt et ouvre le projet : tout est là.

La version portable de KiCad illustre parfaitement cette portabilité : une clé USB suffit pour emporter l’EDA et tous ses projets embarqués, sans installation ni droits administrateur. L’embedding garantit que les designs restent complets même sur un support amovible. C’est un argument de poids pour les ingénieurs terrain qui doivent présenter des projets chez des clients sans avoir accès à leur poste de travail habituel. Attention toutefois à la cohérence des versions : la version portable disponible est alignée sur la 10.0.5, et non sur la 10.0.6 — un détail qui compte si vous travaillez à plusieurs sur un même dépôt (dossier KiCad Portable).

Git et collaboration : la fin des fichiers orphelins

Le versioning avec Git est l’un des grands bénéficiaires de l’embedding. Dans un workflow classique, les fichiers de bibliothèques sont souvent exclus du dépôt (via .gitignore) ou gérés comme des sous‑modules, ce qui complique les diff et les merge. Les modifications d’un symbole ou d’une empreinte ne sont pas tracées dans l’historique du projet, ce qui peut entraîner des régressions silencieuses.

Avec l’embedding, chaque composant fait partie intégrante du dépôt. Si vous modifiez un symbole, le fichier .kicad_sch change, et Git voit la différence. Les diff deviennent lisibles (format texte), les merge sont plus fiables, et la reproductibilité des builds est garantie : on peut reconstruire un design exactement comme il était à un commit donné, sans dépendre de l’état des bibliothèques locales.

Pour les équipes, cela ouvre la voie à :

CI/CD : un serveur d’intégration continue peut cloner le dépôt, lancer une vérification DRC, générer les fichiers Gerber, le tout sans configuration supplémentaire. L’API Python pcbnew et l’outil en ligne de commande kicad-cli permettent d’automatiser des vérifications DRC/ERC personnalisées et la génération de BOM et d’empreintes directement dans le pipeline (guide d’automatisation) — une approche que l’embedding rend bien plus robuste, puisque toutes les données sont dans le dépôt.
Revue de code : les modifications de symboles ou d’empreintes sont visibles dans la pull request, ce qui permet une relecture fine.
Distribution de designs prêts à fabriquer : un client ou un fabricant reçoit un dépôt Git complet, avec la garantie que tout est présent.

Des services spécialisés ont d’ailleurs émergé pour tirer parti de cette synergie entre KiCad et Git : BoardRepo et CADLAB.io proposent un hébergement cloud avec visualisation web des schémas et PCB, historique visuel et commentaires sur les composants ou les pistes, avec une offre gratuite limitée et une option on-premise pour les entreprises. Anchorpoint propose également un guide complet pour utiliser Git avec KiCad comme filet de sécurité ultime pour les layouts (guide Anchorpoint). L’embedding rend ces outils nettement plus efficaces, puisque le dépôt contient tout.

Mise en garde : l’embedding augmente la taille du dépôt, surtout si vous incluez des modèles 3D complexes. Mais cette augmentation est souvent acceptable au regard des gains de fiabilité. Certaines équipes choisissent d’embarquer uniquement les symboles et empreintes, et de laisser les modèles 3D en lien externe (ou de les compresser). Le passage au STEP (voir ci-dessous) atténue nettement ce point.

KiCad 10 : l’embedding au cœur d’un écosystème en pleine ébullition

KiCad 10 n’a pas seulement stabilisé l’embedding : il l’a intégré dans un écosystème beaucoup plus large. Plusieurs évolutions majeures méritent d’être soulignées.

Le passage au format STEP pour tous les modèles 3D

Dès le cycle de KiCad 9, l’équipe a basculé le format 3D par défaut vers STEP. Avec KiCad 10, seuls des fichiers STEP sont désormais distribués dans les bibliothèques officielles : l’annonce de la 10.0.0 précise que « starting with KiCad version 10 we are shipping STEP files only — this dramatically reduces the install size of the 3D models and gives better geometric accuracy and fewer differences between visualization and export » (annonce de la version 10.0.0). Pour l’embedding, c’est une excellente nouvelle : les modèles STEP embarqués sont plus compacts et plus précis que les anciens formats VRML, ce qui atténue l’un des principaux freins à l’adoption (la taille des projets). Les bibliothèques officielles ont été entièrement migrées vers STEP, un chantier considérable qui a mobilisé la communauté pendant plusieurs mois.

La bibliothèque CERN : 17 000 composants à embarquer

Le 12 mai 2026, le CERN a officialisé la publication de sa bibliothèque interne de composants pour KiCad : plus de 17 000 symboles et empreintes, validés par le Bureau de Conception (source). Cette bibliothèque, compatible avec KiCad 9.x et 10.x, est publiée sous licence CERN-OHL-P-2.0, une licence open-source permissive qui autorise une utilisation libre, y compris commerciale. C’est une mine d’or pour les concepteurs : chaque composant a été rigoureusement vérifié par les ingénieurs du CERN, qui conçoivent des équipements scientifiques parmi les plus exigeants au monde.

Combinée à l’embedding, elle change radicalement le workflow : vous pouvez piocher un composant dans la bibliothèque CERN, l’embarquer dans votre projet, et le design devient autonome — sans dépendre de la présence de la bibliothèque CERN sur la machine du destinataire. C’est précisément le cas d’usage qui justifie l’embedding : une bibliothèque externe volumineuse (17 000 composants) dont on n’utilise qu’une poignée, et qu’on fige dans le projet. La communauté LinuxFr souligne d’ailleurs la prudence de mise : plusieurs intervenants rapportent s’être « déjà fait avoir avec des bibliothèques KiCad qui semblaient correctes, mais étaient fausses niveau dimensions », et préfèrent vérifier les empreintes critiques — l’embedding ne dispense pas d’une revue, il garantit seulement que ce que vous avez validé reste identique chez votre interlocuteur (discussion LinuxFr).

Haute vitesse, DRC graphique et routeur interactif

La branche 10.0.x a aussi fait progresser le cœur du geste de conception, et ces nouveautés interagissent avec l’embedding. KiCad 10 apporte des outils natifs pour la haute vitesse : routage différentiel, accord de longueur interactif (méandres, accordéons), éditeur de règles et de contraintes graphique. Un design haute vitesse embarque typiquement des empreintes personnalisées et des modèles 3D spécifiques — autant d’éléments qu’il vaut mieux figer dans le projet pour garantir que le DRC et les contraintes se comportent de la même manière sur toutes les machines. Le routeur interactif (push and shove, walk around) et le DRC graphique sont détaillés dans nos précédents dossiers (analyse haute vitesse, guide routage).

L’écosystème : IA, autoroutage et plugins

L’embedding s’articule enfin avec la vague d’outils qui entoure KiCad 10.0.x. Côté autoroutage, Freerouting reste la référence open-source, mais sa version 2.3.0 a introduit une régression documentée : des routes qui s’auto-signalent des violations de clearance sur des cartes que la 2.2.4 routait proprement (rapport de bug) — un rappel que la validation DRC reste indispensable, embedding ou pas. Côté IA, des ponts natifs apparaissent, comme Konnect, plugin Rust pour KiCad 10 qui expose Claude via MCP comme assistant de schématique et de routage (DevTrends). Ces outils travaillent d’autant mieux que le projet est autonome : un assistant qui lit un dépôt complet (symboles, empreintes, 3D embarqués) n’a pas à résoudre des chemins de bibliothèques externes. Enfin, les scripts de productivité — grilles de vias de stitching générées automatiquement, par exemple — s’appliquent à des projets dont les données sont toutes locales (SaludPCB, ScriptedPCB).

Migration : ce qui casse, ce qui surprend

Passer à la 10.0.x depuis une version antérieure mérite un peu de méthode. Les retours de la communauté signalent des avertissements ERC récurrents lors de l’import de projets Altium (« Symbol pin or wire end off connection grid » sur presque chaque broche), et des problèmes de performance sur le déplacement de pistes existantes dans l’éditeur PCB en 10.0.4/10.0.5, corrigés depuis (forum KiCad). L’embedding, lui, ne casse rien : les projets existants restent ouvrables, et vous pouvez activer l’incorporation composant par composant. La règle d’or : sauvegarder, inventorier ses bibliothèques, puis embarquer progressivement.

Ce qu’il faut retenir

L’embedding n’est pas un gadget : c’est ce qui transforme un projet KiCad en artefact autonome, versionnable et reproductible. Avec la branche 10.0.x — 10.0.6 stable depuis le 29 août 2026, 10.0.7 imminente —, il s’articule avec le passage intégral au STEP, la bibliothèque CERN de 17 000 composants, les outils de versioning cloud et les plugins d’IA. Pour les équipes, la recette est simple : embarquer symboles et empreintes (et les modèles 3D STEP, désormais compacts), versionner le tout dans Git, valider par DRC dans la CI, et garder un œil sur les versions — la 10.0.7 ne devrait plus tarder.

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.

Fichiers embarqués dans KiCad 9/10 : la révolution silencieuse de la gestion des projets