Kicad Master · 20 October 2026

Variantes de composants dans KiCad 10 : la fin des projets clonés et le vrai début du workflow de production

Pendant des années, gérer trois configurations d’une même carte signifiait trois projets, trois BOM et une bonne dose de copier-coller. Avec les variantes de conception de KiCad 10, le schéma redevient la source unique de vérité — à condition d’accepter une discipline nouvelle et de composer avec des bugs encore ouverts.

Le jour où la carte n’a plus été un fichier unique

Prenez une carte contrôleur un peu banale : un cœur MCU, une alimentation, deux connecteurs, un peu de mémoire. Vous en vendez trois déclinaisons. La version économique, dépopulée : la moitié des options absentes, même circuit imprimé, même perçage. La version « option A » : connectique complète, alimentation renforcée. Et une série dérivée pour un client qui veut sa référence gravée et deux composants changés. Jusqu’ici, dans KiCad, la réponse tenait en un mot : duplication. Trois dossiers, trois .kicad_pro, trois BOM retravaillées à la main, et un jour ou l’autre une correction de routage appliquée à deux projets sur trois.

KiCad 10.0.0, annoncé le 30 mars 2026 sur kicad.org, introduit précisément ce qui manquait : des variantes de conception (design variants) gérées côté schéma. Dit comme ça, on pourrait croire à une case à cocher « DNP » un peu mieux rangée. C’est beaucoup plus que ça : c’est le passage d’un workflow où la carte existait en plusieurs exemplaires à un workflow où la carte existe une fois, et où les variantes sont des vues de cette carte unique.

Il faut poser d’emblée le périmètre vérifiable, parce que le sujet est jeune et la littérature mince. Ce que l’on sait de source officielle ou spécialisée : la version 10.0.0 est sortie le 30 mars 2026, les variantes de conception figurent parmi les nouveautés majeures, et la documentation de référence est publiée sur docs.kicad.org/10.0. Ce que l’on sait des retours d’usage : la série 10.0.x a enchaîné les correctifs, jusqu’à une 10.0.6 publiée le 29 août 2026 et une 10.0.7 en release candidate au 3 octobre 2026 — signe qu’on est sur une base désormais stabilisée, mais encore en rodage sur les bords. Et ce qui reste à confirmer : les détails fins du modèle de données et le comportement exact de certains exports, que seule la pratique en atelier tranchera.

