Un second canal de vente pour un opérateur eSIM
Lancer un canal partenaires sans ralentir le produit qui fait le chiffre d’affaires : une seule équipe, un seul pilotage, une architecture pensée pour les partenaires.
- Type
- Mission client, anonymisée
- Secteur
- Télécommunications, voyage
- Équipe
- 5 profils : back-end, full stack, design, produit, QA
- Technique
- Java, Quarkus, React, Flutter
- Livrables
- Évolutions du produit voyageurs, plateforme partenaires
- Mon rôle
- Organisation de l’équipe, architecture de la plateforme partenaires
Le produit marchait. Des voyageurs achetaient des forfaits data sur le site et l’application, et l’entreprise voulait maintenant que des partenaires les revendent. Sur le papier, il suffisait d’ajouter une plateforme d’affiliation. En pratique, la question posée à la direction technique était plus inconfortable : comment lancer un nouveau canal sans ralentir celui qui fait vivre l’entreprise ?
Le piège des deux équipes
La réponse la plus courante consiste à monter une seconde équipe pour le nouveau projet. Elle a ses avantages, et un défaut que j’ai vu coûter cher plusieurs fois : au bout de quelques mois, deux équipes construisent deux visions du produit, dupliquent les mêmes règles de tarification et se disputent les mêmes ressources partagées.
J’ai recommandé l’inverse : une seule équipe de cinq personnes, back-end, full stack, design, produit et QA, avec une feuille de route commune. Le Product Manager arbitre chaque semaine la part de l’équipe consacrée au produit voyageurs et celle consacrée aux partenaires. La direction voit ainsi, à tout moment, ce que coûte le nouveau canal à l’ancien.
Une architecture pensée pour les partenaires
Une plateforme d’affiliation n’est pas un simple espace client de plus. Les partenaires ont besoin de leurs propres comptes, de suivre leurs ventes et leurs commissions, et d’avoir confiance dans ces chiffres. Nous avons donc conçu la plateforme comme un ensemble de services distincts, écrits en Java avec Quarkus, qui s’appuient sur les règles déjà présentes dans le produit au lieu de les recopier.
Pour le reste, j’ai cherché à limiter le nombre de technologies qu’une petite équipe doit maîtriser : React pour les interfaces web, Flutter pour une application mobile unique sur iOS et Android. Chaque technologie en moins, c’est une personne de plus capable de reprendre le travail d’une autre pendant les congés.
Le résultat n’est pas spectaculaire, et c’est voulu : le produit voyageurs a continué d’évoluer pendant que le canal partenaires se construisait, avec la même équipe et un seul pilotage.