Historique d’un produit d’Amidship
Construire le logiciel n’était qu’une partie du travail de propriétaire du produit.
Amidship a bâti une plateforme logicielle autour du quotidien d’une entreprise de services — du site public et de la réservation à la planification, aux clients, aux paiements et à l’administration. En 2017, l’inscription était ouverte au public et le produit comptait des clients payants. Des années plus tard, la production a été arrêtée volontairement; le logiciel a été préservé et a fini par trouver une seconde vie plus ciblée.
Construit · exploité · retiré volontairement
Le problème
Une entreprise de services forme une seule opération, même lorsque ses logiciels sont dispersés.
Une petite entreprise de services peut facilement avoir son site Web à un endroit, ses rendez-vous ailleurs, l’historique de ses clients dans un autre système, ses paiements et factures dans un autre, puis le reste de ses règles de fonctionnement dans des messages, des feuilles de calcul et la mémoire des personnes.
L’occasion produit dépassait la réservation en ligne. Le parcours du client et le travail de l’exploitant faisaient partie du même système : découvrir l’entreprise, choisir un service, réserver, payer, revenir — pendant que l’entreprise gère les disponibilités, les clients, l’argent et les règles entourant chaque rendez-vous.
Décision clé
Construire autour du parcours opérationnel, plutôt qu’autour d’une collection de fonctions déconnectées.
- Site Web / découverte
- Service + réservation
- Dossier client
- Paiement / facture
- Opérations de l’entreprise
Le produit
Un seul système pour le parcours du client et celui de l’exploitant.
La plateforme réunissait les sites d’entreprise, les services, la réservation en ligne, le personnel et les disponibilités, les dossiers clients, les paiements, les factures et l’administration des ventes. Elle devait aussi gérer les éléments moins visibles du quotidien : rappels, politiques d’annulation, emplacements, calendriers, devises, fuseaux horaires et configuration.
Cette portée obligeait les différentes parties à rester cohérentes. Ce qu’un client pouvait réserver devait correspondre au calendrier de l’exploitant. L’état des paiements devait s’aligner sur les rendez-vous et les factures. La configuration de l’entreprise devait se refléter autant dans le site public que dans les outils internes.
Dans le produit
Le produit de 2017, tel qu’il était vraiment.
-
Inscription publique · 2017
Le parcours d’accueil des entreprises qui rejoignaient la plateforme.
-
Administration de l’entreprise · 2017
Les réservations et les ventes vivaient aux côtés des clients, de la configuration de l’entreprise et des paramètres.
-
Planification mobile · 2017
Le travail de l’exploitant se poursuivait sur mobile au lieu de s’arrêter au back-office sur ordinateur.
Cycle de vie du produit
Savoir quand arrêter fait aussi partie du métier de propriétaire de logiciel.
- 2015 · Construire Le produit horizontal pour entreprises de services prend forme.
- 2017 · Exploiter Inscription publique, clients payants et soutien quotidien du produit.
- 2024 · Retirer La production est arrêtée volontairement et un état récupérable est conservé.
- 2026 · Réutiliser Le même code applicatif est réactivé pour un secteur plus précis sous une marque et un profil juridique LashDesk distincts.
Le 1er janvier 2024, le système de production a été mis hors ligne volontairement. La base de données et les fichiers téléversés ont été sauvegardés, l’infrastructure de production a été retirée et les anciens domaines ont été redirigés. Garder indéfiniment un vieux produit en ligne n’était pas considéré comme l’option par défaut.
En 2026, le code applicatif préservé a été réactivé autour d’une proposition verticale beaucoup plus ciblée sous LashDesk. LashDesk possède aujourd’hui une marque et un profil juridique distincts; ce qui compte ici est la lignée logicielle — un système mature pouvait être réutilisé parce que son modèle opérationnel conservait de la valeur.
Le jugement produit doit tenir pendant tout le cycle de vie.
Être propriétaire d’un produit oblige à porter des décisions qui survivent souvent à la fin d’un mandat : quelle part du processus posséder, quoi intégrer, comment soutenir de vrais clients, quand l’exploitation ne se justifie plus, quoi préserver et si un logiciel existant mérite une autre utilisation.
Cette expérience de fondateur et d’exploitant influence encore le travail d’Amidship. Nous nous intéressons aux logiciels qui méritent la complexité qu’ils introduisent — et à ce qui arrive après la première version, lorsque le produit a des clients, de l’histoire, des coûts d’exploitation et des conséquences.