[APPLICATION CELUS] L’intelligence artificielle n’aura pas mis longtemps à s’inviter dans la conception électronique (CAO). Les ingénieurs peuvent désormais l’interroger directement pour rechercher des informations dans une documentation technique, comparer des composants, ou même générer certains éléments d’une conception. Mais répondre à une question technique est une chose. Prendre véritablement part à un processus d’ingénierie en est une autre, en particulier dans le domaine des systèmes embarqués.
Auteur : Tobias 
Pohl
CEO et cofondateur
CELUS
Une réponse simplement plausible de l’IA ne suffit pas dans le domaine de la CAO qui doit répondre à des exigences précises et composer avec de nombreuses contraintes et interdépendances.
Les choix effectués au niveau de l’architecture ont en effet des conséquences directes sur la sélection des composants, les interfaces, l’alimentation, les coûts et, en définitive, sur la faisabilité même du système.
La prochaine étape de l’IA appliquée à la conception électronique ne consiste donc plus seulement à générer des réponses mais à évoluer vers une ingénierie agentique.
Autrement dit, vers des systèmes d’IA capables de comprendre un objectif, d’établir un plan d’action, d’en exécuter les différentes étapes, puis d’en vérifier le résultat au regard des exigences initiales.
Les limites d’une IA fonctionnant en "one shot"
Une grande partie des usages actuels de l’IA générative repose sur un schéma relativement simple : l’ingénieur formule une requête et le modèle lui fournit une réponse.
Cette approche est parfaitement adaptée à certaines tâches ponctuelles. Mais un projet de conception électronique se déroule rarement de manière aussi linéaire. Prenons les premières étapes du développement d’un système embarqué.
L’ingénieur sait peut-être déjà que celui-ci devra assurer des fonctions de traitement et de détection, disposer d’une connectivité sans fil et fonctionner à partir d’une source d’alimentation donnée.
Pour autant, tout n’est pas nécessairement arrêté. Les besoins en puissance de calcul peuvent encore évoluer. Le choix d’une interface de communication peut dépendre d’un composant qui reste lui-même à sélectionner. Et des critères de coût, de disponibilité ou de pérennité peuvent finalement conduire à écarter un composant pourtant parfaitement adapté sur le plan technique.
Une conception se construit donc par étapes, au fil de choix qui évoluent et s’influencent mutuellement. Dès lors, la modification d’une seule exigence peut remettre en question plusieurs décisions déjà prises. Une IA qui se serait contentée de générer une architecture à partir de la demande initiale doit alors déterminer comment réagir.
Faut-il adapter la solution existante ? Repartir sur une nouvelle architecture ? Ou commencer par identifier les hypothèses de départ que ce changement vient remettre en cause ?
C’est précisément là que l’approche agentique se distingue d’un assistant IA classique. Au lieu de chercher immédiatement à fournir une solution, le système commence par faire le point : quelles sont les informations dont il dispose ? Sur quelles hypothèses repose-t-il ? Quelles données lui manquent encore ?
Il peut ensuite établir les différentes étapes nécessaires pour parvenir à une solution. Et si une exigence change en cours de route, il peut reprendre ce raisonnement à l’endroit où le changement intervient, au lieu de considérer la nouvelle information comme une requête isolée.
Planifier d’abord, exécuter ensuite
La nuance peut sembler minime. En ingénierie, elle change pourtant considérablement la manière dont l’IA peut être utilisée. Avant de passer à l’action, un agent peut décomposer un objectif en plusieurs étapes et déterminer les informations et les moyens nécessaires pour chacune d’elles.
Des agents spécialisés, ou différentes fonctions d’un même système, peuvent ensuite prendre en charge chacune de ces tâches. Pour concevoir une architecture matérielle embarquée, par exemple, une première étape peut consister à analyser les exigences fonctionnelles, une deuxième à identifier les solutions techniques envisageables et une troisième à vérifier que les différents blocs retenus peuvent effectivement fonctionner ensemble.
Surtout, ce processus doit rester transparent pour l’ingénieur. Il ne s’agit pas de créer une boîte noire autonome à laquelle on fournirait la description d’un produit pour récupérer, à l’autre bout, une conception prête à l’emploi et réputée incontestable. Les choix techniques impliquent des compromis qui ne peuvent pas tous être délégués.
L’expérience du concepteur, la stratégie d’approvisionnement de l’entreprise, les impératifs de certification ou encore certains critères absents du cahier des charges peuvent justifier de privilégier une architecture plutôt qu’une autre.
L’IA agentique a donc davantage vocation à jouer le rôle de copilote que de pilote automatique. Elle peut se charger d’une partie des recherches et des tâches répétitives, proposer une démarche et en expliquer les différentes étapes. L’ingénieur garde ainsi la main et décide si la voie proposée est la bonne.
Du langage aux données d’ingénierie
La conception électronique présente une autre particularité par rapport aux applications plus générales de l’IA générative : une connaissance technique ne sert réellement que si elle peut être traduite en décisions et en actions concrètes.
Un ingénieur peut consulter la fiche technique d’un composant et un modèle d’IA peut lui aussi en analyser le contenu.
Mais conclure que deux composants semblent convenir ne signifie pas pour autant qu’ils pourront fonctionner ensemble. Il faut encore vérifier la compatibilité de leurs interfaces électriques et déterminer les circuits nécessaires à leur interconnexion.
Pour cela, l’IA doit pouvoir s’appuyer sur des données d’ingénierie structurées. Chez Celus, par exemple, les fonctions électroniques sont représentées par des blocs lisibles par la machine, baptisés CUBO.
Ceux-ci associent les circuits aux informations concernant leurs interfaces, leurs contraintes et les règles de conception qui leur sont applicables. L’objectif va donc bien au-delà de la constitution d’une nouvelle bibliothèque de composants. Il s’agit de traduire l’intention du concepteur et les relations techniques entre les différents éléments sous une forme exploitable par la machine.
Une fois ces informations structurées, le logiciel n’est plus limité à leur recherche ou à leur synthèse : il peut les utiliser pour agir sur la conception.
AInsi, a partir d’une exigence fonctionnelle, un agent IA peut ainsi construire progressivement une architecture électronique, sélectionner les blocs appropriés et déterminer comment les associer. Cette architecture peut ensuite servir de point de départ à la réalisation du schéma électronique, puis du circuit imprimé.
La vérification, une étape indispensable
Un résultat peut sembler parfaitement cohérent sans pour autant respecter toutes les exigences fixées au départ. Ce risque augmente à mesure que le raisonnement se complexifie et que les différentes décisions s’enchaînent.
Dans un processus d’ingénierie, la vérification ne peut donc pas être une simple étape facultative. Un workflow agentique peut prévoir une phase spécifiquement consacrée à ce contrôle. Le résultat obtenu est alors comparé aux exigences initiales : l’architecture remplit-elle toutes les fonctions demandées ? Les différentes contraintes ont-elles bien été respectées ? Une hypothèse retenue au début du processus est-elle devenue incompatible avec un choix effectué par la suite ?
Lorsqu’un problème est détecté, le système peut reprendre la tâche concernée ou demander l’intervention de l’ingénieur, plutôt que de poursuivre sur la base d’une décision devenue incorrecte.
Cette capacité de vérification devient d’autant plus essentielle que l’IA ne se contente plus de conseiller l’ingénieur mais commence à intervenir directement dans la conception.
En revanche, ce n’est pas parce qu’une IA présente une réponse de manière convaincante que cette réponse est techniquement juste. La confiance doit venir des données d’ingénierie qui permettent de confronter le résultat aux exigences du projet.
Garder l’ingénieur aux commandes
A mesure que l’IA gagne en autonomie, une question se pose naturellement : quelle part de contrôle l’ingénieur doit-il lui céder ? Dans l’idéal, très peu. L’automatisation n’est pas nouvelle dans la conception électronique.
Depuis des décennies, les outils successifs prennent en charge des tâches que les ingénieurs effectuaient auparavant manuellement. L’IA agentique prolonge cette évolution, mais elle ne change pas un principe essentiel : automatiser le travail ne signifie pas déléguer la responsabilité.
C’est toujours à l’ingénieur de déterminer ce qui doit être conçu, d’arbitrer entre différentes architectures et de valider les décisions importantes. L’agent peut explorer plusieurs pistes, exécuter certaines étapes et contrôler son propre travail.
Mais lorsqu’un choix engage véritablement la conception, il doit pouvoir s’arrêter et laisser la décision à l’ingénieur. Cette manière de travailler permet aussi d’explorer plus facilement plusieurs solutions.
Aujourd’hui, étudier une architecture alternative peut nécessiter des heures, voire des jours de recherche sur les composants et obliger à reprendre une partie de la conception. Dans ces conditions, le nombre de pistes étudiées reste nécessairement limité.
En automatisant une grande partie de ce travail préparatoire, l’ingénieur peut comparer davantage d’architectures en amont du projet, lorsqu’il est encore relativement simple de revenir sur certains choix.
Et c’est peut-être là que se trouve l’un des principaux bénéfices de l’IA agentique : non pas simplement réaliser plus vite la même conception, mais permettre aux ingénieurs d’explorer davantage de solutions avant de s’engager dans une direction.
Une architecture pensée pour les agents comme pour les ingénieurs Pour passer de l’assistant IA à un véritable agent d’ingénierie, il ne suffira pas de greffer des modèles de langage toujours plus performants aux outils de conception existants. Un agent doit disposer de données structurées sur lesquelles s’appuyer, savoir précisément quelles tâches il peut exécuter et être capable de contrôler ses propres résultats.
Il faut également définir clairement les limites de son intervention et les étapes auxquelles une validation humaine est nécessaire.
Autre impératif : ces agents devront pouvoir travailler d’un outil à l’autre. Le développement d’un système embarqué fait déjà intervenir de nombreux environnements et de nombreuses sources de données, depuis la définition des exigences et le choix des composants jusqu’à l’architecture, la saisie des schémas, la simulation, le routage du circuit imprimé, l’approvisionnement et la fabrication.
Si l’agent IA fonctionne à son tour en vase clos, il ne fera qu’ajouter une nouvelle rupture dans une chaîne déjà très fragmentée. L’évolution la plus prometteuse est donc celle d’un écosystème dans lequel différents agents spécialisés et outils d’ingénierie peuvent échanger et travailler ensemble, sans pour autant priver l’ingénieur de la maîtrise de l’architecture globale.
Les capacités de l’IA vont sans aucun doute continuer à progresser. Mais dans la conception des systèmes embarqués, la question n’est pas simplement de savoir jusqu’où l’IA peut aller. Il s’agit surtout de savoir si elle peut transformer les intentions de l’ingénieur en actions concrètes et vérifiables.
C’est finalement ce qui distingue l’assistant de l’agent : le premier aide l’ingénieur à trouver une réponse ; le second l’aide à avancer concrètement dans la conception.
-blocks-basic-fr.jpg)
