Dans un projet de modernisation SI, la qualité logicielle ne se limite pas à vérifier le bon fonctionnement d’une application. Elle permet de sécuriser l’ensemble de la chaîne de valeur : de la donnée saisie sur le terrain jusqu’à sa restitution auprès des utilisateurs finaux. Dans le secteur logistique, cette exigence est d’autant plus critique que la fiabilité des informations conditionne le suivi des marchandises, l’analyse des incidents et la prise de décision opérationnelle. Dans ce type de contexte, une démarche QA progressive, structurée et orientée risque permet de fiabiliser des flux de données complexes et de renforcer la maîtrise d’un système en évolution.

 Pourquoi la fiabilité des données est un enjeu critique dans un SI logistique

La modernisation d’un système d’information logistique ne consiste pas uniquement à remplacer une solution existante par un nouvel outil… Elle engage la continuité de service, la fiabilité des données, la qualité de l’expérience utilisateur et la capacité de l’organisation à piloter ses opérations avec confiance. Lorsque plusieurs systèmes communiquent entre eux, le risque ne se situe pas seulement dans l’application visible par l’utilisateur. Il se loge souvent dans les zones d’échange : formats de fichiers, mappings, référentiels, traitements intermédiaires, données stockées en base…

Dès lors, une information mal convertie, incomplète ou mal restituée peut avoir des conséquences directes, comme une perte de visibilité sur l’acheminement d’une marchandise, une difficulté à comprendre un incident, un ralentissement des décisions et même une multiplication des investigations entre équipes Métier et IT. Dans ce type de contexte, la QA devient un levier de maîtrise permettant de rendre les risques visibles mais aussi de structurer les validations et de donner aux équipes une lecture plus fiable de l’état réel du système.

Un SI logistique en pleine transformation, entre mise en production et évolutions

Dans le cadre de ce projet, un nouveau SI logistique devait assurer la circulation d’informations entre des systèmes opérationnels utilisés par les équipes terrain, un bus d’orchestration de données et un portail destiné aux clients finaux. La criticité venait de la nature des données restituées dans le portail : localisation des marchandises, progression de l’acheminement, incidents éventuels, points de blocage… Ces informations conditionnaient directement la visibilité offerte aux utilisateurs sur le suivi des opérations logistiques. Le projet s’inscrivait dans un environnement évolutif : une première version de la solution avait été mise en production en mars 2025, tandis que les travaux d’évolution se poursuivaient. La démarche QA devait donc se construire progressivement, en parallèle de la trajectoire projet.

Quand une erreur de transformation compromet toute la chaîne de données

Le sujet central n’était pas seulement de tester des composants techniques : il s’agissait de sécuriser la circulation, la transformation et la restitution d’informations critiques. Les systèmes sources transmettaient des fichiers plats dans un format spécifique, tandis que le portail utilisateur reposait sur des échanges JSON. Le bus d’orchestration devait donc récupérer les données, les interpréter, les transformer et les transmettre dans un format exploitable. Cette transformation n’était pas uniquement technique mais impliquait également une traduction fonctionnelle des données. Certaines informations étaient codifiées selon une logique propre aux systèmes d’origine, alors que le portail attendait une codification différente. Le risque portait donc autant sur le format que sur le sens de la donnée.

Le projet présentait également une complexité supplémentaire : l’absence d’interface graphique sur le bus d’orchestration. Les contrôles ne pouvaient pas s’appuyer sur un parcours utilisateur classique. Ils nécessitaient une analyse approfondie des fichiers, des logs, des traitements et des données en base. Le véritable enjeu était donc de transformer un risque diffus en risque maîtrisable : identifier où la donnée pouvait se dégrader, comprendre pourquoi un écart apparaissait et disposer d’éléments tangibles pour arbitrer, corriger et sécuriser les évolutions.

Une stratégie QA progressive, centrée sur les flux les plus critiques

ALDEMIA a structuré son intervention selon une approche progressive, adaptée au niveau de maturité du projet et aux priorités Métier. La première étape a consisté à cadrer une stratégie de test dans un contexte où l’activité QA était encore en construction. Plutôt que de chercher à couvrir uniformément l’ensemble du périmètre, l’effort a été concentré sur les flux les plus critiques : ceux dont la défaillance pouvait avoir un impact direct sur la qualité des informations restituées aux utilisateurs. Le périmètre de test a été défini de manière collaborative avec les parties prenantes projet, dans une approche permettant de construire une couverture cohérente, tenant compte à la fois des attentes fonctionnelles, des contraintes techniques et des priorités de livraison.

