Pourquoi la logistique sous température dirigée a besoin de données d'événements, et pas seulement de moyennes

La logistique sous température dirigée repose sur une hypothèse : un relevé propre signifie une expédition sûre. Ce n'est pas toujours le cas. L'envoi d'un distributeur pharmaceutique est refusé. Le relevé semblait irréprochable : 18 heures à 3,2 °C. Mais l'auditeur a trouvé 20 minutes à quai, porte ouverte, un pic que les rapports de trajet standard n'ont jamais détecté. La plupart des systèmes affichent des tracés et des seuils. Trips Intelli, une application gratuite et open source de Navixy, reconstitue un trajet comme celui-ci sur une seule chronologie, avec les arrêts, les ouvertures de porte et les relevés de capteurs au même endroit.

Souvent, les données existent, mais elles sont réparties dans trois tables à trois résolutions différentes, et rien ne les relie pour reconstituer cet instant. Les données de sinistres de TT Club vont dans le même sens. Plus de la moitié des incidents en température dirigée proviennent d'instructions de manutention mal communiquées et de réglages de température erronés, tandis que les pannes ou dommages d'équipement représentent environ un quart. Dans ce cas, le groupe frigorifique a tenu toute la nuit. La marchandise a été exposée pendant 22 minutes à quai.

Cet article montre comment une couche d'analytique peut répondre à la question de l'auditeur : que s'est-il exactement passé à quai à 14h22 ?

Les changements d'état sont là où les expéditions sensibles à la température échouent réellement

Les recommandations de l'OMS sur le stockage et le transport des produits pharmaceutiques sensibles au temps et à la température (TRS 961, annexe 9) traitent ces points par des exigences sur les quais de chargement, la qualification des itinéraires de transport et le suivi de la température en transit. Lors d'un trajet routier réfrigéré, la marchandise est la plus exposée aux points de manutention :

• la période initiale de pré-refroidissement,
• le chargement,
• les ouvertures de porte pendant la livraison,
• le temps d'immobilisation lors des arrêts multiples,
• et les rétentions en douane ou aux frontières.

Ce ne sont pas les parties du trajet où un enregistreur de température excelle. Elles sont souvent imprévues et faciles à manquer dans des données moyennées, et c'est précisément à ces moments que la chaîne du froid risque le plus de se rompre.

La conséquence réglementaire en découle logiquement. Les bonnes pratiques de distribution de l'UE (2013/C 343/01) exigent que les excursions de température pendant le transport soient signalées au distributeur et au destinataire et fassent l'objet d'une investigation selon une procédure définie. Le distributeur doit également pouvoir démontrer que les médicaments n'ont pas été exposés à des conditions susceptibles d'en compromettre la qualité. La GUI-0069 de Santé Canada (lignes directrices sur le contrôle environnemental des médicaments pendant le stockage et le transport) fixe des attentes similaires pour les médicaments en transit. Une moyenne horaire « conforme » n'apporte pas grand-chose à un enquêteur lorsque l'excursion a duré 22 minutes.

Pour les produits frais et les chaînes du froid alimentaires, le texte réglementaire diffère, mais la réalité opérationnelle est identique : une expédition refusée dans un centre de distribution pour des raisons de température fera l'objet d'une investigation événement par événement, et non moyenne par moyenne.

Le problème d'intégration de la logistique sous température dirigée

Voici le problème de données concret. Un déploiement télématique moderne produit généralement trois flux : un tracé de positions GPS, un journal de capteur de température et des événements de télémétrie tels que le contact mis/coupé et l'ouverture/fermeture de porte.

Dans la plupart des systèmes de flotte, ces flux vivent dans des tables séparées ou sont interrogeables à des résolutions différentes. Selon la configuration de l'appareil, les relevés de température et les positions GPS sont souvent enregistrés à des intervalles différents. Les événements de porte sont horodatés à la seconde mais sont souvent stockés dans un schéma conçu pour l'alerte en temps réel, et non pour la corrélation a posteriori.

L'événement d'ouverture de porte qui a causé l'excursion se trouve à quatre lignes du relevé de température qui l'a enregistré. Les relier suppose de connaître les limites du trajet, le contexte de géozone de l'arrêt et les identifiants de canal de capteur qui correspondent à un compartiment de charge précis. La plupart des organisations soit ne réalisent pas du tout cette jointure, soit engagent un intégrateur pour la construire une fois pour un seul client et ne la généralisent jamais.

