Electrosens R&D
Electrosens Kicad Master · 28 October 2026

Versioning de projets KiCad en 2026 : Git, plugins, cloud et serveurs MCP — le workflow qui professionnalise l’EDA libre

Fini le temps où l’on dupliquait des dossiers « projet_v2_final_rework » pour sauvegarder une variante de PCB. En 2026, la gestion de versions est devenue un standard pour les concepteurs KiCad, portée par un plugin tiers robuste, des services cloud spécialisés, des outils de revue visuelle et — nouveauté de l’année — des serveurs MCP qui branchent l’IA directement sur l’éditeur. Alors que l’intégration native reste en développement, l’écosystème actuel professionnalise déjà la conception électronique open source. Plongée dans les pratiques qui changent la donne.


De l’âge de pierre à l’ère Git : pourquoi KiCad est fait pour le versioning

Il y a encore quelques années, le concepteur KiCad typique gérait ses révisions comme on range des boîtes dans un grenier : des dossiers « v1 », « v2 », « v3_essai », parfois un fichier ZIP avec la date. Les projets collaboratifs se heurtaient à l’absence de suivi des modifications, et toute expérimentation risquait de polluer le design principal. Puis Git est arrivé, comme une évidence.

KiCad sauvegarde ses fichiers de conception – schémas, empreintes et PCB – au format S-expression, un texte structuré lisible par un humain. Contrairement aux formats binaires propriétaires (comme les .PcbDoc, .SchDoc et .PrjPcb d’Altium), ce choix rend chaque fichier parfaitement adapté au versioning avec Git : les différences entre deux versions peuvent être comparées ligne à ligne, fusionnées et annotées. Comme le souligne un article d’Anchorpoint publié le 1er juillet 2026, « KiCad saves its PCB designs as plain text files, making it uniquely perfect for Git version control » Anchorpoint. Cette spécificité est d’autant plus précieuse que les outils de synchronisation classiques (Dropbox, Google Drive) ne proposent ni verrouillage de fichiers, ni historique de modifications exploitable, ni retour arrière fiable vers un état précis — l’article d’Anchorpoint est explicite sur ce point.

Les premières tentatives d’intégration remontent à KiCad 5.x, où des utilisateurs bricolaient des scripts pour versionner les fichiers .kicad_pcb et .sch. Mais c’est avec KiCad 7 et 8 que le mouvement s’est structuré autour d’un plugin dédié : kicad-git, développé par Adam W. (adamws). Ce plugin, installable via le gestionnaire de plugins et de contenu (PCM) de KiCad, offrait pour la première fois une interface graphique de commit directement depuis l’éditeur PCB. Il utilise git gui en arrière-plan, et peut être configuré pour d’autres outils comme TortoiseGit.

Parallèlement, des services cloud comme CADLAB.io et BoardRepo ont vu le jour, proposant un hébergement spécialisé pour les projets KiCad avec visualisation web des schémas et PCB, commentaires et historique Git. La communauté a rapidement adopté ces solutions, comme en témoignent les discussions sur le forum KiCad et les dépôts GitHub de cartes open source.

Aujourd’hui, la branche 10.0.x est la version de référence. La 10.0.6 a été publiée le 29 août 2026 comme release de correction de bugs KiCad 10.0.6 Release, et la 10.0.7 est en phase de test : une première release candidate a été publiée le 27 septembre 2026, une seconde le 3 octobre 2026, avec une sortie finale attendue « soon unless critical issues are found » KiCad 10.0.7 RC2. Autrement dit, à l’automne 2026, la version stable grand public reste la 10.0.6, la 10.0.7 se préparant en coulisses. Si l’intégration Git native promise par la feuille de route n’est pas encore livrée dans l’interface principale, les outils existants – plugin kicad-git, services cloud, Kiri, et désormais les serveurs MCP – offrent déjà un workflow professionnel. Surtout, KiCad 10 a apporté une avancée majeure qui change la donne pour le versioning : l’embedding des symboles, empreintes et modèles 3D directement dans les fichiers de projet, éliminant le problème des bibliothèques orphelines qui empoisonnait la collaboration (nous y revenons plus bas).


Le cœur du réacteur : le plugin kicad-git toujours dans la course

Le plugin kicad-git reste l’outil le plus utilisé pour versionner un projet KiCad. Installé via le PCM, il ajoute un bouton dans la barre d’outils de l’éditeur PCB (Pcbnew). Un clic ouvre une fenêtre git gui où l’on peut visualiser les fichiers modifiés, écrire un message de commit et pousser vers un dépôt distant. Simple, efficace, mais limité : le plugin ne fonctionne pas dans l’éditeur de schémas (Eeschema). Une lacune que le développeur assume clairement dans le README du dépôt GitHub adamws/kicad-git.

