Jeff de Bruges : refondre l'extranet de commande des boutiques, relié à l'ERP du siège

Le cahier des charges décrivait l'ancien outil et numérotait ses règles de gestion. Innéair l'a annoté : ses commentaires rattachaient les sections aux user stories du backlog, ou posaient à son auteur des questions de règles. Dans le code, Innéair a cité l'identifiant de plusieurs de ces règles au point où elles s'appliquent, pour relier un comportement à la phrase qui le justifie.

Innéair a écrit le tunnel des commandes de réassort : le choix du bon de commande, les quantités et les minimums, les brouillons, puis l'envoi groupé selon les règles d'expédition des entrepôts. Une commande envoyée garde ses propres lignes et ses propres prix. Tant qu'elle reste un brouillon, elle reprend les changements du bon et signale au magasin les articles ajoutés ou retirés, une amélioration que Jeff de Bruges avait demandée. Avec un autre développeur, Innéair a aussi écrit le calcul du prix applicable à chaque magasin : sur cinq niveaux de priorité, il retient le prix propre au magasin ou, à défaut, celui de son groupe, jusqu'au tarif de référence.

Innéair a écrit les vues de ces fonctionnalités, côté boutiques comme côté siège, ainsi que la navigation de l'outil, ses menus et son fil d'Ariane, et pilotait l'intégration des maquettes.

Avant les grandes opérations commerciales, les boutiques saisissaient des précommandes. Une fois un bon de précommande clôturé, le siège les transforme en commandes : Innéair a écrit cette transformation, complète, par magasin ou par article, et le serveur la traite par lots.

Innéair a aussi écrit le suivi des commandes, avec les devis, les bons de livraison, les factures et les articles manquants, ainsi que la saisie mensuelle du chiffre d'affaires des boutiques. Une boutique ne peut pas sauter de mois ; elle peut corriger sa saisie jusqu'au 10 du mois suivant, et l'outil vérifie la cohérence entre ses montants hors taxes et toutes taxes comprises.

L'extranet échange avec l'ERP les articles, les prix et les commandes. Un autre développeur avait conçu les web services SOAP de ces échanges ; Innéair les a restructurés autour d'une classe commune, avec une gestion d'erreurs centralisée, et a contribué à la file de messages qui envoie les commandes à l'ERP, avec son rejeu et sa file d'erreurs.

Innéair a aussi écrit les clients des API qui alimentent les chiffres de la page d'accueil, et transformé le script de reprise des données de l'ancien outil en commande Symfony, avec l'anonymisation des données reprises.

Le socle de l'application existait depuis une semaine quand Innéair est arrivée. Le jour même, Innéair a ramené son installation à une seule commande, contre cinq auparavant, avec Docker et un Makefile qui documente lui-même ses cibles. Trois jours plus tard, les tests tournaient sur chaque merge request. En cours de projet, Innéair a mis à niveau Symfony et PHPUnit.

Innéair dirigeait quatre développeurs et supervisait le travail des autres ; l'équipe réunissait des développeurs de l'agence, d'un sous-traitant et du monde freelance, dont un qu'Innéair avait proposé à l'agence. Elle répartissait le travail et pilotait notamment la gestion des comptes, des profils et des droits. Innéair relisait chaque merge request de l'équipe, puis testait la fonctionnalité pour vérifier qu'elle répondait à ce que le client attendait. Elle intégrait le travail de l'équipe et livrait les versions en recette.

Comme Scrum Master, Innéair animait les revues de sprint, les démonstrations et les rétrospectives, sur des sprints de deux semaines. Chaque revue suivait le même plan : l'objectif vu par l'utilisateur, ce qui avait été réalisé, les points techniques, puis les points de vigilance. Chaque action décidée en rétrospective avait un responsable et une échéance, et la rétrospective suivante vérifiait qu'elle avait été tenue.