C'est là le manque. Ce n'est pas un problème de matériel. C'est un problème d'architecture de données.

Navixy IoT Query, une plateforme d'analytique de données, expose l'ensemble des données télémétriques et métier sous forme de connexion PostgreSQL directe : données de suivi, relevés de capteurs, événements de géozone, états personnalisés et métadonnées de trajets dans un schéma que vous pouvez interroger en SQL standard. IoT Query rend la jointure possible. Trips Intelli rend l'investigation exploitable.

Qu'est-ce que Trips Intelli

L'application Trips Intelli couvre la couche manquante de corrélation d'événements au niveau du trajet, en tant qu'application complète d'intelligence des trajets. Elle ne possède pas sa propre couche d'ingestion de données. Elle se connecte à la même surface PostgreSQL que peut interroger tout utilisateur Navixy disposant d'un accès à IoT Query, et exécute un pipeline de traitement en plusieurs étapes sur ces données pour produire des analyses de trajet et des dossiers de conformité.

Le choix d'architecture compte pour celui qui construit : aucune API propriétaire à négocier, aucun entrepôt de données intermédiaire à maintenir et aucun pipeline de réingestion à garder synchronisé. Le traitement s'effectue sur des données qui existent déjà.

Cinq questions d'investigation, traitées au niveau du trajet

Un auditeur de conformité examinant une expédition sous température dirigée posera une catégorie précise de questions.

Non pas « Quelle était la température moyenne ? », mais :

• Où se trouvait le véhicule quand le capteur a franchi le seuil ?
• La porte était-elle ouverte à ce moment-là ?
• S'agissait-il d'un arrêt planifié ou d'une déviation imprévue ?
• Ce conducteur enchaîne-t-il des heures supplémentaires ?
• Quel est le profil de risque de ce trajet comparé aux autres sur le même corridor ?

Aucune de ces questions ne peut trouver de réponse à partir d'une simple bande de température et d'un journal GPS. La conformité de la chaîne du froid doit être comprise dans le contexte de l'ensemble du trajet, et non comme un graphique de température isolé. Trips Intelli est conçu pour réunir itinéraire, température, événements de porte, arrêts et statut du trajet dans un même contexte d'investigation.

Segmentation des trajets avec stationnement classifié. Le pipeline segmente chaque flux de positions en trajets et arrêts, classe chaque arrêt comme MOVING, PARKING ou ENGINE_ON_PARKING, et y associe durée et contexte de géozone. Un arrêt de 22 minutes au quai de chargement d'un centre de distribution est un événement distinct et étiqueté, et non un trou dans le tracé GPS.

Conformité au corridor d'itinéraire. Chaque trajet est vérifié par rapport à un corridor d'itinéraire défini. Les déviations sont classées par type : hors itinéraire, arrêt non autorisé, avec le segment et l'horodatage du départ. Elles peuvent aussi être notées par gravité, aidant les analystes à distinguer une déviation mineure du corridor d'un événement nécessitant une investigation immédiate. Un conducteur qui a fait un détour imprévu par la cour d'un entrepôt non réfrigéré est un cas différent d'un conducteur qui s'est arrêté à un cross-dock planifié.

Surveillance des seuils de capteur dans le contexte de géozone. La température, le niveau de carburant, l'humidité ou tout capteur disponible dans le schéma IoT Query peuvent être surveillés par rapport à des seuils min./max. configurables. L'alerte inclut le relevé du capteur, l'horodatage et la géozone dans laquelle se trouvait le véhicule à ce moment. Vous pouvez ainsi répondre à « L'excursion a-t-elle eu lieu pendant le chargement à l'Entrepôt d'origine B, ou en transit ? » avec une seule requête plutôt qu'une jointure manuelle.

Corrélation de l'état de la porte avec la localisation et la température. Les événements d'ouverture de porte sont corrélés avec la position du véhicule et le relevé de température au même horodatage. Au lieu de consulter des graphiques séparés, un enquêteur peut suivre une chronologie multicouche qui combine température, état de la porte, position sur l'itinéraire et statut du trajet dans une même vue. Vous pouvez voir, par exemple, que la température est passée de 3 °C à 11 °C pendant un événement de porte ouverte de 14 minutes aux coordonnées [x, y], alors que le véhicule se trouvait hors de son corridor d'itinéraire prévu. C'est le type de séquence qu'une investigation réglementaire doit reconstituer.

