D'un lancement bloqué à des opérations en direct

Le produit existait. Le lancement, non.

Reotech travaille avec ALB Mobility, basée à Paris, depuis 2024. À notre arrivée, un autre prestataire avait déjà construit une part importante du produit. Sur le papier, beaucoup de composants attendus étaient présents. Dans les faits, le système n’était pas prêt pour de vraies opérations.

Chaque tentative de mise en production exposait des défaillances entre modules connectés. Les paiements et les services externes n’étaient pas intégrés de façon fiable. L’application mobile ne couvrait pas les parcours attendus des chauffeurs, et des capacités opérationnelles essentielles manquaient encore.

Pour ALB, ce n’était plus seulement un problème technique. L’entreprise approchait une saison importante, et le produit deviendrait utilisable par de vraies personnes.

Nous avons commencé par le métier, pas par le code.

Avant de décider ce qu’il fallait réparer ou reconstruire, nous avons partagé de longues sessions de travail avec l’équipe ALB.

Nous avons appris comment fonctionnait l’opération, comment les différents acteurs interagissaient, ce que les premiers utilisateurs devaient accomplir chaque jour, et où le fondateur voulait emmener l’entreprise. Cela nous a donné une image bien plus claire qu’un backlog de problèmes techniques isolés.

La réponse évidente aurait été de tout réécrire. Cela aurait peut-être produit un code plus sain à terme, mais cela aurait aussi consommé le temps dont ALB ne disposait pas.

À la place, nous avons tracé le chemin le plus court et le plus responsable vers la production. Nous avons identifié les parcours qui bloquaient le lancement, réparé les intégrations critiques, ajouté les capacités opérationnelles manquantes, et reporté ce qui n’aidait pas les premiers utilisateurs à réussir.

Le lancement s’est fait avec les utilisateurs, pas derrière une porte close.

Quand les premiers utilisateurs sont entrés dans la plateforme, notre implication ne s’est pas arrêtée au déploiement.

Nous sommes restés proches de leur travail quotidien, nous avons suivi les problèmes rencontrés, investigué les incidents au fur et à mesure, et transformé le retour du terrain en décisions produit. Développement, déploiement, accompagnement des utilisateurs et amélioration du produit ont avancé ensemble.

Cela nous a permis de distinguer ce qui semblait important depuis le code de ce qui empêchait réellement quelqu’un de terminer son travail.

Résultat : une boucle de retour plus courte et un produit façonné par de vraies opérations — pas par des hypothèses formulées en salle de réunion.

Le rattrapage est devenu un partenariat produit durable.

Une fois ALB en production, le travail est passé du rattrapage au développement continu.

Des outils jusque-là déconnectés sont devenus une plateforme unique reliant dispatch, partenaires, chauffeurs et clients. Aujourd’hui, le système comprend un tableau de bord administratif, des espaces partenaires et clients, une application mobile chauffeur, les paiements, des services externes et le socle partagé qui coordonne l’ensemble.

La livraison utilise largement AWS pour l’hébergement et les services opérationnels. Le système utilise aussi Supabase et Brevo, notamment pour les e-mails transactionnels, aux côtés de React, React Native, Node.js, PostgreSQL et Mapbox.

L’affectation d’un chauffeur prend aujourd’hui deux fois moins de temps qu’avant.

Reotech continue de travailler aux côtés d’ALB : fiabilité et sécurité renforcées, parcours existants améliorés, nouvelles capacités introduites, et observation attentive du comportement de la plateforme à mesure que l’opération grandit.

Décider à partir de la même image

Notre rôle auprès d’ALB ne se limite pas à recevoir des tickets et à les implémenter.

Parce que nous connaissons le métier, ses utilisateurs et sa direction, nous pouvons prendre des décisions produit et techniques à partir de la même image que le client. Nous savons ce qui exige une attention immédiate, ce qui peut attendre, et comment une décision sur une partie de la plateforme peut affecter l’ensemble de l’opération.

La vision reste la responsabilité du fondateur. La nôtre est de la comprendre assez profondément pour la transformer en logiciel qui fonctionne dans le monde réel — et de garder le produit aligné avec la direction de l’entreprise.