IA et vibecoding
Pourquoi une porte de fabrication compte plus qu'un concepteur IA
Une porte de fabrication PCB vérifie de façon indépendante l'ERC, le DRC, la parité, la BOM, le stock, les Gerbers, les perçages, le placement et le contrôle de révision avant qu'une carte ne soit commandée.
Publié le Mis à jour le
La vitesse de génération n’a aucune importance si la frontière de libération est faible
Un concepteur IA peut créer un schéma ou un layout rapidement. Un ingénieur compétent peut aussi faire un changement rapide sous délai serré. Les deux peuvent produire une carte d’apparence finie alors que la BOM pointe vers le mauvais boîtier, que le PCB est obsolète par rapport au schéma, ou que l’archive de fabrication contient le fichier de perçage d’hier.
Une porte de fabrication se situe entre le travail de design modifiable et une commande irréversible. Elle n’accepte une version que lorsque des contrôles indépendants et des relecteurs nommés satisfont les critères de libération. Peu importe que la source ait été dessinée à la main, générée depuis du code, routée par un optimiseur, ou modifiée par un agent.
Cela rend la porte plus durable que n’importe quel concepteur particulier. Les outils changent ; l’exigence de données de fabrication traçables et cohérentes en interne demeure.
Définissez précisément l’entrée et la sortie
L’entrée de la porte est un candidat de design versionné :
- exigences et exceptions approuvées ;
- schéma KiCad exact, PCB, projet, règles et bibliothèques ;
- MPN exact et données d’alternatives approuvées ;
- versions des outils et des dépendances ;
- entrées mécaniques et profil de capacité de fabrication visé.
La sortie est un unique paquet de livraison immuable :
- fichiers Gerber et de perçage ;
- BOM et données pick-and-place ;
- plans de fabrication et d’assemblage ;
- fichiers STEP, IPC-2581, de test et de programmation en option ;
- rapports ERC/DRC et autres contrôles ;
- révision source, hashes, approbations et notes de version.
La signification de la libération pour la fabrication désigne précisément cette transition contrôlée. Copier des fichiers dans un dossier nommé final-final n’est pas un processus de libération.
Couche 1 : complétude et identité de la source
Avant d’exécuter les contrôles électriques, échouez sur une identité manquante :
- des symboles montés sans fabricant ou sans MPN complet ;
- des empreintes sans mapping de boîtier révisé ;
- des variables de texte non résolues ou des bibliothèques de projet manquantes ;
- une version d’outil inconnue ou des changements générés non committés ;
- un statut DNP différent entre le schéma, la BOM et les données de placement ;
- des exigences ou des profils de règles non liés à une révision.
Pour les bibliothèques générées, exigez un contrat de broches fondé sur un document primaire. L’ERC ne peut pas détecter un symbole et une empreinte dont le mapping est cohérent entre eux mais tout aussi erroné, comme expliqué dans pourquoi les LLM inventent des numéros de broches.
Couche 2 : contrôles déterministes de KiCad
Exécutez les contrôles dans un répertoire de build propre et faites échouer la commande sur les violations. Un squelette shell pour KiCad 9 :
#!/usr/bin/env bash
set -euo pipefail
SCH="hardware/controller.kicad_sch"
PCB="hardware/controller.kicad_pcb"
OUT="build/release"
rm -rf "$OUT"
mkdir -p "$OUT/checks" "$OUT/gerbers" "$OUT/drill" "$OUT/assembly"
kicad-cli sch erc \
--severity-error --severity-warning \
--exit-code-violations \
-o "$OUT/checks/erc.rpt" \
"$SCH"
kicad-cli pcb drc \
--schematic-parity \
--severity-error --severity-warning \
--exit-code-violations \
-o "$OUT/checks/drc.rpt" \
"$PCB"
--exit-code-violations fait renvoyer à KiCad un statut non nul quand des violations sont signalées. --schematic-parity vérifie que le PCB correspond au schéma. C’est le cœur de l’automatisation headless de KiCad, mais ce n’est pas toute la porte.
Ne rendez pas la CI verte en supprimant globalement les avertissements. Chaque exclusion a besoin d’une raison technique, d’un responsable, d’un emplacement source et d’une revue. Préférez corriger la configuration des règles ou le design.
Couche 3 : cohérence de l’approvisionnement et de l’assemblage
Exportez la BOM depuis le schéma vérifié, pas depuis une copie maintenue manuellement :
kicad-cli sch export bom \
--fields 'Reference,Value,Footprint,Manufacturer,MPN,${QUANTITY},${DNP}' \
--labels 'Refs,Value,Footprint,Manufacturer,MPN,Qty,DNP' \
--group-by 'Value,Footprint,Manufacturer,MPN' \
--exclude-dnp \
-o "$OUT/assembly/bom.csv" \
"$SCH"
kicad-cli pcb export pos \
--format csv --units mm --side both --exclude-dnp \
-o "$OUT/assembly/positions.csv" \
"$PCB"
Ajoutez des scripts qui comparent les ensembles de références montées, rejettent les positions dupliquées, exigent des MPN exacts, valident les empreintes autorisées, et vérifient le stock/cycle de vie en direct pour les pièces critiques. Confirmez que l’entrée de catalogue choisie par l’assembleur correspond au même MPN et au même boîtier physique. Une paire BOM/CPL syntaxiquement valide peut malgré tout spécifier le mauvais composant.
Couche 4 : régénérez les données de fabrication depuis zéro
Ne promouvez jamais des fichiers laissés par une exécution précédente. Tracez dans le répertoire de livraison vide :
kicad-cli pcb export gerbers \
--layers F.Cu,B.Cu,F.Mask,B.Mask,F.Silkscreen,B.Silkscreen,Edge.Cuts \
-o "$OUT/gerbers/" \
"$PCB"
kicad-cli pcb export drill \
--format excellon --excellon-units mm \
--generate-map --map-format pdf \
-o "$OUT/drill/" \
"$PCB"
test -s "$OUT/assembly/bom.csv"
test -s "$OUT/assembly/positions.csv"
Paramétrez la liste des couches pour le stack-up réel ; une carte à quatre couches a besoin de ses fichiers de cuivre interne. Vérifiez les noms de fichiers de couche et de perçage attendus, un contour de carte unique, du cuivre non vide, et des origines cohérentes. Appliquez les limites spécifiques à l’atelier dans la checklist DFM PCB.
Générez des hashes une fois que chaque artefact est définitif :
find "$OUT" -type f ! -name SHA256SUMS -print \
| LC_ALL=C sort \
| while IFS= read -r file; do shasum -a 256 "$file"; done \
> "$OUT/SHA256SUMS"
Le commit source et le fichier de checksums permettent au service achats de prouver quels octets ont été approuvés et téléversés.
Couche 5 : revue visuelle et technique humaine
L’automatisation ne peut pas trancher toutes les questions physiques. Exigez une validation nominative pour :
- l’alimentation du schéma, le reset/boot, la protection et les circuits critiques ;
- les mappings exacts de broches symbole vers empreinte ;
- le découplage, les boucles de courant, les chemins de retour, la géométrie RF/haute vitesse, et le design thermique ;
- l’orientation des connecteurs, la clearance du boîtier, l’accès de test, et les repères de polarité ;
- la superposition Gerber/perçage et le contour de carte ;
- l’aperçu d’assemblage, les rotations, le miroir de la face inférieure, et la population DNP ;
- les options de devis de fabrication par rapport au stack-up et à la finition visés.
Le relecteur doit inspecter les sorties générées, pas seulement le canevas KiCad. Le moteur de rendu du fabricant est une autre vue indépendante et doit correspondre à la revue Gerber locale.
Pour la production ou les prototypes coûteux, séparez l’approbation du design du passage de la commande. Le service achats ne devrait téléverser qu’une archive dont le checksum correspond à l’enregistrement de libération signé. Cette petite frontière à deux personnes empêche qu’un export brouillon d’un ingénieur ou une modification côté portail ne contourne la porte.
Une porte vérifie la qualité de la livraison, pas le fonctionnement du produit
Une porte propre prouve que les règles codées ont été satisfaites et que les artefacts livrés sont cohérents. Elle ne prouve pas que le circuit répond à ses exigences, survit aux pannes, passe la CEM, ou fonctionne sur toute la plage de température. La mise en route physique et la vérification restent une partie du plan produit.
Cette frontière est aussi l’endroit où un pipeline comme MakeIRL peut être utile : la valeur ne réside pas seulement dans la génération d’une carte, mais dans le fait de rendre incontournables des contrôles fondés sur des preuves avant la fabrication. Tout outil devrait être jugé sur les artefacts et les contrôles qu’il expose.
La porte compte plus qu’un concepteur IA parce qu’elle contient les erreurs de n’importe quel concepteur. Elle transforme la vitesse en itération sûre : générez librement, échouez visiblement, approuvez délibérément, et ne commandez qu’une seule livraison traçable.