C

Devlogs

septembre 2026

Unifications arrêtsvelogrimpe#

Suite du devlog abstraction arrets

Gros travail de spécification à partir du premier jet fait par Florent. J’ai finalement opté pour un découplage de Motis car c’est très contraignant et demande d’avoir déjà résolu tous les problèmes liés à Motis pour démarrer un quelconque chantier. Contraignant car ça limite les arrêts disponibles à ceux existants dans Motis et ça pose le problème des doublons issus de plein de datasets différents (typiquement provenant d’opérateurs différents) sans référentiel commun.

Une journée de spécification, et j’ai pu lancer l’IA sur le chantier en l’obligeant à tout faire étape par étapes avec des recettes intermédiaires pour me permettre de ralentir le rythme et de faire plein de remarques au fur et à mesure. C’est le minimum pour ne pas me faire larguer. Je reste malgré tout très loin du code.

Je suis partagé sur cette décision, mais php et vue.js n’étant pas mes langages de travail, je suis trop lent et incompétent pour avancer sereinement et effectivement sans IA. Un jour je réimplémenterai (peut être) l’ensemble du site (pour en faire une app, qui sait ?), ou d’autres le feront, mais pour le moment, c’est le mieux que je peux faire pour faire avancer le site dans ses projets ambitieux.

Gestion des contenus statiques (suite)velogrimpe#

Suite du devlog contenus statiques

Ça y est, la migration est enfin faite. Le système est en fait assez simple, mais j’en ai profité pour faire une petite refacto des accès au disque. Maintenant tous les accès au disque passent par des utilitaires qui vont déterminer le base_path des contenus statiques et il y a plusieurs fonction pour former des paths et vérifier l’existence.

Je n’ai finalement pas complètement conservé le mode de fonctionnement prévu. On a bien un dossier public en mode symlink qui pointe vers un dossier hors du chemin d’hébergement (public_html dans le cas de hostinger). Mais je n’ai pas conservé la structure identique bdd/XXX —> public/bdd/XXX. J’ai été un peu plus loin et supprimé le dossier intermédiaire bdd + fait du ménage dans les fichiers. Et j’ai des règles dans le .htaccess qui vont rediriger bdd/xxx vers public/xxx, ce qui permet de conserver toutes les anciennes URLs (dont celles existantes dans les mails).

Je n’ai par contre finalement pas touché au dossier images qui contenait majoritairement des assets, et j’ai supprimé tous les fichiers qui n’avaient rien à faire là.

Pour open-data, c’était plus simple, il suffisait d’exporter vers le dossier public et de modifier le download.php pour qu’il pointe vers ce nouvel emplacement.

Quelques coquilles sur la migration mais ça s’est plutôt bien passé^[J’ai utilisé pas mal l’IA sur ce developpement car je voulais qu’il se termine en moins d’un jour et que je ne suis pas bien à l’aise avec les concepts et fonctions PHP. Ça m’empêche de progresser en PHP, mais bon. Si j’avais 100% de mon temps là dessus, peut être que j’aurais accepté de passer par la phase d’apprentissage. Avant l’IA, je ne me serais pas posé la question et ça aurait pris le temps nécessaire, mais là, c’est de plus en plus difficile de faire l’effort.].

Gestion des contenus statiques (suite)velogrimpe#

Suite du devlog contenus statiques

Première étape en production. On peut maintenant récupérer des contenus via les deux URLs exemple:

Les données ne sont pas encore mises à jour dans le dossier public/.

Prochaine étape : faire écrire dans les deux dossiers en même temps.

Cool URLs do not change

Note pour plus tard, à ne pas oublier : à la fin écrire des règles de redirections pour tous les contenus de bdd (pas d’exceptions), images (plein d’exception) et open-data (une exception)

Utilitaires pour la modification des arrêts de busvelogrimpe#

Les arrêts de bus étaient modifiables, mais rien ne référençait ce mode. Ajout d’un selecteur côté admin.

Gestion des contenus statiques (suite)velogrimpe#

Suite du devlog contenus statiques

Toujours dans le but d’éviter les dégats sur les fichiers statiques qui sont super précieux.

Mon plan est de commencer par dupliquer le contenu vers le dossier public et d’ajouter un symlink versionné de public_html/public vers le dossier public/ à la racine. On verra déjà si les contenus sont accessibles.

La migration devrait ensuite être assez facile en remplaçant progressivement des urls /bdd/ par /public/bdd etc.

nouvelle abstraction Arrets (suite)velogrimpe#

Suite du devlog précédent

