Internaliser un produit IoT, sans équipe technique.
Une startup de casiers connectés qui veut sortir de la dépendance à son fournisseur de bornes. Direction non-tech, POC initial développé par le fournisseur lui-même. Internalisation complète de l'application, montée d'une équipe technique de 2 développeurs, V1 livrée sous 150K€ sur une infrastructure cloud qui scale à plusieurs centaines de casiers.
Site du client : lesbiensencommun.com ↗
Le contexte
Un produit IoT en propre, sans tech interne.
Les Biens en Commun déploient des casiers connectés en libre service sur des bornes physiques, avec une application B2C pour la réservation et un back-office pour la gestion. Le produit existe, le marché aussi.
À mon arrivée, le POC fonctionnel avait été livré par le fournisseur des bornes : un logiciel conçu à la base pour des casiers de bowling, tweaké à la marge pour le cas d'usage Les Biens en Commun. La stack tournait sur l'infra du fournisseur, les données passaient par ses systèmes, chaque nouveau casier entraînait un nouveau back-office.
Yann et son associé n'ont aucune compétence technique en interne et veulent reprendre la main avant que la dépendance ne devienne irréversible. Et garder la possibilité de changer de fournisseur de bornes à l'avenir.
Le problème
Quatre problèmes qui se cumulaient.
Dépendance
Logiciel et matériel verrouillés sur un seul fournisseur.
Le logiciel applicatif était à la base conçu pour des casiers de bowling, tweaké pour Les Biens en Commun. Il tournait sur l'infra du fournisseur des bornes. Impossible de changer de fournisseur matériel sans tout réécrire, et la moindre défaillance commerciale ou technique de ce prestataire devenait un risque business direct.
Architecture
Un back-office par casier.
Chaque nouvelle borne physique entraînait la duplication du back-office de gestion. Aucun déploiement industriel possible. La croissance était bridée par construction.
UX mobile
Piloter une borne depuis un mobile, vite et bien.
L'usage premier : un locataire arrive devant son casier, déverrouille depuis son téléphone, repart. Le parcours doit tenir sous 30 secondes, fonctionner en réseau dégradé, et ne pas laisser un utilisateur planté devant une borne qui ne répond pas. L'interface initiale n'allait pas du tout, et la couche IoT amenait son lot de sujets à découvrir.
Opérations
Gestion manuelle, données dispersées.
Réservations gérées à la main, données utilisateurs éparpillées entre plusieurs bases, aucun suivi unifié des locations et de la maintenance. Le temps de gestion croissait linéairement avec le nombre de casiers.
Ce que j'ai fait
CTO-as-a-Service sur plus de 2 ans, en 4 phases.
Pas une refonte. Une internalisation progressive : auditer ce qui existe, cadrer un MVP qui dérisque la dépendance fournisseur, défricher la couche IoT pour une UX mobile fluide, monter une équipe, livrer en autonomie.
- 01
Audit et stratégie technique
Analyse de l'existant : le POC initial avait été livré par le fournisseur de casiers connectés, sous sa stack et sur son infra. Cartographie des dépendances, des contraintes IoT (firmware bornes, latence, fiabilité réseau), définition de la roadmap produit pour internaliser proprement.
Démarrage
- 02
MVP et architecture cloud
Priorisation des fonctionnalités. Conception d'une infrastructure AWS scalable : 7 services orchestrés, capable d'absorber le passage de 1 à plusieurs centaines de casiers sans dupliquer les back-offices. Application B2C en Progressive Web App pour éviter les contraintes app store.
Conception
- 03
Pilotage du développement
Sélection des prestataires techniques, recrutement et encadrement de 2 développeurs internes, arbitrages produit et tech au quotidien. Yann et son associé restent décisionnaires côté business, sans avoir à arbitrer la stack eux-mêmes.
Build, plus de 2 ans en CTO-as-a-Service
- 04
Déploiement et autonomisation
Migration des données depuis l'ancien système, mise en service de la nouvelle solution sur le terrain, formation des équipes. L'équipe technique est aujourd'hui constituée et autonome sur sa stack.
Livraison
Les résultats
Ce qui tourne aujourd'hui.
Budget V1
< 150K€
Pour une V1 complète sur AWS : application B2C en PWA, back-office métier unifié, interface bornes, intégration matériel.
Scalabilité
Centaines de casiers
Infrastructure cloud unifiée. Un seul back-office pour tous les casiers. Le déploiement d'une nouvelle borne est devenu une opération de routine.
Temps de gestion
80 % en moins
Automatisation des réservations, suivi unifié, plus de saisie manuelle. Le temps d'opération a été divisé par 5.
Impact business
+50 % d'occupation
Taux d'occupation des casiers en hausse. Satisfaction utilisateur multipliée par 3 selon les retours clients sur la PWA.
L'app livrée
Côté utilisateur, ce que ça donne.
Une PWA mobile : carte du quartier, casiers disponibles, réservation en deux taps, déverrouillage de la borne en moins de 30 secondes une fois sur place.
Photos : Les Biens en Commun.
La stack
Avec quoi ça tourne.
- Application B2C Progressive Web App, cross-plateforme, pas de contrainte app store pour les locataires.
- Back-office Application métier unifiée, gère les centaines de casiers et toutes les bornes au même endroit.
- Bornes connectées Interface utilisateur côté borne physique, intégration avec le firmware fournisseur.
- Infrastructure AWS, 7 services orchestrés. Conçue pour le passage à l'échelle dès la V1.
- Équipe 2 développeurs internes, 1 CTO externalisé en arbitrage et pilotage.
01
Leçon n°1
Un POC livré par un fournisseur n'est pas une V1.
Quand un fournisseur de matériel vous livre l'application qui pilote son matériel, c'est pratique au démarrage. Vous avancez vite, vous validez le marché. Mais c'est un POC, pas une V1. La stack est faite pour son besoin de démonstration, pas pour votre montée en charge.
L'internaliser plus tard, c'est inévitable. Plus vous attendez, plus c'est lourd. Sur Les Biens en Commun, l'arbitrage a été fait au bon moment : le produit avait validé le marché, la dépendance n'était pas encore systémique.
02
Leçon n°2
Sans pilote technique côté client, l'internalisation ne se fait pas.
Yann et son associé sont des fondateurs non-tech. Très compétents sur leur métier, sur la traction commerciale, sur le pilotage business. Mais sans personne en interne pour arbitrer une architecture, choisir une stack ou cadrer un sprint, l'internalisation devient un pari.
Le CTO-as-a-Service répond à ce problème précis. Pas besoin d'embaucher un CTO en CDI à 130K€ quand le besoin tient sur 2 à 3 jours par mois d'arbitrages structurants et de pilotage d'équipe.
03
Leçon n°3
Une architecture unifiée se décide à la V1, pas à la V3.
Le piège classique dans l'IoT : un back-office par installation, parce qu'au début ça va plus vite. Au 5e casier, on découvre que ça ne scale plus. Au 20e, on est coincé. Refactoriser plus tard coûte 5 à 10 fois plus cher que de cadrer l'architecture correcte dès la V1.
Sur Les Biens en Commun, le choix d'une infrastructure AWS unifiée dès le MVP a permis d'absorber le passage à plusieurs centaines de casiers sans réécriture. La scalabilité n'est pas un sujet de la V3. C'est un sujet du jour 1.
Le retour de Yann
Plus de 2 ans après.
Travailler avec un CTO était indispensable. Sans besoin à temps plein, opter pour un CTO à temps partiel comme Fabien faisait beaucoup de sens. 2 ans plus tard, sa vision Tech et Produit nous a permis de cadrer le produit, sélectionner les ressources et structurer la stack.
Vous êtes dans une situation similaire ?
Produit IoT à internaliser, dépendance technique sur un fournisseur, direction non-tech, croissance bridée par l'architecture. Si un de ces sujets vous parle, on peut en parler en 30 minutes.