Score d'anomalie par ML avec explication en clair. Chaque trajet reçoit un score de risque d'un modèle IsolationForest entraîné sur l'historique de trajets propre à la flotte. Les trajets anormaux ressortent avec une explication en clair : « Hors quart / de nuit », « Durée inhabituelle pour ce corridor » ou « Motif de déviation de capteur incohérent avec l'itinéraire ». Un analyste peut prioriser les investigations sans lire chaque enregistrement brut. Le score est un indicateur probabiliste ; un trajet signalé mérite un examen, et non une conclusion défavorable automatique.

En savoir plus sur les différents niveaux de rapports de trajets dans Navixy.

La vue qui transforme la télémétrie brute en dossier d'investigation

La vue principale de l'application est un tableau de trajets avec un panneau de filtres, une carte intégrée et une chronologie de statuts. Un responsable conformité examinant une expédition signalée peut filtrer par excursion de capteur, événement de porte ou déviation d'itinéraire, sélectionner le trajet et voir la chronologie reconstituée complète dans une seule vue : position GPS, canal de température, état de la porte et marqueurs d'événements annotés. L'export en XLSX se fait en un clic.

C'est l'interface qu'utilise réellement la personne qui dépose une réponse réglementaire ou négocie une réclamation auprès d'un transporteur. Le développeur qui l'a construite travaille au niveau des requêtes ; le responsable conformité qui l'utilise travaille au niveau des événements. Tous deux regardent les mêmes données.

Résultats par rôle : ce qui change vraiment

Trips Intelli produit un unique dossier au niveau du trajet, corrélant les données GPS, capteurs et événements dans une seule vue. Ce qui change, c'est la partie du dossier que lit chaque rôle.

Pour le responsable conformité : une déviation de température peut être rattachée à l'événement précis de chargement ou de porte qui l'a causée, avec horodatage, localisation et durée. Les BPD de l'UE et la GUI-0069 de Santé Canada exigent exactement cela avant une décision de disposition. Le dossier était auparavant assemblé manuellement à partir de trois systèmes ; c'est désormais une seule vue filtrée.

Pour le répartiteur : les trajets hors quart, les conducteurs en heures supplémentaires et les itinéraires hors corridor apparaissent dans le même tableau que les excursions de température. Un conducteur effectuant un quart de nuit sur un corridor de livraison pharmaceutique et un conducteur avec un arrêt non autorisé dans une supérette sont tous deux visibles sans extraire de rapports distincts d'un système séparé.

Pour le gestionnaire de flotte : les scores d'anomalie par ML rendent la revue hebdomadaire gérable. Une flotte de 200 véhicules génère 1 400 trajets par semaine. Lire chaque enregistrement n'est pas une option. Les 12 premiers par score de risque, examinés le lundi matin, captent les incidents qui méritent attention, y compris ceux où le relevé de température aurait semblé correct.

Pour l'intégrateur de systèmes qui construit sur la pile : le schéma IoT Query qu'elle interroge est le même schéma disponible pour tout développeur qui construit sur Navixy. Ajouter un nouveau canal de capteur, un seuil propre à une réglementation ou un corridor d'itinéraire propre à un client est un changement de configuration et, dans certains cas, une modification SQL.

Trips Intelli produit le dossier et la classification de risque. Il ne certifie pas la conformité, ne garantit pas l'acceptabilité d'une expédition et ne remplace pas la décision de disposition qui revient à une personne qualifiée au titre de la réglementation applicable.

Premiers pas avec Trips Intelli : le schéma est déjà là

IoT Query est la surface de connexion PostgreSQL que Trips Intelli interroge. Si l'activité de logistique sous température dirigée du client tourne déjà sur des données de flotte Navixy (positions GPS, relevés de capteurs, événements de géozone), le schéma est déjà là. Vous n'avez pas besoin de construire une couche d'ingestion.

C'est exactement le genre de problème auquel vos propres clients sont déjà confrontés : une expédition refusée sur des preuves ténues, une équipe conformité posant des questions auxquelles les données de flotte ne peuvent pas encore répondre. Trips Intelli vous donne une réponse toute prête : une solution que vous pouvez présenter à tout client qui transporte des marchandises sensibles à la température, sans construire vous-même la logique de corrélation d'événements.

C'est une chose de plus que vous pouvez offrir à un client sans ajouter de travail d'ingénierie.