Electrosens R&D
Electrosens Kicad Master · 12 October 2026

KiCad 10 face aux outils IA-first : le match de l’écosystème PCB en 2026

Depuis mars 2026, KiCad 10 tient ses promesses de maturité : 7 609 commits, des bibliothèques refondues, une 3D passée au STEP-only. En face, une génération d’outils « IA-first » promet de court-circuiter le travail de conception. Faut-il choisir un camp, ou apprendre à composer ? Comparatif argumenté sur cinq axes, avec verdict par profil.


Deux façons de dessiner une carte en 2026 : le choc des cultures

Il y a un an, la question ne se posait pas vraiment. Aujourd’hui, elle structure les conversations dans les équipes hardware. D’un côté, KiCad 10.0.0, sorti en mars 2026, avec une annonce officielle sur kicad.org qui détaille une refonte des bibliothèques, des ajustements d’interface et des outils de conception PCB. De l’autre, une vague d’outils qui se présentent comme « AI-native » : Flux, Celus, Quilter, JITX, PCBGPT, et une constellation de copilotes et de générateurs. Leur promesse tient en une phrase : décrire ce qu’on veut, laisser la machine proposer un schéma, un placement, un routage.

Le calendrier donne la mesure du basculement. Autodesk a annoncé l’arrêt d’EAGLE dès 2023, et l’arrêt des ventes comme du support est intervenu le 7 juin 2026. Altium Designer, lui, reste solidement ancré sur son marché professionnel, avec un abonnement annuel par utilisateur situé entre 3 850 et 5 000 USD en 2026 — nous y reviendrons, car ce chiffre pèse lourd dans le match. Entre ces deux pôles historiques, une troisième voie s’est installée : l’IA appliquée à la conception, portée par des startups et par des plugins greffés sur les outils existants.

La vraie question n’est donc pas « KiCad ou l’IA ? ». Elle est : que gagne-t-on réellement avec un workflow IA-first, que perd-on en contrôle, traçabilité et reproductibilité, et où KiCad 10 reste-t-il imbattable ? Pour y répondre, nous allons dérouler cinq axes concrets — génération de schéma, placement/routage assistés, bibliothèques et plugins, collaboration/versioning, coût total et verrouillage — en les confrontant à trois cas d’usage : le proto rapide, la carte pro multi-contraintes, et le projet maintenu sur plusieurs années.


KiCad 10 : la maturité tranquille d’un écosystème qui ne promet rien mais tient tout

Commençons par ce que contient réellement KiCad 10, car le discours ambiant a tendance à réduire l’open source à « gratuit, donc limité ». L’annonce de mars 2026 raconte une autre histoire. La version a été construite avec 7 609 commits uniques modifiant le code et les traductions, en augmentation par rapport à la version 9. Ce n’est pas un chiffre marketing : c’est le signe d’un projet qui avance par accumulation, sans rupture.

