Qu'est-ce que le vibecoding hardware, et peut-il vraiment fonctionner en sécurité ?

Le vibecoding hardware est une interface, pas une méthode d’ingénierie

En logiciel, « vibe coding » signifie généralement décrire un résultat en langage naturel, laisser un agent générer ou modifier du code, et piloter en testant le résultat. Appliqué au hardware, l’agent peut sélectionner des composants, écrire une description de circuit, modifier un schéma, placer ou router un PCB, exécuter des outils EDA, et préparer des fichiers de fabrication.

Cette interface est utile. Elle permet à un créateur d’exprimer son intention sans maîtriser chaque geste de KiCad ou chaque format de fichier. Elle ne supprime pas les contraintes électriques, thermiques, mécaniques, d’approvisionnement ou de fabrication qui font fonctionner une carte.

Le hardware a aussi une boucle de retour plus dure qu’une page web. La compilation prend des secondes ; la fabrication et la livraison d’un PCB prennent des jours, et une broche erronée peut détruire un composant. La version sûre du vibecoding ressemble donc moins à « prompt, commande, espoir » et plus à :

describe → formalize → generate → inspect → check → manufacture → test

L’agent peut accélérer chaque transition. Il ne doit être la seule source de vérité à aucune étape irréversible.

Ce qu’il peut bien faire

L’approche fonctionne le mieux quand le design est assemblé à partir de blocs connus, bien documentés, et que les critères d’acceptation sont explicites. Exemples :

• des cartes porteuses pour des modules radio pré-certifiés ;
• des breakouts de capteurs et de connecteurs ;
• des cartes microcontrôleur basse vitesse basées sur un circuit de référence éprouvé ;
• des cartes LED, boutons, Qwiic/I2C, ou de distribution d’alimentation simple ;
• des variantes d’un design déjà revu avec des connecteurs ou options de population modifiés ;
• la génération de BOM, de fichiers de règles, de scripts de livraison et de plans de test.

Un agent est particulièrement utile pour le travail répétitif : créer des champs de composants cohérents, vérifier que chaque broche d’alimentation de circuit intégré a un découplage, générer une première netlist, ou invoquer les contrôles KiCad. Le guide ultérieur sur le vibecoding d’une carte ESP32 montre le type de design de module borné qui peut en bénéficier.

Ce même flux de travail est un mauvais endroit pour apprendre par l’échec quand la carte gère le secteur électrique, des batteries à haute énergie, des fonctions de sécurité, un usage médical, un mouvement dangereux, une conversion de forte puissance, ou un design RF dont la conformité compte. L’IA peut assister des ingénieurs qualifiés dans ces cas, mais la commodité du langage naturel n’apporte pas la compétence de domaine ni les preuves de certification manquantes.

Transformez le prompt en un contrat d’exigences

« Fais une carte de capteur environnemental » laisse presque toutes les décisions importantes non spécifiées. Une entrée utile nomme les interfaces, les limites, la mécanique et les tests d’acceptation :

function: "USB-powered temperature and humidity logger"
input_power:
  connector: "USB-C receptacle, 5 V sink only"
  max_current_mA: 300
logic:
  module: "ESP32-C3 module with onboard antenna"
interfaces:
  - "I2C sensor at 3.3 V"
  - "UART test pads"
mechanical:
  outline_mm: [45, 30]
  mounting_holes: "4 x M2.5, grounded: no"
manufacturing:
  layers: 2
  assembly_side: "top only"
  fab_rules: "named vendor standard capability profile"
acceptance:
  - "ERC and DRC have zero unwaived errors or warnings"
  - "USB input current stays below 300 mA"
  - "sensor reads within its stated tolerance at room reference"

Le contrat expose les questions avant que le cuivre n’existe. L’USB doit-il transmettre des données, ou seulement alimenter ? Quelle variante exacte de module ? Où l’antenne peut-elle déborder ou exiger un keepout ? Les trous de fixation sont-ils isolés électriquement ? Un bon agent doit renvoyer les décisions non résolues plutôt que de les inventer.

