Kicad Master · 17 October 2026

KiCad 10.0.7 en approche : quand les patches communautaires comblent les angles morts de la version stable

Alors que la branche stable s’apprête à passer en 10.0.7 — deux release candidates déjà publiées fin septembre et début octobre 2026 — et que KiCad 11 se profile pour février 2027, un dépôt GitHub tenu par un contributeur passionné propose des correctifs et améliorations qui n’ont pas encore franchi les portes de l’amont. Export Eco1/Eco2, couches Underlay, correctifs de segfaults : plongée dans un écosystème parallèle qui révèle les rouages de la gouvernance du logiciel libre.

Un dépôt qui défie le cycle officiel

Il y a des dépôts GitHub qui passent inaperçus, et d’autres qui racontent une histoire. cbernardo/kicad-patches appartient à la seconde catégorie. Ce dépôt rassemble des correctifs écrits par un développeur indépendant pour KiCad, le célèbre suite de conception de PCB open source. Sa simple existence pose une question troublante : pourquoi, alors que l’équipe officielle publie des versions stables à un rythme soutenu — la 10.0.6 est sortie le 29 août 2026 et la 10.0.7 est en phase de release candidate —, un contributeur externe juge-t-il nécessaire de maintenir son propre arsenal de patches ?

La réponse tient en un mot : la lenteur. Non pas celle des développeurs, mais celle d’un cycle de publication qui privilégie la stabilité à l’innovation. KiCad 10, sorti en mars 2026, a apporté son lot de nouveautés, mais comme toujours, certaines fonctionnalités restent en attente, soit parce qu’elles ne sont pas prioritaires, soit parce qu’elles nécessitent des discussions approfondies. Pendant ce temps, les utilisateurs avancés — ceux qui conçoivent des cartes complexes, des prototypes industriels, des projets de restauration de matériel ancien — ont besoin de solutions immédiates. C’est exactement ce que propose ce dépôt : des patches ciblés, prêts à l’emploi, qui répondent à des besoins concrets non couverts par la version stable.

Le paradoxe est savoureux : alors que la 10.0.6 corrige des bugs critiques et que la 10.0.7 s’apprête à prendre le relais, ce dépôt communautaire offre des fonctionnalités qui ne verront peut-être le jour que dans KiCad 11 — dont la sortie est attendue autour de février 2027 selon le fil officiel « Post-V10 New Features and Development News » du forum KiCad. Comment ces patches naissent-ils ? Comment survivent-ils aux changements de versions ? Et surtout, que disent-ils de la santé du projet KiCad ? Autant de questions que nous allons explorer, en nous appuyant sur le contenu réel du dépôt et sur les dynamiques de la communauté.

Dans les coulisses du dépôt : des patches qui répondent à des besoins réels

Le dépôt cbernardo/kicad-patches n’est pas un fourre-tout. Chaque patch y est documenté, souvent lié à une révision précise du système de gestion de versions Bazaar (BZR), l’ancien outil utilisé par KiCad avant la migration vers Git. La dernière révision BZR mentionnée pour la création des patches est la 4657, tandis que d’autres patches se réfèrent aux révisions 5259, 5140 et 4942. Ces numéros, qui peuvent sembler obscurs, sont en réalité des jalons : ils indiquent la base de code sur laquelle chaque correctif a été développé, et donc le niveau de compatibilité avec les versions actuelles.

Parmi les patches les plus parlants, on trouve celui qui permet l’export de graphiques vers les couches Eco1 et Eco2 via l’outil bitmap2component. Pour les concepteurs de PCB, ces couches sont essentielles : elles servent à ajouter des marquages de fabrication, des logos, des références sérigraphiées ou des instructions d’assemblage. Or, la version officielle de KiCad ne permet pas toujours d’exporter des images directement vers ces couches, un manque qui oblige les utilisateurs à des contournements chronophages. Ce patch comble exactement ce vide.

Autre exemple : l’ajout de couches « Underlay » pour la reconstruction de PCB. Imaginez que vous deviez recréer un circuit imprimé à partir d’une photo ou d’un scan d’une carte existante. La fonction Underlay permet de superposer une image de référence sous le dessin des pistes, facilitant ainsi le calage et la reproduction. C’est un outil précieux pour la rétro-ingénierie, un domaine où KiCad est de plus en plus utilisé. Le patch underlay_in_progress.patch (basé sur la révision 5140) est encore en développement, mais il montre la voie.

