Gestion de flotte de trottinettes électriques. Mettre à l'échelle sans perturber les opérations

Un opérateur de mobilité partagée a commencé à rencontrer des problèmes d’extension lorsque sa flotte de trottinettes électriques s’est développée dans plusieurs villes. Les flux de paiement, le suivi de la conformité, les alertes de sécurité et les automatisations de maintenance sont progressivement devenus plus difficiles à gérer au sein d’un flux opérationnel unique. Chaque nouvelle automatisation résolvait un problème tout en rendant l’ensemble du système plus difficile à maintenir, à dépanner et à faire évoluer.

Cette étude de cas examine comment l’opérateur a réorganisé ses automatisations, séparé les domaines opérationnels et modifié son approche de la gestion de flotte de trottinettes électriques à mesure que l’entreprise continuait de croître.

Pourquoi la mise à l’échelle de la gestion de flotte de trottinettes électriques devient-elle difficile sur le plan opérationnel

Pour les flottes de trottinettes électriques en libre-service, même de petits retards opérationnels deviennent immédiatement visibles. Les utilisateurs s’attendent à ce que les trottinettes se déverrouillent presque instantanément après la confirmation du paiement. Lorsque cela ne se produit pas, les trajets sont abandonnés, les tickets de support s’accumulent et les opérateurs commencent à perdre des revenus avant même que la course ne commence.

Mais les problèmes de “payer-pour-démarrer” ne sont qu’une partie des pressions auxquelles les opérateurs de mobilité partagée font face au quotidien. Le vol, le sabotage, les déplacements non autorisés, le respect des limites de vitesse, la gestion de la batterie et les réglementations spécifiques à chaque ville ajoutent tous leur part de chaos opérationnel. Chaque nouvelle ville apporte des exigences de reporting différentes. Chaque nouveau flux de travail introduit davantage d’alertes, de nouvelles dépendances et plus de risques que des systèmes non liés interfèrent soudainement les uns avec les autres.

Gérer une flotte de 200 trottinettes électriques, bien que ce ne soit pas une tâche triviale, semble encore assez gérable.

Faire passer l’échelle à 2 000 trottinettes réparties dans plusieurs villes, équipes et règles opérationnelles revient à coordonner plusieurs systèmes qui se chevauchent, tandis que les incidents, alertes et mises à jour de flux de travail ne cessent d’apparaître en urgence.

« Tout va bien » © KC Green

C’est exactement la situation à laquelle un opérateur de mobilité partagée a fait face lorsque sa flotte s’est agrandie. Les flux de paiement, le suivi de la conformité, les alertes de sécurité et les automatisations de maintenance sont progressivement devenus difficiles à gérer dans un flux opérationnel unique.

Mais examinons cela plus en détail.

Étude de cas : automatiser l’exploitation de trottinettes électriques en libre-service

Un opérateur de mobilité partagée européen a d’abord abordé le problème sous l’angle de l’expérience utilisateur.

L’entreprise faisait face à une frustration grandissante liée aux retards d’activation de trajets. Les utilisateurs complétaient leur paiement dans l’application, attendaient à côté de la trottinette qu’elle se déverrouille, puis abandonnaient parfois complètement la course si le processus prenait trop de temps.

À plus petite échelle, ces incidents pouvaient être gérés manuellement. Mais à mesure que la flotte s’est développée dans plusieurs villes, les tickets de support liés aux retards de déverrouillage ont augmenté, tout comme les plaintes des utilisateurs et la surcharge opérationnelle.

L’opérateur a décidé d’automatiser le processus de paiement-avant-démarrage à l’aide de IoT Logic.

Note: IoT Logic est un environnement low-code pour la télématique et l’automatisation IoT. Les flux de travail qui nécessitaient auparavant du développement backend personnalisé et des intégrations peuvent être configurés visuellement en moins d’une heure, selon leur complexité.

Le flux initial écoutait un indicateur de confirmation de paiement dans le flux de télémétrie entrant. Une fois que la plate-forme détectait que l’attribut de paiement personnalisé était passé à un état confirmé, le flux déclenchait une commande M2M GPRS automatisée pour libérer le verrou de la trottinette à distance. Dans le même temps, la télémétrie continuait à être transmise à Navixy à des fins de suivi et de surveillance.

L’automatisation en elle-même était relativement simple. Confirmation de paiement détectée, envoi de la commande de déverrouillage.

La latence de démarrage de course a chuté. La fiabilité du déverrouillage s’est améliorée. Les plaintes des utilisateurs ont diminué.

