Intégration de Dynamics 365 avec le RTLS et la RFID.

L’élément le plus utile à comprendre dans la gestion d’entrepôt D365 est le contenant (licence plate). C’est l’identifiant que le système utilise déjà pour une unité de manutention (une palette, un conteneur, un carton), et c’est le point d’ancrage naturel d’une étiquette physique.

Une cause d’échec fréquente des programmes RFID dans D365 est l’identité parallèle. L’étiquette reçoit son propre numéro, une table de correspondance apparaît, et dès lors chaque écart devient un débat sur le système qui a raison. Encoder le numéro de contenant dans l’étiquette, ou associer l’étiquette au contenant au moment de sa création, évite toute une catégorie de problèmes.

Lorsque les contenants ne sont pas utilisés (pièces sérialisées, outils, actifs réutilisables), la question devient : quelle entité D365 existante porte l’identité ? Mieux vaut trancher avant de spécifier le moindre matériel.

D365 offre plusieurs points d'entrée. Choisir le mauvais est une raison fréquente pour laquelle un projet de localisation fonctionne en pilote puis s'effondre en production.

Le schéma qui tient : la télémétrie arrive dans Azure, est réduite aux événements qui comptent, et seuls ces événements atteignent D365. Une mise à jour de position chaque seconde n'est pas un événement métier. Une palette qui passe de la zone de préparation à la zone d'expédition, si.

Il vaut la peine de le dire clairement, car c'est proposé étonnamment souvent. D365 est un système transactionnel doté d'un framework de traitement par lots et de limites d'API. Ce n'est pas une base de séries temporelles.

Six cents tags émettant à 1 Hz, cela représente environ 52 millions d'événements par jour (600 × 86 400 secondes). La bonne architecture maintient entièrement ce flux en dehors de l'ERP et n'envoie à D365 que les changements d'état : arrivées, départs, achèvements, exceptions. Tout le reste a sa place dans un data lake, pour l'analyse.

C'est aussi ce qui préserve la trajectoire de mise à niveau. Plus votre conception de localisation dépend de personnalisations dans D365, plus chaque mise à jour de la plateforme devient pénible.

Réception. Une lecture au quai peut créer ou confirmer le numéro de contenant (licence plate) et déclencher le travail de rangement, en remplaçant un scan manuel plutôt qu'en ajoutant une étape à côté.

Rangement et exactitude des emplacements. D365 sait où il a dirigé le stock. La localisation vous dit où il est réellement allé. Rapprocher les deux est souvent le gain mesurable le plus rapide.

Inventaire tournant. La RFID transforme le comptage, d'un événement planifié en un processus continu en arrière-plan, ce qui change la façon dont le travail de comptage est configuré au lieu de simplement l'accélérer.

En-cours. Les passages d'une zone à l'autre deviennent de véritables signaux d'avancement, au lieu que les opérateurs confirment les étapes après coup.

Cour et quai. La position des remorques et des conteneurs est généralement totalement absente de l'ERP, c'est pourquoi c'est souvent là qu'il est le plus facile de démontrer la valeur.

D365 Warehouse Management peut fonctionner avec un ERP tiers grâce au mode Warehouse management only de Microsoft. Si c'est la configuration de votre parc applicatif, l'intégration comporte deux sauts au lieu d'un, et la question de l'identification devient plus importante, pas moins.

Si D365 n'est pas encore en production, la question du séquencement compte davantage que la technologie. Une conception de localisation bâtie autour d'un processus d'entrepôt lui-même sur le point de changer devra être refaite. La réponse habituelle consiste à spécifier le modèle de données dès maintenant, à arrêter la stratégie d'identification et à reporter les décisions de déploiement qui dépendent du nouveau processus jusqu'à ce qu'il soit stabilisé.

• Le tag porte-t-il le numéro de contenant (licence plate), ou y est-il associé ?
• Quels événements sont de véritables événements métier, et lesquels relèvent de la télémétrie ?
• À qui appartient la couche d'intégration : votre partenaire ERP, le fournisseur de localisation ou vous ?
• Les données de localisation sont-elles un jour réécrites dans D365, ou servent-elles seulement à informer ?
• Que se passe-t-il lorsque les deux divergent, et lequel fait foi ?

Cette dernière question pèse plus lourd que n'importe quel choix technologique. La trancher dès la conception évite des reprises pendant les tests.

Nous ne mettons pas en œuvre Dynamics 365 : nous conseillons d'abord, donc nous n'avons aucune raison d'orienter l'intégration dans un sens ou dans l'autre. Nous spécifions ce que doit être le modèle de données, quels événements comptent et ce que le fournisseur de localisation et le partenaire ERP doivent chacun livrer, avant que l'un ou l'autre ne remette un devis.

À lire aussi : intégration SAP EWM, la vue d'ensemble des intégrations et précision des stocks.

Les informations sur les normes et les fournisseurs présentées sur cette page proviennent des sources publiques ci-dessous, vérifiées le 25 septembre 2026. Les déclarations des fournisseurs sont présentées comme leurs propres affirmations.

1. Microsoft Learn : présentation des événements métier (applications Finance et Opérations)
2. Microsoft Learn, Data management : data entities and data packages
3. Microsoft Learn : Priority-based throttling (API service protection)
4. Microsoft Learn : Dual-write overview
5. Microsoft Learn : présentation du mode Gestion d'entrepôt uniquement
6. Microsoft Learn : réception par plaque d'immatriculation via l'application mobile Warehouse Management
7. Microsoft Learn : Qu'est-ce qu'Azure IoT Hub ?
8. Microsoft Learn : Qu'est-ce qu'Azure Event Hubs ?
9. Microsoft Learn : Qu'est-ce que Microsoft Fabric ?

Dernière mise à jour : 4 octobre 2026