Versions KiCad 10.x (2026)10.0.6 (stable)10.06version10.0.7 RC110.07version10.0.7 RC210.07version
Fonctionnalité Plugin kicad-git Outil natif (à venir)
Installation Via PCM + config manuelle (config.ini) Intégré dans l’interface
Éditeur supporté PCB uniquement Schéma + PCB (prévu)
Interface Lance git gui externe Fenêtre native avec diff
Résolution conflits Manuelle (via git) Assistée (prévue)
Blame / cherry-pick Non Non (prévu ultérieurement)

L’avantage du plugin est sa maturité : il est utilisé depuis KiCad 7, et sa maintenance reste active. Il repose sur une installation préalable de Git et de git gui (fourni avec Git pour Windows). Pour les utilisateurs avancés, il est possible de le personnaliser via un fichier config.ini pour utiliser TortoiseGit ou d’autres clients.

Sur le forum EEVblog, un fil intitulé « How do you do PCB version control with KiCad? » montre que beaucoup de concepteurs utilisent kicad-git en combinaison avec GitHub ou GitLab pour la collaboration EEVblog. Certains préfèrent une approche en ligne de commande pure, mais pour le concepteur non développeur, le bouton « Commit » est un confort non négligeable. Le wiki du LBL ATLAS propose d’ailleurs un guide pas-à-pas pour versionner un projet KiCad avec Git, utile pour les équipes qui veulent un protocole reproductible LBL ATLAS Wiki.

La question de la compatibilité avec KiCad 10 se pose. Le développeur Adam W. a indiqué sur GitHub que le plugin continuerait d’être mis à jour tant que l’API de KiCad le permettrait. Mais si l’intégration native devient complète, le plugin pourrait devenir redondant. En attendant, il reste une solution fiable et éprouvée.


Cloud et collaboration : CADLAB.io passe en version officielle

Le versioning local, c’est bien. Le versioning collaboratif, c’est mieux. C’est là qu’interviennent des services spécialisés.

CADLAB.io a franchi un cap en 2026 : le service a annoncé la sortie officielle de sa solution de « visual version control » pour KiCad CADLAB.io. Concrètement, la plateforme permet d’héberger un dépôt Git, mais surtout de visualiser les schémas et PCB directement dans le navigateur, avec un historique visuel et la possibilité de laisser des commentaires sur des composants ou des pistes. C’est un outil précieux pour les revues de design en équipe, et la sortie « officielle » marque une stabilisation bienvenue après des années de version bêta. CADLAB.io documente par ailleurs son approche du versioning Git pour KiCad sur une page dédiée CADLAB.io – Git Version Control for KiCad.

BoardRepo est un autre service dédié au versioning de projets KiCad. Il propose une intégration poussée avec Git, une visualisation web des designs, et des fonctionnalités de collaboration. Selon leur guide, « Version control for KiCad projects » BoardRepo, il suffit de pousser son dépôt Git vers leur plateforme pour bénéficier d’une interface de revue.

Service Visualisation web Commentaires CI/CD Gratuit ?
CADLAB.io Oui (schéma + PCB) Oui Non Oui (limité)
BoardRepo Oui (schéma + PCB) Oui Non Oui (limité)
GitHub / GitLab Non (fichiers bruts) Oui (code review) Oui (via actions) Oui (public)

L’avantage de ces services est leur intégration poussée : ils comprennent le format KiCad et affichent les composants, les pistes, les plans de masse. Un reviewer peut pointer un défaut sur un via et le designer le corrige immédiatement. Les plans gratuits sont limités en nombre de dépôts privés, mais suffisants pour les hobbyistes.

GitHub et GitLab restent des alternatives plus généralistes. On peut y héberger un dépôt KiCad, mais la visualisation se limite aux fichiers texte bruts. En revanche, ils offrent des pipelines CI/CD : on peut automatiser la génération des fichiers Gerber, les vérifications DRC, ou même lancer des simulations. Un article de juillet 2026 d’Electronics Design détaille précisément comment automatiser KiCad avec l’API Python pcbnew et kicad-cli pour intégrer des vérifications DRC/ERC personnalisées dans une chaîne CI, et générer automatiquement BOM et empreintes Electronics Design AU. Quelques projets open source (comme des cartes Arduino-like) utilisent cette approche.

Attention toutefois à la confidentialité. Héberger ses designs sur un service cloud expose à des risques de fuite de données, surtout pour des produits commerciaux. CADLAB.io et BoardRepo proposent des options de déploiement sur site (on-premise) pour les entreprises, mais à un coût. Le verrouillage fournisseur est également un risque : si le service ferme, la migration peut être complexe.


