Facility Lockers
Cinq ans aux côtés de Facility Lockers pour reprendre la main sur le produit et transmettre sa maîtrise aux équipes.
- Service
- Fractional CTO
Facility Lockers souhaitait sortir d’une organisation de développement trop coûteuse et retrouver la maîtrise de son produit. Depuis cinq ans, Not a Monkey accompagne l’entreprise comme CTO à temps partagé : décisions techniques, priorités produit, développement et évolution des applications. Un chantier récent prolonge ce travail de fond : étendre la couverture des parcours de bout en bout et les documenter dans un wiki partagé avec le support.
Contexte
Un casier connecté fait intervenir bien plus qu’une porte et un code. Une livraison, une commande de service ou une réservation de bagages traverse plusieurs interfaces : espace client, portail de réservation, borne sur site et administration. Les droits d’accès, les disponibilités, les notifications et les états doivent rester cohérents tout au long du parcours.
Pour Facility Lockers, l’enjeu initial était de reprendre le contrôle de cet ensemble et de sortir d’une forte dépendance à une équipe de développement coûteuse. Il fallait pouvoir décider des priorités, comprendre les choix techniques et faire évoluer le produit en tenant compte des moyens de l’entreprise et des besoins du terrain.
Au fil des années, cet accompagnement s’est étendu à de nombreux chantiers sur les applications et leur exploitation. La connaissance du produit devait aussi devenir accessible au support : comprendre ce qu’un utilisateur essaie de faire, reconnaître l’étape où il se trouve et savoir comment traiter ou transmettre son problème.
Une direction technique dans la durée
Reprendre les décisions produit et techniques
Accompagnement de la sortie de l’organisation de développement historique, reprise de la connaissance du produit et clarification des priorités. Le rôle de CTO à temps partagé redonne à l’entreprise un interlocuteur capable de relier les décisions techniques aux besoins métier et aux coûts de développement.
Faire évoluer un système déjà en exploitation
Intervention dans la durée sur l’architecture, le développement et les arbitrages entre applications historiques et services cloud. Les parcours de réservation, de dépôt, de retrait et d’administration sont abordés comme les étapes d’un même produit, avec une attention particulière aux échanges de données et aux rôles des utilisateurs.
Rendre les parcours reproductibles
Structuration d’un environnement local réunissant les applications et leurs services. Les tests disposent de données fictives, de portes simulées et de notifications capturées localement. Un environnement de test isolé permet de rejouer les situations et de restaurer les données après chaque scénario.
Étendre la couverture de bout en bout
Construction d’une suite Playwright qui suit les actions réelles à travers les interfaces et vérifie leurs effets : création d’une réservation, dépôt, notification, retrait et libération du casier. Les variantes, les droits d’accès et les situations de reprise font partie du travail. La couverture distingue les comportements vérifiés, les écarts constatés et les contrôles restant à réaliser, notamment sur le matériel physique et les prestataires réels.
Partager la connaissance avec le support
Mise en place d’un wiki organisé par rôle et par parcours métier, utilisé comme référence commune pour le produit, les tests et le support. Chaque guide rassemble les étapes, les règles, les captures des applications et les points de diagnostic. Les schémas de cycle de vie et les liens vers les vérifications aident les équipes à décrire un problème avec le même vocabulaire et à préparer une remontée exploitable.
Relier le produit, les tests et le support
Une même lecture des parcours à travers les applications.
Le front-office, le portail de réservation de bagages, la borne et le back-office participent aux mêmes parcours métier. Le travail de direction technique relie ces interfaces et leurs services, puis organise leur vérification. L’environnement local permet de reproduire une situation, les tests d’en observer le résultat et le wiki d’en partager les règles et les points d’attention.
Du parcours à l’écran jusqu’au casier
Vérifier les effets d’une action dans les différentes applications.
La borne est un point de passage entre le logiciel et l’usage sur site. Les scénarios suivent les dépôts, les retraits et les réservations, puis vérifient les états et la disponibilité du casier dans les interfaces concernées. Cette capture provient de l’environnement de test, avec une station fictive et des portes simulées.
Un point d’entrée commun pour le support
Retrouver le bon parcours selon le rôle et le problème rencontré.
Le wiki propose une lecture dédiée aux opérations et au support, avec recherche et navigation par cas d’usage. Il relie les interfaces, les responsabilités et les étapes à vérifier. Les équipes disposent ainsi d’un point de départ pour comprendre une demande et échanger avec la technique. Capture du guide local dans sa vue support.
Des cycles de vie compréhensibles
Relier chaque état à l’action qui le déclenche et à la prochaine étape.
Les diagrammes du wiki rendent visibles les transitions d’une commande ou d’une réservation. Le support peut sélectionner un état, consulter sa signification et retrouver les vérifications associées. Les règles attendues, les comportements observés et les limites documentées sont distingués pour guider le diagnostic. Capture du parcours de dépôt et de retrait d’un colis.
Vous souhaitez reprendre la maîtrise de votre produit et donner une direction claire à vos équipes ? Construisons un accompagnement de CTO à temps partagé adapté à votre réalité.
Fractional CTO