Bravo pour cette belle initiative et ce travail de développement d'une application "d'aide à la décision" !
Cela répondra à celles et ceux (comme moi sur Nice) qui s'adaptent à la situation actuelle et ne choisissent que des courses à moins de 9 kms de distance, dans la majorité des cas.
J'ai regardé le live comme vous et je trouve que cette appli est très intéressante car elle résoud deux problèmes :
- le calcul du taux horaire est précis puisqu' il se base sur des requêtes des GPS et non les temps et les distances volontairement sous-estimés par les applications.
- Le calcul du taux horaire est plus précis que ce que l'on pourra faire mentalement.
Je considère, contrairement à ce qui a été dit plus haut qu'il y a du bon et du moins bon 1EUR du km et ce qui diffère entre le bon et le moins bon, c'est précisément le taux horaire théorique de la course.
Également les algorithmes ne placent pas du tout les chauffeurs sur un même pied d'égalité. Exemple: Entre Platinum et pas Platinum chez Uber, tu sens la différence. Idem chez Bolt et Heetch avec leurs scores d'activité.
Merci pour ces précisions, tu apportes des éléments intéressants !
Sur le calcul GPS vs données appli, c'est effectivement un vrai point fort de Ryven — les temps et distances sous-estimés par les plateformes, c'est une réalité que tout chauffeur connaît. Et sur l'inégalité algorithmique entre chauffeurs, je suis totalement d'accord : entre un Platinum et un chauffeur standard chez Uber, la différence se ressent clairement sur la qualité et le volume des propositions. Je ne travaille pas avec Bolt et Heetch donc je ne peux pas me prononcer sur leurs systèmes de score, mais je pense que le statut influe également sur la commission perçue par Uber — ce qui rajouterait encore une couche d'opacité sur la rentabilité réelle d'une course.
Cela dit, même avec un calcul plus précis, la question reste entière : quel paramétrage utiliserais-tu concrètement dans Ryven ? Quel seuil de taux horaire et quel prix au km seraient tes critères de rentabilité ?
Parce que sur Paris intra-muros en journée, la grille tarifaire moyenne — hors temps d'approche — tourne autour de 1,00 €/km + 15,70 €/h. Le taux horaire sur la course seule monte à près de 31 €/h, mais dès qu'on intègre le temps d'approche — qui représente en moyenne près de 20 % du temps total — il redescend autour de 25 €/h. C'est précisément pour ça que la garantie horaire est éligible sur plus de 70 % des courses effectuées dans Paris.
Ce qui ramène toujours au même constat : la vraie rentabilité dépend avant tout de la stratégie choisie par le chauffeur — son véhicule, sa tolérance aux bouchons, ses horaires — bien plus que du tri des courses en temps réel.
Merci pour ces précisions, tu apportes des éléments intéressants !
Sur le calcul GPS vs données appli, c'est effectivement un vrai point fort de Ryven — les temps et distances sous-estimés par les plateformes, c'est une réalité que tout chauffeur connaît. Et sur l'inégalité algorithmique entre chauffeurs, je suis totalement d'accord : entre un Platinum et un chauffeur standard chez Uber, la différence se ressent clairement sur la qualité et le volume des propositions. Je ne travaille pas avec Bolt et Heetch donc je ne peux pas me prononcer sur leurs systèmes de score, mais je pense que le statut influe également sur la commission perçue par Uber — ce qui rajouterait encore une couche d'opacité sur la rentabilité réelle d'une course.
Cela dit, même avec un calcul plus précis, la question reste entière : quel paramétrage utiliserais-tu concrètement dans Ryven ? Quel seuil de taux horaire et quel prix au km seraient tes critères de rentabilité ?
Parce que sur Paris intra-muros en journée, la grille tarifaire moyenne — hors temps d'approche — tourne autour de 1,00 €/km + 15,70 €/h. Le taux horaire sur la course seule monte à près de 31 €/h, mais dès qu'on intègre le temps d'approche — qui représente en moyenne près de 20 % du temps total — il redescend autour de 25 €/h. C'est précisément pour ça que la garantie horaire est éligible sur plus de 70 % des courses effectuées dans Paris.
Ce qui ramène toujours au même constat : la vraie rentabilité dépend avant tout de la stratégie choisie par le chauffeur — son véhicule, sa tolérance aux bouchons, ses horaires — bien plus que du tri des courses en temps réel.
En ce qui me concerne, j'ai besoin de connaître un taux horaire théorique par course et ryven semble un très bon outil pour cela mais je n'ai pas de paramètre fixe quel que soit le moment dans la journée et dans l'année.
Ma stratégie car je pense qu'il est essentiel d'en avoir une, c'est, dans la mesure du possible, de rester en banlieue ouest à l'exception des aéroports et d'essayer de maximiser en permanence le taux horaire, en ayant toujours en tête le coup d'après (l'endroit où je vais va t'il me permettre de retrouver facilement une course).
Des fois je me dis que je me fais peut être des nœuds dans la tête pour rien, mais mes chiffres ne sont pas mauvais et je ne me prends pas la tête dans des endroits à problème.
Je sais que je manque de patience, donc je ne pourrais jamais travailler dans Paris à chasser la garantie horaire mais comme je ne la touche quasiment jamais, cela signifie que je suis en moyenne au delà de 30 EUR de l'heure de temps de travail effectif.
À la base, je viens du monde de l’informatique.
Je suis développeur depuis plusieurs années, mais avec le ralentissement du secteur, j’ai commencé à faire du VTC.
Et en travaillant tous les jours sur les applications, j’ai vite remarqué un vrai problème.
Un jour, Uber me propose une course à seulement 3 km vers 9h du matin.
Je me dis : “ça va, rapide”.
J’arrive chez le client, je lance la course… 48 minutes de trajet à cause du trafic.
Et là je me suis dit :
“Comment on peut accepter une course sans connaître la vraie réalité derrière ?”
Puis il y a aussi le retour le soir.
Quand tu veux rentrer chez toi, tu hésites à accepter certaines courses, parce que tu as peur de t’éloigner encore plus ou de finir dans une zone compliquée.
C’est exactement de cette frustration qu’est né Ryven
L’idée n’est pas de remplacer les applications VTC, mais d’aider les chauffeurs à prendre de meilleures décisions : mieux voir les temps réels éviter certaines courses peu rentables prendre en compte le retour maison
Ryven est encore au début, mais merci à tous ceux qui testent l’app et m’envoient leurs retours
J'ai dev le même genre d'app, le marché manque de ça.
Mais j'ai mis en standby car le choix de l'api est important quant à l'estimation de temps.
Impossible d'utiliser maps car trop coûteux vu le nb de courses par jour par chauffeur, même un forfait à 5€/mois ne serait pas rentable.
M'enfin, j'attends que tout soit niquel avant de la lancer, notamment côté reviewing et safety audit.
En ce qui me concerne, j'ai besoin de connaître un taux horaire théorique par course et ryven semble un très bon outil pour cela mais je n'ai pas de paramètre fixe quel que soit le moment dans la journée et dans l'année.
Ma stratégie car je pense qu'il est essentiel d'en avoir une, c'est, dans la mesure du possible, de rester en banlieue ouest à l'exception des aéroports et d'essayer de maximiser en permanence le taux horaire, en ayant toujours en tête le coup d'après (l'endroit où je vais va t'il me permettre de retrouver facilement une course).
Des fois je me dis que je me fais peut être des nœuds dans la tête pour rien, mais mes chiffres ne sont pas mauvais et je ne me prends pas la tête dans des endroits à problème.
Je sais que je manque de patience, donc je ne pourrais jamais travailler dans Paris à chasser la garantie horaire mais comme je ne la touche quasiment jamais, cela signifie que je suis en moyenne au delà de 30 EUR de l'heure de temps de travail effectif.
Ta stratégie est intéressante et le fait de toujours penser au « coup d'après » c'est clairement ce qui fait la différence sur le long terme.
Sur ton taux horaire, bonne nouvelle : tu n'as pas besoin de Ryven pour le connaître précisément — Uber te donne déjà toutes les infos nécessaires pour le calculer exactement. Je l'ai fait pour deux chauffeurs : l'un était à 31 €/h, l'autre à 33 €/h. Tu saurais ainsi non seulement si tu dépasses les 30 € de la garantie horaire, mais de combien tu les dépasses — et ça change la perception qu'on a de sa propre rentabilité.
C'est marrant, j'ai pensé quasiment à l'identique à cette app (quelque chose d'approchant et de très simple dans la forme) il y a un peu plus de six mois, quand j'ai commencé à envisager de me lancer dans ce métier, en constatant à quel point l'app mobile des plate-forme est chiche à escient en informations utiles (et ça peut être encore pire, comme je l'ai montré dans ce sujet malgré un espace d'affichage encore plus grand que celui d'un téléphone !). Appelons cette app rebU.
Sans API pour prélever les données depuis l'app Uber Driver, je pensais à faire observer et lire l'écran du smartphone (Screen Scraping) par rebU en tâche de fond, dont le but aurait été, à chaque proposition de course, de faire automatiquement le calcul des km totaux à effectuer (approche + course), pour comparer ceux-ci avec le prix affiché par la plate-forme en indiquant alors à l'écran en surimpression, via une simple division {tarif/total km}, le prix réel de la course en €/km soit dans un rectangle rouge (prix ≪ seuil), jaune (tarif ≈ seuil ± X.XX €) ou vert (tarif ≫ seuil). Le "seuil" étant indiqué par l'utilisateur dans les préférences de rebU (par exemple : 1,30 €/km) et le delta pour passer d'une couleur à l'autre étant à évaluer empiriquement. Ce système permettrait de réaliser immédiatement si une course est rentable, sans avoir à faire grossièrement le calcul de tête à chaque fois. Ce serait une aide à la prise de décision rapide tout en abaissant la charge mentale du chauffeur.
C'était avant que Uber ne propose un filtre dans leur app qui permet désormais de masquer toute course en dessous d'un certain seuil fixé par le chauffeur (en tout cas si cette fonction existait déjà à l'époque, je l'ignorais). Cependant, le seuil Uber n'inclut que les km de la course, pas l'approche. Par conséquent, rebU reste valide puisque cette app calculerait le seuil à partir des vrais km à parcourir pour aller chercher le client et le transporter.
Je précise que j'ai bossé dans l'informatique auparavant, mais que je ne ne suis pas développeur. J'aurais donc dû m'aider de l'IA (par ex Claude Code) voir d'un ami dev pour réaliser l'app en question. J'ai un iPhone.
N.B. : mon idée d'app est évidemment beaucoup plus simple que Ryven car rebU ne cherche pas à connaître le temps passé pour l'approche ou la course via un service de navigation. Ryven est donc supérieur au niveau des possibilités et de l'évaluation.
Messages Fusionnés
J'ai regardé attentivement les vidéos TikTok de
T@testous3 montrant Ryven en fonctionnement en conditions réelles, et je suis très surpris par une chose : si l'app recalcule et affiche correctement la véritable distance de la course (souvent erronée dans l'app Uber) elle ne semble pas du tout prendre en compte la distance d'approche dans le calcul de la rentabilité de la course en €/km.
Ça me semble étrange et malheureux, parce qu'une course avec une approche de dingue, ruinant complètement sa rentabilité, pourra tout de même être déclarée comme "Bonne course" dans l'app ! Dans tous les exemples montrés dans les vidéos, l'approche est ridiculement faible (0,1 km, 0,3 km…) donc indolore, et elle peut être négligée. Mais ce n'est pas toujours le cas !
J'ignore s'il est prévu d'inclure la distance d'approche dans le calcul de rentabilité dans une version mise à jour de Ryven, mais ça me semble incontournable pour que l'app soit réellement exploitable.
Messages Fusionnés
Un exemple avec cette image. Imaginons que la course fait bien en réalité 14,2 km comme ce que Uber prétend (Ryven la calcule aussi à cette même distance). L'app affichera une rentabilité de 25,28/14,2 = 1,78 €/km et indiquera "Bonne course". Sauf qu'en réalité, la véritable rentabilité est 25,28/(7,4+14,2) = 1,17 €/km. C'est pas nul mais tout de suite moins mirobolant.
Pourquoi j'ai créé Ryven
48 minutes de trajet à cause du trafic.
mieux voir les temps réels
