Uptime, ou comment construire un produit IoT dans les règles de l’hardware

Uptime, ou comment construire un produit IoT dans les règles de l’hardware

Cette semaine, Axel Colin de Verdière, CTO d’Uptime, m’a ouvert les portes des cossus bureaux parisiens de la start-up leader dans la maintenance prédictive d'ascenseurs connectés. Entre défis stratégiques et organisation des équipes, vous saurez (presque) tout de la construction d’un produit IoT ! Rencontre au sommet.

Salut Axel, commençons par quelques éléments de contexte ?

J’ai un parcours plutôt ingé, diplômé de polytechnique et orienté très tôt vers l’informatique et plus particulièrement l’IoT qui m’a toujours parlé. Dès la sortie de l’école, j’ai fait mes armes en start-up et principalement chez Sen.se spécialisée dans les objets connectés grand public où je me suis familiarisé au dev, au lead, à l’infra et au hardware.

A la fin de cette aventure je souhaitais rester dans l’IoT qui me fascinait toujours autant mais sortir du grand public pour quelque chose de plus industriel et avec un cas d’usage qui avait plus de valeur. C’est comme ça que je suis tombé sur Augustin et Amaury Celier, fondateurs d’Uptime, expert en maintenance prédictive d’ascenseurs. Leur projet m’a tout de suite séduit : un vrai product-market fit sur un marché de niche mais en forte croissance, souffrant d’un painpoint parfaitement identifié qui n’attend que l’IoT pour avancer.

En quoi consiste exactement le projet ?

Ce painpoint c’est la qualité de service : des pannes fréquentes malgré d’onéreux frais de maintenance avec un vrai souci de transparence. Et parallèlement, on est face à des consommateurs qui - comme dans de nombreux autres secteurs - attendent plus de lisibilité, d’instantanéité et de tech.

On a d’abord créé une boîte de maintenance d’ascenseur qui propose un service augmenté par la technologie. Cette première business unit nous a permis de roder notre modèle de maintenance prédictive et surtout d’en prouver son efficacité avec plus de 1000 ascenseurs en 3 ans, une super qualité de service et beaucoup moins de pannes que nos concurrents. Nos clients sont satisfaits du service et notre portefeuille-clients bénéficie d’ailleurs d’une belle croissance exclusivement organique !

Dans un second temps, depuis le début de l’année, on s’est mis à vendre notre techno à des ascensoristes tiers en Europe.

On souhaite absolument poursuivre avec ces deux activités extrêmement complémentaires voire interdépendantes. On n’aurait jamais pu vendre une solution sans l’avoir installée puis testée par des techniciens chevronnés sur le terrain.

Comment êtes-vous organisés en interne ?

On a trois pôles majeurs.

Il y a la première business unit dont je te parlais, que l’on appelle la Predictive Factory, avec les techniciens de maintenance, le customer success et les sales. En face on a notre deuxième activité, le pôle expansion avec la vente de notre solution. Et au milieu il y a la tech et le produit, dont je fais partie. Ce pôle compte une vingtaine de personnes et s’organise sur le modèle répandu et éprouvé de Spotify : trois squads pluridisciplinaires, dont un hardware et deux software.

Concernant ces squads, on s’est demandé comment on allait scinder la responsabilité de chaque équipe :

Il y a l’organisation en “component team” où chaque équipe travaille sur un front end différent, un modèle que l’on a jugé pas très pertinent car la plupart de notre valeur est créée sur plusieurs applis en parallèle

Un autre schéma était la “feature team” ou chaque équipe se charge d’une feature particulière ou bien d’un set de features, ce qui n’allait pas non plus avec notre business en perpétuelle évolution

Puis il y a l’ “impact team” pour laquelle on a optée où l’idée est de définir chaque semestre des OKR (Objective and Key Results) à partir de la stratégie produit et de les attribuer à chaque équipe. Les équipes auront alors tous les moyens à leur disposition et pourront intervenir sur toutes les applications pour répondre à l’objectif fixé

Peux-tu me parler de ces 3 squads plus dans le détail ?

Chaque squad comprend un Product Manager, un Tech Lead, des Devs et un Designer ; avec en plus un Data Analyst dans transverse.

> L’équipe hardware est en quelque sorte une équipe plateforme qui va chercher à améliorer le boîtier en comprenant les besoins remontés par les deux équipes soft ainsi que par le pôle expansion chargé du déploiement. Ajouter un datapoint sur le boîtier, faire évoluer le boîtier pour le déployer plus facilement ou bien résoudre un bug… On a créé une interface qui permet de recueillir ce type de besoins et de les prioriser pour mieux les traiter.

