Cockpit
← Projets

TribuLive (API covoiturage + legacy en prod)

Front Nuxt 3 EN PROD sur tribulive.mobi (Netlify/GitLab, master=prod — prudence). Refonte (API Rails + web React) = base du pivot « fournisseur d'API covoiturage ».

À faire

3 te bloquent
  • arbitrage A vs B pour les pages non-covoit te bloque
  • go pour appliquer la data en prod te bloque
  • DNS tribulive.mobi le moment venu (bascule de nuit, par lui) te bloque
  • PARITÉ COVOIT ATTEINTE + EN PROD (PR #16+#17 mergées) : page évènement « comment venir », mise en relation VALIDÉE bidirectionnelle (passager↔conducteur), Mon espace /u/:token (gérer/accepter/refuser/annuler), onglet Liste + filtres + FAQ. Migration DATA complète TESTÉE en local sur le vrai dump (290 fest, 1218 navettes, 8150 trajets, 5116 demandes — 0 erreur, 97,9% contacts OK) → À APPLIQUER sur la DB plateforme prod (import:festivals + import:covoit ALL=1). PUIS bascule DNS Gandi (⚠️ répliquer MX/SPF/DMARC) avant 12/07 → couper legacy. Pages NON-covoit (home, /events liste, organisateur, faq, cgus, EN) = encore 404 sur la refonte → arbitrage A(reconstruire dégradé) vs B(réutiliser le Nuxt existant, pointé sur l'API refonte) REPORTÉ par Sébastien (« plus tard, facile »).

Fait récemment

17 entrées
  • 10 juil.
    🆕 CHANTIER STATS CLIENT (organisateur) lancé — LIVE avant le 16/07 (arbitrage Sébastien). Page où l'orga voit l'activité mobilité de SON événement (covoit actuels, trajets, demandes, mises en relation, navettes, places, CO₂ estimé) + EXPORT (imprimable/CSV) pour le dossier subvention CNM. Double usage : preuve de valeur pricing + bilan mobilité douce. Cible immédiate = Vieilles Charrues 2026 en live pendant le pic. Archi (CTO, validée) : interface sur le NOUVEAU code (front refonte tribugo-web = repo « tribulive-web ») ; données covoit = endpoint agrégé read-only côté LEGACY Rails (tribugo-on-rails, 1 endpoint + HMAC, zéro modif schéma, SQL Couche B portée vers Rails → plus de firewall/cold-start sur le chemin client) ; accès = magic link par event (token=HMAC-SHA256(secret, slug), stateless) ; contrat JSON figé v1.0 (front agnostique de la source, repointable à la migration). Trafic Plausible = phase 2 optionnelle via proxy tribugo-api (clé Stats API en env, JAMAIS côté front). Ticket d'orchestration + contrat figé : `tribugo-api/tickets/2026-07-10-cto-stats-client-organisateur.md`. Répartition : Projet pose/pilote les tickets, CTO exécute+pushe+vue transverse. Gate ops : deploy legacy = brique du festival → test à fond + PR + viser deploy avant le 14/07 ; merge prod = go explicite Sébastien. MAJ 13:30 : contrat v1.0 GELÉ (forme approuvée CTO). Notes d'exé actées : CO₂ basé sur mises_en_relation (1 mise ≈ 1 voiture évitée, plus défendable CNM) ; places_occupees en proxy sur mises si le schéma legacy ne le porte pas ; par_od best-effort ; platform.status piloté par joignabilité DB ; limite v1 = token HMAC déterministe sans expiration (rotation secret = invalide tout). Exécution : CTO prend les lots 2-3-4 en worktrees isolés par repo, owne tous les commits/push (rien en prod sans go Sébastien relayé par moi). Lot 2 (endpoint legacy) DÉMARRÉ. Clé Plausible Stats API déjà créée par Sébastien (testée 200, trousseau plausible-api) → phase 2 sans dépendance. Prochain jalon : endpoint sort VC=58/89/13/31 → vérif conjointe avant branchement front. Deploy visé avant le 14/07.
  • 10 juil.
    ⚡ ARBITRAGE STATS = LEGACY-ONLY POUR LE FESTIVAL. Sébastien tranche : pour Vieilles Charrues (16-19/07) on mesure via Plausible sur le legacy ; la refonte / Couche B = plus tard. (A) Couche A LIVE : le CTO a poussé Plausible (cookieless, sans bandeau) sur les 2 surfaces — master f4a1660 → tribulive.mobi, widget 4023fd1 → widget.tribulive.mobi (1er build widget en 1 an, deps propres vue3-zoomer, build vert). Site Plausible tribulive.mobi créé (essai 9 j, couvre le festival), data-domain=tribulive.mobi, prop surface (site/widget). Events : covoit_page_vue, clic_proposer_trajet/publier_demande/rejoindre/contacter, submit_*, clic_pdf_navette (prop ligne, précieux BreizhGo), bascule_liste, clic_filtre. Netlify payé (Pro actif → 22/07, plus de dunning). VÉRIFIÉE ET CLOSE (CTO) : script HTTP 200 sur les 2 URL prod, pageviews + sources remontent (référents festival-lesdeferlantes.com / lesnuitssecretes.com = preuve que le widget embarqué reporte). Goals posés à la main dans l'UI Plausible (API provisioning bridée Enterprise) : clic_pdf_navette (prop ligne), submit_trajet, submit_demande. (B) Couche B EN PAUSE : commit d301acd (endpoint /api/v1/stats, LegacyRecord read-only, public/stats.html+/dashboard, testé local vs new_prod = VC 58 trajets/89 demandes/13 mises en relation/31 navettes) parqué sur branche `feat/stats-dashboard-couche-b`, NON poussé. Rien engagé sur Render (pas de LEGACY_DATABASE_URL, pas d'IP DO Trusted Sources, pas de warm-up). Gotcha noté pour la reprise : tribulive-api = Render free → cold start (502 au 1er hit) + firewall DO managed (allowlist les 3 IP sortantes statiques du service, visibles seulement dans le dashboard Render). Reprise au « futur projet ». Mapping sessions confirmé : Agent.CTO (local_e9528ad9) = exécutant TribuLive.
  • 10 juil.
    DASHBOARD ACTIVITÉ lancé (délégué CTO). Sébastien veut mesurer le festival Vieilles Charrues (16-19/07). Décision : on RESTE sur le legacy pour le festival (migration après). Deux tickets CTO déposés dans tribugo-api/tickets/ : (A) cto-plausible-front-analytics = Plausible + événements clics sur le front legacy (widget Nuxt widget.tribulive.mobi, repo ~/dev/tribulive-front, master=prod, Netlify en dunning → vérifier deploy) ; Sébastien a déjà un compte Plausible (data-domain à confirmer). (B) cto-stats-dashboard-couche-b = endpoint /stats + dashboard sur la refonte lisant new_prod en read-only, compteurs trajets/demandes/mises en relation + courbe/jour. Dashboard final = A+B. Sébastien crée un agent CTO pour exécuter (prompt fourni). ⚠️ à confirmer : sémantique tables legacy driver_offers/journey_proposals/journeys/passengers avant de compter les mises en relation.
  • 10 juil.
    PARITÉ COVOIT LIVRÉE + EN PROD + DATA VALIDÉE. (1) Mise en relation covoit validée bidirectionnelle (passager sollicite un trajet ↔ conducteur contacte une demande) : mail au propriétaire SANS coordonnées → page /g/:token Accepter/Refuser → échange des coords à l'acceptation ; Sollicitation rendue agnostique (cible = trajet OU demande) ; emails look legacy (Resend). (2) Mon espace `/u/:token` (public/espace.html + API mon-espace) : le publieur voit ses annonces + demandes reçues, accepte/refuse, marque complet, annule ; correction d'une fuite (sorties#dashboard exposait les tel avant validation). (3) Page évènement à parité : onglet Liste fonctionnel, Filtres (types+directions), FAQ (9 Q/R reprises du legacy) + footer. → PR #16 + #17 MERGÉES, déployées Render, 34 specs vertes. (4) Migration data complète TESTÉE en local sur ~/tribulive-new_prod-2026-07-06.dump (chargé dans docker tribulive_legacy) : import:festivals + import:covoit ALL=1 → 290 fest, 1218 navettes, 8150 trajets, 5116 demandes, 0 erreur, 97,9% contacts exploitables, flux end-to-end validé sur une vraie conductrice. PAS encore appliquée à la prod plateforme. (5) Garde-fou emails hors-prod (interceptor → smaurette@gmail.com, dev/test only) = PR #18 OUVERTE (dev-only, pas besoin de deploy) ; feature « recevoir en Gmail » en pause. (6) Ticket client Vieilles Charrues FAIT : 14 fiches buses (event 401) mises à jour 2026 via SQL ciblé sur la base legacy live new_prod (backup tribugo-api/tmp/vc-buses-backup-20260710-111128.sql), vérifié via l'API du widget (0 lien périmé) ; Finistère+Morbihan→flyers 2026, Rennes+Loudéac→Ligne 229 été, Gare de Rennes→TER ; brouillon email prêt (signé Sébastien) ; récap dans tickets/…-REPONSE.md. Le « point 1 édition 2025 » = faux positif (le widget est déjà en 2026).
  • 9 juil.
    VEILLE : le covoit Hellfest 2026 (client perdu) est opéré par StadiumGo en marque blanche sur transport.hellfest.fr — preuve technique (même build que stadiumgo.fr, CDN multi-tenant), basculement daté par archive.org : TribuLive au 2025-06-16 → StadiumGo au 2026-04-11. StadiumGo déborde du sport vers les festivals via son offre B2B business.stadiumgo.fr (déjà : FFF, GP Explorer, UTMB). Rapport : rapports/2026-07-09-enquete-festicar-stadiumgo.md
  • 7 juil.
    ⚡ DÉCISION (Sébastien via CFO) : COUPER le legacy, BASCULER tribulive.mobi sur la refonte. Le legacy est « pourri », on ne le lift/reconstruit PAS. Front dégradé (textes succincts) accepté, tant que parité fonctionnelle avec l'actuel : annuaire festivals (logos+dates+lieu), covoit sans compte, navettes/transports (MarqueurMobilité), carte, GPX, emails (Resend), dashboard orga. Audit coûts CFO : legacy = ~220€/mo en dunning (DO 73$ past-due 12/07, Netlify 67€, Cloudinary 99$), tout se coupe seul sous ~2 semaines. Data à migrer minuscule : DB new_prod 30 Mo (dump ~/tribulive-new_prod-2026-07-06.dump) + médias 51 Mo / 623 originaux mappés 1:1 (cockpit-data/rapports/migration-tribulive/media-manifest.csv). Séquence imposée : parité → bascule DNS → PUIS couper (covoit LIVE en pic festival, zéro downtime). Ticket : `tribugo-api/tickets/2026-07-07-DECISION-bascule-refonte-couper-legacy.md` — CTO doit rendre analyse d'écart + ETA (avant 12/07 possible ? sinon on paie 68$ DO pour tenir).
  • 6 juil.
    IFRAME PÊCHE (coordination lancée). Route GET /embed?source=&spot_slug= sert carte.html avec framing autorisé (frame-ancestors *, X-Frame-Options retiré) + cache 120s (itération à deux sans cache 1 an) — commit 6ec9d52, déployé. Framing vérifié en ligne. Staging pêche seedé : 5 spots démo Lauragais (Vallègue×2, Ganguise, Thésauque, Saint-Ferréol, Lenclas), 6 sorties. Snippet iframe + partage des rôles envoyés à la session Pêche (« Bathymetry/Vallègue », local_1bba9692) : elle pose l'iframe dans peche-lauragais (je n'y touche pas), me donne sa convention de slug pour aligner les pins. Sébastien a autorisé les modifs staging.
  • 6 juil.
    DÉPLOYÉ + PHASE B (« les deux »). DÉPLOIEMENT : Phase A + carte poussés sur main → Render live (migration a DROP sorties/demandes du staging = reset assumé). PHASE B codée/déployée : MarqueurMobilite (ex-Bus généralisé) + CoucheGpx (vélo), endpoint GET /api/v1/carte?source=&spot_slug= (covoit sans tel + marqueurs + traces), carte.html étendue (pins covoit + transports typés emoji + lignes GPX + légende), rake demo:festival. Carte multimodale VÉRIFIÉE en preview (1 covoit + 5 transports + tracé vélo, screenshot). Staging live : /carte.html?source=peche|festival-demo (covoit seedé via API publique ; marqueurs/traces PAS seedés sur staging car garde-fou a bloqué l'écriture DB distante). Tuiles OSM = proto (bloquées en sandbox, OK en prod ; prévoir MapTiler). Commits 6eddd5e (carte), cbd16df (Phase B).
  • 6 juil.
    PROTO ÉTOFFÉ (Sébastien : « on peut casser, informer plus tard ; proto rapide et sympa connectable pêche+rando »). (1) Multi-source validé : même back sert peche (spot_peche) ET oslow/rando, isolation par source (commit 90ba53f). (2) Carte covoiturage embeddable MapLibre (public/carte.html?source=…) : pins par lieu, popup sorties, badge TribuLive, servie par l'API (commit 6eddd5e) — vérifiée en preview, 3 pins issus des données live. Roadmap proto : 1)multi-source ✅ 2)carte embed ✅ 3)déployer staging 4)API propre /trajets 5)Phase B festival (marqueurs mobilité, GPX, mode validation, orga). Tuiles = OSM proto ; prévoir vrai fournisseur (MapTiler, comme legacy) en prod.
  • 6 juil.
    PHASE A CODÉE & TESTÉE (commit local ea32697, non déployé). Modèle cible interne en place : Destination (find_or_create par source+slug, mode echange_direct|avec_validation) / Trajet (ex-sortie) / Sollicitation (ex-demande, initiee_par passager|conducteur + statut ; mode direct => acceptee + 2 emails). TrajetMailer remplace SortieMailer. L'API publique /api/v1/sorties reste 100% identique (routes, payloads, statut remappé active|complete|annulee, forme demande inchangée) => pêche non impactée. Testé bout-en-bout en local (docker). ⚠ La migration DROP sorties/demandes => déploiement à coordonner avec la Direction (reset base test). Push gated.
  • 6 juil.
    MODÈLE DE DONNÉES CIBLE écrit (docs/modele-cible.md, commit local 8b3e0d1). Audit legacy (tribugo-on-rails Rails 7 + tribulive-front Nuxt) fait. Direction validée par Sébastien : back UNIQUE multi-fronts, vocabulaire arrêté = Destination / Participant / Conducteur+Passager / Trajet / Demande (annonce passager autonome) / Sollicitation (contact avec initiee_par passager|conducteur + statut, règle les 2 sens) / MarqueurMobilité (ex-Bus) / CoucheGPX (vélo, aujourd'hui hardcodé front) / Organisateur. Interrupteur par destination : echange_direct (pêche) vs avec_validation (festival). Phasage : Phase A (pêche/rando) puis Phase B (festival). Données réelles Déferlantes vérifiées via API (5 navettes, 20 conducteurs, 44 demandes ; vélo GPX PAS en base). Legacy intouché.
  • 6 juil.
    CORS DÉBLOQUÉ POUR LA PÊCHE ✅ (chemin critique Direction). Ajouté http://localhost:3003 + https://peche-lauragais.onrender.com à FRONTEND_URL (Render), redéployé (le PUT env seul ne redéploie pas → redeploy explicite nécessaire). Preflight OPTIONS validé sur les 2 origines (allow-origin renvoyé, methods GET/POST/OPTIONS, headers Content-Type, credentials true) + contrôle négatif OK. Direction prévenue (cross-session). Sébastien tranche : on RESTE en dev/staging sur tribugo-api.onrender.com, PAS de renommage service ni domaine pour l'instant (gelés). 2 sorties de test laissées en base par la Direction (« TestDir »).
  • 6 juil.
    DÉPLOYÉ EN LIGNE ✅ PR #15 mergée dans main → auto-deploy Render. Le boot a d'abord échoué : l'ancienne base Postgres gratuite (dpg-d83h…) avait expiré/disparu, DATABASE_URL périmée. Créé une nouvelle base tribulive-db (free, Frankfurt), reposé DATABASE_URL, redéployé → LIVE. Smoke-test prod OK sur https://tribugo-api.onrender.com : health 200, créer sortie, liste publique (sans tel), demande (201), dashboard (coords + wa.me). SMTP Resend actif en prod. ⚠ Le dashboard web (tribugo-web.vercel.app) appelle encore l'ancien endpoint B2B, pas les sorties → lot 2. Renommage marque non fait (garde-fous).
  • 6 juil.
    LOT 1 CODÉ & VÉRIFIÉ (proto, Opus). API Sorties dans tribugo-api : modèle Sortie/Demande dédié (découplé du B2B), 6 endpoints (create, index public sans tel, demandes avec échange coords immédiat, annuler/completer token, dashboard/me/:token), 4 emails wa.me (MailHog), rate-limit IP + honeypot + 1 demande/tel/sortie, tel normalisé E.164. Flux testé bout-en-bout en local (postgres+mailhog docker), tout vert. Commit 5cbffa4. ⚠ La Direction a poussé un contrat v1.1 pendant le dev (départ géocodé Nominatim + filtre « autour de moi ») → non couvert, à faire en lot 1b (commit 17162f1). Renommage lot 0 pas encore fait.
  • 6 juil.
    PLAN MVP DÉPOSÉ (session projet, Fable) dans le ticket mission. Audit : la refonte (API Rails 8 + web React/MapLibre) couvre déjà ghost users/magic link, dashboard /u/:token, carte embed, emails — base retenue ; legacy intouché (frontière actée) ; modèle « Sortie » dédié (Event/Journey/Booking impose une acceptation, interdite par le contrat) ; 5 lots (0=renommage, 1=API staging → la pêche se branche, 2=dashboard+CGU, 3=carte embed, 4=prod/RGPD). En attente arbitrage Direction sur 4 points (§8), dont domaine : api.tribulive.mobi est PRIS par le legacy → reco achat tribulive.fr.
  • 6 juil.
    PIVOT DÉCIDÉ (Sébastien, via session Direction/Pêche) : TribuLive garde son nom et devient FOURNISSEUR D'API COVOITURAGE pour les sites passion (pêche = 1er client, OSLOW ensuite) — retour à l'ADN d'origine : pas de compte, 3 clics, coordonnées échangées par message (email+wa.me en MVP, SMS phase 2), dashboard privé /u/:token, carte. Contrat d'interface v1 rédigé par la Direction + ticket mission déposés dans les tickets du repo API. La session projet doit d'abord ÉVALUER l'existant (no-auth flows/ghost users côté API, dashboard+carte côté web, frontière avec legacy tribulive-front) et proposer son plan MVP. ⚠ MARQUE : TribuLive est LA marque — l'ancienne (attaquée par Trivago pour proximité de nom) ne doit plus apparaître nulle part ; renommage des repos/services techniques au plan de la session
  • 18 juin
    Front legacy maintenu en prod sur tribulive.mobi