- Accueil
- Nautilus Plus / Ultime Fit
Étude de cas · Environ 1 à 1,5 an
Consolider
ce qui porte
le revenu.
Un paiement qui n’aboutit pas, ce n’est pas seulement un bug. C’est du chiffre d’affaires qui n’entre pas.
- Client
- Nautilus Plus / Ultime Fit
- Durée
- Environ 1 à 1,5 an
- Statut
- Travailleur autonome, puis mandat poursuivi chez Actif Gestion Technologies
- Terrain
- Paiements · Renouvellements · Comptabilité · Données · Opérations
- Rôle
- Développement, gestion produit, architecture, coordination
Comment ce mandat a commencé
J’ai commencé à accompagner Ultime Fit à mon compte, comme travailleur autonome. Quand j’ai rejoint Actif Gestion Technologies, le client est venu avec moi et le mandat s’est poursuivi au sein de l’entreprise. Au total, la relation aura duré autour d’un an et demi.
Le point de départ portait sur des mécanismes de paiement et de renouvellement à reprendre. Présenté comme ça, ça ressemble à un mandat de développement. Ça ne l’était pas.
Pourquoi ce n’était pas un sujet technique
Un encaissement ne s’arrête pas au moment où l’appel réussit. Il continue dans l’écriture comptable, dans le rapprochement de fin de mois, dans le courriel envoyé au membre, dans la réponse que le service client donnera trois jours plus tard. Toucher aux paiements, c’est toucher à tout ça en même temps.
C’est pour cette raison que le mandat s’est étendu bien au-delà du code. Il a fallu parler à la direction, à la comptabilité, aux développeurs internes, à des prestataires externes, et aux personnes qui tenaient l’infrastructure. Une bonne partie du travail consistait à faire circuler l’information entre des métiers qui se croisaient rarement sur un même dossier.
Ce que j’ai pris en charge
- Paiements et renouvellements d’abonnement.
- Comptabilité et réconciliation des flux.
- Gestion produit et architecture applicative.
- Collecte, traitement et circulation des données.
- Courriels transactionnels et automatisations.
- Sécurité et infrastructure.
- Coordination entre développeurs internes et externes, direction, comptabilité et responsables serveurs.
La séquence
- Stabiliser. Un mécanisme à la fois, en commençant par ceux dont le coût était le plus direct. Pas de grande refonte : des reprises successives, vérifiables une par une.
- Structurer. Clarifier les données, les processus, et surtout qui est responsable de quoi. C’est souvent là que ça bloque, pas dans le code.
- Relancer. Donner aux opérations les conditions d’avancer par elles-mêmes, sur un socle qu’elles comprennent.
- Préparer la suite. Laisser une base stable et traçable, utilisable par les personnes qui reprendraient le dossier après moi.
Ce que ça a produit
Le résultat le plus utile n’est pas spectaculaire : quand quelque chose se passe dans la chaîne d’encaissement, on sait quoi, quand, et pour quel membre. C’est journalisé, mesuré, rattaché à son contexte.
Ça a l’air modeste écrit comme ça. En pratique, ça change la nature des conversations : on parle de ce qu’on fait d’un cas précis, avec le détail sous les yeux.
Sur les chiffres
Je n’affiche aucune métrique de croissance pour ce mandat. Les données appartiennent au client et je n’ai pas de résultats consolidés que je pourrais publier de mon côté. Le jour où j’en aurai, ils seront ici.
Ce que j’en retiens
Deux choses. La première, c’est qu’un sujet de paiement est presque toujours un sujet d’organisation déguisé. La seconde, c’est qu’il vaut mieux reprendre dix petits mécanismes vérifiables qu’en réécrire un gros d’un coup — même si la deuxième option est beaucoup plus satisfaisante à annoncer en réunion.
Le produit