Plus important encore, l’opérateur a constaté à quelle vitesse les automatisations opérationnelles pouvaient améliorer la réactivité de la flotte sans nécessiter d’intégrations fortement couplées ou de développement backend supplémentaire.

Extension aux workflows de conformité et de sécurité

Après avoir automatisé le processus de paiement-avant-démarrage, l’opérateur a commencé à analyser d’autres goulots d’étranglement opérationnels et processus répétitifs qui pouvaient être gérés automatiquement au fur et à mesure de la croissance de la flotte.

La conformité aux limites de vitesse était dictée par les exigences municipales. Dans plusieurs villes d’Europe et des États-Unis, les trottinettes électriques en libre-service sont soumises à une limite de 25 km/h, et beaucoup exigent des opérateurs qu’ils signalent les infractions prolongées. L’opérateur avait besoin d’un moyen de détecter quand un utilisateur dépassait la limite sur plusieurs messages télémétriques consécutifs, en éliminant les pics GPS, et de créer un enregistrement d’incident avec coordonnées, horodatage et ID de l’appareil.

Un webhook node pouvait alors envoyer cet incident à leur CRM, créant un enregistrement de conformité sans intervention manuelle.

La détection de mouvement non autorisé répondait à une autre pression opérationnelle : des trottinettes qui se déplacent alors qu’aucune session de location active n’existe. Ce schéma indiquait souvent un vol ou un sabotage. L’opérateur souhaitait déclencher une alerte à l’équipe d’exploitation, joindre les coordonnées GPS et activer à distance l’alarme embarquée de la trottinette.

La détection de sabotage allait plus loin. L’ouverture du boîtier, le détachement du tracker et les vibrations anormales indiquaient qu’une personne tentait de désactiver ou de voler la trottinette. Ces événements devaient activer immédiatement l’alarme, transmettre la position à Navixy et créer un incident de sécurité pour l’équipe de réponse.

Chaque automatisation répondait à un réel problème opérationnel. Et chacune a d’abord été ajoutée au flux existant.

Pourquoi la configuration initiale a cessé de fonctionner

Comme c’est souvent le cas, cette évolution ne s’est pas faite sans complications.

Cette fois, la raison était une limitation architecturale d’IoT Logic. Un appareil utilisé comme source de données ne pouvait appartenir qu’à un seul flux à la fois. L’utiliser dans une nouvelle automatisation le retirait automatiquement du flux précédent.

La solution de contournement a semblé raisonnable au début. L’opérateur a combiné la logique de paiement, la conformité de vitesse, les alertes de sécurité et la détection de sabotage en un seul grand flux gérant tout à la fois.

Techniquement, cela fonctionnait. Cependant, la maintenance est rapidement devenue difficile.

Chaque nouvelle automatisation rendait ce flux plus fragile. Le dépannage prenait de plus en plus de temps, car la logique de paiement, de conformité, de sécurité et de maintenance étaient toutes interconnectées. Mettre à jour une partie du flux signifiait risquer de perturber des processus non liés dans toute la flotte.

Le système qui visait à simplifier les opérations semblait progressivement devenir un autre goulot d’étranglement opérationnel.

Transition vers des automatisations opérationnelles modulaires

Le point de basculement est survenu lorsque la plate-forme a permis à un même appareil de participer à plusieurs flux IoT Logic indépendants simultanément. Ce qui nécessitait auparavant un seul flux opérationnel surdimensionné pouvait désormais être scindé en domaines opérationnels dédiés sans dupliquer les flux de télémétrie ni coupler des automatisations sans lien.

L’opérateur a reconstruit ses automatisations en quatre flux séparés :

• Flux de paiement : la confirmation de paiement déclenche la commande de déverrouillage
• Flux de conformité : un excès de vitesse prolongé déclenche un incident dans le CRM
• Flux de sécurité : un mouvement non autorisé déclenche une alerte et active l’alarme
• Flux de sabotage : l’ouverture du boîtier ou le détachement déclenche l’alarme et la transmission de la position

Chaque flux recevait la même télémétrie de l’appareil. Chaque flux fonctionnait de manière indépendante. Modifier la logique de conformité n’avait aucun impact sur la logique de paiement. Tester le flux de sécurité ne nécessitait pas de tester le flux de sabotage.

Analysons rapidement ces flux.

Flux 1 : Déverrouillage de la trottinette après paiement

Déclencheur : Un événement de confirmation de paiement apparaît dans le flux de télémétrie, indiquant que l’utilisateur a finalisé sa transaction.

