Kicad Master · 6 November 2026

KiCad dans le navigateur : la démo WebAssembly qui annonce (peut-être) la prochaine frontière du PCB libre

Fin octobre 2026, Hackaday relayait une expérience de KiCad compilé en WebAssembly et lancé dans un simple onglet. Derrière l’anecdote de salon, une question très concrète se pose pour quiconque conçoit des cartes : le navigateur peut-il devenir autre chose qu’une vitrine — un poste de revue, un outil d’enseignement, voire une alternative à l’installation locale ? Enquête sur ce qu’on sait, ce qu’on ignore, et ce qu’il faut surveiller.

Une démo WASM qui tombe pile au bon moment

Commençons par être honnêtes sur ce que nous avons sous la main. L’expérience relayée par Hackaday fin octobre 2026 — KiCad compilé en WebAssembly, exécuté dans un onglet de navigateur — nous est parvenue sous forme de signal, pas de dossier technique. Nous ne disposons ni du post original complet, ni du nom de l’auteur, ni du commit exact, ni de la chaîne d’outils retenue (Emscripten, WASI, Qt for WebAssembly ?), ni des limites documentées dans les discussions qui ont suivi sur Hacker News, la liste kicad-developers ou GitLab. Il faut le dire d’emblée : sur ce point précis, la matière manque. Un article de fond honnête ne peut pas inventer un commit ni un benchmark.

Ce que l’on peut affirmer, en revanche, c’est le contexte dans lequel cette démo atterrit — et il est éloquent. KiCad est aujourd’hui un projet mature, porté par une communauté solide et financé via The Linux Foundation, avec un rythme de publication soutenu : la version stable 10.0.7 est sortie le 7 octobre 2026, après une 10.0.6 le 29 août 2026 et une série de release candidates en septembre. Le projet a donc une base 10.0.x bien rodée, et c’est dans cet écosystème — pas dans un vide — que s’inscrit l’expérience navigateur.

Pourquoi l’anecdote dépasse-t-elle le gadget ? Parce qu’elle touche à trois promesses que le monde du PCB libre n’a jamais vraiment tenues ensemble : la revue à distance sans friction, l’enseignement sans installation, et l’automatisation de design dans une chaîne CI/CD. Le navigateur est le seul environnement qui coche ces trois cases à la fois. La question centrale de cet article tient donc en une ligne : démo de salon, outil de review, ou véritable alternative à l’installation locale ? Nous allons cartographier le possible, expliquer la technique, pointer les chiffres qui manquent, et dessiner trois scénarios crédibles à 12-24 mois.

Ce qu’un onglet peut vraiment faire : la frontière du possible en 2026

Distinguons soigneusement trois niveaux : ce qui est vérifié (les faits sourcés), ce qui est plausible (ce que la technique autorise), et ce qui relève du fantasme (ce qu’on aimerait croire).

Côté vérifié, il faut être clair : aucune source officielle ne documente une build navigateur de KiCad. kicad.org ne décrit que les modules desktop — éditeur de schéma (eeschema), éditeur de PCB (pcbnew), visionneuse 3D avec raytracer, simulateur SPICE intégré, contrôleur de règles électriques (ERC). La page de téléchargement ne liste que des installeurs natifs Windows, Linux et macOS. Aucune distribution web n’est proposée. Une seule source tierce (factae.eu) évoque un « KiCad disponible dans le navigateur », sans contenu extractible pour recouper.

Côté plausible, en revanche, on peut raisonner sur ce qu’un onglet sait faire en 2026. Les opérations réalistes pour une build WASM de ce type :

• Ouverture de fichiers .kicad_sch et .kicad_pcb en lecture, avec zoom et pan — c’est le socle minimal d’un viewer.
• Inspection de propriétés : cliquer sur un composant, lire sa référence, sa valeur, son empreinte.
• Partage d’un lien vers un schéma — la vraie killer feature pour la revue.
• Review collaborative avec commentaires superposés au dessin.
• Export d’images (captures de schéma, rendus de PCB) et export de BOM en CSV.

La ligne rouge, elle, se situe ailleurs. Le routage interactif lourd (push-and-shove, accord de longueur, tuning de paires différentielles) exige une réactivité à la milliseconde et un moteur de collision sophistiqué : dans un onglet, c’est un pari très risqué. Le DRC complet sur gros designs suppose de traiter des géométries massives en mémoire. L’éditeur d’empreintes, la gestion fine des bibliothèques (des gigaoctets de footprints, comme en témoigne le dépôt KiCad Footprints sur GitLab, tagué 10.0.7-rc1 le 22 septembre 2026) et les plugins natifs Python restent, eux, hors de portée d’un simple portage WASM.

