Spendesk
Comment Spendesk a diagnostiqué l'impact de son outil de démo sur ses ventes et structuré la feuille de route pour y remédier
Contexte
Spendesk est une licorne française qui propose une plateforme unifiée de gestion des dépenses : cartes de paiement, notes de frais, factures fournisseurs, tâches pré-comptables. Au moment de l'intervention, la société comptait plus de 5 000 entreprises clientes et une équipe technique de plus de 30 personnes.
Spendesk était en pleine refonte de son architecture technique. Dans ce contexte, un problème plus discret accumulait des dommages collatéraux côté commercial : l'outil de démonstration, conçu en interne, n'était plus maintenu en parallèle avec le produit principal. Les équipes commerciales travaillaient avec des scénarios à reparamétrer manuellement et des fonctionnalités récentes qu'elles ne pouvaient pas montrer. L'équipe tech, de son côté, avait suffisamment de sujets prioritaires pour que la maintenance de l'outil de démo reste systématiquement en bas de la liste.
Spendesk a confié à Hones le soin de structurer ce chantier, faute de bande passante disponible en interne pour le prendre en charge.
Défis
Défi #1 — Rendre visible l'impact commercial d'un problème tech non traité
Le problème était connu dans les grandes lignes, mais personne ne l'avait documenté dans toute son étendue. Combien de démos se cassaient ? Sur quelles fonctionnalités ? Combien de temps les commerciaux passaient-ils à reparamétrer des scénarios ? Quel était le coût réel de cet environnement peu fiable sur la conversion ?
Hones a conduit 25 entretiens auprès des équipes tech, des commerciaux de plusieurs pays et des utilisateurs de l'outil pour cartographier le problème dans sa globalité. Ce travail a permis de passer d'une frustration diffuse à un diagnostic factuel que les deux équipes pouvaient lire de la même façon.
Défi #2 — Concevoir une solution compatible avec une architecture en cours de refonte
Proposer une nouvelle version de l'outil de démo n'était pas une question isolée. Spendesk était en refonte profonde de son architecture logicielle. Toute solution devait s'aligner sur cette direction en cours, pas sur l'ancienne, pour ne pas créer une nouvelle couche de dette à court terme.
Hones a d'abord pris le temps de comprendre les choix techniques déjà arrêtés avant de formuler des options. Chaque scénario technique proposé était évalué sous trois angles : facilité de développement, maintenabilité dans le temps, compatibilité avec la roadmap globale de Spendesk.
Défi #3 — Résoudre la question organisationnelle à la racine du problème
Construire un nouvel outil sans changer le modèle de responsabilité aurait reproduit le même problème quelques mois plus tard. La cause profonde n'était pas technique : c'était l'absence de propriété claire sur la maintenance de l'environnement de démo.
La recommandation : traiter la démo comme on traite les tests unitaires. Chaque équipe feature, en développant une nouvelle fonctionnalité, s'assure que la démo fonctionne et ajoute les données nécessaires. La responsabilité est distribuée, pas centralisée sur une équipe dédiée qui sera toujours déprioritisée. À l'issue des trois mois, Spendesk disposait d'une roadmap produit à 18 mois et de plusieurs scénarios d'organisation pour ancrer cette logique dans les pratiques de l'équipe.
Résultats
- Le problème a été documenté pour la première fois dans toute son étendue, avec des données collectées auprès de 25 interlocuteurs internes. Les deux équipes, commerciale et technique, partageaient enfin la même lecture de la situation.
- Une roadmap produit à 18 mois a été livrée, organisée et priorisée, couvrant les fonctionnalités de l'outil de démo et les principaux parcours utilisateurs.
- Un modèle organisationnel concret a été proposé pour ancrer la maintenance dans les pratiques de chaque équipe feature, et éviter que le problème ne se reproduise après la refonte.
- Les équipes commerciales étaient mobilisées autour d'un projet qui répondait directement à leurs contraintes quotidiennes, avec une visibilité claire sur la trajectoire.
Ce qu'on a appris
Un environnement de démo qui se dégrade progressivement n'attire pas l'attention comme un bug critique en production. Il n'envoie pas d'alerte. Il crée juste une accumulation de petites frictions quotidiennes côté commercial, que tout le monde finit par absorber comme une fatalité. Jusqu'au moment où quelqu'un fait le calcul de ce que ça coûte réellement en temps et en conversion.
L'insight organisationnel de ce cas reste valable indépendamment de Spendesk : si personne n'est explicitement responsable de quelque chose, ce quelque chose se dégrade. Le parallèle avec les tests unitaires fonctionne bien. Une équipe qui livre une feature sans s'assurer que la démo fonctionne transfère un coût invisible vers les commerciaux. Changer ça ne demande pas une équipe dédiée supplémentaire, ça demande une règle claire et partagée.
