Mettre AX sur un téléphone ne veut pas dire rapetisser AX

Mettre Dynamics AX sur un téléphone ne devrait pas vouloir dire rapetisser tous ses menus. Un ERP contient trop de champs, d’états et d’exceptions pour un écran utilisé debout. Je choisirais une décision précise, par exemple approuver une commande bloquée, et j’exposerais uniquement les données nécessaires à cette décision.

Le téléphone ne devrait pas parler directement à la base AX. Il appelle une API derrière une passerelle. Le service authentifie l’utilisateur, vérifie son rôle, lit le document par les interfaces applicatives d’AX et retourne une représentation mobile. L’approbation repart avec l’identifiant et la version lue.

Une approbation avec concurrence

Le flux pourrait être :

1. récupérer commande 471, état à approuver, version 12;
2. afficher fournisseur, montant, écart et pièces utiles;
3. recueillir décision et commentaire;
4. envoyer commande=471, version=12, décision=approuver;
5. relire côté serveur et appliquer dans une transaction AX;
6. retourner version 13 et numéro d’audit.

Si une autre personne a modifié le montant et produit version 13 entre les étapes, le serveur refuse l’approbation de la version 12. Le téléphone recharge et montre la différence. Sans contrôle optimiste, il approuverait une commande différente de celle affichée.

Le mode hors ligne doit être choisi selon le risque. On peut mettre en cache une liste en lecture, mais une approbation financière ne devrait pas sembler terminée sans confirmation. L’interface distingue brouillon local, envoi en attente et appliquée dans AX. Une clé idempotente protège un double clic ou une réponse perdue.

Le petit appareil agrandit la frontière de sécurité

Le jeton d’accès est court, stocké dans le mécanisme sécurisé de l’appareil et révocable. L’API autorise l’objet et l’action, pas seulement le menu. Les données locales sont minimisées et chiffrées; une pièce jointe sensible ne doit pas rester dans le dossier Photos. Une solution de gestion peut exiger verrouillage et couper l’accès d’un téléphone perdu.

Le réseau mobile impose timeout, reprise et compression. Une liste de cent commandes n’a pas besoin de tous les champs comptables. La pagination et un cache conditionnel réduisent le trafic. Le service doit protéger AX d’une vague de rafraîchissements par quotas et files.

Si AX est en maintenance, l’API retourne un état explicite et conserve seulement les commandes sûres à reprendre. L’utilisateur voit le délai; le support voit la corrélation. Une file de rejets avec propriétaire empêche les approbations de disparaître entre mobile et ERP.

Réduire les données avec une projection dédiée

L’API mobile ne devrait pas sérialiser l’objet AX complet. Une projection d’approbation contient numéro, fournisseur, montant, devise, écart, version et deux liens de document. Elle est calculée côté serveur et mise en cache brièvement selon l’utilisateur. Cette réduction limite réseau, exposition et couplage au modèle interne. Si AX ajoute un champ sans rapport, le téléphone ne change pas. Le cache porte un ETag et n’est jamais utilisé pour autoriser l’écriture. Au moment d’approuver, le service relit AX et vérifie les règles. La projection accélère la lecture sans devenir une seconde source de vérité.

Je ferais donc concevoir l’écran à partir d’une seule décision, puis testerais perte réseau, double envoi, changement concurrent, rôle retiré et appareil perdu. La mobilité apporte de la valeur quand elle raccourcit un temps d’attente précis sans cacher l’état de l’ERP.

Mise à jour de 2026

Les versions Dynamics AX 2012 ne sont plus soutenues depuis 2022 ou 2023, selon l’édition. Elles ont notamment été remplacées par Dynamics 365 Finance et Supply Chain Management. Avant de financer une nouvelle interface mobile autour d’un ancien AX, il faut donc évaluer la migration de la plateforme elle-même. Microsoft publie les dates de soutien et les orientations de migration.