Les jeux de données ont été constitués à partir de plusieurs sources : des cas Métier représentatifs, des fichiers issus de situations réelles de production et des fichiers JSON préparés pour couvrir différents scénarios. Cette combinaison a permis de tester le système sur des cas concrets tout en ciblant les situations nécessaires à la validation des règles de transformation. Les tests API ont été conçus et exécutés avec Postman et des requêtes ont été paramétrées pour simuler les échanges entre les systèmes sources, le bus d’orchestration et les autres composants du SI. Des variables et scripts ont également été utilisés pour rendre certains fichiers dynamiques, notamment lorsque l’unicité des données devait être garantie. La traçabilité a par ailleurs constitué un axe structurant de l’intervention.

Des tags ont permis d’identifier l’origine des cas de test, mais aussi l’environnement d’exécution et la date de lancement. Les campagnes ont quant à elles été organisées dans Azure DevOps Test Plans, avec des tableaux de bord dédiés au suivi de l’avancement, des tests réalisés, des tests restants et des écarts à traiter. Enfin, l’analyse des anomalies s’est appuyée sur plusieurs outils complémentaires. Les logs permettaient de suivre le déroulement des traitements, les contrôles en base de vérifier la conservation et la transformation des données, tandis qu’Azure DevOps centralisait la déclaration, la priorisation et le suivi des anomalies.

 Des flux mieux sécurisés et des anomalies plus faciles à diagnostiquer

La mission a permis de poser un cadre QA structurant dans un environnement complexe, évolutif et fortement dépendant de la qualité des données. Les tests ont contribué à sécuriser progressivement les flux critiques, en vérifiant la bonne transformation des données entre les systèmes sources, le bus d’orchestration et le portail utilisateur. Ils ont également permis de limiter les risques de perte d’information, d’erreur de correspondance ou de rejet de fichier.

L’intervention a renforcé la capacité des équipes à analyser les écarts. Grâce à l’exploitation croisée des fichiers, des logs et des données en base, il devenait possible de mieux distinguer une donnée source erronée, un défaut de format, un problème de mapping, une règle non respectée, un paramétrage incorrect ou une anomalie applicative. Cette capacité d’analyse a facilité les échanges entre les équipes projet et contribué à une priorisation plus précise des actions correctives.

La mission a également permis de constituer progressivement un patrimoine de tests de non-régression, principalement orienté vers les fonctionnalités déjà en production. À date, la répartition estimée était d’environ 70 % de tests manuels, majoritaires sur le périmètre en construction, et 30 % de tests automatisés, davantage concentrés sur le périmètre en production. Des templates de reporting ont aussi été mis en place pour structurer le suivi de l’avancement, des résultats de test et des points de blocage. Ces supports ont renforcé la visibilité des parties prenantes et contribué à formaliser le pilotage QA.

Les enseignements clés pour fiabiliser un SI fondé sur des échanges de données

Ce cas montre qu’un projet SI fondé sur des échanges de données complexes ne peut pas être sécurisé uniquement par des tests d’interface. Lorsque la valeur du système repose sur la qualité de la donnée, il est nécessaire de tester toute la chaîne : collecte, transformation, transmission, stockage et restitution. Il met également en évidence l’importance d’une approche orientée risque, puisque dans un environnement évolutif, la priorité n’est pas de tout tester au même niveau mais bien d’identifier les flux dont la défaillance aurait le plus fort impact Métier.

La traçabilité apparaît aussi comme un facteur clé de maîtrise : elle ne sert pas seulement à documenter les tests mais permet bel et bien de comprendre l’origine des anomalies, d’objectiver les écarts et de faciliter les arbitrages. Enfin, la constitution progressive d’un patrimoine de non-régression représente un levier essentiel pour sécuriser les évolutions futures, en particulier lorsque le projet combine des usages déjà en production et des fonctionnalités encore en construction.

Sécuriser les flux aujourd’hui pour fiabiliser les évolutions de demain

Dans une modernisation SI logistique, la qualité logicielle joue un rôle central : elle sécurise les données, rend les risques visibles et renforce la capacité de l’organisation à piloter ses décisions sur des bases fiables. En structurant progressivement la stratégie de test, en priorisant les flux critiques et en renforçant la traçabilité, ALDEMIA a contribué à fiabiliser un dispositif au cœur de la chaîne logistique. Pour les organisations confrontées à des enjeux similaires, l’objectif est clair : ne pas attendre la mise en production pour découvrir les écarts, mais mettre en place une démarche qualité capable de sécuriser les flux, les décisions et les évolutions futures.