Enfin, le patch vrml_layer_pth.patch (révision 4942) corrige des segfaults potentiels dans l’export VRML lorsque des trous métallisés (plate-through holes) sont présents. Pour qui travaille avec des logiciels de visualisation 3D ou des outils de vérification mécanique, un export VRML qui plante est un cauchemar. Ce correctif, simple mais crucial, illustre parfaitement le rôle de ces patches : ils ne sont pas de simples gadgets, mais des solutions à des problèmes réels rencontrés en production.

Le mécanisme technique : comment appliquer ces patches sans casser son installation

Concrètement, comment un utilisateur lambda peut-il bénéficier de ces patches ? Le dépôt ne contient pas de fork complet de KiCad, mais une collection de fichiers .patch, chacun ciblant une fonctionnalité ou un correctif spécifique. Ces fichiers sont conçus pour être appliqués avec des outils standards comme git apply ou patch -p1. La procédure typique consiste à :

Cloner le dépôt : git clone https://github.com/cbernardo/kicad-patches.git
Télécharger le source de KiCad : de préférence une version correspondant à la révision BZR indiquée dans le patch, ou la dernière version stable (10.0.6, en attendant la 10.0.7).
Appliquer le patch : git apply chemin/vers/le/patch.patch depuis la racine du source KiCad.
Compiler : avec CMake, en s’assurant que les dépendances (wxWidgets, Boost, etc.) sont installées.

La compilation de KiCad n’est pas triviale, mais elle est bien documentée. Le principal risque est de casser une installation stable : si le patch n’est pas compatible avec la version du code source, la compilation échouera, ou pire, produira un exécutable instable. Pour éviter cela, il est fortement recommandé de :

Travailler dans une copie séparée : ne jamais patcher l’installation système, mais compiler dans un répertoire dédié.
Vérifier la compatibilité : lire attentivement la description du patch, qui indique la révision BZR de référence.
Tester en environnement isolé : utiliser un conteneur Docker ou une machine virtuelle pour valider le comportement avant de l’adopter en production.

Une fois compilé, le binaire peut être utilisé en parallèle de l’installation officielle, en définissant des variables d’environnement appropriées. Cette approche permet de bénéficier des fonctionnalités expérimentales sans sacrifier la stabilité de son environnement de travail quotidien. À noter que sur les plateformes où KiCad est distribué en paquet — comme ALT Linux, qui propose kicad-10.0.6-alt2 dans son dépôt Sisyphus —, la compilation manuelle reste la seule voie pour tester un patch avant son intégration amont.

Nightly builds, branche de développement, forks : quelle différence avec ces patches ?

Pour obtenir des fonctionnalités en avance, les utilisateurs ont plusieurs options. Les nightly builds officiels, compilés automatiquement à partir de la branche de développement, offrent un accès immédiat aux dernières nouveautés, mais au prix d’une stabilité aléatoire. La branche de développement — désormais celle de KiCad 11, ouverte après la sortie de la 10.0 — est plus fiable, mais elle est réservée aux développeurs et aux testeurs avertis. Les forks communautaires, comme ceux qui ajoutent des fonctionnalités spécifiques, existent mais sont souvent peu maintenus.

Les patches communautaires se distinguent par leur granularité : ils ciblent une fonctionnalité précise, sans entraîner tout le reste de la branche de développement. Cette approche présente plusieurs avantages :

Stabilité préservée : on part d’une version stable connue, on applique un correctif chirurgical, et on obtient une version stable plus la fonctionnalité souhaitée.
Facilité de test : on peut activer ou désactiver un patch indépendamment des autres.
Maintenance ciblée : l’auteur du patch peut le mettre à jour rapidement en cas de changement dans le code source, sans avoir à suivre tout le rythme de développement.