Le pipeline complet du langage naturel vers la carte traite ce contrat structuré comme le début du design, pas comme une documentation rédigée après coup.

Fondez chaque sélection de composant sur des preuves primaires

Pour chaque composant non trivial, conservez la référence fabricant exacte, la révision de la fiche technique du fabricant, le plan de boîtier, le mapping de broches et les notes d’application pertinentes. Les résultats de recherche et les résumés de distributeurs sont des aides à la découverte. Ce ne sont pas des preuves pour une affectation de broches.

Cela compte parce que les modèles de langage peuvent produire un tableau de broches fluide et plausible qui appartient en réalité à un autre boîtier ou à un dispositif apparenté. Le mécanisme de l’échec et les contre-mesures sont couverts dans pourquoi les LLM inventent des numéros de broches. Une règle qui mérite d’être appliquée est simple : aucun symbole ou empreinte généré n’est approuvé tant qu’une personne ou un processus déterministe n’a pas recoupé chaque pad avec la documentation de boîtier primaire.

Demandez à l’agent de citer les numéros de page et de citer le champ concerné, mais vérifiez vous-même la citation. Les modèles peuvent mal lire un tableau, confondre les vues de dessus et de dessous, ou citer une page réelle qui ne soutient pas l’affirmation.

Rendez la sortie EDA inspectable et modifiable

Un agent hardware utile produit des artefacts de projet normaux : schémas et cartes KiCad, source de circuit code-native, une BOM avec des MPN exacts, des contraintes lisibles, et un journal de livraison. Une image rendue ne suffit pas. Une sortie uniquement en Gerber, impossible à retracer jusqu’à un schéma, ne suffit pas non plus.

Passez en revue les mêmes éléments que vous réviseriez sur une carte créée manuellement :

• le mapping de broches symbole vers empreinte ;
• les limites et le séquencement de l’arbre d’alimentation ;
• les valeurs de découplage et leur placement physique ;
• l’orientation des connecteurs et la clearance mécanique ;
• les boucles de courant, les chemins de retour, l’impédance et les nets sensibles ;
• les chemins thermiques, les pads exposés et la surface de cuivre ;
• la correspondance entre stock, cycle de vie et boîtier d’assemblage.

Si l’outil ne peut pas expliquer pourquoi un net existe ou quelle source soutient un choix de composant, le temps gagné à la génération se déplace vers l’audit.

Placez des contrôles déterministes entre l’agent et la fabrication

Exécutez KiCad indépendamment de l’agent qui a créé le design :

kicad-cli sch erc \
  --severity-error --severity-warning \
  --exit-code-violations \
  -o build/erc.rpt board.kicad_sch

kicad-cli pcb drc \
  --schematic-parity \
  --severity-error --severity-warning \
  --exit-code-violations \
  -o build/drc.rpt board.kicad_pcb

Ces contrôles détectent les violations de règles et la dérive schéma/PCB. Ils ne peuvent pas prouver que le symbole source correspond à la fiche technique ou que le circuit répond à ses exigences, donc ajoutez une réconciliation BOM/CPL, une revue des documents source, une inspection des Gerbers, et une checklist de livraison signée. Ce processus en couches est la porte de fabrication.

Est-ce que ça peut vraiment fonctionner ?

Oui, pour des designs bornés où l’entrée est spécifique, les composants sont fondés sur des documents primaires, les sorties restent modifiables, et un relecteur compétent assume la libération. Cela peut raccourcir le chemin de l’intention à un premier prototype et rendre la création hardware accessible à des personnes qui pensent plus naturellement en code ou en prose.

Cela ne peut pas rendre l’ambiguïté sûre. Le créateur a toujours besoin d’une mise en route à courant limité, de vérifications de rail avant de monter des composants coûteux, de tests de firmware, de mesures thermiques, et d’un plan pour la révision deux. Le vibecoding hardware est le plus crédible quand le « vibe » s’arrête à l’interface des exigences et que le reste du pipeline est de l’ingénierie explicite.