Des systèmes connectés à l’ingénierie intelligente

Le contenu de cette page a été traduit automatiquement par un service tiers.

Pourquoi les agents d’IA ont besoin de plus qu’un simple accès aux données

Depuis des années, la transformation numérique dans l’ingénierie est principalement axée sur l’intégration.

Nous avons connecté la CAO au PLM, le PLM à l’ERP, ainsi que l’ingénierie à la fabrication, à la qualité, aux fournisseurs et au service.

Ce travail reste indispensable. Mais connecter les systèmes n’est plus le défi le plus difficile.

Le véritable défi consiste désormais à préserver le contexte d’ingénierie lorsque les informations circulent entre ces systèmes.

Une exigence ne se résume pas à du texte. Une conception ne se limite pas à une géométrie. Une modification n’est pas simplement un objet révisé. Chacun de ces éléments porte un contexte, notamment la configuration du produit, la révision, les dépendances, les responsabilités, les approbations et les décisions qui l’ont précédé.

Lorsque ce contexte est perdu, les systèmes peuvent rester connectés, mais les connaissances d’ingénierie, elles, ne le sont plus.

L’intégration traditionnelle est conçue pour déplacer les informations entre les systèmes. Mais le simple transfert des données ne garantit pas que le système ou l’équipe qui les reçoit en comprenne la signification.

Une exigence peut-elle rester liée à la conception, aux essais, aux risques et aux éléments de certification qu’elle influence ?

Une modification de conception peut-elle être comprise de manière cohérente par les équipes logiciel, matériel, fabrication, qualité et service ?

Les équipes peuvent-elles déterminer à quel produit, à quelle configuration client et à quelle révision les informations s’appliquent ?

Peuvent-elles distinguer les informations faisant autorité de celles qui ne sont que des copies ?

Le véritable défi n’est plus simplement de déplacer les informations. Il consiste à préserver les relations qui donnent à ces informations toute leur valeur.

Pourquoi le contexte d’ingénierie est plus important que l’intégration des systèmes

La continuité numérique est souvent décrite comme un lien entre les systèmes du cycle de vie. Cette définition est incomplète.

Une continuité numérique réellement utile doit permettre aux personnes et aux systèmes de comprendre ce qui a changé, pourquoi cela a changé, ce qui est concerné, à quelle configuration cela s’applique, qui l’a approuvé et quelles preuves étayent cette décision.

Cela exige des identifiants persistants, des relations traçables, une gestion des configurations, des informations sur la responsabilité, la provenance et l’autorité des données.

L’objectif n’est pas de regrouper toutes les disciplines de l’ingénierie dans un seul système. Les environnements d’ingénierie modernes resteront distribués. La conception mécanique, l’électronique, le logiciel, l’ingénierie système, la simulation, la fabrication, la qualité, les fournisseurs et le service continueront d’utiliser des outils différents.

L’objectif est de conserver des informations distribuées sans perdre le contexte qui les relie.

L’IA rend cette exigence encore plus importante.

La première génération d’IA appliquée à l’ingénierie a principalement joué un rôle de copilote. Les copilotes aident les utilisateurs à rechercher des informations, les résumer, générer du contenu, comparer des données et recommander les prochaines étapes. C’est toujours la personne qui interprète le résultat et décide de l’action à entreprendre.

La prochaine étape est celle des agents.

Les agents ne se contentent pas de répondre à des questions. Ils participent aux processus métier.

Un agent d’ingénierie peut préparer une demande de modification, identifier les éléments concernés, mettre à jour les informations, rassembler les éléments justificatifs ou transmettre une tâche pour approbation.

Cela impose des exigences beaucoup plus élevées à l’environnement de données sous-jacent.

Un copilote peut rester utile avec un contexte partiel. Un agent, en revanche, ne peut pas agir en toute sécurité sans savoir sur quel produit, quelle variante et quelle révision il travaille, quelles informations font autorité, quels éléments dépendent de la modification envisagée, quelles règles s’appliquent et à quel moment une approbation humaine est nécessaire.

Le fait de connecter un agent à plusieurs systèmes ne signifie pas qu’il comprend les relations entre les informations qu’ils contiennent.

Un agent peut effectuer une modification correcte localement tout en créant des problèmes ailleurs. Une modification d’exigence peut avoir des répercussions sur le logiciel, le matériel, les essais, les instructions de fabrication, les fournisseurs et les éléments de certification. Cette même modification peut être valable pour une configuration produit et incorrecte pour une autre.

C’est pourquoi l’accès aux données ne suffit pas. L’IA a besoin du contexte produit.

L’objectif n’est pas une autonomie sans limites. Il est de mettre en place une délégation contrôlée.

L’IA peut préparer un travail proposé, identifier les dépendances, évaluer les impacts, constituer les éléments justificatifs et transmettre le travail au bon réviseur. Les personnes conservent leur capacité de jugement, leur pouvoir d’approbation et leur responsabilité.

Pour que ce modèle fonctionne, l’environnement produit doit définir les informations auxquelles l’agent peut accéder, ce qu’il est autorisé à modifier, les dépendances qu’il doit évaluer, les règles qu’il doit respecter et les personnes qui doivent approuver le résultat.

Sans cette base, les agents d’ingénierie resteront limités à des tâches isolées et à faible risque. Avec elle, ils pourront commencer à prendre en charge des processus d’ingénierie réellement significatifs.

Construire une base PLM pour les agents d’IA

Le PLM a traditionnellement servi de système de référence pour les structures produit, les révisions, les documents et les processus. Ce rôle reste essentiel, mais il ne suffit plus à lui seul.

Le PLM doit désormais contribuer à préserver le contexte produit dans un environnement d’ingénierie distribué. Sa valeur ne réside pas uniquement dans sa capacité à stocker davantage d’informations. Elle réside dans sa capacité à maintenir les relations nécessaires pour comprendre le produit, évaluer les changements et soutenir la prise de décision.

Cette fonction devient encore plus importante lorsque l’IA commence à participer à ces décisions et à ces processus.

Pour les responsables de l’ingénierie et du PLM, la question n’est plus seulement de savoir si les systèmes sont connectés.

La question la plus importante est de savoir si le contexte d’ingénierie est préservé d’un système à l’autre.

Est-il possible de comprendre les dépendances avant qu’une modification ne soit effectuée ? La configuration produit peut-elle être déterminée de manière fiable ? L’IA est-elle capable de distinguer les informations faisant autorité de celles qui sont simplement disponibles ? Chaque action proposée peut-elle être reliée aux preuves qui la justifient et aux approbations correspondantes ?

Les entreprises qui sauront répondre à ces questions seront beaucoup mieux positionnées pour gérer la complexité des produits et déployer l’IA de manière responsable à grande échelle.

L’intégration reste indispensable. Mais elle n’est pas la finalité.

La véritable finalité est de disposer d’une compréhension cohérente, gouvernée et exploitable du produit, suffisamment solide pour inspirer confiance aux personnes et permettre aux agents d’IA d’agir en toute sécurité.

Pour approfondir ce sujet, consultez Building the Foundation for AI in Product Development.