KeyOpsTech : fiabiliser le suivi de colis d'une logistique hors ligne en Afrique de l'Ouest

Chaque fois qu'un colis changeait de mains, les deux téléphones échangeaient des QR codes, et la responsabilité du colis passait de l'un à l'autre. Les téléphones travaillaient souvent sans réseau : ils envoyaient leurs événements plus tard, chacun de son côté. Le serveur recevait donc chaque transfert deux fois, parfois avant la création du colis, et c'était à lui de reconstituer le parcours de chaque colis et d'en tenir l'état. À l'arrivée d'Innéair, ces règles étaient dispersées entre un contrôleur, un abonné et un service, mêlées à l'envoi des SMS et à la détection des fraudes.

Innéair a écrit l'étude préalable et l'architecture cible de la refonte, puis l'a découpée en lots, confiés à trois développeurs dont elle a piloté le travail. Elle en a conçu le cadre : chaque opération métier devient une classe qui écrit son entrée dans l'historique du colis, avec un statut de réussite ou d'échec, applique sa règle, puis publie un événement. Les notifications, la détection des fraudes et les opérations dérivées, comme la mise à disposition ou le départ en livraison, s'abonnent à ces événements. Innéair a écrit les dix premières opérations et aligné les statuts sur ceux de la page de suivi des clients ; sous son pilotage, l'équipe a écrit les règles de transition, puis ses propres opérations. La refonte est partie en production en janvier 2020.

Un téléphone renvoyait un événement tant que le serveur ne l'avait pas acquitté, et une erreur durable bloquait toute sa file d'envoi. Le serveur acquittait déjà les doublons ; Innéair a étendu cet acquittement aux événements invalides, que le rejeu ne corrigerait jamais, et elle a déplacé le contrôle des doublons de MongoDB vers MySQL. Pendant la recette de la refonte, elle a gardé dans l'API, pour les applications déjà installées, un champ que la refonte supprimait du modèle.

Dans le cadre de la refonte, Innéair a aussi piloté le tri des événements reçus dans le désordre : la création d'abord, la livraison à la fin, puis l'ordre des étapes sur la route et la date. Les informations courantes du colis ne sont mises à jour que par la dernière entrée de son historique.

Dès septembre 2019, Innéair a allégé le modèle. Elle a sorti les colis inconnus de la table des colis, où ils étaient enregistrés comme de faux colis, pour leur donner leur propre objet, avec une association automatique quand un seul colis correspond. Elle a aussi retiré les lots, les retours et les destructions de colis.

Elle a ensuite remplacé un calcul de routes maison par l'algorithme de Yen d'une bibliothèque déjà présente dans le projet, et retiré MongoDB du code et de la production.

Innéair dirigeait l'équipe du back-end, quatre personnes au plus en même temps, dont un ops : elle orientait la conception, relisait et fusionnait le travail de chacun. Elle a piloté toutes les mises en production du back-end, en se synchronisant avec l'exploitation et l'équipe mobile, et les a lancées elle-même à partir de janvier 2020.

Sous le pilotage d'Innéair, l'équipe a presque triplé ses tests unitaires, passés de 176 à 488 pendant la mission ; chacune des quatorze opérations du nouveau cadre a son test. Innéair a aussi monté Symfony en version 4.4 et PHPUnit en version 9.

Une refonte en production avance par étapes que l'on peut nommer : retirer, renommer, extraire, faire cohabiter l'ancien et le nouveau, migrer, puis assurer la compatibilité. Un client que l'on ne contrôle pas, ici un téléphone déjà distribué sur le terrain, continue d'imposer ses règles au serveur longtemps après la refonte : chaque code de réponse devient une décision.