Kicad Master · 15 October 2026

Documentation KiCad 2026 : le manuel officiel est-il devenu le maillon faible de l’écosystème ?

KiCad 10.0.7 approche, KiCad 10.0.6 est sorti le 29 août 2026, et un quatrième KiCon se prépare à Shenzhen. Le logiciel, lui, n’a jamais été aussi rapide. Mais pendant que le code accélère, les guides « Démarrer avec KiCad » en ligne affichent toujours les branches 5.1 et 9.0. Alors, la doc est-elle devenue le vrai facteur limitant d’un écosystème pourtant en pleine explosion ?

Le paradoxe de la doc KiCad : un logiciel qui accélère, un manuel qui patine

Il y a quelque chose d’étrange à observer l’écosystème KiCad en cette fin 2026. D’un côté, une cadence de sortie qui force le respect : la branche 10.0.x s’enchaîne à un rythme soutenu — 10.0.6 publiée le 29 août 2026, sa première release candidate le 18 août, et déjà deux release candidates pour 10.0.7 les 27 septembre et 3 octobre 2026. Le projet organise même sa quatrième conférence asiatique annuelle, KiCon Asia, à Shenzhen du 5 au 7 novembre 2026. De l’autre côté, un détail qui saute aux yeux de quiconque cherche de l’aide : la documentation officielle en ligne, celle que l’on atteint via docs.kicad.org, propose toujours un guide « Démarrer avec KiCad » structuré autour des branches 5.1 et 9.0.

Autrement dit : un utilisateur qui installe KiCad 10.0.6 aujourd’hui — sur Windows, Linux ou un Mac Apple Silicon — se retrouve face à un manuel d’introduction dont la dernière itération « moderne » date d’une branche majeure antérieure. Ce n’est pas anecdotique. C’est le symptôme d’un décalage structurel entre la vitesse d’un projet de logiciel libre mature et la vitesse d’une chaîne éditoriale qui, elle, n’a jamais vraiment changé de logiciel.

La question mérite d’être posée frontalement : dans un écosystème où le code, les plugins, l’IA embarquée et les importateurs progressent vite, la documentation est-elle devenue le maillon faible ? Ce dossier tente d’y répondre sans caricature. Il retrace l’histoire éditoriale de la doc officielle, décortique sa chaîne de production, mesure l’écart avec le logiciel, compare les ressources disponibles, explore les sujets avancés mal couverts, décrit comment les concepteurs comblent réellement les trous sur le terrain, et esquisse les pistes pour recoller au peloton.

De la 5.1 à la 9.0 : petite histoire d’une doc qui n’a jamais vraiment changé de logiciel

Pour comprendre l’état actuel, il faut regarder ce que la documentation officielle expose publiquement. Deux URL suffisent à raconter l’histoire : docs.kicad.org/5.1/fr/getting_started_in_kicad et docs.kicad.org/9.0/fr/getting_started_in_kicad. Entre les deux, une branche majeure d’écart dans le numéro, mais une continuité frappante dans la structure : le même guide d’introduction, la même logique de « Getting Started », la même organisation en chapitres qui accompagne l’utilisateur du schéma au routage puis à la fabrication.

Cette stabilité a un mérite : elle offre un point d’entrée cohérent, rassurant, qui ne dépaysera pas celui qui revient après deux ans d’absence. Mais elle trahit aussi une réalité moins flatteuse : la documentation officielle n’a pas connu de refonte éditoriale profonde à la mesure des bouleversements fonctionnels des dernières années. Le projet a bien migré ses outils — la documentation KiCad est aujourd’hui produite en AsciiDoc, compilée via une chaîne de type Sphinx, hébergée sur l’infrastructure GitLab du projet, et traduite via Weblate — mais cette modernisation de l’outillage n’a pas été accompagnée d’une réécriture de fond des contenus. On a changé la plomberie, pas la maison.

Le résultat est un paradoxe classique des projets open source arrivés à maturité : la documentation est techniquement « ouverte » — n’importe qui peut proposer une correction — mais elle reste éditorialement conservatrice, organisée autour de guides hérités qui n’ont pas été repensés pour les usages de 2026. Les nouvelles fonctionnalités s’accumulent dans les release notes et les annonces de version, mais peinent à se frayer un chemin dans le corps du manuel. La doc suit le logiciel avec un train de retard, et ce retard, cumulé branche après branche, finit par devenir un fossé.

