AWS relie 3 agents d'IA pour vérifier le remplacement de composants aéronautiques

Lorsqu'une pièce nécessaire est retirée de la production, il ne suffit pas à l'ingénieur de trouver un composant au nom similaire. Il faut récupérer les spécifications, comparer la tension, la masse, les interfaces et la plage de températures, vérifier la géométrie du boîtier, déterminer le délai de livraison et rassembler le tout dans un document destiné à la revue. Dans l'aéronautique, une erreur à ce stade peut coûter bien plus cher que quelques jours de travail manuel.

AWS a présenté le prototype d'un assistant qui répartit cette tâche entre trois agents spécialisés. L'un recherche les pièces adaptées, le deuxième vérifie les tolérances techniques, le troisième travaille avec la documentation et les informations à jour sur le cycle de vie des composants. Une limite importante : le système rassemble des preuves et prépare un brouillon d'évaluation, mais n'autorise pas le remplacement. Le dernier mot revient à l'ingénieur.

Comment le parcours d'une requête est organisé

Imaginons qu'une roue de réaction pour satellite ne soit plus disponible. L'ingénieur demande d'évaluer le risque de retrait du modèle de la production, de trouver des alternatives et de les comparer à la pièce d'origine.

D'abord, un petit planificateur détermine la séquence d'actions. L'agent de catalogue cherche des candidats dans la base de pièces. L'agent d'évaluation compare leurs caractéristiques. L'agent de connaissances extrait des informations des descriptions techniques, des plans et des sources web. Si plusieurs spécialistes ont travaillé, un modèle distinct fusionne les résultats en une seule réponse.

Cette séparation est utile au-delà de l'organisation. Chaque agent n'a accès qu'aux outils nécessaires. L'agent de recherche ne peut pas modifier les résultats de la vérification, et l'agent d'évaluation ne se charge pas de la recherche libre de fournisseurs. Cela réduit le nombre d'actions inattendues et simplifie l'audit.

Là où l'on ne fait pas confiance au modèle pour calculer

La partie la plus solide de la solution : la vérification des tolérances est effectuée par du code Python ordinaire. Pour chaque catégorie de pièces, les paramètres critiques et les règles sont définis à l'avance : correspondance exacte de la tension, dépassement de masse admissible, compatibilité de l'interface et autres contraintes.

Avec des données d'entrée identiques, la vérification donne toujours le même résultat. Le modèle de langage peut expliquer le tableau et rédiger la note, mais n'a pas le droit de réécrire le statut « réussi », « non-conformité » ou « vérification requise ». Après chaque évaluation, le système conserve un journal des actions : le relecteur voit donc non seulement la conclusion, mais aussi le chemin qui y mène.

C'est un bon modèle pour tous les processus critiques. Le modèle intervient là où il faut de la recherche, de l'analyse de documents et un texte cohérent. Le code gère les règles qui doivent être reproductibles sans interprétation créative.

Pourquoi une recherche multimodale

Une partie des données d'ingénierie ne se trouve pas dans des tableaux. Le couple peut n'apparaître que sur un graphique, l'emplacement du connecteur sur une photographie, et les dimensions de montage sur un plan. Amazon Nova Multimodal Embeddings place le texte et les images dans un espace de recherche commun. Ainsi, une requête sur une caractéristique peut renvoyer le diagramme voulu, et une image téléversée, une pièce similaire.

Les photographies de deux composants sont également comparées par similarité cosinus, après quoi le modèle décrit les différences visibles : fixations, connecteurs et forme du boîtier. Mais la ressemblance visuelle reste une preuve d'appoint. Le résultat de la vérification est déterminé par les exigences d'ingénierie définies.

Les limites de l'approche sont notables. Les règles de tolérance devront être maintenues manuellement, la qualité de la réponse dépend de l'exhaustivité de la base, et la recherche web ne remplace pas la confirmation du fabricant. La démonstration n'utilise que sept pièces fictives : elle prouve donc l'idée d'architecture, et non la préparation à une véritable certification.

La conclusion pratique pour le développeur est simple : ne construisez pas un seul agent omniscient. Séparez la recherche, les calculs et la préparation du document ; confiez les vérifications critiques à du code déterministe ; conservez les sources et le journal des actions ; laissez à l'humain les décisions lourdes de conséquences. C'est précisément cette frontière qui transforme une démonstration spectaculaire d'agents en un outil dont on peut discuter avec des ingénieurs et des auditeurs.