Critère	Patches communautaires	Nightly builds	Version stable (10.0.6 / 10.0.7)
Stabilité	Bonne (basée sur une version stable)	Faible (code en développement)	Excellente (testée)
Fonctionnalités	Ciblées, spécifiques	Toutes les nouveautés	Limitée aux fonctionnalités officielles
Accès aux nouveautés	Immédiat pour les patches	Immédiat pour tout	À chaque version majeure
Maintenance	Par l’auteur du patch	Par l’équipe officielle	Par l’équipe officielle
Support officiel	Aucun	Aucun	Complet

Ce tableau montre clairement que les patches communautaires occupent une niche unique : celle de l’utilisateur qui veut une fonctionnalité précise sans subir les aléas du développement en cours. C’est une approche pragmatique, très prisée des professionnels qui ne peuvent pas se permettre de passer des heures à résoudre des régressions.

Le cycle de vie d’un patch : de la wishlist à l’intégration upstream

Comment un patch passe-t-il du statut de bricolage personnel à celui de fonctionnalité officielle ? Le processus commence souvent par une wishlist : l’auteur du dépôt, cbernardo, tient un fichier cb_kicad_wishlist qui liste ses souhaits d’améliorations pour KiCad. C’est une pratique courante dans le monde open source : on note ce qui manque, on réfléchit à une solution, puis on code.

Une fois le patch écrit et testé, l’auteur peut le proposer en amont, via le système de merge requests de GitLab (le dépôt officiel de KiCad). L’équipe de développement, dirigée par des figures historiques comme Wayne Stambaugh et Jean-Pierre Charras (créateur du projet en 1992), examine alors la proposition. Les critères d’acceptation sont stricts : qualité du code, compatibilité avec les versions futures, documentation, tests. Certains patches sont acceptés rapidement, d’autres restent en attente pendant des mois, voire des années.

Le délai moyen d’intégration est difficile à estimer, faute de statistiques publiques. Mais on observe que les patches les plus simples (corrections de bugs, améliorations mineures) sont souvent intégrés en quelques semaines, tandis que les fonctionnalités plus ambitieuses (comme l’ajout de couches Underlay) nécessitent des discussions approfondies et des itérations multiples. L’équipe officielle est légitimement prudente : chaque ajout au code source doit être maintenu à long terme, documenté et compatible avec l’architecture existante.

Il arrive aussi que des patches ne soient jamais intégrés, soit parce que la fonctionnalité est jugée trop spécifique, soit parce que l’approche proposée ne correspond pas à la vision des développeurs. Dans ce cas, le dépôt communautaire devient un refuge : la fonctionnalité continue de vivre, maintenue par son auteur, et les utilisateurs qui en ont besoin peuvent l’utiliser en connaissance de cause.

Ce que révèle ce dépôt sur la gouvernance de KiCad

L’existence de ce dépôt est un signal fort sur la santé de l’écosystème KiCad. D’un côté, elle démontre la vitalité de la communauté : des contributeurs externes sont prêts à investir du temps pour améliorer un logiciel qu’ils utilisent au quotidien. De l’autre, elle met en lumière une tension structurelle entre la stabilité et l’innovation.

Les développeurs officiels, Wayne Stambaugh en tête, ont toujours accueilli favorablement les contributions externes. La migration de KiCad vers SourceForge en 2007, puis vers GitLab, a été motivée par la volonté de faciliter l’intégration des patches communautaires. Depuis, le projet a bénéficié de contributions majeures, notamment du CERN, qui a mis des ingénieurs à disposition pour améliorer le routage. Cette ouverture est une force, mais elle implique aussi une charge de travail importante pour l’équipe de coordination, qui doit examiner chaque proposition.

Les discussions publiques sur les forums et le GitLab officiel montrent que les développeurs sont conscients de ce phénomène. Ils encouragent les contributeurs à proposer leurs patches en amont, tout en rappelant que l’intégration peut prendre du temps. Cette position, à la fois ouverte et prudente, est caractéristique des projets open source matures. Elle explique pourquoi certains correctifs mettent des années à rejoindre la branche principale — et pourquoi, en attendant, des dépôts comme cbernardo/kicad-patches jouent un rôle de soupape.

L’écosystème 2026 : quand la communauté prend le relais sur toute la chaîne

Ce dépôt de patches n’est pas un cas isolé. Il s’inscrit dans un écosystème 2026 où la communauté KiCad a pris l’habitude de combler elle-même les angles morts du logiciel, sur toute la chaîne de conception.