Ce que cela dit de la priorité donnée à la documentation est limpide : dans l’arbitrage permanent entre « écrire du code » et « écrire de la doc », le code gagne presque toujours. C’est compréhensible — un bug bloquant la fabrication d’une carte est plus urgent qu’un paragraphe manquant — mais c’est aussi ce qui produit, à terme, un écosystème où le logiciel est excellent et l’apprentissage laborieux.

Qui écrit la doc KiCad en 2026 ? Dans les coulisses de la chaîne de production

La chaîne de production documentaire de KiCad repose sur un modèle hybride, typique des grands projets libres. Trois populations contribuent : une petite équipe de coordination documentaire, les développeurs eux-mêmes (qui documentent souvent leurs propres fonctionnalités, parfois à contrecœur), et une communauté de bénévoles qui corrigent, traduisent et complètent au fil de l’eau. Les outils sont ceux du développement logiciel moderne : AsciiDoc pour le format source, une compilation Sphinx, un hébergement GitLab avec revue par merge request, et Weblate pour la traduction collaborative.

Ce dispositif a un avantage considérable : il abaisse la barrière à la contribution. Proposer une correction de doc, c’est ouvrir une merge request, exactement comme pour du code. Mais il a aussi une limite structurelle : la cadence. Les releases logicielles de KiCad s’enchaînent à un rythme soutenu — entre une version stable majeure et ses correctifs, il peut s’écouler quelques semaines à peine, comme le montre la séquence 10.0.6 (29 août 2026) puis 10.0.7 RC1 (27 septembre) et RC2 (3 octobre). La documentation, elle, ne peut pas suivre ce rythme. Une release candidate logicielles se teste en quelques jours ; une mise à jour de manuel se rédige, se relit, se traduit, se valide — en semaines, voire en mois.

S’ajoute la question du versionnage des pages en ligne. KiCad publie sa documentation par branche (/5.1/, /9.0/, etc.), ce qui est une bonne pratique : chaque version du logiciel garde sa doc de référence. Mais cette architecture a un effet pervers : elle fige les contenus. Une page rédigée pour la 9.0 ne sera pas automatiquement rafraîchie pour la 10.0 ; il faut une action éditoriale délibérée pour la porter d’une branche à l’autre. Et comme les ressources humaines sont limitées, certaines pages restent « collées » à leur branche d’origine, donnant cette impression déroutante d’un manuel qui parle d’un logiciel qui n’existe plus tout à fait.

La tension est donc double : tension de cadence (le logiciel va plus vite que la doc) et tension de versionnage (le découpage par branche protège la cohérence mais ralentit la propagation des mises à jour). Ni l’une ni l’autre n’est un défaut de conception ; ce sont les conséquences inévitables d’un modèle ouvert où la documentation est un bien commun entretenu par des contributeurs dont ce n’est presque jamais le métier principal.

L’écart en chiffres : pages, couverture, délais, traductions

Mesurer précisément l’écart entre logiciel et documentation est difficile, faute de données publiques consolidées sur le nombre de pages du manuel par version ou sur le délai moyen de mise à jour des guides. Mais quelques observations suffisent à objectiver le phénomène.

D’abord, la couverture fonctionnelle. Les nouvelles fonctionnalités de KiCad 10 — comme les labels de puissance locaux, dont l’usage fait l’objet de questions sur le forum officiel dès le 3 août 2026 — apparaissent dans les release notes et les annonces, mais leur documentation d’usage détaillée arrive souvent plus tard, ou de façon parcellaire. Un utilisateur qui découvre une fonctionnalité dans les notes de version doit fréquemment compléter par lui-même, en fouillant le forum ou en testant à l’aveugle.

Ensuite, la fraîcheur des traductions. Le recours à Weblate permet une traduction communautaire dans de nombreuses langues, mais la fraîcheur est très inégale selon les langues. Les versions françaises, allemandes ou espagnoles sont généralement bien suivies ; d’autres langues accusent un retard plus marqué. Le fait que des sites tiers proposent des téléchargements « en russe » de KiCad 10.0.6 — comme le montre une page du 9 septembre 2026 — illustre d’ailleurs une demande de localisation que la doc officielle ne satisfait pas toujours au même rythme.