> Les deux équipes software vont avoir chacune un objectif business à traiter sur six mois/un an. Par exemple en ce moment, l’une d’entre elles est spécifiquement missionnée sur la diminution des pannes, tant chez nos clients-tiers qu’en interne dans la Predictive Factory, grâce à des recommandations d’actions pendant la maintenance mais aussi pendant le dépannage. Pour atteindre cet objectif, le Product Manager de l’équipe va explorer toutes les possibilités de développement. C’est très large et il va pouvoir aller très loin avec beaucoup d’idéation entre les membres de son équipe - les Devs notamment - et de nombreux tests de petites features, de petits bouts de datas, en cherchant à dérisquer au maximum.

Notre Data Analyst embauché l’année dernière est un véritable atout pour Uptime. Doté d’un véritable esprit problem-solver, il fournit de la valeur à toutes les équipes d’Uptime et commence d’ailleurs à crouler sous les demandes.

On ne sait jamais, si un ou une passionné.e de data lit cet article et souhaite nous rejoindre, c’est le moment !

Et ce boîtier violet posé devant toi, comment fonctionne-t-il ?

Notre boîtier possède deux grands avantages : il s’adapte à toutes les marques d’ascenseur et il ne nécessite pas l’installation de capteurs dans l'ascenseur. Quand on parle de maintenance prédictive et de monitoring à distance, on pense effectivement tout de suite à des capteurs sauf que c’est une techno compliquée à installer donc onéreuse. D’autant plus qu’il t’en faut beaucoup si tu veux une quantité suffisante de données à catégoriser pour fournir de la valeur intéressante sur le long terme.

Nous on a choisi de capitaliser sur les capteurs qui existent déjà sur l’ascenseur. On en extrait les données via un port diagnostic sur lequel vient se brancher le technicien en intervention puis on les transmet à notre système pour les retravailler. S’ouvre alors un boulevard d’analyses de trafic, d’identification et de prévention des pannes ! Par exemple, si on s’aperçoit que la porte palière du 4ème étage rencontre régulièrement des difficultés à se fermer, l’info est transmise au technicien dans le cadre de sa prochaine intervention. C’est pour lui un considérable gain de temps et d’efficacité !

Et puis évidemment, grâce à la data, la panne d’un ascenseur va permettre d’anticiper la future panne de l’immeuble voisin. Plus on a d’ascenseurs connectés, plus on a de data, plus on est capable de trouver des patterns intéressants et de transformer tout cela en algorithme de maintenance prédictive !

Quels sont les principaux KPIs que vous pilotez ?

- le nombre de pannes

- le temps d’indisponibilité de l’ascenseur

- des KPIs plus opérationnels qui vont directement influer sur le coût, comme le nombre d’heures passées sur le terrain

Et comment avez-vous géré la déferlante Covid ?

Sur l’organisation de l’entreprise, on avait déjà adopté avant la crise un peu de remote, plus d’écrit et d’asynchrone. Le télétravail a en revanche posé des défis d’ordre technique pour l’équipe hardware qui est lourdement équipée.

Sur un plan plus business on a eu de la chance car on n’a pas été trop impacté. Il y a eu au départ un léger ralentissement de notre croissance car les syndics - qui sont nos principaux clients - ont mis un peu de temps à s’adapter. Mais très vite on a retrouvé notre rythme de croisière !

Ce qui a été intéressant pour nous, c’est que ça nous a donné un cas d’usage sur la fréquence d’utilisation et donc de maintenance des ascenseurs. Confinements et télétravail ont fait chuter le trafic de certains immeubles qui nécessitait donc moins d’intervention. Les visites de routine du schéma classique de maintenance sont devenues encore plus absurdes et contre-productives !

Il est venu le temps de notre traditionnelle séquence “inspirationnel” : Qui sont les gens qui t’on aidé, guidé, orienté ?

Entre le perso, le réseau Whyse, celui de notre investisseur Serena… il y en a tellement ! Même si en Ile de France il y a finalement assez peu de sociétés qui travaillent sur le hardware...

A l'époque, j'avais pas mal discuté avec Antoine Lizée qui était à l’école avec moi. Son approche de la data chez Alan m’avait bien inspiré pour Uptime.

J’ai aussi eu la chance de rencontrer Guillaume Simon le CPO de Stuart il y a 2 ans, au moment où l’on amorçait notre transition de culture très tech vers plus de produit. Il m’avait donné plein d’insights super intéressants sur la manière dont il avait structuré ses équipes : les rôles du Product Manager, du Scrum Master, du Product Designer par rapport au reste de l’équipe… C’était passionnant, je l’en remercie encore !

Et moi c’est toi que je remercie Axel pour cet échange qui m’a permis - j’ose le dire - de m’élever dans ce monde complexe de l’IoT !

Rejoindre Whyse

Développez vos compétences et votre réseau professionnel