Traçabilité : définir les événements avant de choisir les lecteurs

Partir d’une recherche réelle

Lorsque le service client cherche un colis, quelles informations lui manquent exactement ? Sa dernière observation, son emplacement ou sa prise en charge par un partenaire ? Notre méthode consiste à reconstituer un parcours court, de l’expédition à la réception, avec les équipes concernées. Pour chaque étape, notez la décision qui dépend de l’information. Cela permet de distinguer un simple suivi interne d’un besoin de partage entre organisations. Le choix d’un lecteur ou d’une étiquette vient ensuite.

Comprendre le rôle d’EPCIS

GS1 décrit EPCIS comme un standard de partage d’événements de traçabilité. Ces événements expriment l’objet concerné, le moment, le lieu et le contexte métier ; la version 2.0 prend également en charge des informations issues de capteurs. Le vocabulaire CBV aide à donner un sens commun aux valeurs employées. GS1 précise que le standard n’impose pas un support unique et peut accompagner codes-barres ou RFID. Choisir EPCIS n’équivaut donc pas à imposer immédiatement un changement de tous les équipements de lecture.

Écrire un contrat d’événement

Notre proposition : définissez ensemble un exemple d’expédition et un exemple de réception. Précisez l’identifiant attendu, le lieu, le moment observé, l’auteur du système source et le sens du statut. Décidez aussi comment reconnaître une correction ou un envoi reçu deux fois. Cette convention métier doit être comprise par les partenaires avant l’intégration. Une donnée parfaitement transmise peut rester inutilisable si « reçu » signifie entrée sur le quai chez l’un et contrôle terminé chez l’autre.

Cas pratique : une réception partielle transmise en retard

Un entrepôt reçoit une partie d’une expédition puis transmet l’événement après une interruption de communication. Notre scénario de travail demande de répondre à deux questions différentes : quand l’opération a-t-elle eu lieu et quand l’information est-elle devenue disponible dans le système ? La documentation GS1 distingue le moment de l’événement du moment de son enregistrement dans le référentiel. Nous proposons de conserver cette distinction dans les écrans et les échanges entre partenaires, pour ne pas déplacer artificiellement une réception à l’heure de son import.

Reconstituez le cas avec les identifiants et quantités convenus. Vérifiez ce qu’affiche le suivi avant l’arrivée du message, après sa réception puis après un éventuel correctif. Une expédition ne doit pas paraître entièrement reçue parce qu’un seul événement de réception existe. Faites préciser au métier comment une réception partielle est représentée et quelle action reste attendue. Lorsque des capteurs sont ajoutés, demandez également à quel instant leur observation se rapporte. Un relevé joint à un événement n’est pas nécessairement une mesure effectuée exactement au moment de la réception. L’enjeu est de présenter une chronologie explicable, qui conserve l’écart entre observation physique et circulation de l’information.

Tester les trous du parcours

Préparez un pilote avec une réception partielle, un retard de transmission et une lecture manquante. Vérifiez ce que l’utilisateur voit et comment il distingue absence d’événement et absence de mouvement. Ce protocole est notre proposition de réception, pas une garantie fournie par le standard. Comparez les informations échangées aux constats opérationnels et limitez le partage aux partenaires qui en ont besoin. Le résultat attendu est une histoire compréhensible du parcours, avec des incertitudes visibles, plutôt qu’une chronologie artificiellement complète.

Prévoir les corrections sans effacer l’histoire

GS1 documente des déclarations d’erreur et des événements correctifs. Cette possibilité illustre un principe important : une information initialement publiée peut devoir être rectifiée tout en restant traçable. Notre conseil de préparation est de convenir avec les partenaires du traitement d’un événement erroné avant le premier échange réel. Qui signale l’erreur, quel identifiant permet de la retrouver et comment les consommateurs de la donnée en seront-ils informés ?

Ne confondez pas correction et retransmission. Un même message envoyé deux fois après une reprise technique ne décrit pas forcément deux mouvements physiques. Faites démontrer le comportement attendu sur des jeux d’exemples par l’intégrateur, puis demandez au métier d’interpréter le résultat affiché. Précisez aussi la disponibilité des référentiels de lieux et de produits : un code techniquement valide mais inconnu du partenaire reste difficile à exploiter. Nous suggérons de tenir un registre commun des points non résolus, avec un responsable et une convention provisoire visible. Limitez enfin la diffusion aux données nécessaires au parcours retenu. Un standard d’échange fournit une structure et un langage ; la qualité des constats, les droits de partage et la compréhension mutuelle restent des responsabilités concrètes à organiser.