Enfin, le délai de mise à jour. Entre la sortie d’une version et l’actualisation complète des guides correspondants, l’écart se compte en semaines, parfois en mois pour les chapitres avancés. Ce n’est pas propre à KiCad — c’est le lot de la plupart des projets libres — mais c’est d’autant plus visible que le logiciel, lui, sort vite.

La promesse « open source = docs ouvertes » se vérifie donc sur l’ouverture : n’importe qui peut contribuer. Elle se vérifie moins sur la fraîcheur et la complétude, qui restent tributaires du volontariat.

Doc officielle, wiki, docs intégrées, tutoriels tiers : le match des ressources

Si l’on compare les ressources disponibles pour un concepteur PCB en 2026, le constat est nuancé — et plutôt encourageant, à condition d’accepter de sortir de la doc officielle.

La documentation officielle reste la référence pour les fondamentaux : créer un schéma, router une carte simple, générer des fichiers Gerber, comprendre l’organisation du projet. Elle est fiable, versionnée, et traduite. C’est le socle incontournable.

L’aide intégrée à l’application — aide contextuelle, infobulles, messages d’erreur — est souvent sous-estimée. Elle a un avantage décisif : elle est toujours alignée sur la version installée. Quand la doc en ligne parle encore de la 9.0, l’aide intégrée de votre KiCad 10.0.6, elle, ne ment pas. C’est le premier réflexe à cultiver.

Le wiki communautaire et les forums — forum.kicad.info, Discord, Stack Exchange — constituent la vraie documentation vivante de KiCad. C’est là que se règlent les cas concrets : un import Altium 25.6.2 vers KiCad 10.0.6 qui génère des avertissements ERC « Symbol pin or wire end off connection grid » sur presque chaque broche, un problème de lenteur extrême du déplacement de pistes dans l’éditeur PCB en 10.0.4/10.0.5, ou l’usage des nouveaux labels de puissance locaux. Ces fils de discussion, datés de septembre et août 2026, sont souvent plus utiles que n’importe quelle page de manuel.

Les tutoriels tiers — OurPCB avec son « KiCad Tutorial – 9 Steps to Learn Quickly », Hackaday, DigiKey, les chaînes YouTube — excellent dans l’approche par tâche. Ils montrent un workflow complet, du concept à la fabrication, avec les pièges réels. Leur faiblesse : ils vieillissent vite et ne sont pas versionnés. Un tutoriel de 2023 sur KiCad 7 peut induire en erreur sur KiCad 10.

Enfin, la documentation des outils commerciaux — Altium, Cadence, Siemens EDA — est plus fraîche et plus complète, mais elle a un coût. Altium Designer se facture entre 3 850 et 5 000 USD par utilisateur et par an, avec une formation à 1 000–2 000 EUR par personne, et un coût total sur trois ans pour cinq postes dépassant 175 000 USD. À ce prix, la doc fait partie du contrat. KiCad, gratuit, n’a pas cette ressource — et c’est précisément là que se joue la comparaison.

Ce que la doc ne dit pas : empilage, DRC graphique, variantes, IPC-2581, flex-rigid

C’est sur les sujets avancés que l’écart devient le plus criant. Là où la doc officielle brille sur les bases, elle devient silencieuse ou elliptique dès qu’on entre dans le territoire du professionnel exigeant.

L’empilage (stackup) : la définition précise des couches, des épaisseurs, des matériaux et des impédances contrôlées est un sujet critique pour toute carte haute fréquence ou à contraintes d’impédance. La doc officielle en donne les bases, mais l’optimisation fine — choix de diélectrique, gestion des plans de masse, calcul d’impédance — se trouve ailleurs : blogs spécialisés, notes d’application de fabricants, forums.

Le DRC graphique et les contraintes avancées : la vérification des règles de conception est bien documentée dans son principe, mais la mise en place de contraintes complexes, de règles conditionnelles, de classes de nets, reste largement à la charge de l’utilisateur. Les tutoriels tiers, comme celui de rottenwifi.com du 13 août 2026 sur l’autoroutage KiCad 10, comblent partiellement ce vide.

