Mis à jour 5 nov. 2026
3 min de lectureWorkflows entre systèmes : rendre les décisions explicites.
Une correspondance de statuts n’est pas un processus de décision. Les enseignements d’une intégration Teamcenter–Polarion sur les responsabilités, les décisions en attente et la reprise.
Équipe technique PLM Nexus
- Décision demandéePolarion
- Approbation en attenteL’équipe responsable décide
- Communiquer le résultatMaintenir la cohérence entre les systèmes
Schéma du processus
Notre travail Teamcenter–Polarion pour CNH a porté sur l’intégration et la coordination des workflows. La leçon générale est qu’échanger un statut ne revient pas à coordonner une décision.
Modéliser explicitement la décision en attente
Dans un workflow entre systèmes, représentez explicitement les décisions en attente. Définissez qui peut décider, ce que signifie chaque résultat et comment le communiquer.
Définir qui décide, puis mapper les données
Pour chaque transition, identifiez le système d’origine, le responsable de la décision et la réponse attendue par l’autre système. Distinguez la réception de la demande de l’acceptation de la décision. Un appel de service techniquement réussi peut laisser le processus métier en attente d’une personne.
Tester les branches, pas seulement l’échange
Pour une nouvelle intégration, incluez dans le plan de test l’approbation, le refus, une notification répétée et une défaillance de service. Convenez de l’état visible et de la reprise pour chaque cas. Ces scénarios prolongent la leçon de conception ; ils ne sont pas présentés comme des résultats de tests historiques chez CNH.
L’IA peut accélérer le mapping, le code et la préparation des tests. L’équipe doit toujours déterminer quel système porte chaque transition et vérifier le comportement obtenu. C’est une gouvernance utile : des décisions claires intégrées au workflow, pas un document de plus déconnecté de la réalisation.
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 |
|---|---|---|
| Demande reçue | Le système destinataire enregistre l’attente ; recevoir ne vaut pas approuver. Nommez le décideur. | Identifiant de corrélation et état d’attente dans les deux systèmes. |
| Approbation ou refus | Seul le responsable habilité décide ; chaque résultat possède un état distinct et mappé. | Acteur, décision, horodatage et état correspondant. |
| Notification dupliquée | Rejouer le même événement ne répète pas la transition métier. | Clé d’événement, répétition et trace d’une seule transition. |
| Échec de transmission | Conservez un état visible d’attente/erreur, un responsable de reprise et une règle de réessai ; n’annoncez pas un succès. | Journal d’échec, clé de réessai et état final réconcilié. |
Prochaine étape
Si ce schéma apparaît dans votre environnement Teamcenter, découvrez le service correspondant ou discutons du changement nécessaire.