Kiri : un outil de revue visuelle pour les designs KiCad

Un acteur désormais bien identifié de l’écosystème : Kiri (KiRI), un outil visuel conçu pour la revue des designs KiCad. Développé par leoheck, Kiri est disponible sur GitHub leoheck/kiri. Il permet de charger un projet KiCad (schéma et PCB) et de naviguer dans l’historique Git, d’afficher les différences entre deux commits, et de laisser des commentaires directement sur les éléments du design.

Source : theconversation.com

Contrairement à CADLAB.io ou BoardRepo, Kiri est un outil local (ou déployable sur un serveur) qui se connecte à votre dépôt Git. Il offre une interface web pour visualiser les schémas et PCB, avec un diff visuel qui surligne les modifications. C’est un complément idéal pour les équipes qui souhaitent garder le contrôle de leurs données tout en bénéficiant d’une revue graphique.

Techniquement, Kiri ne réinvente pas la roue : il s’appuie sur les outils existants pour générer des images SVG des schémas et des couches de PCB, puis les compare. Le README du dépôt précise le détail des moteurs utilisés selon la version de KiCad installée : pour les schémas, kicad-cli est utilisé si KiCad ≥ 7 est présent ; pour KiCad 6 (dépourvu de kicad-cli), l’export passe par l’automatisation de l’interface graphique via xdotool (Linux/Windows) ou cliclick (macOS) — une méthode « far from the ideal » et non recommandée ; pour KiCad 5, ce sont plotkicadsch/plotgitsch qui prennent le relais. Pour les couches de PCB, Kiri s’appuie sur Kicad-Diff via la bibliothèque Python pcbnew, plus rapide que kicad-cli qui n’exporte qu’une couche à la fois. Kiri supporte KiCad ≥ 5 et peut s’intégrer à Pcbnew par un bouton dans la barre d’outils. Un point à garder en tête : l’outil est mature mais son développement suit son cours, et la communauté le teste activement. Pour les concepteurs qui veulent une solution de revue sans passer par un service cloud, Kiri reste une option solide et souveraine.


L’embedding : la révolution silencieuse qui change tout pour Git

Si le versioning Git est devenu réellement viable pour KiCad, c’est en grande partie grâce à une fonctionnalité introduite dans KiCad 9 et devenue un pilier avec KiCad 10 : l’embedding des symboles, empreintes et modèles 3D directement dans les fichiers de projet. Comme le détaille notre article dédié, cette capacité élimine le problème des bibliothèques orphelines qui empoisonnait la collaboration L’embedding dans KiCad. Avant, un projet versionné sur Git pouvait référencer des bibliothèques locales qui n’existaient pas chez le collaborateur – le clone fonctionnait, mais le design était cassé. Avec l’embedding, chaque fichier .kicad_sch ou .kicad_pcb contient tout ce qu’il faut pour être ouvert et modifié, ce qui rend le versioning Git réellement fiable.

KiCad 10 a également basculé les modèles 3D officiels au format STEP uniquement. L’annonce de la 10.0.0 est explicite : « 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 » KiCad 10.0.0 Released. Pour le versioning, c’est un gain net : moins de fichiers à tracker, moins de risques de divergence entre la visualisation et l’export.

Un point de vigilance toutefois, relevé sur le forum KiCad en août 2026 : les versions 10.0.4 puis 10.0.5 ont introduit une régression de performance sérieuse dans l’éditeur PCB, où le déplacement de pistes déjà routées devenait extrêmement lent, au point de rendre la 10.0.5 « inutilisable » pour certains utilisateurs forum.kicad.info. La 10.0.6, publiée fin août, corrige ce type de régression — raison supplémentaire de rester à jour sur les correctifs plutôt que de figer une version intermédiaire dans un dépôt de production. Et la 10.0.7, en RC depuis fin septembre, poursuit ce travail d’assainissement.


MCP et IA : le versioning entre dans une nouvelle dimension

La vraie nouveauté de 2026 pour le workflow KiCad ne vient pas de Git lui-même, mais de la couche qui s’y greffe : les serveurs MCP (Model Context Protocol). Ces serveurs permettent à des assistants comme Claude de lire et manipuler un projet KiCad — schémas, PCB, DRC — via une interface standardisée. Comme le détaille notre enquête dédiée, l’écosystème MCP pour KiCad est encore jeune mais bouillonne [notre article MCP et KiCad 10].

Source : hilelectronic.com