Les variantes de carte : gérer plusieurs versions d’une même carte (peuplements différents, options) est un besoin industriel courant. La couverture officielle est mince, et l’on se tourne vers les forums.

L’IPC-2581 : ce format d’échange de données de fabrication, alternative ouverte aux Gerber, est un sujet de niche. La doc officielle l’aborde peu ; les concepteurs qui l’utilisent s’appuient sur des ressources externes.

Le flex-rigid : concevoir des cartes souples ou rigides-flexibles implique des règles mécaniques et de routage spécifiques. C’est un domaine où la documentation KiCad est quasi muette, et où l’expertise se transmet par la pratique, les fabricants et les communautés spécialisées.

Les risques concrets sont réels : une erreur d’empilage mal comprise peut conduire à une carte non conforme en impédance ; une contrainte DRC mal configurée peut laisser passer un défaut qui ne sera détecté qu’en fabrication ; une méconnaissance de l’IPC-2581 peut compliquer l’échange avec un fabricant. Le coût de ces lacunes documentaires se paie en prototypages ratés, en délais et en argent.

Sur le terrain : comment un concepteur PCB comble les trous en 2026

Prenons le parcours d’un concepteur type. Pour les tâches de base — dessiner un schéma, placer des composants, router une carte simple, exporter des Gerber — la doc officielle suffit. C’est même l’un de ses points forts : le « Getting Started » reste un excellent point d’entrée, et l’aide intégrée répond aux questions immédiates.

Mais dès qu’on attaque des tâches avancées, le réflexe change. Pour l’empilage, on consulte les notes d’application des fabricants de PCB. Pour les contraintes fines, on fouille les forums. Pour l’autoroutage, on suit des tutoriels récents — et l’on découvre que l’intégration de Freerouting dans KiCad 10 est devenue un sujet à part entière, avec ses propres pièges : une régression signalée le 28 août 2026 montre que Freerouting 2.3.0 produit des routages que son propre scoring signale comme porteurs de violations de clearance, là où la version 2.2.4 routait proprement. Ce genre d’information ne se trouve pas dans la doc officielle ; elle vit dans les issues GitHub et les discussions communautaires.

Les habitudes à mettre en place sont donc claires. Toujours vérifier la version de la doc que l’on consulte : une page /9.0/ ne décrit pas forcément KiCad 10. Privilégier l’aide intégrée pour les questions de version. Croiser les sources : doc officielle pour les bases, forums pour les cas précis, tutoriels récents pour les workflows. Dater ses sources : un tutoriel de 2023 est suspect pour KiCad 10. Et contribuer en retour : quand on résout un problème mal documenté, ouvrir une merge request sur GitLab est le meilleur moyen d’améliorer la doc pour les suivants.

Un exemple parlant : la migration depuis Altium. Un fil du 1er septembre 2026 montre un utilisateur important un projet Altium 25.6.2 vers KiCad 10.0.6 et rencontrant l’avertissement ERC « Symbol pin or wire end off connection grid » sur presque chaque broche. La doc officielle ne traite pas ce cas précis ; c’est la communauté qui apporte la solution. Pour un professionnel qui migre, cette dépendance aux forums est à la fois une bouée et un risque : la qualité de la réponse dépend de la bonne volonté d’un bénévole.

Docs-as-code, contribution communautaire, IA : les pistes pour recoller au peloton

Les pistes d’amélioration existent, et certaines sont déjà en partie empruntées. La démarche docs-as-code est en place — AsciiDoc, GitLab, merge requests — et c’est une base saine. Ce qui manque, c’est le carburant humain : plus de contributeurs, plus de relecteurs, plus de traducteurs. Le projet pourrait intensifier ses appels à contribution, notamment lors des KiCon — le KiCon Asia 2026 à Shenzhen, du 5 au 7 novembre, est une occasion idéale.

L’automatisation est une autre piste. Détecter automatiquement les fonctionnalités nouvelles dans les release notes et créer des tickets de documentation correspondants permettrait de ne rien laisser passer. Un tel système, couplé à un tableau de bord de couverture, rendrait l’écart visible et donc traitable.