L’idée naïve serait de:

  1. renommer la table gares en arrets et de rajouter une colone type permettant d’identifier le type d’arrêts (defaut: ter / tgv pris de la colone train_tgv)
  2. Pour choisir une gare de départ d’itinéraire vélo, laisser toutes les possibilités
  3. Quand c’est nécessaire (filtres, exploiter le champ type pour filtrer)

Une idée plus sophistiquée serait d’utiliser des tables d’association, mais ça rajoute beaucoup d’opacité et de complexité. J’aimerais bien éviter si je peux.

Problèmes que cela m’évoque:

  • Que faire des gares multi-modales ? (actuellement les gares ter + tgv sont marquées tgv)
  • Comment relier les arrêts aux villes ?
    • Dans la version actuelle, les villes sont structurantes, mais il n’est pas prévu de relier un arrêt de bus à une ville, donc pas mal d’exceptions à traiter
    • Dans la version future, où toutes les durées sont calculées automatiquement (durées réelles min), les itinéraires bus seront surement absurdes, avec beaucoup de correspondances etc. Et comment les calculer ?
      • Si on veut pouvoir calculer un itinéraire, il vaudrait mieux sourcer les arrêts sur les bases de données issus des flux GTFS

Bon, ça a l’air de faire émerger quelques idées intéressantes:

  • Sourcer les données arrêt sur transitous / Motis
  • Dédoublonner les données existantes (ça devrait se faire, on a les codes gare sncf, utilisés dans les gtfs sncf)
  • Les gares multi-modales sont en doublons, comme sur Motis finalement, donc un seul type.
  • Faire évoluer la table gares pour accueillir les arrêts
  • Dans le futur, on devra pouvoir calculer des itinéraires de n’importe où vers un arrêt (via Motis). Les seuils de temps max / corresp. max permettront de faire le lien ville - arrêt. Avec quelques limitations.:
    • on n’aura jamais (p=99.9%) l’information vélo accepté
    • il peut y avoir des trous dans la couverture de Motis
    • Les données transport évoluent dans le temps
  • Il serait bien de refondre la notion de ville:
    • Lister les arrêts présent dans une ville
    • Itinéraires ville - arrêt —> ville (gare) - arrêt

Toujours pas de code, mais l’idée commence à faire son chemin. Voyons ce que ça donnera dans quelques jours.

août 2026

nouvelle abstraction Arrets (gares, bus, téléphériques)velogrimpe#

On a récemment ajouté la gestion des arrêts de bus : permettre de les ajouter via un formulaire, d’en lier plusieurs avec des informations de ligne de bus, les afficher sur la page falaise, les lier aux falaises etc.

C’est pour le moment assez peu intégré dans l’application : une falaise qui ne serait relié qu’à un arrêt de bus apparaitra encore hors topo. Et d’ailleurs il est impossible de créer des itinéraires vélo au départ d’un arrêt de bus.

L’idée générale de ce développement serait de regrouper les gares, arrêts de bus et tout autre arrêt de transport en commun (téléphérique, tram, …) sous une même abstraction, de permettre de créer des itinéraires vélo depuis ces arrêts, de relier ces arrêts à des villes.

Sujet important et très structurant. Besoin de réfléchir plus.

édition itinéraire velovelogrimpe#

On a travaillé avec Florent sur un formulaire de validation et d’édition des itinéraires vélo.

  • Problème (flow actuel de flo)
  • Editeur
  • Complexité
  • Aspects sécuritaires (depuis le hack, je me méfie des uploads)
  • Pour le moment en prod cachée, reste à linker ça partout

voletcartovelogrimpe#

On travaille depuis un moment sur le passage à MapLibre pour la carte principale de velogrimpe.fr, pour permettre plus de fluidité dans le zoom (entre autre). Pendant ces tests de migration, j’en ai profité pour réduire le scope des informations des falaises que l’on transfère entre PHP et JS et donc transporté avec la page dans le html. J’avais oublié de vérifier les données utilisées dans le petit panneau en bas à droite de la carte, le fameux champ falaise_voletcarto qui contient un bref descriptif de la falaise, idéal pour se faire une idée depuis la carte.

J’en ai profité pour fixer un ou deux bugs sur la version maplibre.

gestion des contenus statiquesvelogrimpe#

J’ai commencé à travaillé sur la gestion des contenus statiques. Actuellement on les sert depuis l’intérieur du code, dans un sous-dossier bdd.

  • On a eu des PB (hack)
  • J’ai réglé le PB (comment)
  • J’ai d’autres PB (hostinger)
  • Je cherche une solution de repli (warning cas des pmtiles)