Pourquoi la frontière passe-t-elle là ? Trois raisons techniques simples. D’abord les threads : le routage interactif et le DRC sont massivement parallèles, et le WebAssembly multi-thread exige des en-têtes COOP/COEP contraignants côté serveur. Ensuite l’accès fichiers : un onglet n’a pas de système de fichiers natif, il faut un FS virtuel en mémoire — donc pas de « ouvrir mon dossier de projet » à la légère. Enfin le rendu : KiCad desktop s’appuie sur OpenGL, qu’il faut traduire en WebGL, avec des compromis sur les performances et la fidélité visuelle.

Sous le capot : pourquoi porter KiCad dans un navigateur est un petit exploit

Compilons mentalement. KiCad est une base de code C++ adossée à Qt, développée sur des décennies, avec des millions de lignes. La porter dans un navigateur, ce n’est pas « recompiler avec un flag » — c’est affronter une chaîne d’obstacles en cascade.

La chaîne WebAssembly. Trois grandes voies existent. Emscripten est la plus mûre : elle compile du C/C++ vers WASM et fournit un environnement POSIX émulé, un FS virtuel, et des bindings vers le DOM et WebGL. WASI est plus élégant mais plus jeune, orienté modules serveur, avec un support navigateur encore limité. Qt for WebAssembly est la voie « officielle » pour une application Qt : elle existe, elle fonctionne, mais elle impose ses propres contraintes de taille et de performance. Chacune de ces voies impose des compromis différents, et le choix n’est pas neutre.

Le poids du bundle. Une application Qt compilée en WASM, c’est typiquement un bundle de plusieurs dizaines de mégaoctets — parfois plus. Pour KiCad, avec ses multiples modules, on parle d’un chargement initial qui peut facilement dépasser la minute sur une connexion moyenne, à moins d’un découpage agressif et d’un cache intelligent. C’est le premier tueur d’expérience utilisateur.

Le rendu graphique. KiCad desktop utilise OpenGL pour le dessin de PCB et la 3D. En navigateur, il faut passer par WebGL (ou WebGL2), avec des limitations sur les extensions, la gestion de la mémoire GPU et les performances sur de grands dessins. Le raytracer 3D de KiCad, lui, est un candidat très improbable à un portage navigateur dans l’immédiat.

Le système de fichiers virtuel. Un onglet ne voit pas vos dossiers. Il faut soit charger des fichiers par glisser-déposer, soit passer par l’API File System Access (support inégal selon les navigateurs), soit tout faire transiter par un serveur. Chaque option change le modèle de sécurité et le workflow.

Les threads et la mémoire. WASM multi-thread existe, mais impose des en-têtes de sécurité stricts et une architecture serveur adaptée. La mémoire, elle, est plafonnée par le navigateur (souvent quelques gigaoctets), ce qui limite les gros designs.

La leçon : « ça compile » ne signifie pas « c’est utilisable ». Une démo qui affiche un schéma est un exploit technique ; une démo qui route une carte quatre couches en temps réel est un autre monde. La distance entre les deux est exactement celle qui sépare le gadget de l’outil.

Les chiffres qu’on attend et ceux qu’on n’a pas

Soyons rigoureux. Voici ce que l’on sait, et ce que l’on ignore.

Ce tableau est en soi un signal. Dans un projet mature comme KiCad, une fonctionnalité sérieuse s’accompagne de notes de version, de benchmarks, de discussions sur la liste de développement, de tickets GitLab. L’absence de ces artefacts autour de la démo navigateur suggère fortement qu’on est face à une expérimentation individuelle ou communautaire, pas à un chantier officiel. Ce n’est pas un dénigrement : c’est ainsi que naissent beaucoup d’innovations. Mais cela change la nature du signal.

Le point de comparaison desktop, lui, est solide. KiCad 10.0.x est une base stable, avec des fonctionnalités comme les importateurs, les variantes et le DRC graphique introduites en 10.0 (voir les nouveautés de KiCad 10). L’écosystème est actif : un plugin IA natif comme Konnect, binaire Rust unique exposant 228 outils via MCP pour piloter Claude, a été relayé le 14 octobre 2026 par fellow.news et le 26 octobre 2026 par Adafruit. C’est le niveau de maturité contre lequel la démo navigateur doit être jaugée — et pour l’instant, elle ne joue pas dans la même catégorie.

Revue à distance, éducation, CI/CD de design : les vrais gisements

Là où le navigateur change réellement la donne, ce n’est pas en remplaçant le poste de travail — c’est en débloquant des usages que le desktop rend pénibles.