Côté automatisation du layout, des scripts comme ceux publiés par scriptedpcb.com génèrent des grilles complètes de vias de stitching reliés à la masse, plutôt que de les placer une à une. Un tutoriel de plugin publié le 11 août 2026 va dans le même sens : remplir automatiquement les plans de masse d’un clic. Ces outils répondent à un besoin que le cœur du logiciel ne couvre pas nativement.

Côté IA, l’écosystème s’est structuré en trois familles distinctes, comme l’a analysé protoflow.ai le 31 juillet 2026 : les plugins intégrés à l’éditeur, les outils de génération de schéma puis d’export, et la génération de composants assistée. Un exemple notable est 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 — repéré par DevTrends le 7 septembre 2026. À noter que le copilote « ALT TAB Circuit Copilot » reste, lui, au statut expérimental.

Côté fabrication, l’outil AIVON, présenté le 15 septembre 2026, propose une cotation instantanée de fabrication directement depuis KiCad. Et côté documentation, le constat est plus mitigé : alors que le code accélère, le manuel officiel peine à suivre — un paradoxe que nous détaillons dans notre dossier dédié.

Enfin, l’écosystème matériel suit : 3Dconnexion consacre désormais une page officielle à KiCad et une vidéo de démonstration à ses SpaceMouse, signe que le logiciel est devenu une cible commerciale légitime pour les périphériques professionnels.

KiCad 11 se prépare : ce que la branche de développement annonce déjà

Si les patches communautaires comblent des manques maintenant, la branche de développement de KiCad 11 — attendue autour de février 2027 — montre ce que l’amont prépare. Le fil officiel « Post-V10 New Features and Development News » du forum KiCad recense déjà plusieurs fusions significatives.

D’abord, le support de l’import des cartes SprintLayout, qui devrait couvrir toutes les versions récentes du programme — un pas de plus dans la stratégie d’import multi-formats après l’arrivée de l’import Altium. Ensuite, « Find by Properties », une fonction de recherche par propriétés qui facilite l’édition en masse sur le PCB : on sélectionne un objet pour retrouver tous ceux qui partagent ses propriétés, ou on bascule en mode requête pour des recherches par expression, avec génération d’expressions depuis la sélection courante.

L’API IPC et kicad-python gagnent également de nouvelles capacités : tous les types de génération de sortie possibles avec kicad-cli sont désormais accessibles via l’API, et un mode headless permet de lancer kicad-cli api-server pour une session longue sans interface, avec auto-démarrage de kicad-cli à la demande depuis les bindings Python. Pour tester ces fonctions avant la 11.0, il faut compiler kicad-python depuis les sources — les versions PyPI restant réservées à la branche stable.

Enfin, le workflow de mise à jour des empreintes gagne une option « match pad positions » : si la nouvelle empreinte a son origine ailleurs (broche 1 contre centre du corps) ou une convention d’orientation différente (Level A = haut-gauche, Level B = bas-gauche), KiCad tente de recaler automatiquement les pastilles. Autant de fonctionnalités qui, demain, rendront certains patches communautaires obsolètes — mais qui, aujourd’hui, n’existent que pour ceux qui compilent la branche de développement.

Conclusion : la soupape et le laboratoire

Le dépôt cbernardo/kicad-patches n’est ni une anomalie ni une menace. C’est à la fois une soupape — il permet à des utilisateurs d’accéder maintenant à des fonctions attendues demain — et un laboratoire : certaines idées qui y germent finissent par rejoindre l’amont, d’autres restent des solutions de niche assumées.

Pour l’utilisateur, la leçon est pragmatique. Si vous avez besoin d’une fonctionnalité précise absente de la 10.0.6 ou de la future 10.0.7, et que vous savez compiler KiCad, un patch communautaire peut vous faire gagner des semaines. Si vous préférez la stabilité, attendez la 10.0.7 — dont la sortie est imminente après deux release candidates — ou surveillez la branche 11. Dans tous les cas, l’existence de ces dépôts parallèles est le signe d’un projet en bonne santé : une communauté assez investie pour ne pas attendre, et une équipe amont assez solide pour que ses choix tiennent dans le temps.

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.

Patches communautaires : quand la communauté fait avancer KiCad plus vite que les versions officielles