L’IA génératrice de tutoriels est la piste la plus discutée en 2026. L’écosystème KiCad s’y engouffre : un plugin natif en Rust, Konnect, permet depuis le 7 septembre 2026 de connecter Claude à KiCad 10 via MCP pour assister la conception et le routage. Une analyse de protoflow.ai du 31 juillet 2026 recense trois méthodes réelles pour ajouter de l’IA à un workflow KiCad : les plugins in-editor, les outils « generate-then-export », et la génération de composants. L’IA peut aider à produire de la documentation, à répondre aux questions des utilisateurs, à générer des exemples. Mais elle ne remplace pas la validation humaine : une doc générée sans relecture peut propager des erreurs à grande échelle.

La comparaison avec les outils commerciaux est instructive. Altium, Cadence ou Siemens EDA investissent massivement dans leur documentation et leur formation — formation facturée 1 000 à 2 000 EUR par personne chez Altium. KiCad ne peut pas aligner ces moyens, mais il peut jouer une autre carte : la réactivité communautaire et l’ouverture. La vraie question est de savoir si cela suffit. Face à un Altium à 3 850–5 000 USD par utilisateur et par an, KiCad reste imbattable sur le prix ; mais si l’adoption bute sur une documentation insuffisante, l’économie réalisée se paie en temps d’apprentissage.

Conclusion : la doc, prochain grand chantier de KiCad ?

La documentation KiCad 2026 n’est pas un désastre. C’est une documentation solide sur les fondamentaux, ouverte à la contribution, traduite dans de nombreuses langues, et adossée à une communauté d’une réactivité remarquable. Mais c’est une documentation qui n’a pas suivi le rythme du logiciel. Entre les guides hérités des branches 5.1 et 9.0 toujours en ligne, les sujets avancés mal couverts et la dépendance accrue aux ressources tierces, l’écart s’est installé.

La bonne nouvelle, c’est que ce chantier est identifiable, et donc traitable. Le projet a les outils — AsciiDoc, GitLab, Weblate — et la communauté. Ce qui manque, c’est une priorisation explicite de la documentation dans la feuille de route, des appels à contribution structurés, et peut-être une automatisation qui rende l’écart visible.

La maturité d’un logiciel open source se mesure aussi à la qualité de sa documentation. KiCad a prouvé qu’il pouvait rivaliser avec les outils commerciaux sur les fonctionnalités ; il lui reste à prouver qu’il peut rivaliser sur l’accompagnement. C’est le prochain grand chantier — et, à en croire la vitalité de son écosystème, il a toutes les cartes en main pour le mener à bien.

Sources

• KiCad – Schematic Capture & PCB Design Software
• KiCad Version 10.0.6 Release (kicad.org, 29 août 2026)
• KiCad Version 10.0.7 Release Candidate 1 Available (kicad.org, 27 septembre 2026)
• KiCad Version 10.0.7 Release Candidate 2 Available (kicad.org, 3 octobre 2026)
• KiCad Conference Asia 2026 Announcement (kicad.org, 16 septembre 2026)
• Démarrer avec KiCad | 5.1 | Français | Documentation | KiCad
• Démarrer avec KiCad | 9.0 | Français | Documentation | KiCad
• KiCad — Wikipédia
• KiCad — Wikipedia (EN)
• Downloads | KiCad EDA
• Altium → KiCad 10 import: "Symbol pin or wire end off connection grid" (forum.kicad.info, 1er septembre 2026)
• KiCad 10.0.4 / 10.0.5 – extremely slow track movement in PCB Editor (forum.kicad.info, 12 août 2026)
• Local power labels – how? (forum.kicad.info, 3 août 2026)
• KiCad Autorouting Made Easy: Walk Around, Shove, and Freerouting (rottenwifi.com, 13 août 2026)
• KiCad AI in 2026: Copilots, Plugins, and Generators That Actually Work (protoflow.ai, 31 juillet 2026)
• Как подключить Claude к KiCad 10 (DevTrends, 7 septembre 2026)
• OurPCB Published the ‘KiCad Tutorial-9 Steps to Learn Quickly’
• Importing EAGLE Projects Into KiCad 7, And How To Fix Them (Hackaday, 1er juillet 2023)
• KiCad vs Altium in 2026: Where the Free Tool Actually Competes (protoflow.ai, 9 août 2026)
• The 2026 PCB Design Software List: KiCad, Altium, and EasyEDA Compared (electricalflux.com, 9 septembre 2026)

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