Chiffres réels disponibles dans les sources (KiCad 10)Commits uniques (KiCad7609valeurNouveaux symboles952valeurNouveaux footprints1216valeurNouveaux modèles 3D386valeurFootprints générés par78valeur

La refonte la plus visible concerne les bibliothèques. KiCad 10 ajoute 952 nouveaux symboles, 1 216 nouveaux footprints et 386 nouveaux modèles 3D. Surtout, plus de 78 % des footprints de la bibliothèque sont désormais générés à partir de données plutôt que dessinés manuellement. C’est un changement de nature : un footprint généré est reproductible, versionnable, et corrigeable par script. Le passage aux seuls fichiers STEP pour les modèles 3D — l’abandon des autres formats — réduit la taille d’installation et améliore la précision géométrique. Pour l’inspection mécanique et le rendu, le visualiseur 3D avec raytracer intégré reste l’un des points forts de la suite.

Côté outils, KiCad 10 conserve ce qui a fait sa réputation : éditeur de schémas hiérarchique capable de tenir des conceptions à plusieurs centaines de feuilles, simulateur SPICE intégré, vérificateur de règles électriques (ERC), routeur interactif, et un éditeur PCB avec des outils de visualisation et de sélection améliorés. La documentation officielle existe en français, avec des versions référencées 5.1 et 9.0 — et l’écosystème suit : la version 10.0.6 est sortie le 29 août 2026, la 10.0.7 en est à sa deuxième release candidate au 3 octobre 2026.

Ce que cette maturité implique concrètement pour la traçabilité est décisif. Les fichiers KiCad sont du texte : netlists, PCB, bibliothèques. Un projet KiCad se diffe, se merge, se revoit comme du code. Sur un projet maintenu sur plusieurs années, c’est la différence entre un historique exploitable et une boîte noire. Et le financement ? KiCad est soutenu via The Linux Foundation (CommunityBridge), une organisation 501(c)(6) à but non lucratif basée aux États-Unis, qui collecte des dons. Pas d’actionnaire à satisfaire, pas de pivot stratégique à craindre.


L’IA-first PCB : comment ça marche vraiment (et ce que ça ne fait pas encore)

Il faut se méfier des deux excès symétriques : croire que l’IA va remplacer le concepteur, ou la balayer d’un revers de main. Regardons sous le capot. Une analyse publiée le 31 juillet 2026 sur protoflow.ai recense trois méthodes réelles pour ajouter de l’IA à un workflow KiCad : les plugins in-editor, les outils « generate-then-export » qui produisent un schéma puis l’exportent, et la génération de composants assistée. C’est un cadre utile, parce qu’il distingue ce qui vit dans l’outil de ce qui vit à côté.

Techniquement, les briques sont connues. Les modèles de langage servent à transformer une description textuelle en netlist ou en ébauche de schéma. L’apprentissage par renforcement (RL) est mobilisé pour le placement et le routage : on définit une fonction de coût (longueur de pistes, nombre de vias, intégrité du signal) et l’agent explore l’espace de conception. Les solveurs de contraintes, eux, vérifient et optimisent le respect des règles. Un exemple concret et documenté : 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 — présenté par DevTrends le 7 septembre 2026. Autre illustration : PCB Auto Router, outil de routage automatique accéléré sur GPU, qui supporte l’import KiCad et JLC EDA, avec routage de paires différentielles et de segments à longueur égalisée.

Ce que ces outils automatisent vraiment : l’exploration d’espace de conception (générer dix variantes de placement plutôt qu’une), la génération de variantes (décliner une topologie), et l’assistance au placement. Ce qu’ils ne font pas encore bien : le contrôle fin, les contraintes complexes imbriquées (mécanique + CEM + thermique + haute fréquence simultanément), la reproductibilité stricte, et — point sensible — l’ouverture. La plupart sont des services propriétaires, avec des formats fermés et des limitations d’export. Le gain de vitesse annoncé par les plateformes AI-native se compte en ordres de grandeur sur certaines tâches de layout, mais ce chiffre mérite d’être lu avec prudence : il porte sur des cas d’usage précis, pas sur un projet industriel complet.


Génération de schéma : le LLM qui pond des netlists contre l’éditeur hiérarchique qui tient des centaines de feuilles

C’est l’axe où le contraste est le plus net. D’un côté, un outil IA-first prend une spécification en langage naturel — « un régulateur buck 12 V vers 3,3 V, 3 A, avec protection en entrée » — et propose une netlist, parfois un schéma. Pour un prototypage rapide, l’effet est spectaculaire : on passe de plusieurs heures à quelques minutes pour une topologie standard. Pour générer des variantes et comparer des approches, c’est un vrai levier d’exploration.

Source : en.wikipedia.org

Mais il faut regarder ce qui se passe ensuite. Une netlist générée doit être vérifiée. Qui garantit que le découpage est correct, que les condensateurs de découplage sont au bon endroit, que les tolérances tiennent ? Le concepteur, avec ses outils. Et c’est précisément là que KiCad 10 reprend la main : ERC intégré, simulation SPICE dans le même environnement, bibliothèque officielle de référence. Sur une carte pro multi-contraintes, la chaîne « génération IA → vérification humaine → itération » finit souvent par ressembler à un workflow classique, avec une étape de plus.

Critère Outils IA-first (génération) KiCad 10 (éditeur hiérarchique)
Point de départ Description textuelle Saisie manuelle / import
Vitesse sur topologie standard Très rapide Modérée
Conceptions multi-feuilles (centaines) Non démontré Oui, supporté
ERC / vérification Externe ou absente Intégré
Simulation SPICE Rarement intégrée Intégrée
Reproductibilité de la génération Faible (modèle non déterministe) Totale (fichiers texte)
Cas d’usage idéal Proto rapide, exploration Carte pro, projet long

Le verdict sur cet axe est nuancé : pour un proto rapide ou une exploration de topologies, la génération IA fait gagner un temps réel. Pour une carte pro multi-contraintes ou un schéma qui devra être maintenu, relu et audité, l’éditeur hiérarchique de KiCad 10 reste la référence — non par conservatisme, mais parce que la vérification et la traçabilité y sont natives.


Placement et routage assistés : le RL qui propose contre le push-and-shove qui obéit

Passons au cœur du métier : le layout. Ici, la promesse IA est la plus forte, et la prudence la plus nécessaire. Les outils à base de RL proposent des placements optimisés selon une fonction de coût, et des routages complets. Le discours commercial parle d’un layout « 10x plus rapide » sur les plateformes AI-native. C’est crédible sur certaines tâches — un placement initial, une exploration de topologies de routage — mais cela ne dit rien de la qualité électrique finale, ni du temps de reprise humaine.

En face, KiCad 10 propose une boîte à outils manuelle mature : routeur interactif, modes Walk Around et Shove (push-and-shove), routage différentiel, tuning de longueur. Un guide publié le 13 août 2026 sur rottenwifi.com détaille d’ailleurs un workflow d’autoroutage KiCad complet : configurer les règles, placer les composants, utiliser Walk Around et Shove, intégrer Freerouting, puis valider chaque carte avec DRC et contrôles de fabrication. Ce dernier point est capital. L’autoroutage existe dans l’écosystème KiCad — Freerouting en est l’exemple le plus connu — mais il vient avec ses propres pièges : un rapport de régression publié le 28 août 2026 sur GitHub signale que Freerouting 2.3.0 produit des routes que son propre scoring identifie comme portant des violations de clearance, là où la version 2.2.4 routait proprement. Autrement dit : l’automatisation sans validation est un piège.

Là où l’IA excelle : l’exploration (proposer dix placements), l’optimisation multi-objectifs (minimiser longueur et vias simultanément), et le défrichage d’une carte inconnue. Là où le contrôle manuel reste indispensable : les contraintes mécaniques (connecteurs, hauteurs, zones interdites), la CEM, et la haute fréquence, où chaque stub, chaque retour de masse, chaque impédance compte. Sur ces terrains, un routeur qui « propose » ne remplace pas un concepteur qui « décide ». Et sur un projet long, la reproductibilité du routage — pouvoir expliquer pourquoi une piste passe là — reste non négociable.


Bibliothèques et plugins : l’écosystème ouvert contre le jardin clos

C’est peut-être l’axe le plus sous-estimé, et celui où l’écart se creuse le plus vite. KiCad 10 s’appuie sur une bibliothèque officielle massive — des milliers de symboles, footprints et modèles 3D, avec les ajouts chiffrés de la version 10 — et sur une gestion de bibliothèques personnalisées qui a été refondue. Le format est ouvert, documenté, scriptable : c’est ce qui permet à 78 % des footprints d’être générés à partir de données. À côté, un écosystème de plugins réputé pour son ouverture, alimenté par des initiatives comme la liste awesome-kicad sur GitHub, et par des intégrations tierces (DIGIKEY, SnapEDA) qui poussent des composants directement dans l’outil.

Source : fr.wikipedia.org

Les outils IA-first, eux, intègrent souvent des bibliothèques propriétaires. Ce n’est pas un défaut en soi : un catalogue curé peut être plus fiable qu’une bibliothèque ouverte où tout le monde peut contribuer. Mais cela crée une dépendance. Si le fournisseur disparaît, si les conditions changent, si l’export se limite à un format propriétaire, que reste-t-il ? Sur un projet maintenu plusieurs années, la question n’est pas théorique. La pérennité des données est un critère de conception, au même titre que le choix d’un microcontrôleur.

Un exemple concret de la vitalité de l’écosystème ouvert : un tutoriel publié le 11 août 2026 sur saludpcb.com montre comment un plugin KiCad génère et remplit automatiquement une grille de vias de stitching pour les plans de masse — une tâche fastidieuse, résolue par script. Ce type d’outil n’existe que parce que le format est ouvert et l’API accessible. La documentation de l’API pcbnew pour l’intégration continue a d’ailleurs été publiée en juillet 2026. C’est l’illustration exacte de ce que permet un écosystème ouvert : des solutions pointues, écrites par la communauté, pour des problèmes que les éditeurs n’ont jamais jugé prioritaires.


Collaboration et versioning : le Git des cartes contre le cloud propriétaire

Sur cet axe, la comparaison est presque binaire. KiCad 10 produit des fichiers texte. Netlists, PCB, bibliothèques : tout se prête naturellement à Git. On peut différencier une révision, revoir une modification en pull request, revenir en arrière, comparer deux branches d’une même carte. Des guides existent — Anchorpoint propose par exemple un guide Git pour KiCad — et la pratique se répand dans les équipes qui traitent le hardware comme du logiciel.

Les outils IA-first proposent souvent l’inverse : une plateforme cloud collaborative, avec édition en temps réel, commentaires intégrés, gestion des accès. Les avantages sont réels : pour une équipe distribuée, le temps réel et les commentaires contextuels réduisent les frictions. Mais les risques le sont tout autant. Où sont les données ? Qui peut les exporter ? Que se passe-t-il si l’abonnement s’arrête ? Sur un projet soumis à conformité et audit — defense, médical, industriel —, la question de la localisation et de la traçabilité des données n’est pas un détail. Un historique Git local, signé, versionné, est un artefact d’audit. Un historique dans le cloud d’un tiers l’est beaucoup moins.

Pour une équipe distribuée qui travaille sur des cartes non sensibles, le cloud propriétaire peut être un gain net. Pour un projet maintenu sur plusieurs années, avec des exigences de conformité, le versioning par fichiers texte reste la voie sûre. Et rien n’empêche d’ajouter une couche de collaboration par-dessus Git — revues, CI, génération automatique de Gerbers — sans céder le contrôle des données.


Coût total et verrouillage : gratuit ne veut pas dire sans coût, payant ne veut pas dire sans liberté

Attaquons le chiffre qui fâche. KiCad 10 est gratuit et open source, financé par des dons via The Linux Foundation. Mais « gratuit » ne signifie pas « sans coût » : il faut compter la formation, l’infrastructure, la maintenance, et le temps d’adaptation. À l’inverse, les outils propriétaires affichent des prix qui donnent le vertige. Altium Designer, référence du marché pro, coûte entre 3 850 et 5 000 USD par utilisateur et par an en 2026, avec une formation facturée entre 1 000 et 2 000 € par personne. Sur trois ans, pour cinq postes avec formation, la facture dépasse 175 000 USD. Et Altium ne tourne que sous Windows — un détail qui pèse dans un parc hétérogène.

Scénario KiCad 10 Outils IA-first / propriétaires
Proto rapide (1 personne, 1 carte) Coût licence : 0 € ; coût réel : temps d’apprentissage Abonnement mensuel par siège (variable selon l’éditeur)
Carte pro multi-contraintes (équipe de 5) Licences : 0 € ; formation et intégration à budgéter Altium : > 175 000 USD sur 3 ans (5 postes, formation incluse)
Projet au long cours (5+ ans) Coût stable, pas de renouvellement imposé Risque de hausse tarifaire, de changement de modèle, voire d’arrêt (cf. EAGLE, ventes arrêtées le 7 juin 2026)

Le verrouillage est l’autre face de la pièce. Formats propriétaires, export limité, dépendance à un fournisseur : l’histoire récente donne des exemples. Autodesk EAGLE a annoncé son arrêt en 2023, et l’arrêt des ventes comme du support est intervenu le 7 juin 2026. Des concepteurs se sont retrouvés à devoir migrer des projets entiers. Un rapport de forum publié le 1er septembre 2026 illustre d’ailleurs la friction d’une telle migration : importer un projet Altium 25.6.2 vers KiCad 10.0.6 a généré des avertissements ERC « Symbol pin or wire end off connection grid » sur presque chaque broche et chaque fil. La migration est possible — mais elle a un coût, et elle rappelle qu’un format fermé n’est jamais vraiment à vous.


Verdict nuancé et scénarios hybrides : KiCad + plugins IA, la voie pragmatique

Alors, qui gagne ? Personne, et c’est une bonne nouvelle. Le match n’oppose pas un gagnant à un perdant, mais deux philosophies à des besoins différents.

KiCad 10 reste imbattable là où le contrôle, la traçabilité, la reproductibilité et le coût à long terme priment : cartes professionnelles multi-contraintes, projets maintenus sur plusieurs années, environnements soumis à audit, équipes qui veulent garder la main sur leurs données et leur outillage. Sa gratuité n’est pas un argument de façade : c’est ce qui permet d’investir le budget ailleurs — formation, infrastructure, plugins sur mesure. Et son écosystème ouvert transforme chaque besoin pointu en opportunité de script.

Les outils IA-first sont pertinents là où la vitesse d’exploration compte plus que la maîtrise fine : prototypage rapide, génération de variantes, équipes sans expertise PCB approfondie qui ont besoin d’un point de départ crédible. Leur faiblesse — le contrôle, la reproductibilité, le verrouillage — devient acceptable quand l’enjeu est d’itérer vite sur des concepts, pas de produire un artefact industriel.

La voie qui tient déjà la route en 2026 est hybride, et elle est plus mature qu’on ne le croit. L’analyse de protoflow.ai du 31 juillet 2026 le montre : on peut greffer de l’IA sur KiCad de trois façons — plugins in-editor (comme Konnect, qui connecte Claude via MCP), outils generate-then-export (on génère un schéma ailleurs, on l’importe dans KiCad pour vérification et poursuite), et génération de composants assistée. Le socle reste KiCad 10 : c’est lui qui porte l’ERC, la simulation, le versioning Git, la bibliothèque de référence. L’IA vient en amont (exploration, génération) et en périphérie (vérification, automatisation de tâches répétitives comme le stitching de vias). Le concepteur garde la décision ; la machine accélère l’exploration.

Reste une question de fond, qui dépasse le match. Si l’IA génère les schémas et propose les routages, que reste-t-il au concepteur ? Probablement l’essentiel : savoir quoi demander, pourquoi une contrainte prime sur une autre, et comment vérifier qu’une proposition tient. La formation devra évoluer — moins de saisie, plus d’architecture, de contraintes et de validation. Les défis à venir sont connus : normalisation des formats d’échange, interopérabilité entre outils IA et suites classiques, et questions éthiques sur des modèles entraînés sur des designs dont la provenance est parfois floue. Sur ce terrain, l’écosystème ouvert a un avantage structurel : il rend les règles du jeu visibles. C’est peut-être, en 2026, son meilleur argument.


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.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *