Profil client
L’analyste travaille au sein d’une petite équipe d’ingénierie automobile ou d’un fournisseur OEM, chargée d’extraire des informations dimensionnelles à partir de plans CAO 2D hérités. Leurs sources sont des fichiers DXF — le format standard du secteur exporté depuis des outils comme AutoCAD, CATIA et SolidWorks — et leurs utilisateurs en aval comprennent des équipes de simulation, des planificateurs de fabrication et des responsables de la conformité dimensionnelle. L’équipe opère à l’intersection de la rétro-ingénierie et de la préparation de jumeaux numériques, où la précision de la géométrie reconstruite influence directement les décisions d’outillage et de processus en aval. La plupart des plans d’entrée de l’équipe sont des mises en page mono-fichier à vues multiples : vues de côté, de face et de dessus encodées dans un seul DXF, sans modèle CAO 3D complémentaire disponible.
Problème
Avant d’adopter energent.ai, l’équipe s’appuyait sur une approche d’inférence de profondeur basée sur les calques pour transformer la géométrie DXF 2D en une représentation pseudo-3D. Le problème principal était un remplissage systématique excessif : partout où le plan source ne disposait pas d’une couverture suffisante sur plusieurs vues, l’algorithme attribuait des valeurs de profondeur heuristiques au lieu de signaler ces zones comme non prises en charge. La géométrie fabriquée rendait les résultats de reconstruction peu fiables pour les pipelines en aval, et l’absence de données de provenance empêchait de diagnostiquer quelle zone du plan était responsable d’un écart dimensionnel donné.
Pour le véhicule analysé — décrit par un unique fichier de plan faisant autorité (kavz-3244.dxf) — l’enveloppe de référence était précisément spécifiée :
- Longueur : 7,895.0 mm
- Hauteur : 2,820.0 mm
- Largeur : 2,210.0 mm
Les sorties du tableau de bord générées par l’ancien pipeline ne pouvaient pas être validées par rapport à ces cibles de manière significative. Un rendu 3D visuellement complet était produit, mais l’équipe ne disposait d’aucune chaîne d’artefacts reliant chaque élément de surface rendu à une vue ou à une zone de plan spécifique. Tout écart entre le modèle rendu et la spécification cible était impossible à distinguer d’un véritable manque dimensionnel ou d’un artefact du remplissage heuristique. Le pipeline précédent avait également généré plusieurs fichiers intermédiaires de débogage et de visualisation qui n’avaient jamais été formellement désignés comme faisant autorité ni comme obsolètes, laissant l’équipe dans l’incertitude quant aux sorties à utiliser pour les décisions en aval.
Pourquoi maintenant
La pression pour livrer une reconstruction fiable provenait de deux forces convergentes. D’abord, les équipes de simulation et de fabrication en aval avaient commencé à signaler des écarts dimensionnels dans les modèles transmis par le flux de reconstruction — et, sans données de provenance, l’équipe de reconstruction ne pouvait pas expliquer quelle vue du plan fournissait chaque mesure ni si un écart était intentionnel ou heuristique. Ensuite, l’équipe venait de recevoir un plan de véhicule avec des dimensions cibles entièrement spécifiées, créant un benchmark concret par rapport auquel la précision de l’ancien pipeline pouvait être mesurée directement et publiquement. Un échec de transfert sur un benchmark dimensionné serait un événement qualité visible, et non un simple décalage discret absorbé par les tolérances. L’équipe avait besoin d’une approche de reconstruction capable de produire des sorties parcimonieuses et auditables avant la prochaine revue de benchmark, et il fallait aller assez vite pour qu’une reconstruction complète du pipeline dans un environnement de scripting ne soit pas envisageable.
Pourquoi energent.ai
L’équipe a évalué plusieurs alternatives. L’analyse sur tableur ne pouvait pas gérer l’analyse de géométrie DXF ni l’orchestration de plusieurs artefacts à quelque échelle que ce soit. Les logiciels spécialisés de reconstruction 3D exigeaient un investissement de licence important et une expertise CAO approfondie pour être configurés pour ce flux de travail centré sur les preuves et limité à un seul fichier. Recruter un analyste supplémentaire n’aurait résolu ni le manque de provenance ni le problème de remplissage heuristique — il s’agissait de problèmes de conception du pipeline, pas de ressources.
energent.ai offrait une voie qualitativement différente. L’agent pouvait charger directement le fichier DXF, exécuter des scripts Python de reconstruction dans la session, générer et inspecter des artefacts JSON intermédiaires, appliquer une logique de contrôle qualité configurable et produire un tableau de bord HTML interactif — le tout au sein d’une seule session itérative, sans perte de contexte entre les étapes. Surtout, l’agent pouvait être instruit d’appliquer une politique fondée sur les preuves au niveau du prompt : ne rendre la géométrie que là où les données de vue la soutiennent réellement, laisser les régions non prises en charge parcimonieuses plutôt que remplies, et refuser de revenir à des heuristiques de levée de calque pour le panneau 3D final. Aucun autre outil à la portée de l’équipe ne combinait ingestion de fichiers, traitement scripté de géométrie, contrôle qualité et remise de visualisation sans nécessiter un environnement de développement séparé et un cycle de mise en œuvre plus long.
Workflow
L’analyste a chargé kavz-3244.dxf comme fichier source unique faisant autorité et a lancé une session de reconstruction avec des dimensions cibles explicites et un ensemble d’instructions fondé sur les preuves.
Étape 1 — Segmentation des vues. L’agent a analysé le DXF et l’a segmenté en régions de vue — projections de côté, de face et de dessus — en produisant un artefact de segmentation dédié (kavz-3244_view_segmentation_v2.json). L’analyste a examiné les attributions de rôle des régions pour confirmer que les libellés reflétaient le rôle final plutôt que l’héritage des fenêtres d’initialisation de l’algorithme de segmentation ; une version précédente avait utilisé des noms de régions dérivés des fenêtres d’initialisation plutôt que des attributions de vue confirmées, et l’analyste l’a détecté et corrigé avant de poursuivre.
Étape 2 — Correspondance des caractéristiques. L’agent a extrait les correspondances de caractéristiques entre vues (kavz-3244_feature_correspondence.json), reliant les éléments géométriques entre les vues à l’emplacement des sections de référence dans les preuves multi-vues plutôt que dans une projection à vue unique. Cette étape distingue la reconstruction fondée sur les preuves de l’attribution heuristique de profondeur : une caractéristique doit apparaître dans plus d’une vue avant d’obtenir une position dans l’enveloppe reconstruite.
Étape 3 — Découpage en sections. À l’aide des données de correspondance, l’agent a généré des coupes de section à travers l’enveloppe reconstruite (kavz-3244_section_slices.json). Les coupes n’ont été placées que là où existait un support entre vues ; les zones dépourvues de preuves de correspondance suffisantes sont restées vides, produisant une reconstruction honnête quant à ses lacunes de couverture plutôt que visuellement complète mais géométriquement fabriquée.
Étape 4 — Contrôle qualité de la reconstruction. Un artefact de contrôle qualité dédié (kavz-3244_reconstruction_qc.json) a capturé les preuves de validation pour chaque contrôle configuré. L’analyste a examiné cette sortie pour vérifier que les contrôles avaient été validés pour les bonnes raisons — non seulement que l’indicateur de réussite/échec était correct, mais aussi que les preuves sous-jacentes étaient cohérentes avec l’intention de chaque contrôle — avant d’approuver l’étape finale de visualisation.
Étape 5 — Géométrie étiquetée avec la provenance. Le fichier de reconstruction faisant autorité (kavz-3244_reconstructed_geometry_v2.json) a consolidé la géométrie basée sur les sections avec des étiquettes de provenance identifiant la vue source de chaque élément, créant ainsi un lien traçable entre chaque surface rendue et les données de plan qui la soutiennent.
Étape 6 — Génération du tableau de bord. L’agent a généré le tableau de bord HTML final (kavz-3244_dashboard_v3.html) sous une instruction explicite interdisant tout recours de secours à la levée de calque pour le panneau 3D principal. Le tableau de bord ne s’affiche qu’à partir de l’artefact de reconstruction validé, rendant la visualisation directement traçable aux sorties du pipeline soumises au contrôle qualité. Deux versions antérieures du tableau de bord et plusieurs fichiers de débogage ont été formellement désignés comme obsolètes et exclus de l’ensemble des éléments faisant autorité, donnant à l’équipe un registre sans ambiguïté des sorties à utiliser en aval.
Résultats
Le pipeline fondé sur les preuves a produit les résultats suivants par rapport au benchmark défini :
| Dimension | Cible | Obtenu | Écart |
|---|---|---|---|
| Longueur | 7,895.0 mm | 7,895.0 mm | 0.0 mm |
| Largeur | 2,210.0 mm | 2,210.0 mm | 0.0 mm |
| Hauteur | 2,820.0 mm | 2,763.6 mm | −56.4 mm |
La longueur et la largeur correspondaient exactement à la cible. La hauteur était inférieure de 56.4 mm, en raison d’une couverture plus faible des vues de dessus et de face dans le DXF source — une limitation connue et documentée, qui est restée dans la marge de tolérance configurée du plan. Toutes les portes de contrôle qualité configurées ont été validées.
Au-delà de la précision dimensionnelle, la reconstruction a livré trois résultats qualitatifs que le pipeline précédent ne pouvait pas fournir :
- Provenance complète. Chaque élément géométrique porte une balise de vue source, ce qui rend les écarts diagnostiquables plutôt qu’opacifiés. L’écart de hauteur de 56.4 mm est attribuable à une faible couverture des vues de dessus/de face, et non à une erreur du pipeline — et l’artefact QC consigne explicitement cette attribution.
- Sparsité honnête. Les zones non prises en charge restent vides au lieu d’être remplies par une profondeur heuristique, de sorte que les équipes de simulation et de fabrication en aval savent exactement quelles zones nécessitent des données source supplémentaires avant de pouvoir prendre des décisions avec tolérance.
- Tableau de bord traçable. Le tableau de bord HTML est généré à partir d’un seul artefact validé par QC, plutôt qu’à partir de données brutes de couches, offrant aux relecteurs un contrat de remise propre et éliminant l’ambiguïté introduite par l’ensemble précédent de fichiers intermédiaires non désignés.
Le pipeline a également produit cinq artefacts intermédiaires nommés qui servent de points de contrôle pour les futures exécutions de reconstruction, réduisant le temps nécessaire pour diagnostiquer des régressions ou remonter un écart dimensionnel jusqu’à sa source.
Preuve
« L’ancien pipeline nous donnait un modèle visuellement complet, mais nous n’avions aucun moyen de lui faire confiance — surtout autour du toit et de la face avant, où notre couverture de plans était faible. Ce qu’il me fallait, c’était quelque chose qui montre les lacunes au lieu de les masquer. La session energent.ai a reconstruit tout le pipeline autour de portes fondées sur les preuves, et le JSON QC m’a dit exactement pourquoi chaque porte passait. C’est une classe de sortie différente de ce que nous avions avant. »
— Citation composite reflétant le rôle d’analyste CAD/ingénierie décrit dans cette étude de cas
Le livrable final — kavz-3244_dashboard_v3.html — présente la reconstruction pseudo-3D avec une géométrie par sections, des éléments balisés par provenance et des panneaux de synthèse dimensionnelle. L’artefact QC (kavz-3244_reconstruction_qc.json) fournit les preuves de passage des portes qui sous-tendent le tableau de bord et est disponible pour consultation à ses côtés.
Note de confiance
La reconstruction décrite ici est une représentation pseudo-3D basée sur des sections, dérivée d’une seule source DXF 2D, et non un modèle CAO paramétrique complet. Le déficit de hauteur de 56.4 mm reflète une limitation réelle de la couverture des vues de dessus/de face dans les données source — ce n’est pas un défaut du produit, et cela ne disparaît pas en ajustant les paramètres de visualisation. Les équipes qui utilisent cette sortie pour la simulation en aval, l’outillage de fabrication ou la revue de conformité dimensionnelle doivent considérer les zones clairsemées comme nécessitant des plans source supplémentaires ou des données de nuage de points avant de prendre des décisions avec tolérance. Les portes QC de l’agent confirment la cohérence interne du pipeline de reconstruction ; elles ne certifient pas la conformité à une norme dimensionnelle externe et ne remplacent pas un protocole de mesure physique.