pourquoi

Que signifie “tester” sa plateforme EDI ?

Avant d’aller plus loin, il convient en premier de bien définir les différentes activités de test. Dans le test informatique, on distingue deux activités de “test”, qui s’appliquent également pour les plateformes EDI : la validation et la non-régression.

La validation consiste à s’assurer que des évolutions ou corrections apportées à sa plateforme EDI sont correctes par rapport aux spécifications de ces changements. L’objectif est de répondre à la question : est-ce que l’implémentation des changements est correcte ? Par exemple, est-ce que ce nouveau mapping applique la règle métier associée ?

La non-régression consiste à s’assurer que les changements introduits dans sa plateforme EDI n’ont pas entraîné de modifications de comportement non désirées sur les fonctionnalités existantes. L’objectif est de répondre à la question : est-ce que ma plateforme EDI continue de fonctionner correctement suite à l’implémentation des changements ? Par exemple, est-ce que tous mes flux existants se comportent comme attendu ? On peut également vouloir vérifier que les aspects non-fonctionnels de la plateforme (performance, charge, sécurité) sont toujours corrects.

Quels bugs peut-on rencontrer dans une plateforme EDI ?

Selon les contextes, il est plus ou moins fréquent d’apporter des modifications à sa plateforme EDI. Les cas le justifiant sont néanmoins nombreux : ajout d’un nouveau partenaire, modification d’une règle métier, mise à jour de son ERP ou WMS, migration de plateforme ou encore changement de serveur.

 Tester ces modifications avant la mise en production (MEP) est indispensable pour détecter :

  • d’éventuels problèmes fonctionnels ou non-fonctionnels
  • les impacts de ces changements sur les flux existants et les partenaires associés

Cette activité de test va permettre de prendre des mesures correctives qui éviteront des pertes d’informations, susceptibles de perturber la supply chain ou la facturation. Cela peut également permettre de détecter les partenaires qui pourraient être impliqués par des changements dans des flux (mapping, communication), afin de les prévenir des modifications à apporter de leur côté avant la MEP.

Plusieurs types de bugs peuvent être rencontrés dans une plateforme EDI, qui ont des conséquences potentiellement importantes sur les activités de l’entreprise.


Faut-il tester sa plateforme EDI ?

Il est possible de classer les plateformes EDI en 3 catégories. La classification suivante est proposée par GS1 :

  • EDI Web : La plateforme est hébergée par un prestataire, et non intégrée dans le SI de l’entreprise (pas de lien électronique avec l’ERP par exemple). Les besoins spécifiques sont développés par le prestataire pour les échanges B2B.
  • EDI ASP (Application Service Provider) : La plateforme EDI est hébergée et managée par un prestataire. Elle s’intègre dans le SI de l’entreprise. Le prestataire effectue les développements de besoins spécifiques à l’entreprise, que ce soit pour l’intégration dans le SI comme pour les échanges B2B.
  • EDI in situ : L’entreprise gère les développements, la maintenance et l’infrastructure de sa plateforme EDI.

Dans ces différents cas, les activités de test ne sont pas les mêmes. Pour une solution EDI Web, il est uniquement nécessaire de recetter les flux pour s’assurer qu’ils sont fonctionnellement corrects. Les performances, la charge, la sécurité et autres aspects de robustesse sont assurés par le prestataire.

Dans le cas d’un EDI ASP, les besoins de test seront plus importants. Comme pour l’EDI Web, il faudra s’assurer que les règles métier sont correctement mises en place, et en plus que l’EDI s’intègre correctement avec les différents éléments de son SI. Les performances, la charge, la sécurité et autres aspects de robustesse sont assurés par le prestataire.

Enfin, pour un EDI in situ, il va falloir effectuer des tests plus poussés. En plus de ceux concernant les règles métier et l’intégration, il faut également s’assurer que la plateforme EDI répond bien aux besoins non-fonctionnels (performance, charge et sécurité).

Dans quelles situations tester sa plateforme EDI ?

Il y a plusieurs situations qui imposent de tester sa plateforme EDI :

  • Une migration d’une plateforme EDI vers une autre plateforme EDI ou une mise à jour (montée de version/upgrade) de son progiciel EDI.
  • Une modification fonctionnelle d’une partie de sa plateforme EDI (règle métier, ajout ou modification de partenaire).
  • Un changement dans une ou plusieurs application(s) de son SI s’intégrant avec son EDI, telle que l’ERP, le WMS ou le CRM.
  • Un changement de l’environnement matériel (serveur, OS) ou réseau (firewall) de sa plateforme EDI.

Dans le cas d’une migration EDI ou d’une mise à jour importante du progiciel de sa plateforme EDI, il est important de s’assurer que la nouvelle plateforme EDI va se comporter de manière similaire à la précédente, autant fonctionnellement (traitement de la donnée, communication) que non fonctionnellement (performance et support de la charge). 

Pour une modification fonctionnelle de la plateforme EDI, il va falloir d’abord vérifier que l’ajout ou les changements sont fonctionnellement corrects par rapport aux spécifications du métier. Ensuite, il faut s’assurer que les changements n’ont pas d’effets de bord sur les autres flux et mappings. Ce dernier cas est très dépendant de l’architecture de la plateforme : s’il y a du code partagé ou des règles métier dans le mapping, alors il faut s’assurer de l’absence de régression pour tous les flux impactés.

Un changement dans le SI (upgrade de l’ERP, ajout d’un WMS, migration du CRM) peut aussi avoir des impacts sur les flux entrants et sortants. On va chercher dans ce cas à s’assurer que la plateforme EDI s’intègre toujours correctement dans le SI.

Enfin, une mise à jour de l’environnement matériel et réseau de la plateforme EDI nécessite de s’assurer que le nouveau matériel n’a d’impact négatif ni sur les performances générales (temps de réponse, charge, sécurité) ni sur les connexions utilisées par les flux.

Quels bénéfices ?

En leur faisant gagner de nouveaux clients, en optimisant la supply chain ou réduisant les coûts liés au traitement de données, l’EDI permet aux entreprises de rester compétitives et de croître plus rapidement. À condition que la plateforme EDI soit toujours opérationnelle et performante !

Tester sa plateforme EDI est donc indispensable afin de garantir qu’indépendamment des changements effectués avant une nouvelle mise en production, les flux EDI continueront d’être correctement traités. Suivant les enjeux et la maturité de l’équipe en charge des flux EDI, il peut être nécessaire de s’outiller pour tester sa plateforme EDI efficacement. Cela permettra de diminuer les coûts associés à ces activités, d’améliorer la qualité de la plateforme EDI et d’augmenter la productivité des équipes de développement.

Si vous cherchez à vous outiller pour l’automatisation des tests de votre plateforme EDI, n’hésitez pas à consulter ce que nous proposons et contactez-nous pour échanger sur vos besoins.

Share