Mis à jour 5 nov. 2026
3 min de lectureImport documentaire : le fichier ne suffit pas.
Un chargement réussi ne prouve pas que le document appartient à la bonne révision. Une démarche de vérification concrète pour les personnalisations Active Workspace.
Équipe technique PLM Nexus
- Révision cibleLe bon objet métier
- Relation du datasetLe rôle documentaire prévu
- Résultat enregistréContenu et métadonnées vérifiés
Schéma du processus
Notre travail sur Active Workspace pour SACMI a porté sur l’adaptation d’une personnalisation d’import de documents, les vérifications fonctionnelles et la livraison. Les conseils qui suivent présentent une approche générale de la vérification des imports documentaires.
Commencer par la relation, pas par le bouton
Définissez la révision source, le type de dataset, la relation et les métadonnées attendues avant de modifier l’interface. Ces éléments précisent ce que la commande doit préserver. Un fichier visible ne suffit pas s’il est rattaché au mauvais objet ou par la mauvaise relation.
Une matrice de tests courte et utile
Pour une personnalisation similaire, prévoyez quatre vérifications : la révision et le type de fichier pris en charge, une sélection non prise en charge, un import répété et un utilisateur sans l’autorisation requise. Définissez le résultat attendu avant chaque exécution. Il s’agit de contrôles recommandés, pas d’un relevé des tests de la mission historique.
Après l’opération, rouvrez la révision et inspectez le dataset, la relation et les propriétés. Vérifiez le résultat enregistré, pas seulement le message de réussite. Si un échec laisse un résultat partiel, rendez cet état visible et convenez de sa reprise.
Rendre la livraison reproductible
Consignez la version AWC cible, la configuration, la sélection initiale et les résultats attendu et observé. Conservez ce relevé avec la personnalisation. Le prochain mainteneur pourra distinguer une évolution métier d’une régression introduite lors d’un nouveau portage.
Il s’agit de contrôles d’acceptation proposés, pas de tests exécutés ni de résultats clients. Convenez du comportement attendu avec le responsable du processus, notez l’environnement et la version, puis renseignez le résultat observé et la preuve. Une cellule vide ne signifie pas un test réussi.
| Scénario | Résultat attendu | Preuve à conserver |
|---|---|---|
| Import pris en charge | Fichier, dataset, relation et révision correspondent à la cible convenue. | Identifiants, relation et fichier rouvert. |
| Sélection non prise en charge | Refus clair ; aucun objet indésirable créé. | Message et liste des objets avant/après. |
| Import répété | Mise à jour, nouvelle version ou refus convenu ; aucun doublon accidentel. | Identifiants et versions après les deux essais. |
| Droits insuffisants | Aucun contournement des droits ; tout résultat partiel est identifié. | Utilisateur de test, action refusée et état enregistré. |
| Opération interrompue | État partiel visible ; reprise ou nouvel essai avec résultat défini. | Point d’échec, état des objets et preuve de reprise. |
Prochaine étape
Si ce schéma apparaît dans votre environnement Teamcenter, découvrez le service correspondant ou discutons du changement nécessaire.