Deux projets structurent le paysage. D’un côté, Konnect, un plugin natif KiCad 10 écrit en Rust, binaire unique sans dépendance runtime, bâti sur l’API IPC officielle de KiCad plutôt que sur SWIG, avec un bundle de skills et d’agents Claude, des audits de revue de design et un pipeline de fabrication. Selon la fiche du dépôt, il expose 171 outils et est distribué sous AGPL-3.0 (gratuit pour les individus et l’open source, licence commerciale pour les entreprises) Konnect. Un article de DevTrends du 7 septembre 2026 confirme cette description : Konnect est présenté comme un plugin natif Rust pour KiCad 10 qui transforme Claude en assistant de schématique et de routage via MCP DevTrends. Un article de Fellow du 14 octobre 2026 va dans le même sens, en évoquant 228 outils — un chiffre qui a donc évolué depuis la fiche initiale, signe d’un développement actif Fellow. De l’autre côté, le KiCAD MCP Server historique (Python/TypeScript, licence MIT) reste maintenu et pleinement ouvert, mais le développement actif se poursuit désormais sur Konnect KiCAD-MCP-Server.

Pour le versioning, l’intérêt est direct : un serveur MCP peut lire l’état du dépôt, comparer des révisions, lancer un DRC sur une branche, ou générer un rapport de différences entre deux commits — le tout piloté en langage naturel. C’est encore expérimental, et notre article sur l’IA et le PCB en 2026 insiste sur les limites : fiabilité, sécurité, dette de confiance. Mais l’idée d’un « Git assisté » par IA, où l’on demande « qu’est-ce qui a changé sur le plan de masse entre la v3 et la v4 ? », n’est plus de la science-fiction. À noter que ces outils ne remplacent pas Git : ils s’y branchent. Le dépôt reste la source de vérité, l’IA n’est qu’une interface de plus.


Astuces de workflow : ce qui fait vraiment gagner du temps

Au-delà des outils, quelques pratiques consolident un versioning KiCad sain en 2026.

D’abord, versionner les bons fichiers. Un projet KiCad moderne contient le .kicad_pro, les .kicad_sch, les .kicad_pcb, les fichiers de bibliothèque embarqués et les feuilles de calcul de BOM. Les fichiers de cache, les exports Gerber et les dossiers de fabrication générés doivent être ignorés via .gitignore — ou, mieux, générés par CI. L’embedding de KiCad 10 simplifie d’ailleurs ce tri en réduisant la dépendance à des bibliothèques externes.

Ensuite, automatiser les vérifications. La chaîne kicad-cli permet de lancer DRC et ERC en ligne de commande, d’exporter Gerber et BOM, et donc de les intégrer dans une CI GitHub Actions ou GitLab CI. Un commit qui casse le DRC est rejeté avant même la revue humaine. C’est la pratique qui distingue une équipe amateur d’une équipe professionnelle.

Enfin, soigner les revues visuelles. Git seul ne montre pas un déplacement de piste. C’est là que Kiri, CADLAB.io ou BoardRepo entrent en jeu : ils transforment un diff textuel illisible en une image compréhensible. Pour les équipes qui veulent tout garder en local, Kiri reste la référence open source.

Un mot sur les scripts : des outils comme ScriptedPCB proposent de générer des grilles de vias de stitching par script plutôt qu’à la main ScriptedPCB, et des tutoriels récents montrent comment automatiser le remplissage des plans de masse en un clic SaludPCB. Versionner ces scripts aux côtés du design, c’est garantir la reproductibilité de la carte.


Ce qu’il faut retenir

Le versioning KiCad en 2026 n’est plus un bricolage : c’est un écosystème. Le plugin kicad-git reste la porte d’entrée pour le concepteur solo, malgré sa limitation à l’éditeur PCB. Les services cloud (CADLAB.io, BoardRepo) apportent la revue visuelle collaborative, tandis que Kiri offre une alternative locale et open source. La branche 10.0.x — 10.0.6 stable depuis fin août, 10.0.7 en RC depuis fin septembre — a consolidé l’embedding et le passage aux modèles 3D STEP uniquement, deux avancées qui rendent Git réellement fiable. Et les serveurs MCP (Konnect en tête) ouvrent une nouvelle ère, celle d’un versioning assisté par IA, encore jeune mais prometteur.

Source : wonderfulpcb.com

Reste une inconnue : l’intégration Git native dans KiCad. Tant qu’elle n’est pas livrée, l’écosystème tiers fait le travail — et plutôt bien. La leçon de 2026 : ne figez jamais une version intermédiaire dans un dépôt de production, gardez vos vérifications DRC/ERC automatisées, et adoptez la revue visuelle. Votre « projet_v2_final_rework » ne vous manquera pas.


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 *