Le schéma affichait zéro erreur ERC. La BOM était entièrement recoupée avec les fiches techniques. Chaque classe de net était définie, chaque contrainte d’impédance contrôlée documentée dans un log de décision propre. Et quand je me suis assis pour le lire vraiment, je n’ai pas pu.
Les caps de découplage étaient dispersées sur la feuille, placées là où l’outil les avait posées. Les étiquettes hiérarchiques se chevauchaient. Une résistance de pull-up était correctement dimensionnée selon toutes les règles que l’ERC connaissait, mais câblée dans une topologie qui aurait maintenu le bus au niveau bas au démarrage. Le design était formellement valide. Il était aussi totalement illisible.
Ce n’est pas une critique des outils IA en conception hardware. C’est la description d’un écart précis, celui que toutes les équipes utilisant des workflows PCB assistés par IA vont rencontrer si elles ne l’ont pas déjà fait.
Ce que l’IA fait bien au schéma
Les outils sont vraiment utiles. Un LLM bien sollicité peut recouper une valeur nominale de composant avec une fiche technique en quelques secondes. Les frameworks de vérification multi-agents vérifient la connectivité des nets, signalent le découplage manquant sur un rail d’alimentation, auditent les BOM pour des incohérences d’empreinte, et calculent les marges de dérating par rapport aux tables IPC. Ces tâches consommaient autrefois des heures de temps d’ingénieur senior. Les outils les font plus vite, et pour les vérifications basées sur des règles, ils les font de façon fiable.
Les outils ERC ont toujours géré la vérification formelle de connectivité. Ce que la génération actuelle ajoute, c’est le raisonnement multi-documents : « ce net se connecte à une broche nominale à 3,3 V, le composant en amont est sur un rail 5 V, et la fiche technique spécifie une tolérance maximale de surtension de 0,3 V. » Ce type de raisonnement croisé entre plusieurs sources est nouveau, et vraiment utile.
Le paradoxe de Moravec au schéma
En 1988, Hans Moravec a observé quelque chose qui semblait paradoxal : ce que les humains trouvent sans effort, les compétences sensorimotrices, le raisonnement spatial, la perception de bon sens, représentait les problèmes les plus difficiles pour l’IA. Ce que les humains trouvent difficile, la logique formelle, l’application de règles, le calcul, était relativement abordable pour les ordinateurs. Les problèmes faciles étaient difficiles ; les problèmes difficiles étaient faciles.
La conception hardware a sa propre version. La vérification formelle de connectivité : abordable pour l’IA. La reconnaissance de patterns construite sur des années de pannes sur banc : pas encore.
Quand je lis un schéma, je remarque des choses que je ne peux pas toujours articuler immédiatement. Un cap de découplage techniquement présent mais placé trois niveaux hiérarchiques loin de la broche qu’il est censé servir. Une topologie de pull-down qui paraît symétrique sur papier mais que j’ai vu se comporter bizarrement aux températures extrêmes. Une valeur de condensateur de charge pour cristal qui est dans les spécifications mais que j’ai vu défaillir dans des environnements humides. Aucune de ces choses n’est une violation ERC. Elles apparaissent au bring-up, sur le terrain, ou lors d’un audit réglementaire.
Le workflow IA confirme que le net est connecté. Il ne détecte pas que la connexion est correcte mais que le contexte est faux.
Le risque d’ingénierie
Je retrouve les mêmes modes de défaillance dans les schémas générés par IA. Un condensateur fonctionnel résiduel d’un état de design antérieur, toujours dans la netlist, ne servant plus la broche pour laquelle il avait été ajouté, mais ajoutant de la charge et du bruit. Une résistance de pull-up avec la valeur correcte pour une tension d’alimentation, dans un design qui a depuis été révisé vers une alimentation différente, où aucune règle ne signale l’incohérence parce que les deux valeurs sont valides isolément. Une stratégie de découplage qui couvre les rails déclarés mais manque un rail secondaire ajouté tard dans le processus de conception.
Aucun de ces cas n’est une hallucination au sens LLM. Les composants sont réels, les valeurs sont plausibles, l’ERC est propre. Le problème, c’est que le design n’a pas été lu par quelqu’un qui porte un modèle mental de l’ensemble.
Un ingénieur senior qui lit un schéma pour la première fois va détecter ces problèmes en quelques minutes, non pas parce qu’il applique des règles, mais parce que quelque chose cloche. Le cap de découplage est loin de la broche. La topologie est inhabituelle. La valeur est dans la plage mais suspecte par rapport au reste du circuit. De la reconnaissance de patterns. Et la génération actuelle d’outils IA ne l’a pas.
Le risque réglementaire pour les projets critiques
Pour les équipes travaillant sous FDA classe II, MDR CE IIa, IEC 60601 ou ISO 13485, il y a une deuxième dimension à cet écart. Le dossier d’historique de conception doit répondre à une question qui revient dans chaque audit : ce design a-t-il été révisé par un ingénieur qualifié ?
Un schéma généré par IA qui n’a jamais été lu par un humain laisse cette question ouverte. Non pas parce qu’il est faux d’utiliser des outils IA, mais parce que la révision au dossier doit être une vraie révision. Si le schéma ne peut pas être lu par un humain, la révision ne peut pas avoir lieu. Et si elle n’a pas lieu avant la phase clinique, le coût de remédiation est bien plus élevé qu’une révision humaine pendant la conception ne l’aurait été.
J’ai vu ça se jouer dans des remédiations tardives. Les dossiers formels sont complets. Le rapport ERC est joint. L’audit demande pourquoi la signature de révision d’un ingénieur qualifié n’est pas au dossier. À ce stade, les options sont coûteuses.
Le workflow qui ferme l’écart
L’IA pour la couche formelle, un senior pour la couche humaine, un junior sous supervision pour le travail entre les deux. C’est le modèle qui fonctionne.
Concrètement : laisse les outils faire tourner l’ERC, vérifier les fiches techniques, auditer la BOM, recouper les classes de nets. Ensuite, fais lire le schéma par un ingénieur senior, non pas pour réexécuter les règles, mais pour détecter ce que les règles ne peuvent pas détecter. Pour le travail d’itération entre les vérifications formelles, un junior sous supervision structurée garde le temps du senior focalisé sur ce que seul un senior peut faire.
En pratique, beaucoup d’équipes utilisant des workflows assistés par IA n’ont pas d’ingénieur hardware senior à temps plein. Elles ont les outils, les outils produisent une sortie formelle propre, et le bring-up est le premier moment où quelqu’un avec une vraie reconnaissance de patterns regarde le design. C’est tard.
L’écart de Moravec ne disparaîtra pas cette année. Les outils vont finir par le combler. Les équipes qui construisent des workflows en supposant qu’il est déjà comblé vont le payer en pannes de bring-up et en cycles de remédiation. Les équipes qui le comblent elles-mêmes, avec un passage humain au bon moment dans le processus, obtiennent la vitesse de l’IA et la discipline de l’ingénierie senior.