Automatiser un TMS sans API : interaction d’interface, contrôles et limites

Ce que signifie réellement « sans API »

L’opérateur utilise l’interface disponible pour localiser un dossier, renseigner des champs ou déclencher une action. Il ne contourne pas l’authentification et ne suppose pas que tous les écrans sont identiques. Les accès, les actions et les contrôles sont définis pour l’environnement concerné.

Cette approche répond surtout aux situations où une fonction métier existe dans l’interface mais n’est pas exposée par un connecteur exploitable. Elle doit être comparée à une intégration classique selon le volume, la stabilité et le risque.

Une action fiable comporte six étapes

1. 01
   Observer

   Reconnaître l’application, l’écran et l’état courant attendus.

2. 02
   Localiser

   Trouver le bon dossier avec des identifiants contrôlés.

3. 03
   Renseigner

   Appliquer les valeurs provenant du contexte validé.

4. 04
   Relire

   Comparer les champs visibles à l’intention avant validation.

5. 05
   Exécuter

   Déclencher uniquement l’action autorisée.

6. 06
   Vérifier

   Contrôler le message, le statut ou la valeur obtenue et conserver la trace.

Les situations qui doivent interrompre le scénario

• écran, champ ou libellé attendu introuvable ;
• plusieurs dossiers possibles pour la même référence ;
• valeur affichée différente de celle préparée ;
• session expirée ou droits insuffisants ;
• message d’erreur non reconnu ;
• action ayant un impact supérieur au périmètre autorisé.

API ou interface : décider au cas par cas

Une API stable offre généralement un contrat plus direct et plus facile à tester. L’interface apporte de la couverture lorsque ce contrat n’existe pas ou reste incomplet. Les deux approches peuvent cohabiter dans le même workflow.

Le cadrage Vigilo documente la méthode retenue, les points de contrôle, les limites et la stratégie de reprise. Le site ne promet pas une compatibilité universelle sans étude de l’environnement.

Matrice de choix : API, fichier ou interface

« Sans API » décrit une contrainte possible, pas une architecture à imposer. Un même workflow peut lire des données par API, recevoir un fichier et utiliser l’interface pour une action qui n’est exposée nulle part ailleurs. La décision doit donc être prise pour chaque lecture, écriture et contrôle attendu.

Conditions de qualification avant la première écriture

La qualification part d’une action précise — par exemple créer un ordre, modifier un créneau ou joindre une pièce — et non d’une promesse générale d’« automatiser le TMS ». Pour chaque action, l’équipe décrit les cas permis, les états de départ acceptables et la preuve qui établira le résultat.

• environnement, version et écran ou fonction réellement utilisés ;
• identifiants qui désignent sans ambiguïté le dossier et sa version ;
• compte, rôles et droits minimaux nécessaires, avec un propriétaire identifié ;
• cycle de session, expiration, déconnexion et politique d’authentification multifacteur (MFA) ;
• volumes, fréquences, temps de réponse et traitements asynchrones observés ;
• état attendu avant l’action, résultat vérifiable et délai normal d’apparition ;
• cas interdits, messages inconnus et seuils qui imposent l’arrêt ou la validation humaine ;
• stratégie de reprise testée, responsable de l’incident et éléments de preuve à conserver.

Sessions, MFA et interface modifiée : trois états à prévoir

Une session expirée n’est pas une erreur à masquer. Le workflow doit reconnaître la page de connexion ou l’absence de session, s’arrêter avant toute saisie et demander la réauthentification selon la politique de l’entreprise. Si un contrôle MFA exige l’intervention d’une personne, cette étape reste humaine ; l’automatisation ne doit ni récupérer un code hors du canal autorisé ni chercher à contourner le contrôle.

Une interface modifiée se traite de la même façon : l’absence d’un champ, un nouveau dialogue, un libellé déplacé ou une séquence différente invalide les repères attendus. Le scénario concerné est suspendu, la nouvelle version est examinée et les contrôles sont rejoués avant remise en service.

1. 01
   Reconnaître

   Distinguer l’écran métier attendu d’une connexion, d’un défi MFA, d’une erreur ou d’une version inconnue.

2. 02
   Ne pas improviser

   Ne pas cliquer sur un élément ressemblant, deviner un nouvel enchaînement ou étendre les droits pour poursuivre.

3. 03
   Transmettre le contexte

   Fournir à l’équipe l’action prévue, le dernier état confirmé et le point exact de l’interruption.

4. 04
   Revalider

   Tester l’authentification ou l’interface modifiée et sa preuve de résultat avant de réautoriser les écritures.

Reprendre sans répéter une action incertaine

Après une coupure réseau, une expiration de session ou un écran figé, on ne sait pas toujours si l’action a été enregistrée. Relancer immédiatement peut créer un second ordre, appliquer deux fois une modification ou joindre la même pièce en double. La reprise commence donc par une nouvelle observation, jamais par la répétition du dernier clic.

1. 01
   Geler la tentative

   Conserver la référence, les valeurs préparées, l’heure, le dernier écran confirmé et les messages observés.

2. 02
   Relire une source faisant foi

   Rechercher le dossier, son identifiant, sa version et son état par la voie autorisée la plus fiable.

3. 03
   Classer le résultat

   Distinguer succès confirmé, absence confirmée et état indéterminé ; une absence d’écran de confirmation ne suffit pas.

4. 04
   Décider la reprise

   Ne rejouer que si l’absence est établie et si la stratégie validée exclut doublon et contradiction.

5. 05
   Escalader si nécessaire

   Quand plusieurs états restent plausibles, transmettre le dossier avec les preuves disponibles et attendre une décision humaine.

Trois contenus, trois décisions différentes

Ce guide répond à une question technique : comment qualifier et contrôler une interaction lorsqu’une API ne couvre pas l’action. La page commerciale consacrée à l’automatisation TMS sans API présente, elle, l’accompagnement et le positionnement d’Axonovia ; elle ne remplace pas cette méthode de qualification.

Le guide « Automatiser son exploitation sans changer de TMS : comment décider ? » porte une décision plus large d’architecture et d’investissement : exploiter une fonction native, ajouter un complément ou envisager une migration. E02 intervient ensuite pour évaluer une voie d’intégration précise. Il ne sert ni à conclure qu’un TMS doit être conservé ni à dénigrer ses fonctions natives.