La revue de schémas entre équipes distantes. Aujourd’hui, revoir un schéma KiCad à distance implique d’envoyer un PDF, de perdre les propriétés, de commenter par mail. Un viewer web avec commentaires superposés change l’expérience : on partage un lien, chacun annote, les modifications sont tracées. C’est le scénario le plus crédible à court terme, et le plus demandé par les équipes distribuées.

L’enseignement. En salle de TP, installer KiCad sur 30 machines est un cauchemar logistique — versions, pilotes, licences, mises à jour. Un onglet qui ouvre un schéma d’exemple, permet de zoomer, d’inspecter, de suivre le professeur, abaisse la barrière à zéro. On n’apprend pas à router dans un onglet, mais on apprend à lire un schéma — et c’est déjà énorme.

Le CI/CD de design. C’est le gisement le plus sous-estimé. Dans une chaîne d’intégration continue, on veut vérifier automatiquement qu’un commit ne casse pas le DRC, que la BOM est cohérente, que les empreintes existent. Un moteur KiCad exécutable en WASM dans un runner, ou dans un onglet headless, ouvre la voie à des rapports de design générés automatiquement. Les exigences techniques sont ici précises : déterminisme (même entrée = même sortie), reproductibilité (version épinglée), sécurité des fichiers (pas d’exfiltration). Un portage WASM bien fait peut cocher ces cases mieux qu’un binaire natif, parce qu’il s’exécute dans un bac à sable.

La vérification de contributions sur un dépôt Git. Un mainteneur qui reçoit une merge request veut voir le diff de schéma sans cloner l’environnement complet. Un lien vers un viewer web qui affiche le schéma avant/après est un gain de temps considérable. C’est exactement le type d’usage où le navigateur n’a pas besoin d’être aussi puissant que le desktop : il a besoin d’être instantané et partageable.

Licence, gouvernance et argent : le nerf de la guerre du « KiCad dans le cloud »

Ici, on quitte la technique pour entrer dans le droit et la politique — et c’est souvent là que les projets meurent ou prospèrent.

La GPL de KiCad. KiCad est distribué sous licence libre (GPL). Un service web qui exécute du code GPL doit respecter les obligations de distribution : si l’on distribue le binaire WASM, il faut fournir le code source correspondant. Pour un service purement interne, la question est plus nuancée ; pour un service public, elle devient centrale. Un fork web commercial devrait donc soit ouvrir son code, soit assumer une architecture qui ne « distribue » pas le binaire — ce qui est juridiquement délicat dans le navigateur, puisque le WASM est téléchargé par le client.

La position de la KiCad Foundation et des mainteneurs. Nos sources ne documentent aucune position officielle sur un portage web. C’est un silence qui en dit long : le projet n’a pas, à notre connaissance, inscrit le navigateur dans sa feuille de route publique. Les mainteneurs sont historiquement prudents sur les promesses de plateforme — et on les comprend, vu l’énergie que consomme le desktop.

Le financement. KiCad est financé via The Linux Foundation (dons, CommunityBridge/LFX). Ce modèle ne prévoit pas nativement le financement d’un service cloud. Un portage web officiel demanderait soit un nouveau financement dédié, soit une intégration dans une plateforme partenaire.

Le risque de forks hors du giron. Si le projet officiel ne bouge pas, des forks web peuvent prospérer. C’est déjà le cas dans l’écosystème : des viewers tiers existent, des plugins IA comme Konnect poussent la logique d’extension. Le risque est celui d’une fragmentation : plusieurs « KiCad web » incompatibles, avec des formats légèrement divergents. À l’inverse, un fork bien fait peut servir de laboratoire et alimenter le projet officiel.

Comparaison avec les plateformes propriétaires. Le paysage concurrentiel est dense : EasyEDA, Altium 365, Flux.ai, CircuitMaker, Wokwi, et des viewers type KiCanvas. Altium Designer, par exemple, coûte entre 3 850 et 5 000 USD par utilisateur et par an, et plus de 175 000 USD sur trois ans pour cinq postes formation incluse — un modèle économique qui justifie pleinement une plateforme cloud intégrée. Face à cela, KiCad reste gratuit et local. Un « KiCad web » officiel changerait la donne : il offrirait la puissance du libre avec la commodité du cloud. Mais il poserait la question du financement d’une infrastructure, ce que le modèle actuel ne couvre pas.

Trois scénarios à 12-24 mois : démo de salon, outil de review, ou vrai concurrent ?

Hiérarchisons les avenirs crédibles.

