IA

Un agent IA pour le support technique et la visualisation 3D des équipements

Le contexte

Le même équipementier industriel disposait désormais des données de son parc. Restait un problème que la télémétrie ne résout pas : interpréter ce qu’elle dit.

Un technicien en intervention cherchait ses réponses dans des PDF, sur un parking, avec une connexion incertaine. La documentation existe, elle est même bonne — mais elle est répartie entre des manuels, des procédures et un catalogue de pièces, déclinés par version et par configuration d’équipement. Trouver la bonne page suppose de savoir déjà laquelle on cherche.

Côté back-office, le problème était symétrique : les interfaces de gestion de parc et de SAV s’étaient enrichies au point qu’un nouvel arrivant devait apprendre l’arborescence des menus avant de pouvoir répondre à un client.

Ce que nous avons fait

Nous avons construit une couche d’assistance au-dessus de la plateforme existante, ancrée dans le référentiel technique plutôt que dans les connaissances générales d’un modèle.

Un agent ancré dans une documentation indexée et dans les données vivantes du parcTrois sources alimentent l’agent, atteintes de deux façons différentes. La documentation technique est ingérée dans Knowledge Bases, qui la découpe, en calcule les embeddings et stocke les vecteurs dans Amazon S3 Vectors : elle change rarement, elle est donc indexée à l’avance. Le catalogue de pièces avec ses règles de compatibilité et la télémétrie qui porte l’historique de la machine concernée sont interrogés en direct via un serveur MCP, parce qu’un index pré-calculé de ces sources serait périmé. Les deux chemins convergent vers l’agent, qui tourne sur Amazon Bedrock et porte la source de chaque réponse. Il est utilisé par le technicien sur site pour le diagnostic, dans le back-office comme navigation guidée, et par le SAV avec l’historique complet de l’équipement.Ancrer l’agent dans le référentiel techniqueDocuments techniquesmanuels, procéduresCatalogue de piècesréférences, compatibilitéTélémétrie du parchistorique de la machineKnowledge Basesindexé sur S3 VectorsServeur MCPles sources vivantes, interrogées en directAgent sur Amazon Bedrock — chaque réponse cite sa sourceTechnicien sur sitediagnosticBack-officenavigation guidéeSAVhistorique complet
Deux chemins de récupération, parce que les sources diffèrent sur un point qui décide de l’architecture : une documentation mérite d’être indexée à l’avance, l’état d’une machine non. Et l’historique machine figure dans la liste parce que sans lui l’agent répond sur le modèle, pas sur l’exemplaire devant le technicien.
  • Les documents techniques de l’entreprise indexés avec Knowledge Bases. Les manuels, les procédures et les notes de service sont ingérés depuis S3, découpés, vectorisés et rendus interrogeables par le service, qui sert ensuite de source à l’agent. Le magasin de vecteurs derrière est Amazon S3 Vectors, ce qui évite de faire tourner et payer une base vectorielle dédiée pour un usage de cette taille. Utiliser une knowledge base managée plutôt que d’assembler nous-mêmes l’ingestion, le découpage et la récupération, c’est la différence entre un composant que le client réindexe en déposant une nouvelle révision dans un bucket et un pipeline que quelqu’un doit maintenir en vie.
  • Un serveur MCP sur les sources qui restent vivantes : le catalogue de pièces et ses règles de compatibilité, les configurations d’équipement, et la télémétrie du parc. Elles sont interrogées en direct plutôt qu’indexées, parce qu’un index pré-calculé du stock, de la compatibilité ou de l’état d’une machine est une erreur affirmée en puissance. Une seule interface au-dessus de sources qui n’avaient pas la même forme, ce qui évite aussi de réintégrer chacune d’elles dans le prochain outil qui voudra les lire.
  • Un agent de troubleshooting sur Amazon Bedrock, qui s’appuie sur les deux : la documentation indexée pour ce que l’équipement est censé faire, et l’historique de la machine concernée pour ce que cet exemplaire fait réellement. La distinction compte : une réponse sur le modèle générique est presque toujours inutile, parce que les configurations diffèrent d’un exemplaire à l’autre.
  • L’assistance à la navigation dans le back-office. L’utilisateur formule son besoin en langage naturel et arrive sur le bon écran, filtres déjà appliqués, au lieu d’apprendre où se trouve la fonction. L’arborescence reste accessible pour ceux qui la connaissent : l’agent est un raccourci, pas un remplacement.
  • La génération de vues 3D éclatées. À partir du modèle d’assemblage correspondant à la configuration de l’équipement, l’agent produit une vue éclatée du sous-ensemble concerné : quelles pièces se démontent, dans quel ordre, et avec quelle référence. Un schéma générique aurait été plus simple à servir, et faux dès que la configuration s’écarte du cas nominal.
Du modèle d’assemblage à une vue éclatée du bon sous-ensembleLe modèle d’assemblage correspondant à la configuration de l’équipement est le point de départ. L’agent localise le sous-ensemble vers lequel le symptôme pointe. Une vue éclatée de ce sous-ensemble est générée à la demande, montrant quelles pièces se démontent et dans quel ordre. La référence de la pièce l’accompagne, ce qui permet de la commander avant tout déplacement.Du modèle d’assemblage à la pièce en mainModèle d’assemblagepar configurationSous-ensemblelocalisé par l’agentVue éclatéegénérée à la demandeRéférence piècecommandée plus tôt
La dernière étape est celle qui rentabilise la chaîne : une vue éclatée est intéressante, une référence de pièce commandée avant le départ du camion est ce qui supprime la seconde visite. Générer la vue par configuration, plutôt que de sortir un schéma générique, est ce qui rend la référence juste.

Le résultat

Le technicien arrive avec la pièce. C’est la seule mesure qui compte vraiment dans ce métier : la seconde visite, celle qui coûte un déplacement complet parce que la bonne référence n’avait pas été identifiée à temps, se raréfie.

Le SAV répond plus vite, et un nouvel arrivant devient utile en jours plutôt qu’en semaines, parce qu’il n’a plus à mémoriser où les choses se trouvent avant de pouvoir aider quelqu’un.

L’enseignement le plus utile porte sur la confiance. Un agent qui se trompe avec assurance coûte plus cher qu’un agent qui ne répond pas : il envoie quelqu’un sur site avec la mauvaise pièce. Chaque réponse cite donc le document et la section dont elle vient, et l’agent dit explicitement quand le référentiel ne permet pas de conclure. Knowledge Bases renvoie les passages effectivement récupérés, et c’est ce qui donne sa valeur à la citation : elle est un fait de la récupération, pas quelque chose qu’on a demandé au modèle de fournir — un modèle à qui l’on demande de citer ses sources en inventera une. Ce n’est pas une précaution juridique, c’est ce qui fait qu’un technicien continue de s’en servir après la première erreur.

Toutes les références

Parlez-nous directement

Écrivez-nous directement. Pas de commercial, pas d'appel de qualification. C'est l'un de nous deux qui répond, sous 24h.

contact@onescale.io

Nous répondons sous 24h, et c'est l'un de nous deux qui répond.

Basés à Lyon, nous travaillons en France, en Europe et à l’international.