GMP : une application web métier toujours pérenne 6 ans après ?

Depuis le lancement initial du projet et la précédente étude de cas, nous avons été témoins d’une évolution significative dans la façon dont les utilisateurs interagissent avec l’application et avons été confrontés à diverses problématiques.

Notre approche agile a été fondamentale pour le succès du projet, car elle nous a permis de rester flexibles et réactifs face aux besoins et usages des utilisateurs. Au travers de ces quelques points suivants, nous expliquerons notre démarche pour quelques cas d’usage importants que nous avons pu rencontrer.

Suite à l’adoption de l’application par les clients de GMP, des entreprises de transport routier, nous avons très rapidement identifié des usages abusifs. Afin d’être le premier à pouvoir réserver un créneau de passage en douane, certaines entreprises ont développé des « cliqueuses », programmes capables de cliquer sur le bouton de réservation plus rapidement qu’un humain. Le recours à de telles pratiques pose plusieurs problèmes :

• Cela provoque une augmentation significative du trafic sur nos serveurs, avec des millions de requêtes par jour, car chaque cliqueuse envoie jusqu’à plusieurs requêtes par seconde. Sans régulation de ce trafic, le serveur pourrait subir un ralentissement voire une paralysie, comme lors d’une attaque par déni de service (DDoS)
• Cela pose un problème d’équité, car les clients les plus modestes n’ont pas les moyens de recourir à de tels outils, se retrouvant alors sans disponibilité de rendez-vous.

Le problème est épineux pour GMP : elle ne peut pas se permettre d’empêcher ses gros clients de réserver les meilleurs créneaux, mais elle ne peut pas non plus laisser à ses clients qui n’utilisent pas de cliqueuse les créneaux les moins avantageux.

Pour résoudre ces problèmes, nous avons adopté une approche en deux étapes :

1. Bloquer automatiquement les utilisateurs abusifs pendant quelques minutes, grâce à l’outil Rack Attack. Parallèlement, nous avons mis en place un tableau de bord pour les administrateurs, offrant une vue en temps réel des comptes abusifs, de leurs temps de blocage, de leurs adresses IP, etc.
2. Malgré ces mesures, des problèmes et des contournements potentiels persistaient, comme le réglage des cliqueuses juste sous la limite de requêtes autorisées, ou par la mise en place de VPN permettant de faire varier l’adresse IP des cliqueuses. Au fil de nos discussions avec le client, nous avons envisagé une solution complémentaire et durable : la création d’une liste d’attente. Cette liste permet à tous les transporteurs de se positionner sur un créneau, même s’il est complet. En cas d’annulation d’un rendez-vous, le premier de la liste d’attente obtient la réservation. À noter que le nombre de rendez-vous en liste d’attente d’un même conteneur est limité pour éviter une fois encore les abus.

Aujourd’hui, cette solution est toujours en place, et aucun utilisateur n’est bloqué pour abus de « cliqueuse ». La consommation serveur a drastiquement réduit, et les transporteurs sont satisfaits de ne plus subir la lutte perpétuelle pour la prise de rendez-vous.

Dans le but de faciliter davantage l’expérience des utilisateurs de l’application, nous avons pris la décision d’implémenter un système d’échange de rendez-vous pour un même transporteur. Parfois, il peut arriver qu’une organisation ait besoin de permuter deux rendez-vous pour diverses raisons. Avant l’introduction de cette fonctionnalité, la procédure impliquait d’annuler les rendez-vous existants pour les reprogrammer à un autre créneau, ce qui impliquait généralement un passage par la file d’attente en raison de la forte demande.

Cependant, après une analyse approfondie des besoins, il est apparu que la solution la plus simple était également la plus efficace : permettre aux transporteurs de procéder à un échange de rendez-vous au sein de la même journée, dès lors que les créneaux présentaient des caractéristiques similaires. Cette nouvelle option leur offre la possibilité d’éviter de passer par la liste d’attente, tout en contribuant à réduire la charge sur nos serveurs, puisque moins de requêtes sont nécessaires pour effectuer ces échanges.

Le système est en place depuis maintenant quelques mois et fait l’unanimité, chez les transporteurs comme chez la GMP. On dénombre déjà plus de 6 000 échanges de rendez-vous depuis sa mise en place. Grâce à notre politique de tests, l’ajout de cette fonctionnalité qui touche au cœur de l’application a été facilité et fait sans accroc.

Chaque mois, ce sont presque 100 000 emails qui sont envoyés depuis l’application. Que ce soit des confirmations de rendez-vous, des informations sur l’état du terminal et bien d’autres choses, le volume d’envoi est assez conséquent. Au cours de la vie de l’application, cela n’a pas posé de problème en termes de performances, mais cet envoi massif pouvait amener certains services à identifier notre serveur d’envoi comme du SPAM. Or, c’est quelque chose que nous souhaitons bien évidemment éviter à tout prix.

Pour pallier à cela, nous avons décidé d’externaliser l’envoi des mails à un service tiers. Certes, cela implique un coût supplémentaire, mais c’est une garantie sur la bonne tenue des envois et des réceptions de ces derniers.

Nous avons fait le choix de la mise en place de l’outil PostMark. C’est un service que nous avions déjà utilisé auparavant et qui ne nécessite pas de changements dans le code de l’application. Bien qu’induisant un léger surcoût, cela a permis une meilleure stabilité du service et un meilleur tracking de l’usage des emails. À l’avenir, cela nous permettra de définir quels sont les mails pertinents, ceux non nécessaires, etc.

Depuis sa mise en place, ce sont plus de 150 000 emails qui ont été envoyés.

6 ans après, l’application continue de vivre et de grandir en fonction des usages et des besoins. Au travers de ces exemples, nous pouvons voir que nous avons su nous adapter aux besoins de l’application ainsi qu’à l’usage qui en est fait. Elle poursuit donc son cycle d’évolution et nous sommes là pour accompagner la GMP dans la prise de décision et l’intégration ou non de nouvelles fonctionnalités.