Scénario 1 — La démo qui reste une démo. La plus probable à court terme. L’expérience WASM reste une prouesse technique relayée par Hackaday, sans suite officielle. Les mainteneurs ne l’intègrent pas, les benchmarks ne sont jamais publiés, l’intérêt retombe. Conditions : pas de financement dédié, pas de demande communautaire forte, complexité technique sous-estimée. Signaux à surveiller : absence de commits sur un dépôt dédié dans les six mois, pas d’annonce à KiCon.

Scénario 2 — L’outil de review/visualisation adopté. Le scénario le plus réaliste à 12-24 mois. Un fork ou un projet communautaire se concentre sur la visualisation et la revue collaborative, sans prétendre au routage. Il s’intègre à des plateformes (GitLab, GitHub, forums) ou à des outils internes d’entreprise. Conditions : bundle maîtrisé, chargement rapide, licence compatible, UX soignée. Signaux : adoption par des équipes, intégrations dans des plateformes, premiers retours d’usage publics.

Scénario 3 — L’alternative sérieuse à l’installation locale. Le plus ambitieux, le moins probable à 24 mois. Il faudrait résoudre le routage interactif, le DRC, les bibliothèques, les plugins — un chantier de plusieurs années. Conditions : financement massif, soutien officiel de la Fondation, rupture technique (peut-être via l’IA pour assister le routage). Signaux : annonce officielle de la KiCad Foundation, benchmarks convaincants, feuille de route publique.

Un quatrième scénario, plus discret, mérite d’être mentionné : l’intégration du navigateur comme couche de collaboration autour du desktop. Le desktop reste le poste de travail, le navigateur devient la couche de partage et de revue. C’est probablement le compromis le plus sage — et celui qui sert le plus d’utilisateurs.

Ce que ça change pour le concepteur PCB, dès maintenant

Que retenir, concrètement, sans attendre ?

Préparez des workflows hybrides. Même sans KiCad web officiel, l’écosystème bouge : plugins IA (Konnect, 228 outils MCP), importateurs (Altium 25.6.2 → KiCad 10.0.6, avec ses avertissements ERC classiques sur les grilles), outils de cotation (AIVON, présenté le 15 septembre 2026), scripts de génération de vias de stitching. Le concepteur de 2026 vit déjà dans un environnement distribué.

Conservez vos garde-fous. Versionnage Git de vos projets, exports réguliers (Gerber, BOM, PDF), sauvegardes hors ligne. Un outil web, quel qu’il soit, ne doit jamais être le seul dépositaire de votre design. La leçon des dernières années est constante : la portabilité des fichiers est votre assurance-vie.

Testez, mais ne pariez pas. Si une démo navigateur apparaît, essayez-la sur un petit projet, mesurez le temps de chargement, vérifiez la fidélité du rendu. Ne migrez pas votre flux de production sur une base non benchmarkée.

Regardez le mouvement plus large. La question du navigateur n’est qu’un aspect d’une transformation plus vaste : IA, cloud, collaboration. KiCad 10.0.x est une base stable, l’écosystème IA est florissant, les plateformes propriétaires poussent leurs offres cloud. Le PCB libre de 2026 n’est plus un monde de fichiers locaux et de forums : c’est un réseau d’outils interconnectés. Le navigateur en est la pièce manquante — et la démo de Hackaday, même imparfaite, nous rappelle qu’elle n’est plus une utopie.

La prochaine frontière du PCB libre ne sera probablement pas un remplacement du desktop. Ce sera une couche de collaboration qui rend KiCad accessible là où il ne l’était pas : dans un onglet, pour une revue, pour un cours, pour un pipeline. Et si cette couche devient officielle, elle changera la donne. D’ici là, surveillez les commits, les annonces de KiCon, et les premiers benchmarks. C’est là que se jouera la vraie histoire.

Sources

• KiCad — Schematic Capture & PCB Design Software
• Download — KiCad
• Release Notes — KiCad
• Downloads | KiCad EDA
• KiCad 10.0 Documentation
• Version 10.0.0 Released | KiCad
• KiCad 10.0.7 Release (7 octobre 2026)
• Windows Downloads — KiCad
• Démarrer avec KiCad | 5.1 | Français
• KiCad 10.0 New Features: Importers, Variants, Graphical DRC
• KiCad — Wikipedia
• Can AI Now Design PCBs That Just Work? — Hackaday (5 septembre 2026)
• PCB design is easier than ever for me, and it’s all thanks to Claude — MSN
• Plugins missing after version update — KiCad Forum
• KiCad Footprints — GitLab (tag 10.0.7-rc1, 22 septembre 2026)
• Konnect — conception de PCB assistée par IA pour KiCad 10 — fellow.news (14 octobre 2026)

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