Kicad Master · 10 November 2026

KiCad 10.0.8 : six mois dans la série 10.0.x, ce que la mécanique de maintenance a vraiment changé sur l’établi

La 10.0.8 est sortie le 30 octobre 2026. Derrière ce huitième correctif d’une branche ouverte en mars, il y a six mois de crashes corrigés, de régressions colmatées et de promesses de stabilité. Ce n’est pas le lancement de KiCad 10 qu’on raconte ici — c’est ce que la maintenance, patch après patch, a réellement produit dans le travail quotidien du concepteur PCB. Et ce que cela dit du projet lui-même.

Six mois après le coup d’envoi : pourquoi la 10.0.8 n’est pas une mise à jour comme les autres

Il faut se souvenir du calendrier. KiCad 10.0.0 a été publié en mars 2026 — la page de release officielle en porte la trace. Sept mois plus tard, la 10.0.8 paraît le 30 octobre 2026, comme l’atteste le billet officiel relayé par whatsnew.fyi. Entre les deux, sept autres versions intermédiaires : la 10.0.6 le 29 août, la 10.0.7 le 7 octobre, avec ses deux release candidates (rc1 le 27 septembre, rc2 le 3 octobre). Huit releases stables en sept mois, soit un rythme d’environ une tous les trois à quatre semaines. Ce n’est pas anodin : c’est la signature d’une branche qui vit, qui encaisse, et qui corrige.