Car oui, il y a des bugs. Quatre tickets GitLab au moins documentent des limitations réelles : la BOM se comporte mal quand une base de données de composants est branchée (#23271), les propriétés de composants résistent en mode variante (#23272), les design variants ont des problèmes généraux (#24943), et les fichiers jobset avec sortie variante posent question (#22796). Ce ne sont pas des détails cosmétiques : ce sont exactement les zones où le workflow de production passe. On va donc décortiquer ce qui marche, ce qui coince, et comment organiser son travail en attendant que ça mûrisse.

Avant la 10 : l’artisanat des variantes à la colle et au script

Il faut mesurer ce que la situation antérieure coûtait vraiment, parce que c’est là que se joue le retour sur investissement de la fonctionnalité.

La méthode la plus répandue était la duplication de projet. Simple, gratuite, immédiate — et catastrophique à l’échelle. Chaque variante vivait sa vie. Une correction de valeur sur le schéma d’origine devait être répliquée manuellement dans les clones. Un changement d’empreinte après un passage en atelier ? Trois éditions, trois re-routages partiels, trois DRC. Et la fameuse question qui revient à chaque revue : « est-ce que la version B a bien reçu le dernier correctif ? » Personne ne sait, on compare les fichiers à la main.

La deuxième école, plus subtile, consistait à rester dans un projet unique et à porter la variabilité dans les champs personnalisés. On ajoutait des champs DNP, Population, Variant_A, Variant_B sur les symboles, et on laissait un tableur faire le tri. Ça marchait pour la BOM. Ça ne marchait pas pour le PCB : rien dans le fichier de circuit imprimé ne savait qu’un composant était absent dans une configuration donnée. Le fichier de positionnement sortait complet, et il fallait retoucher le pick-and-place à la main — ou pire, demander au fabricant de ne pas poser certains composants en lui envoyant une capture d’écran annotée.

La troisième école, celle des gens sérieux, passait par des scripts Python. Post-traitement de BOM, filtrage des fichiers de positionnement, génération de variantes de Gerbers. C’est puissant, c’est reproductible, et c’est fragile : ça dépend d’une API qui bouge, d’un mainteneur qui change de travail, et d’une documentation que personne ne lit. On connaît tous la boîte à scripts qui fonctionne mais que plus personne n’ose toucher.

Enfin, il y avait la duplication de feuilles schématiques — une hiérarchie par variante — qui règle le problème de la documentation mais crée une dette de maintenance considérable dès que le design évolue.

Le point commun de tous ces contournements : ils cassent la cohérence schéma-PCB. Le schéma dit une chose, le PCB en dit une autre, la BOM une troisième. Chaque ECO (engineering change order) devient une opération de réconciliation manuelle. La communauté réclamait une vraie gestion de variantes depuis longtemps ; sans pouvoir citer ici de numéro d’issue ni de date de merge précise — la matière disponible ne les fournit pas — on peut dire que l’arrivée tardive s’explique assez bien : les variantes touchent au cœur du modèle de données (le lien symbole-empreinte), à la BOM, aux exports fabricant et à l’interface. C’est une fonctionnalité transverse, pas un plugin. Elle ne pouvait pas arriver avant que l’architecture ne soit prête.

Où vivent les variantes : anatomie du modèle de données

C’est ici qu’il faut être honnête sur les limites de ce qu’on peut affirmer. La documentation officielle 10.0.x ne détaille pas publiquement, dans les extraits disponibles, l’emplacement exact des définitions de variantes — fichier projet .kicad_pro, schéma .kicad_sch, ou PCB .kicad_pcb. Ce qu’on peut dire avec certitude, c’est la logique d’ensemble telle qu’elle ressort de la revue de TechExplorations et de la présentation des nouveautés : les variantes sont définies côté schéma, et se propagent vers le PCB et les sorties.

La distinction conceptuelle essentielle, et c’est là que beaucoup de confusion règne : variante de conception (design variant) n’est pas variante de composant. Une variante de composant, c’est un choix de référence alternatif pour un même emplacement — le classique « on peut mettre le régulateur A ou le régulateur B, ils sont brochés pareil ». Une variante de conception, c’est une configuration de la carte entière : dans la variante « économique », tel régulateur est absent, telle mémoire n’est pas montée, tel connecteur est dépopulé. KiCad 10 traite les deux notions, mais c’est la seconde qui structure le workflow de production.

Concrètement, une variante référence des composants et leur associe des attributs : l’état DNP (do not populate, ne pas monter), éventuellement une valeur alternative, et — c’est le point qui demande vérification en atelier — la possibilité d’un footprint alternatif. Ce dernier cas est le plus délicat : changer d’empreinte entre variantes signifie que le PCB doit accueillir les deux, ou que la variante n’est pas routable de la même façon. La documentation ne tranche pas clairement ce cas dans les extraits consultés, et c’est typiquement le genre de chose qu’il faut tester soi-même sur un projet jetable avant de s’engager.

Deuxième point à vérifier : la granularité. Une variante est-elle définie au niveau du projet (donc valable pour toute la hiérarchie) ou peut-elle être surchargée par feuille ? La réponse change tout pour les designs hiérarchiques complexes. Là encore, la doc publique ne le dit pas explicitement dans ce qu’on a pu consulter — test en atelier obligatoire.

Troisième point : la nomination. Les variantes portent des noms, et ces noms vont se retrouver dans les noms de fichiers exportés, dans les BOM, dans les échanges avec le fabricant. Une convention de nommage claire n’est pas un détail cosmétique, c’est ce qui évite d’envoyer la BOM de la variante A avec les Gerbers de la variante B.

Du schéma au PCB : ce que la synchronisation fait vraiment

Voilà le cœur technique, et le cœur du changement de discipline.

Dans l’ancien monde des projets dupliqués, la synchronisation schéma → PCB était une opération lourde : on mettait à jour le PCB depuis le schéma, on regardait les diffs, on validait. Avec les variantes, la même opération doit propager non seulement les composants et les nets, mais aussi les états de variante. La question concrète : quand je modifie une variante après avoir routé, que se passe-t-il ?

La réponse raisonnable, et celle qui ressort de la logique de la fonctionnalité : le PCB hérite des états de variante (quels composants sont montés, quels champs changent), mais pas d’un re-routage. Si vous dépopulez un composant dans une variante, le PCB ne se réorganise pas magiquement pour combler le vide. C’est une bonne chose — un outil qui re-routerait automatiquement sur changement de variante serait un cauchemar — mais ça impose de réfléchir en amont : la carte doit être routée pour accueillir toutes les variantes simultanément. Autrement dit, le routage doit être valide pour l’union des configurations.

C’est un renversement complet de la contrainte de conception. Avant, chaque variante avait son propre routage, optimisé pour elle. Maintenant, il y a un routage unique qui doit satisfaire tout le monde. Pour une carte dépopulée, c’est indolore : les composants en trop laissent des plages vides, ce qui ne gêne personne. Pour une carte à options où deux variantes ont des besoins d’alimentation très différents, c’est plus subtil : il faut prévoir les deux chemins, quitte à ce que l’un soit inutilisé dans une configuration.

Les pièges de désynchronisation existent malgré tout. Le ticket #23272 — impossible de modifier les propriétés de composants en mode variante — est exactement le genre de chose qui peut laisser un PCB dans un état incohérent si on ne vérifie pas. La discipline à adopter : après toute modification de variante, relancer une mise à jour schéma → PCB explicite, vérifier le diff, et ne jamais considérer que « ça s’est propagé tout seul ». C’est moins confortable que l’ancien monde où chaque projet était autonome, mais c’est infiniment plus sûr que de comparer trois dossiers à l’œil.

Un mot sur les blocs de conception PCB (PCB design blocks), également nouveaux en KiCad 10 : ils permettent de réutiliser des sous-ensembles routés entre projets. Combinés aux variantes, ils ouvrent la porte à des architectures où un bloc « alimentation » existe en deux implémentations, chacune dans sa variante. C’est prometteur, mais c’est aussi une nouvelle source de complexité : deux mécanismes de réutilisation qui interagissent, ça se teste.

À la sortie de l’atelier : BOM, pick-and-place, Gerbers et formats fabricant

C’est le moment de vérité. Une variante qui ne produit pas les bons fichiers ne sert à rien.

La BOM. C’est le cas d’usage le plus mature : générer une BOM filtrée par variante, avec les composants DNP exclus ou marqués. C’est précisément ce que la fonctionnalité vise, et c’est ce que décrit le tutoriel d’usage partagé sur le forum KiCad. La réserve : le ticket #23271 signale un comportement incorrect de la BOM avec base de données de composants. Si vous utilisez une base de données externe (ce que font beaucoup d’équipes de production), testez avant de vous engager.

Le fichier de positionnement (pick-and-place). C’est là que l’ancien monde faisait le plus mal : un position file complet pour une carte dépopulée, c’est une invitation à l’erreur en fabrication. La cohérence entre variante et position file est l’un des bénéfices attendus les plus directs. À vérifier concrètement : le fichier sort-il filtré nativement, ou faut-il un post-traitement ? La documentation ne le tranche pas dans les extraits disponibles.

Les Gerbers et perçages. Ici, il faut être clair : les Gerbers ne changent pas selon la variante. Le circuit imprimé est le même ; seuls les composants montés changent. C’est une bonne nouvelle — un seul jeu de Gerbers pour toutes les variantes — mais ça signifie aussi que le fabricant doit recevoir, en plus des Gerbers, l’information de montage par variante. C’est un problème de communication, pas de fichier.

IPC-2581 et ODB++. Ces formats, qui embarquent nativement les données de montage, sont les mieux placés pour porter la notion de variante. KiCad les supporte, mais la question de savoir si les variantes y sont correctement encodées n’est pas documentée dans les sources consultées. C’est un point à tester impérativement si vous travaillez avec un fabricant qui exploite ces formats.

Les questions à poser à son fabricant avant d’envoyer un jeu de fichiers par variante :

Trois cartes, trois variantes : cas d’usage concrets et recettes de mise en place

Cas 1 — la carte dépopulée. Une carte mère, une version économique sans les options. Structuration : une variante « Full » (tout monté, la référence), une variante « Eco » (les options en DNP). Astuce : toujours définir la variante complète en premier, et construire les autres par soustraction. Ça évite l’erreur classique du composant qu’on oublie de dépopuler dans une variante et qu’on retrouve monté sur la carte économique. Vérification avant export : croiser visuellement le schéma en mode « Eco » avec la BOM générée, composant par composant, sur les blocs critiques (alimentation, interfaces).

Cas 2 — la carte à options. Connectique, alimentation, mémoire. Ici, la variante ne se contente pas de dépopuler : elle change des valeurs. Le piège : les composants dont la valeur change entre variantes doivent être clairement identifiés, sinon la BOM dit une chose et le schéma une autre. Astuce : préfixer les références des composants variables (R_OPT1, C_OPT2) pour les repérer d’un coup d’œil dans la BOM. Et documenter, dans un fichier texte à côté du projet, la matrice variante × composant — parce que l’outil ne la génère pas encore sous forme de tableau lisible.

Cas 3 — la série dérivée. Un client veut sa référence, deux composants différents, un marquage spécifique. C’est le cas le plus simple en apparence et le plus piégeux en pratique : la tentation est de dupliquer le projet « juste pour ce client ». Résistez. Une variante de plus coûte moins cher qu’un projet de plus. Astuce : nommer la variante avec le nom du client (ACME_v1), et vérifier que le nom atterrit bien dans les noms de fichiers exportés.

La checklist de contrôle croisé, à passer avant chaque envoi en fabrication :

1. Ouvrir le schéma dans la variante cible, vérifier visuellement les DNP.
2. Générer la BOM, compter les lignes, comparer avec le nombre attendu.
3. Générer le fichier de positionnement, vérifier qu’il ne contient que les composants montés.
4. Relancer un DRC dans la variante (voir section suivante).
5. Vérifier que les Gerbers sont identiques entre variantes — s’ils diffèrent, il y a un problème.
6. Nommer les fichiers avec la variante dans le nom.

Le DNP ambigu mérite un mot : un composant marqué DNP mais dont l’empreinte reste présente sur le PCB peut être monté par erreur si le fabricant ne lit pas la BOM. La parade est documentaire : un marquage clair sur le plan de montage, et une ligne explicite dans le bon de commande.

Le reste de la 10 : ce qui travaille avec les variantes (ou contre elles)

KiCad 10 n’est pas sorti avec les variantes seules. La revue de CNX Software et celle d’Electwork listent un paquet de nouveautés qui interagissent directement avec le workflow variantes.

L’éditeur de règles DRC graphique est le meilleur allié des variantes. Pouvoir définir et visualiser des règles de conception par zone, c’est exactement ce qu’il faut pour vérifier qu’une carte routée pour l’union des variantes reste conforme dans chaque configuration. La question ouverte : le DRC s’exécute-t-il par variante ou sur le design complet ? Si c’est sur le design complet, vous validez l’union — ce qui est plutôt rassurant, mais ne détecte pas les problèmes spécifiques à une configuration (un composant dépopulé qui laisse un net flottant, par exemple). À tester.

Les importateurs Allegro, PADS et gEDA sont une autre histoire. Ils permettent de rapatrier des designs existants — et donc, potentiellement, des designs qui avaient déjà leurs propres variantes. La question de la conversion des variantes à l’import n’est pas documentée dans les sources consultées. Un retour d’expérience sur le forum KiCad du 1er septembre 2026 signale d’ailleurs des difficultés d’import Altium → KiCad 10.0.6 avec des avertissements ERC « Symbol pin or wire end off connection grid » sur presque chaque broche — rappel utile que l’import reste un chantier, et que les variantes importées sont un sujet encore plus neuf.

L’échange CSV dans l’éditeur de symboles facilite la mise à jour en masse de champs — utile quand on doit ajouter un attribut de variante à cinquante symboles.

L’export PDF 3D et les codes-barres sont des ajouts de documentation de production : le premier pour les revues, le second pour le suivi en atelier. Les deux renforcent le workflow variante sans le transformer.

Le mode sombre Windows, les barres d’outils personnalisables et la sélection au lasso sont du confort. Ne les sous-estimez pas : un workflow de production se juge aussi au temps passé dans l’outil.

Enfin, un point qui mérite attention : la mention, dans les extraits disponibles, que KiCad 10 ne distribuerait plus que des fichiers STEP pour les bibliothèques. L’information est tronquée et non vérifiée ; si elle se confirme, elle change la donne pour les modèles 3D utilisés dans les exports mécaniques — un sujet adjacent aux variantes, mais qui touche à la documentation de production.

KiCad face à Altium, Allegro et Xpedition : le rattrapage et les angles morts

La comparaison honnête commence par un constat : Altium Designer dispose d’un Variant Manager documenté officiellement depuis longtemps. Ce n’est pas une nouveauté chez Altium, c’est une fonction mature. KiCad 10 rattrape une partie du retard, pas la totalité.

Ce que KiCad 10 aligne. Les variantes de base : oui. Le DNP : oui. La BOM par variante : oui, avec la réserve de la base de données (#23271). La cohérence schéma-PCB : oui, dans la logique décrite plus haut. Pour une PME qui gère deux ou trois configurations d’une carte, c’est suffisant, et c’est gratuit.

Ce qui reste en retrait. Les matrices de variantes complexes — ces tableaux où l’on croise dizaines de variantes et centaines de composants avec des règles conditionnelles — ne sont pas documentées comme supportées. Les variantes imbriquées (une variante qui en hérite d’une autre) ne le sont pas non plus. La traçabilité documentaire — savoir qui a changé quoi dans quelle variante et quand — reste à construire, probablement via Git et de la discipline. La gestion d’équipe avec verrouillage et historique n’est pas du tout le terrain de KiCad.

Le prix, en revanche, n’est pas comparable. Altium Designer, c’est un abonnement annuel de 3 850 à 5 000 USD par utilisateur, une formation à 1 000–2 000 EUR par personne, et un coût total sur trois ans pour cinq postes qui dépasse les 175 000 USD formation incluse. Pour une petite structure, la question ne se pose même pas : KiCad 10 offre 80 % du besoin variantes pour 0 % du prix. La comparaison KiCad vs Altium publiée par protoflow.ai en août 2026 va dans le même sens : le gratuit concurrence sérieusement le payant sur le cœur du métier, et perd sur la gestion de données d’équipe et les bibliothèques d’entreprise.

Les retours de concepteurs venus d’Altium, prudemment : les sources disponibles n’en fournissent pas de documentés. On peut seulement dire que la migration se heurte à des questions de conversion (voir le retour d’expérience d’import du 1er septembre 2026), et que les variantes importées sont un point de friction probable.

Quand KiCad suffit : petite structure, deux à cinq variantes par carte, pas de base de données de composants centralisée, pas de contrainte de traçabilité réglementaire lourde. Quand il ne suffit pas encore : matrices de variantes à grande échelle, équipes distribuées avec gestion de configuration, exigences documentaires fortes.

Ce que ça change pour l’équipe, et ce qu’il faut surveiller dans les 10.x

Le changement le plus profond n’est pas technique, il est organisationnel. La fin des projets dupliqués signifie la fin d’une certaine forme de confort : celui de pouvoir bricoler une variante sans impacter les autres. Désormais, toute modification touche potentiellement toutes les configurations. C’est plus sûr, mais ça demande une revue de conception par variante — un rituel nouveau : avant de valider un changement, on l’inspecte dans chaque configuration.

Les compétences à acquérir sont modestes mais réelles : comprendre le modèle variante, adopter une convention de nommage, savoir générer et vérifier une BOM filtrée, et surtout tester son propre flux avant de le déployer. La bonne méthode : prendre une carte existante, créer deux variantes factices, générer les exports, comparer avec l’ancienne méthode. Une demi-journée qui évite des semaines d’ennuis.

Les limites à surveiller dans les prochaines révisions 10.0.x sont identifiables : les quatre tickets ouverts (#23271, #23272, #24943, #22796) couvrent la BOM avec base de données, l’édition de propriétés en mode variante, les design variants en général et les jobsets. La sortie de la 10.0.7, en release candidate au 3 octobre 2026 après une 10.0.6 publiée le 29 août 2026, est le prochain jalon à surveiller — les notes de version diront si ces points sont traités.

Dans l’écosystème, deux signaux à garder à l’œil. D’abord, les plugins et scripts BOM : la communauté a construit des années de contournements ; leur adaptation aux variantes natives dira si l’outil est vraiment adopté. Ensuite, le support des fabricants : tant que les fabricants ne sauront pas lire une variante dans un IPC-2581, une partie du travail restera manuelle.

Un dernier conseil, le plus important : ne migrez pas un flux de production sur la foi d’un article. Prenez une carte, faites le test, mesurez le temps gagné, vérifiez les exports avec votre fabricant. KiCad 10 a posé les fondations d’un vrai workflow de production. À vous de bâtir dessus — prudemment, mais sans attendre.

Sources

• KiCad Version 10.0.0 Released — kicad.org, 30 mars 2026
• KiCad 10.0 Documentation — docs.kicad.org
• KiCad 10 review: new features, high-speed tuning, variants, and more — TechExplorations
• KiCad 10.0 New Features: Importers, Variants, Graphical DRC — Electwork
• KiCad 10 release — Dark mode, graphical DRC rule editor, new file importers — CNX Software, 22 mars 2026
• KiCad Releases Version 10.0 with Updates Across Libraries, UI, and PCB Design Tools — PCB Directory
• KiCad 10.0: new features of PCB CAD — sudonull
• KiCad Version 10.0.6 Release — kicad.org, 29 août 2026
• KiCad Version 10.0.7 Release Candidate 2 Available — kicad.org, 3 octobre 2026
• Altium → KiCad 10 import: "Symbol pin or wire end off connection grid" — forum.kicad.info, 1er septembre 2026
• KiCad vs Altium in 2026: Where the Free Tool Actually Competes — protoflow.ai, 9 août 2026
• Tickets GitLab KiCad cités : #23271, #23272, #24943, #22796 (work items officiels, statut et résolution non détaillés dans les sources consultées)

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