Comment j’ai développé un Strava pour les promenades de mon chien
Mai 2026
J’ai un chien et je dois reconnaître une chose.
La majorité des promenades sont d’un ennui déconcertant.
Tout maître le reconnaîtra avec une forme de honte : promener son chien consiste avant tout à suivre mécaniquement un itinéraire connu et répété des centaines de fois. La même rue, le même parc, le même trottoir, puis le chemin du retour…
Pas nécessairement parce qu’il s’agit de la meilleure promenade possible. Simplement parce que ce trajet répond à trois caractéristiques : il est pratique, familier et ne demande aucune réflexion.
En promenant mon chien Hubert dans les rues de Paris, j’ai commencé à me dire qu’il méritait un peu plus que ça. Je me suis alors efforcé de varier les parcours de balade, et j’ai commencé à explorer de nouvelles rues, de nouveaux chemins, de nouveaux itinéraires…
Hubert. Not Uber. © ML
Une fois cette nouvelle routine adoptée, je me suis demandé comment je pouvais conserver une trace de ces nouvelles explorations. J’ai voulu analyser tout un tas de données : quelles rues avons-nous prises ? Quel chemin parcourons-nous le plus souvent ? Quelle est la durée moyenne de nos promenades ? Quel a été le rythme de ces balades ? Quelle distance avons-nous effectuée ? Non pas pour transformer nos balades en une performance, mais plutôt pour mieux observer nos habitudes.
Les applications de suivi d’activité ont installé un modèle où les déplacements physiques et géographiques peuvent être transformés en des enregistrements structurés. Or, ni mon podomètre personnel, ni mon Strava ne me permettaient de recenser des données, spécifiquement aux promenades d’Hubert. Or, la promenade d’un chien repose précisément sur les mêmes signaux : mouvement, rythme, durée, tracé…
© ML
La question n’était donc pas de reproduire un Strava en ajoutant des chiens à l’interface. Il s’agissait plutôt de comprendre si la promenade pouvait disposer de son propre système de mesure. Un système qui analyserait non pas la performance, mais la routine et l’exploration.
Cette question est devenue The Dog Walk Map.
Je ne suis ni ingénieur, ni développeur. Mais avec l’émergence des IA génératives, je crois qu’il est désormais possible de construire toute une panoplie de produits dont l’utilisation peut être personnelle ou professionnelle. À condition de maîtriser certaines bases des LLM, il est possible pour toute personne un peu curieuse de créer des services, des produits, des interfaces, des outils internes, des automatisations, des visualisations de données…
Et c’est ce dont il s’agit avec The Dog Walk Map.
Qui promène qui ?
Sur le papier, le produit est assez simple :
L’utilisateur lance une promenade
Le téléphone enregistre sa position
Les coordonnées sont reliées sur une carte.
Et à la fin, l’application calcule quelques indicateurs et conserve la sortie dans un historique.
Mais le choix technique le plus important était aussi une limite fondamentale du produit. Je me suis posé une question principale : les micro-déplacements d’Hubert doivent-ils être intégrés à l’activité ? Si, par exemple, il s’éloigne pour renifler un muret et qu’il revient vers moi, ces mouvements doivent-ils être comptabilisés dans les données ?
Le cas échéant, une friction apparaissait d’emblée : il aurait fallu ajouter un collier connecté, une balise GPS ou un capteur à l’animal. Or, ne souhaitant pas apporter de complexité à l’utilisateur, j’ai préféré que The Dog Walk Map ne suive pas le chien, mais le meilleur capteur immédiatement disponible : c’est-à-dire le téléphone déjà présent dans la poche du propriétaire qui le promène. J’avais la base : le trajet représenterait donc le déplacement du propriétaire pendant l’activité partagée.
La Carte et le Territoire. © ML
J’ai bien conscience que ce produit ne permettrait pas de mesurer précisément chaque mouvement du chien. Mais dans la plupart des situations, cette approximation est largement suffisante pour répondre au besoin principal : connaître le tracé, la durée et la distance de la promenade.
Le projet reposait donc sur une logique de proxy : mesurer une activité partagée à partir du déplacement de l’humain qui l’accompagne.
“Allez, on y va !”
Dans la phase d’idéation, j’ai immédiatement voulu pousser le concept plus loin : j’ai imaginé la possibilité de renseigner différentes races de chiens, des objectifs hebdomadaires, des recommandations de parcours, des comparaisons entre quartiers ou des fonctions sociales…
Mais, je me suis finalement cantonné à une V1 qui devait répondre à une question beaucoup plus simple : une promenade peut-elle devenir intéressante lorsqu’elle peut être retrouvée plus tard sous la forme d’un tracé et de quelques données ?
J’ai donc limité le prototype à une boucle courte :
Ouverture de l’application
Lancement d’une nouvelle promenade
Choix du type de sortie
Enregistrement du déplacement
Fin de la promenade
Sauvegarde de son tracé et des principales données
Possibilité de retrouver la promenade dans un carnet
Cette limitation du périmètre m’a paru essentielle et m’a obligé à construire une expérience complète plutôt qu’une série de fonctionnalités inachevées. L’application devait raisonnablement avoir un début, un état actif et une fin compréhensible.
Du code au tracé
L’interface se devait d’être efficace et intuitive. La page d’accueil repose sur un principe simple : une carte et un bouton “Démarrer la promenade”. Puis, une proposition de types de sorties.
Dans une première version, j’avais positionné le choix du type de sortie directement sur l’écran principal. Mais cet élément occupait trop d’espace visuellement alors qu’il n’était utile qu’au moment du départ effectif de la balade. Je l’ai donc déplacé dans l’étape suivante.
Let's take a walk on the wild side. © ML
L’utilisateur voit d’abord la carte. Après avoir cliqué sur le bouton “Démarrer la promenade”, une carte de sélection s’ouvre et lui permet d’indiquer le type de promenade : une sortie courte, une sortie longue, une sortie au café ou en terrasse, une sortie dans un parc ou dans un bois.
Une fois la décision prise, l’enregistrement démarre.
Ce changement paraît modeste, mais il a rendu l’interface plus lisible. Il permettait aussi de mieux distinguer les différents états du produit :
L’application est prête
L’utilisateur prépare une sortie
Le suivi GPS est actif
La promenade est terminée
La promenade est enregistrée
Pour un produit de suivi, ces états sont plus importants que la décoration de l’interface. L’utilisateur doit comprendre immédiatement si le système est en train d’enregistrer sa position. Une ambiguïté à ce niveau rendrait toutes les données suivantes difficiles à interpréter.
La construction du prototype
J’ai développé l’application avec React et Vite. La carte repose sur Leaflet, avec des fonds cartographiques issus d’OpenStreetMap. Le navigateur accède à la localisation du téléphone et transmet régulièrement de nouvelles coordonnées.
Chaque nouvelle position est ajoutée à une liste chronologique de points. Leaflet relie ensuite ces points sous la forme d’une ligne sur la carte.
Le système conserve séparément :
La position actuelle du propriétaire
Les points déjà enregistrés
Le statut de la promenade
Les informations associées à la sortie
Les promenades sauvegardées
Je le répète : je ne suis pas développeur, mais l’IA permet d’aiguiller chacun vers les bonnes questions.
Mon point de départ était donc moins le code que le modèle d’information : que faut-il montrer ? Dans quel ordre ? Qu’est-ce qu’une promenade terminée ? Quelles données doivent être conservées ? Que doit-il se passer lorsque l’utilisateur revient dans son historique ?
© ML
Là encore, j’ai utilisé l’IA pour accélérer certaines étapes de développement : générer des premières fonctions, interpréter des erreurs, corriger des comportements et traduire mes intentions produit en logique technique.
Mais l’IA ne pouvait pas décider à ma place de la structure de l’expérience. Je devais donc décrire précisément chaque comportement, tester le résultat et comprendre pourquoi certaines modifications fonctionnaient ou en cassaient d’autres.
Une promenade en pointillés
Concernant le tracé, j’ai constitué une suite de points GPS ordonnés dans le temps. Pour obtenir la distance, l’application calcule la longueur du segment entre deux positions consécutives, puis additionne progressivement ces segments.
La durée, quant à elle, repose sur l’heure de départ et l’heure de fin. Des indicateurs supplémentaires, comme la vitesse moyenne, peuvent ensuite être dérivés de ces mesures de base.
Datadog © ML
J’ai compris que la difficulté ne résidait pas seulement dans la réalisation des calculs, mais dans la qualité imparfaite du signal.
En effet, le GPS d’un téléphone peut dériver alors même que son propriétaire reste immobile. En ville, les immeubles peuvent également dégrader la précision. Un seul point aberrant peut créer un segment artificiellement long et fausser la distance.
Ce prototype n’intègre pas de système avancé de filtrage ou de lissage comme sur les applications Strava ou Uber.
C’est une de ses limites assumées. Une version plus robuste devrait examiner la précision de chaque relevé, ignorer les déplacements improbables et filtrer les points aberrants avant de les intégrer au parcours.
Construire un carnet plutôt qu’une carte isolée
Pour rappel, l’objectif initial était de sauvegarder l’ensemble des promenades que je réalisais avec Hubert afin d’observer les différents chemins que nous empruntions ensemble. Aussi, l’idée consistait à comparer ces données de jour en jour et d’améliorer la qualité des balades.
Or, le produit a peu de valeur si chaque promenade disparaît lorsque la page est fermée. J’ai donc ajouté le fameux Carnet de promenades.
Le principe est simple : à la fin d’une sortie, le tracé et ses informations principales sont sauvegardés dans le stockage local du navigateur. L’utilisateur peut ensuite consulter la liste de ses promenades et rouvrir l’une d’entre elles sur la carte.
Who let the dog out ? © ML
Ce choix, plus simpliste, m’a permis d’éviter de devoir construire immédiatement un système de comptes, une base de données et une infrastructure distante.
Il rendait le prototype beaucoup plus concret : la promenade n’était plus seulement visible en direct, elle devenait un élément d’un historique personnel.
Cette partie a demandé plusieurs corrections.
À un moment, une promenade apparaissait correctement dans la liste, mais le bouton permettant de la consulter ne réaffichait pas le bon parcours sur la carte. Le problème ne venait pas de la carte elle-même, mais de la manière dont la promenade sélectionnée était reliée aux données sauvegardées.
C’est un exemple représentatif du travail réel sur le prototype : une interface peut sembler fonctionner, alors que la continuité entre ses différents états reste incomplète.
1 promenade = 1 test
Un outil de géolocalisation ne peut pas être validé uniquement depuis un ordinateur posé sur un bureau.
J’ai donc d’abord lancé le serveur de développement sur mon réseau local afin d’ouvrir l’application depuis mon téléphone. Puis j’ai déployé le projet sur Vercel pour obtenir une adresse HTTPS accessible en dehors de mon Wi-Fi.
Le chien mène, les données suivent. © ML
Cette étape était nécessaire, car les navigateurs mobiles encadrent strictement l’accès à la géolocalisation.
Le premier test réellement significatif a donc eu lieu dehors, à Paris, dans le 11e arrondissement. Il a consisté à :
Ouvrir l’application sur Safari
Autoriser l’accès à la position
Démarrer une promenade
Marcher
Observer la ligne se construire sur la carte
Terminer la sortie
Vérifier sa présence dans le carnet
C’était bon. Le prototype fonctionnait.
Les limites du produit
The Dog Walk Map permet aujourd’hui de transformer mes déplacements pendant une promenade avec Hubert en un enregistrement composé d’un tracé, d’une durée, d’une distance et d’un historique.
Toutefois, il ne mesure pas le comportement précis du chien (les aller-retours, la dépense énergétique...). Il ne sait pas dans quelle direction Hubert regarde. Combien de mètres il parcourt réellement. Combien de temps il passe à renifler.
Pour cela, il aurait fallu un capteur porté directement par l’animal.
Mon prototype répond à une ambition beaucoup plus étroite et purement fonctionnelle : conserver une trace structurée des promenades de mon chien à partir de mon téléphone — que je transporte déjà.
Parmi les principales limites qui sont identifiées à date :
Le suivi web en arrière-plan reste fragile, notamment lorsque l’iPhone est verrouillé
Les données GPS doivent être davantage filtrées
Le stockage local ne permet pas de retrouver ses sorties sur un autre appareil
La valeur de l’historique dépend de son utilisation dans le temps.
Selon moi, ces limites ne remettent pas en cause le prototype en tant que tel. Elles définissent précisément son usage et les conditions nécessaires pour aller plus loin lors d’une éventuelle V2.
Fin de parcours
En résumé, The Dog Walk Map est né d’une question très simple : où Hubert et moi sommes-nous réellement allés pendant cette promenade ?
Pour y répondre, j’ai dû traduire une activité quotidienne en une succession de règles explicites : quand l’enregistrement commence, quelles données sont captées, comment elles sont calculées, comment elles sont conservées et ce que l’interface peut raisonnablement en dire.
Je n’ai pas construit un produit fini, ni un système capable de suivre chaque mouvement d’Hubert. J’ai construit, grâce à l’IA générative, une première réponse cohérente à un besoin concret : transformer une promenade partagée, habituellement éphémère, en une trace que l’on peut retrouver, consulter et comparer.
Alors, après tout cela, une question reste en suspens.
Hubert est-il plus heureux aujourd’hui ?
Je ne sais pas. Mais moi, je le suis.
À propos
Ancien journaliste, Maxime Lebufnoir a fait évoluer sa pratique au rythme des transformations de son métier. Entre l'essor de la donnée et celui de l’IA générative, il conçoit aujourd'hui des systèmes éditoriaux, des produits et des workflows qui transforment la recherche, les données et l'IA en contenus utiles et impactants. Il a notamment travaillé pour Airbnb, Rover, l’AFP ou TF1.