L’enjeu de cet article n’est donc pas de refaire la critique du lancement de KiCad 10 — d’autres l’ont fait, et bien. Il est de comprendre ce que la mécanique de maintenance a réellement produit. Quand on lit le changelog officiel de la 10.0.8, on ne lit pas une liste de fonctionnalités : on lit une carte des fragilités du logiciel, une photographie des endroits où le terrain a appuyé fort. Un crash du dialogue de préférences (#25698), un échec de sauvegarde sur partage Samba/SMB (#25691), un blocage à la fermeture avec bibliothèque HTTP (#25901) : chacun de ces numéros d’issue raconte une histoire concrète, celle d’un concepteur qui a perdu du travail ou perdu patience.

La méthode de cet article doit être posée d’emblée, avec ses limites. Nous nous appuyons sur le changelog officiel de la 10.0.8, sur les annonces de release du projet, sur les numéros d’issue GitLab cités, et sur les signaux communautaires disponibles — dont un fil du forum KiCad du 1er septembre 2026 sur l’import Altium. Nous assumons les angles morts : le site officiel kicad.org est pauvre en métadonnées (copyright affiché « © 2018-2020 1BitSquared »), la documentation officielle accessible reste figée sur les versions 5.1 et 9.0, et aucune source publique ne fournit de dates de correction par issue. Il faudra donc lire entre les lignes, avec prudence.

Anatomie d’une série .x : ce que les numéros d’issue de la 10.0.8 racontent vraiment

Prenons le changelog de la 10.0.8 au sérieux, comme un document d’enquête. Le billet officiel annonce la couleur : « plusieurs correctifs critiques », et invite à mettre à jour dès que possible. La version est construite depuis la branche 10.0, avec des changements « cherry-picked » depuis la branche de développement. Autrement dit : les mainteneurs ont trié, dans le flux de travail de la branche principale, ce qui méritait de redescendre vers la stable.

Ce tri, on peut le lire dans la liste. Côté correctifs critiques, cinq cas se détachent :

Et côté éditeur schématique, cinq correctifs supplémentaires : préservation des jonctions explicites lors du nettoyage (#25844), fonds opaques sur les icônes de ré-annotation (#17486), faux drapeaux « No connect » à l’import Altium (#22908), chargement par thread des bibliothèques base de données en vol (#25307), héritage du champ empreinte sur symboles dérivés (#25606).

La typologie est instructive. On distingue trois familles. D’abord les crashs purs, qui interrompent le travail sans prévenir : #25698, #25781. Ensuite les régressions fonctionnelles qui ne crashent pas mais cassent un flux : #25691 (sauvegarde réseau), #25901 (fermeture), #25894 (rendu dégradé). Enfin les améliorations glissées, plus discrètes, qui ne corrigent pas un bug mais ajustent un comportement : #17486 sur les icônes, #25844 sur les jonctions. Cette dernière catégorie est la plus intéressante pour comprendre la méthode : elle montre que les mainteneurs ne se contentent pas d’éteindre des incendies, ils polissent aussi à la marge.

Le numéro #17486 mérite un arrêt. Il est bien plus ancien que les autres — les issues de la 10.0.8 s’étalent de #25691 à #25901, soit une fenêtre d’environ 210 numéros. Un #17486 signifie qu’un problème signalé il y a longtemps a trouvé sa correction dans cette release. C’est le signe d’un backlog qui se vide lentement, au fil des cherry-picks.

Routeur interactif, variantes, bibliothèques : les zones qui ont le plus encaissé

Si l’on cartographie les correctifs documentés, une image se dessine. Les zones les plus sollicitées ne sont pas celles qu’on attendrait naïvement. On pourrait croire que le routeur interactif — la star des nouveautés de KiCad 10 selon la revue de Tech Explorations — aurait concentré l’essentiel des patchs. Ce n’est pas ce que montre le changelog de la 10.0.8. Le routeur n’y apparaît pas. La gestion des variantes non plus. Le DRC non plus.

Ce qui apparaît, en revanche, c’est une triade très concrète : l’éditeur schématique (imports, bibliothèques base de données, héritage de champs), l’infrastructure de fichiers (Samba/SMB), et le rendu graphique (OpenGL, iGPU AMD). À quoi s’ajoutent deux points de friction : l’import JLCEDA Pro et le dialogue de préférences.

Cette distribution dit quelque chose de vrai. Les fonctionnalités phares — routeur, variantes — sont sans doute plus stables, ou du moins leurs bugs sont-ils corrigés dans la branche de développement avant d’être rétroportés. Les fragilités se nichent ailleurs : dans les interfaces avec le monde extérieur (imports Altium et JLCEDA), dans les interactions avec l’OS (partages réseau), dans le rendu sur matériel hétérogène (GPU intégrés AMD). C’est le quotidien du concepteur, pas la démonstration marketing.

Il faut ici assumer un angle mort majeur : nous n’avons aucune donnée quantitative par composant. Le changelog fourni est tronqué, et aucune source publique ne compte les correctifs par module. La lecture reste donc qualitative, prudente, fondée sur la présence ou l’absence de numéros d’issue. On ne peut pas dire « le routeur a reçu X correctifs » ; on peut seulement dire qu’il n’apparaît pas dans la liste de la 10.0.8. Nuance essentielle.

Un signal communautaire vient pourtant confirmer la fragilité des imports. Le 1er septembre 2026, un utilisateur signale sur le forum KiCad qu’un projet Altium 25.6.2 migré vers KiCad 10.0.6 déclenche l’avertissement ERC « Symbol pin or wire end off connection grid » sur presque chaque broche et chaque fil. Ce n’est pas un crash, mais c’est un irritant réel, qui touche précisément la promesse d’interopérabilité. Et le correctif #22908 de la 10.0.8 (faux drapeaux « No connect » à l’import Altium) montre que la zone est loin d’être stabilisée.

Du crash au correctif : la réactivité du maintien de branche à l’épreuve des cas concrets

Trois cas méritent d’être disséqués, parce qu’ils racontent chacun une facette différente de la maintenance.

Le crash du dialogue de préférences (#25698). Un utilisateur ouvre les préférences, sélectionne le panneau de couleurs de l’éditeur schématique — et le logiciel plante. C’est le type de bug qui ne détruit pas de données mais qui humilie l’outil : une fonction aussi banale que changer une couleur fait tomber l’application. Sa correction dans la 10.0.8 est un soulagement, mais elle pose question : combien de temps ce crash a-t-il vécu dans la branche stable avant d’être corrigé ? Sans dates par issue, impossible de le dire.

L’échec de sauvegarde sur Samba/SMB (#25691). Celui-ci est plus grave. Une erreur de renommage de fichier temporaire lors d’une sauvegarde sur un partage réseau mappé en lecteur — c’est-à-dire le quotidien de nombreux studios et laboratoires qui travaillent sur un NAS. Le risque n’est pas le crash, c’est la perte de fichier. Un correctif de cette nature justifie à lui seul la mise à jour vers la 10.0.8, et c’est précisément le genre de bug qui rend la promesse « mettez à jour dès que possible » crédible.

Le blocage à la fermeture avec bibliothèque HTTP (#25901). Un utilisateur configure une bibliothèque de symboles HTTP, et le logiciel refuse de se fermer. Bug de coin, mais bloquant pour ceux qui utilisent ce type de bibliothèque — et ils sont de plus en plus nombreux à mesure que les flux collaboratifs se répandent.

Ce qu’on peut dire de la réactivité : la fenêtre des issues de la 10.0.8 s’étend de #25691 à #25901, soit environ 210 numéros. Cela suggère un flux de signalements soutenu sur la période de préparation de la release. Mais on ne peut pas calculer de délais réels de correction : aucune date par issue n’est publique. La numérotation rapprochée indique un trafic, pas une vélocité.

Regard critique, ici, nécessaire. La promesse « plusieurs correctifs critiques, mettez à jour dès que possible » tient-elle ? Oui, sur le fond : les bugs listés sont réels et leur correction compte. Mais elle tient sans canal de communication structuré sur la sévérité. Aucune source publique ne dit combien d’utilisateurs ont été affectés, ni quelle était la gravité relative de chaque bug. Le concepteur doit faire confiance au tri des mainteneurs — ce qui, pour un outil devenu standard industriel, commence à peser.

La fabrique KiCad : ce que la cadence 10.0.x dit du modèle de développement du projet

Il y a un contraste saisissant, et il mérite d’être nommé. D’un côté, un dépôt GitLab vivant : des issues numérotées par milliers, des milestones, des release candidates annoncées publiquement (rc1 le 27 septembre, rc2 le 3 octobre pour la 10.0.7), des tags de bibliothèques d’empreintes synchronisés (10.0.7-rc1 sur GitLab). De l’autre, un site officiel qui affiche encore un copyright « © 2018-2020 1BitSquared » et une documentation qui s’arrête à la 5.1 et à la 9.0.

Cette asymétrie est le vrai sujet. La vitalité du code ne se dément pas : huit releases en sept mois, des cherry-picks depuis la branche de développement, des correctifs qui remontent jusqu’à des issues anciennes (#17486). La politique de backport est claire dans son principe — on ne rétroporte que ce qui est critique ou peu risqué — même si son détail n’est documenté nulle part publiquement.

Le rôle des mainteneurs, en revanche, reste opaque. Aucune source fournie ne décrit la composition de l’équipe de release, les règles de validation, le processus de revue. On sait que le projet est financé via The Linux Foundation (mentionné sur la page de téléchargement), ce qui documente le mode de financement, pas la gouvernance.

Pour un utilisateur qui cherche à évaluer la santé du projet sans lire les commits, la situation est inconfortable. Il voit les releases, il voit les numéros d’issue, mais il ne voit ni la sévérité, ni les délais, ni les critères de tri. C’est un déficit de transparence qui ne remet pas en cause la qualité du travail — les correctifs sont là — mais qui complique la décision d’adoption.

Adopter, attendre ou sauter : quelle 10.0.x pour quel profil

La lecture pratique doit être différenciée, parce que les risques ne sont pas les mêmes selon les profils.

Pour un studio, la 10.0.8 s’impose comme plancher. Les trois crashs majeurs corrigés — préférences, import JLCEDA, fallback OpenGL sur iGPU AMD — touchent des configurations réelles. Le correctif #25894 (rendu logiciel sur GPU intégrés AMD pour grandes cartes) est particulièrement pertinent pour les postes de travail modestes, fréquents dans les petites structures.

Pour un indépendant, l’argument décisif est #25691. Travailler directement sur un partage réseau est une pratique courante ; un échec de sauvegarde dans ce contexte peut coûter des heures. La 10.0.8 corrige ce point, ce qui en fait la version à privilégier même si l’on n’a pas besoin des autres correctifs.

Pour l’éducation et les laboratoires, la logique s’inverse partiellement. On préfère une version déjà éprouvée par la communauté à une version flambant neuve. La 10.0.6 (29 août 2026) ou la 10.0.7 (7 octobre 2026) offrent un recul que la 10.0.8, sortie fin octobre, n’a pas encore. Et les imports Altium/JLCEDA, encore fragiles (cf. le fil du 1er septembre), sont un motif de prudence pour des environnements pédagogiques où les fichiers viennent de sources hétérogènes.

Les signaux à surveiller avant la prochaine étape de la feuille de route : la fréquence des releases (si elle s’accélère, c’est le signe d’une phase de stabilisation intensive ; si elle ralentit, la branche mûrit), la nature des correctifs critiques (beaucoup de crashs = fragilité persistante), et l’état de la documentation officielle (une doc 10.x sur docs.kicad.org serait un signal fort de maturité).

Ce qui tient, ce qui craque : le regard critique de six mois de terrain

Ce qui tient, d’abord. La série 10.0.x a réellement stabilisé trois zones : les imports (Altium, JLCEDA), la sauvegarde réseau (Samba/SMB), et le rendu sur GPU intégrés. Ce ne sont pas des promesses marketing, ce sont des correctifs documentés. Les jonctions explicites préservées (#25844), l’héritage de champs sur symboles dérivés (#25606), le chargement threaded des bibliothèques base de données (#25307) : autant d’ajustements qui améliorent le quotidien sans faire de bruit.

Ce qui reste fragile, ensuite. Le dialogue de préférences a crashé une fois ; rien ne dit qu’il ne recrashera pas. Les bibliothèques HTTP ont bloqué à la fermeture (#25901) ; la zone reste jeune. L’héritage de champs sur symboles dérivés a été corrigé (#25606), mais c’est un mécanisme complexe, propice aux régressions futures. Et l’import Altium continue de produire des faux drapeaux et des avertissements ERC, comme le montre le fil du 1er septembre 2026.

Ce que la communauté signale encore, c’est moins une liste de bugs qu’un sentiment diffus : l’outil est puissant, mais les aspérités se concentrent aux frontières — imports, réseau, matériel hétérogène. C’est cohérent avec ce que le changelog révèle.

Les angles morts, enfin, et ils sont nombreux. Aucune donnée publique sur la sévérité des bugs. Aucune donnée sur le nombre d’utilisateurs affectés. Aucune donnée sur les délais réels de correction. Le contraste entre la vitalité du dépôt GitLab et la pauvreté du site officiel n’est pas qu’esthétique : il pose la question de la transparence comme enjeu de confiance. Pour un outil devenu standard industriel, l’absence de canal structuré sur la sévérité des bugs est un vrai point faible.

Après la 10.0.8 : ce que la maturité d’une série .x change pour la suite

La 10.0.8 marque un point de bascule. Huit releases en sept mois, c’est le signe d’une phase de stabilisation intensive qui touche à sa fin. Les correctifs critiques de la 10.0.8 sont moins nombreux, ou du moins plus ciblés, que ce qu’on attendrait d’une release de crise. La prochaine étape de la feuille de route se prépare, et les six mois écoulés enseignent trois choses.

Premièrement, le rythme attendu. Une release toutes les trois à quatre semaines est tenable pour une branche stable, à condition que la branche de développement continue d’absorber le gros du travail. Les cherry-picks de la 10.0.8 le confirment : la stable n’est pas un dépotoir, c’est un filtre.

Deuxièmement, la place des imports propriétaires. Altium et JLCEDA sont devenus des axes stratégiques, comme en témoignent les correctifs dédiés (#22908, #25781) et les signalements communautaires. C’est une bonne nouvelle pour la migration, une source de fragilité pour la stabilité.

Troisièmement, le décalage persistant entre la vélocité du code et la mise à jour de la documentation et du site officiel. C’est le point noir de ces six mois. Un projet qui livre huit releases en sept mois mais dont la doc reste figée sur la 5.1 et la 9.0 envoie un signal contradictoire.

Ce qu’un concepteur PCB doit désormais surveiller : les milestones GitLab (pour anticiper les releases), les annonces de release (pour ne pas rater un correctif critique), et l’arrivée éventuelle d’une documentation 10.x sur docs.kicad.org. Ce dernier point serait le vrai marqueur de maturité. Tant qu’il n’arrive pas, la série 10.0.x restera, aux yeux de certains, une belle mécanique de maintenance — mais une mécanique dont on ne voit que les rouages, pas le mode d’emploi.

Sources

• KiCad — site officiel
• Release Notes — KiCad
• Version 10.0.0 Released — KiCad
• Download — KiCad
• KiCad changelog — 10.0.8, 30 octobre 2026 — whatsnew.fyi
• KiCad 10 review: new features, high-speed tuning, variants, and more — Tech Explorations
• KiCad Releases Version 10.0 — PCB Directory
• Altium → KiCad 10 import: "Symbol pin or wire end off connection grid" — forum KiCad, 1er septembre 2026
• Démarrer avec KiCad | 5.1 | Documentation KiCad
• KiCad — Wikipédia

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