Action : IoT Logic envoie une commande de déverrouillage à distance via GPRS. Le contrôle de sortie de la trottinette s’active, libérant le verrou physique. La session de course commence.

Objectif : Réduire les frictions au démarrage du trajet. Les utilisateurs attendent une réponse immédiate après le paiement. Les retards créent de la frustration et des abandons.

Flux 2 : Signalement d’infraction à la limite de vitesse

Déclencheur : La vitesse dépasse 25 km/h sur plusieurs messages télémétriques consécutifs. Cette exigence de messages consécutifs filtre les pics GPS et les accélérations brèves, ne retenant que les infractions soutenues.

Action : Un webhook crée un incident CRM contenant les coordonnées, l’horodatage, la vitesse relevée et l’ID de l’appareil. L’équipe de conformité reçoit un rapport prêt pour le compte-rendu municipal.

Objectif : Garantir la conformité municipale et la responsabilisation des utilisateurs. De nombreuses villes exigent des opérateurs qu’ils documentent et traitent les infractions de vitesse, sous peine de perdre leur autorisation d’exploitation.

Flux 3 : Détection de mouvement non autorisé

Déclencheur : La trottinette signale un mouvement alors qu’il n’y a pas de session payante active. Ce schéma suggère que la trottinette est déplacée sans autorisation.

Action : Un webhook envoie une alerte à l’équipe d’exploitation avec les coordonnées GPS. Le flux envoie simultanément une commande à distance pour activer l’alarme embarquée de la trottinette. La télémétrie continue à être transmise à Navixy pour le suivi.

Objectif : Réduire le temps de réponse en cas de vol et améliorer la récupération des actifs. L’alarme attire l’attention. Les coordonnées permettent l’intervention. La télémétrie fournit une trace.

Flux 4 : Détection de sabotage

Déclencheur : La trottinette signale l’ouverture du boîtier, le détachement du tracker ou une activité de vibration anormale. Ces signaux indiquent un sabotage physique.

Action : L’alarme embarquée s’active immédiatement via une commande à distance. Les données de position sont transmises à Navixy. Un événement d’incident de sécurité est envoyé au centre des opérations de sécurité.

Objectif : Réduire les temps d’arrêt liés au sabotage et renforcer la protection contre le vol. L’activation immédiate de l’alarme dissuade toute poursuite du sabotage. La transmission de la position facilite la récupération.

Résultats stratégiques pour les opérateurs de mobilité partagée

La séparation des automatisations en flux indépendants a donné à l’opérateur beaucoup plus de flexibilité à mesure que la flotte continuait de croître. Plutôt que de retravailler constamment un seul système surdimensionné, les équipes pouvaient faire évoluer et adapter les workflows de manière indépendante.

Les résultats opérationnels clés incluent :

• Une expansion plus rapide vers de nouvelles villes Les workflows de conformité pouvaient être ajustés aux réglementations locales sans modifier les automatisations de paiement, de sécurité ou de maintenance.

• Moins de risque opérationnel Les problèmes dans un workflow n’affectaient plus les systèmes non liés sur l’ensemble de la flotte.

• Une gestion plus simple des workflows Les équipes de conformité, de sécurité et d’exploitation pouvaient gérer et mettre à jour leurs propres automatisations de manière indépendante.

• Une expérimentation plus sûre avec de nouvelles automatisations De nouveaux workflows pouvaient être testés et déployés progressivement sans rendre l’ensemble du système plus difficile à maintenir.

Faire évoluer les opérations de flotte sans accroître le chaos opérationnel

Pour les opérateurs de mobilité partagée, faire évoluer une flotte n’est plus seulement un problème matériel ou logistique. C’est un problème de gestion des workflows. Plus une flotte s’étend à différentes villes, exigences de conformité, automatisations et équipes opérationnelles, plus il est difficile d’empêcher les systèmes non liés de se perturber mutuellement.

Dans ce cas, la séparation des automatisations en plusieurs flux IoT Logic indépendants a permis à l’opérateur de poursuivre sa croissance sans transformer la couche d’automatisation en un nouveau goulot d’étranglement opérationnel. Et comme l’exploitation de la mobilité partagée continue de gagner en complexité, ce type de flexibilité devient presque aussi important que la flotte elle-même.

Si vous avez limité vos automatisations parce que vos appareils ne pouvaient appartenir qu’à un seul flux à la fois, c’est peut-être le bon moment pour revoir la structure de vos workflows. Réservez une démonstration pour discuter de vos automatisations et explorer comment elles pourraient être gérées avec IoT Logic.