Quand un agent IA doit développer un produit, on regarde d’abord le modèle et les outils. Quel LLM, quel CAD, quelle simulation ? Après quelques semaines de robot challenge, j’en suis convaincu : la qualité du résultat dépend de l’operating model dans lequel l’agent travaille. C’est-à-dire la question de savoir comment on travaille, décide, vérifie et apprend.
Pour rappel : dans Next challenge, je me suis donné pour objectif de laisser un agent IA développer de façon autonome un petit robot DIY. Des exigences à l’architecture, au CAD et au firmware, jusqu’à la simulation. Je définis le framework et les exigences, le montage reste à ma charge. Un premier concept du robot est désormais entièrement conçu et simulé (pas encore construit). Ce qui est plus intéressant, ce sont les leçons apprises en chemin.
Fidèle au processus et pourtant à côté
Mon premier concept du framework consistait essentiellement en des règles de base et une stack technique. Le résultat était tout juste moyen.
L’exemple le plus frappant : l’agent avait choisi seul comme base un kit d’achat, un châssis rond en acrylique à deux ponts. Dans son modèle CAD se trouvait pourtant un cadre rectangulaire en aluminium. La photo du produit était pourtant dans le dossier du projet depuis le début. C’est moi qui l’ai remarqué, en regardant simplement l’image.
Ce qui est frappant : l’agent avait respecté toutes les règles de processus. Exigences déduites, décisions documentées, recherche avec sources. Il manquait simplement un critère pour reconnaître un bon travail d’ingénierie — pour lui, le cadre en aluminium relevait, pour le dire de façon un peu caricaturale, d’un « ça devrait aller ». Et moi, j’étais parti du principe, presque comme une évidence, que le modèle devait forcément correspondre à ce qui en sortirait.
La deuxième leçon me concernait moi-même. Dès le départ, je savais que je voulais séparer le corpus de règles (comment l’agent travaille-t-il ?) du projet (que construit-il ?), pour pouvoir le réutiliser. Je n’avais pas non plus formulé cela comme une exigence. Cela m’est devenu clair en regardant les premières versions du framework : non, nous n’étions pas encore au but.
Les attentes implicites deviennent soit des exigences explicites, soit elles ne sont pas satisfaites.
Mon operating model prend forme
Après deux ou trois cycles de révision, mon operating model a pris sa forme actuelle.
À gauche entre l’intent : objectifs, exigences, contraintes, budget. À droite sortent les packages de build, prototypes et rapports de test. En bas, une boucle de contrôle revient en arrière, avec findings, expériences et change requests.
L’agent lui-même comporte plusieurs niveaux. La partie supérieure (bleue) dépend du domaine et de l’organisation (ou, dans mon cas : de moi) : des outils comme SysML, CAD, ECAD et simulation, ainsi que des règles de conception, les lessons learned et la question de ce que l’organisation (= moi) peut effectivement fabriquer et tester. Dans mon « entreprise d’un seul homme », cela signifie : soudure oui, SMD non, pas d’imprimante 3D, un multimètre. L’agent doit planifier avec ce que je suis moi-même capable de réaliser ensuite.
La partie inférieure (jaune) est le noyau fixe de l’operating model. Elle s’applique au-delà des projets et se compose de trois couches :
Governance & Conventions. Qui décide de quoi ; comment se déroulent les changements ; quand l’agent transmet-il la main à l’humain ; comment les assets sont nommés.
Engineering Platform. Git, conteneurs, skills et vérifications automatiques. Mais ce pourrait tout aussi bien être un paysage PLM complet comme Windchill ou Teamcenter.
Engineering Method. Basée sur les modèles et architecture first. D’abord les exigences et l’architecture (chez moi en SysML v2), puis la conception et le code. Chaque exigence est traçable jusqu’au cas de test.
Quiconque est à l’aise avec le PLM n’y découvrira pas grand-chose de nouveau. Manuel de développement, change management, processus de validation, design guidelines : tout cela existe pour les équipes humaines depuis des décennies. Un agent a besoin de la même chose, simplement de façon beaucoup plus explicite et imposée mécaniquement à bien des endroits.
Ce qui manquait encore au début
La méthode, la plateforme et les règles du jeu pour les décisions étaient là depuis le début. Ce qui manquait, c’était un critère pour un bon travail d’ingénierie. Le framework l’a reçu lors de la deuxième itération, sous la forme de design guidelines pour chaque discipline, comme les connaît tout service de développement. La leçon du châssis en est un exemple.
Il m’importait tout autant que ces directives ne restent pas figées au niveau du premier jour. L’agent consigne ce qu’il apprend et en déduit des propositions de nouvelles règles. C’est moi qui décide lesquelles s’appliquent.
Quand je fais confiance à l’agent
Dans mon article « L’IA en ingénierie a besoin de règles — et de confiance », il était question de savoir quand on peut faire confiance au travail d’une IA. C’est précisément ce type de fiabilité que l’operating model doit fonder. Je veux pouvoir me fier au résultat sans devoir vérifier moi-même chaque ligne.
Pour cela, il faut d’abord de la traçabilité : chaque décision est justifiée, chaque exigence traçable jusqu’au test. Ensuite, des responsabilités claires. Les questions techniques, l’agent les règle seul ; les objectifs, le budget, la sécurité et les règles du jeu elles-mêmes, uniquement avec moi. Et ce sont les limites que la plateforme fait respecter, une simple demande dans le prompt serait trop fragile sur de longues sessions. Fait amusant : le jour où j’ai moi-même modifié les règles du jeu directement, sans change request, l’agent l’a remarqué au démarrage suivant et me l’a attribué. Pris sur le fait !
L’agentic engineering n’est pas du vibe engineering
Andrej Karpathy a décrit le vibe coding en substance ainsi : on se laisse porter par le vibe et on regarde ce qui en sort. Et les termes vibe engineering et agentic engineering sont souvent confondus. Pourtant : ce qui se passe ici est tout sauf du « vibe ». Il y a un framework clair, censé satisfaire des exigences envers un intent, et cela de façon traçable.
La construction de ce framework demande beaucoup de matière grise et assez peu de vibe.
Je constate ici quelque chose que je connais d’un long travail avec l’IA. Pour des tâches ciblées et isolées, elle fonctionne à merveille. Pour des projets plus vastes, où seul l’intent est peut-être connu, la direction encore très floue, et la definition of done difficile à formuler précisément, cela ne fonctionne qu’en dialogue entre l’humain et l’IA. Sans IA, ce projet n’aurait pas existé. Mais sans moi non plus.
Et le robot ?
C’est un robot domestique craintif qui est en train de naître. Il s’effraie de la lumière et du bruit et se cache dans l’obscurité, de préférence sous notre canapé. Il est simulé dans une réplique numérique de notre salon, avec le même firmware que celui qui tournera plus tard sur le microcontrôleur.
Sous le capot de « proto-1 » se cachent environ 50 exigences, toutes traçables jusqu’au cas de test, 14 décisions documentées, une architecture SysML v2 vérifiée automatiquement et une nomenclature pour un peu moins de 75 euros (pour un budget fixé à 100 euros). L’agent avait lui-même introduit trois bugs dans son firmware. Il les a aussi trouvés lui-même, lors de tests de scénarios et de la simulation.
La prochaine étape, c’est la construction. On verra alors si le concept tient la route et ce que valait vraiment la simulation. Selon les exigences, le petit fuit la lumière et le bruit. Me pourchasser, ça n’est écrit nulle part. Je suis curieux de voir s’il s’y tiendra 😉
Pour ceux à qui ça parle : si vous vous demandez à quoi pourrait ressembler un operating model pour des agents IA dans votre propre ingénierie, avec exigences, change process et Digital Thread, mes collègues de BHC et PROSTEP et moi-même serons ravis de vous aider.
Questions et réponses
Qu’est-ce qu’un operating model pour les agents IA en ingénierie ?
Le cadre dans lequel un agent travaille, indépendamment du projet concret : une engineering method (chez moi basée sur les modèles, architecture first), une engineering platform (Git, conteneurs, skills, vérifications automatiques) et une governance avec des conventions (droits de décision, change process, transmissions à l’humain, nommage). S’y ajoute une control loop qui transforme les expériences du projet en nouvelles règles.
En quoi l’ingénierie agentique se distingue-t-elle du vibe coding ?
Dans le vibe coding, on décrit grossièrement ce qu’on veut obtenir et on se laisse surprendre par le résultat. L’ingénierie agentique travaille par rapport à un intent explicite : des exigences avec des ID, des décisions documentées, des demandes de changement et des vérifications, si bien que chaque résultat peut être retracé jusqu’à son exigence.
