Un système de réservation taxi sans cookie, sans backend, sans GAFAM

Quand Ghislain, chauffeur de Taxi Ghis à Belfort, m'a demandé un site de réservation, j'ai commencé par regarder ce que la concurrence vend aux indépendants : des SaaS américains à 80-150 € par mois, avec une interface Booking-like, vingt-cinq sous-traitants listés dans la PdC quand elle existe, un bandeau cookies à trois colonnes, et la jolie ligne « vos données peuvent être transférées aux États-Unis » noyée à la fin. Pour un chauffeur unique qui veut juste recevoir des demandes de course par mail, c'est une usine à gaz qui résout des problèmes qu'il n'a pas.

Cet article décrit l'architecture qu'on a construite à la place : un site Next.js statique, un formulaire de réservation qui appelle des API européennes, et une boîte mail Outlook qui sert de base de données. Pas un proof of concept — c'est en production depuis avril 2026 sur www.taxighis.com.

Le brief : un chauffeur, une boîte mail, zéro back-office

Taxi Ghis, c'est un chauffeur conventionné CPAM à Belfort depuis 2014. Le besoin tient en cinq lignes :

• Recevoir des demandes de course par mail (avec tous les détails utiles : adresses, date, téléphone)
• Pouvoir accepter ou refuser depuis un téléphone, sans application à installer
• Présenter une estimation de prix honnête au client avant qu'il ne valide
• Ne pas payer d'abonnement mensuel pour ça
• Respecter le RGPD strictement, parce qu'un taxi conventionné transporte des patients (article 9 du RGPD)

Aucune de ces lignes ne demande une base de données, un compte utilisateur, un panneau d'administration, ou un service tiers américain. C'est exactement ce qui guide l'architecture.

L'architecture en quatre briques

Le site repose sur quatre éléments, tous hébergés ou opérés en Europe :

1. Next.js 16 + React 19 + Tailwind v4, build standalone, déployé en conteneur sur un serveur dédié SoYouStart en France (datacenter OVH).
2. OpenRouteService (HeiGIT, Heidelberg, Allemagne) pour le geocoding des adresses européennes et le calcul de la distance routière réelle.
3. Base Adresse Nationale (Etalab, France) pour l'autocomplétion des adresses françaises, plus précise que n'importe quel concurrent.
4. Postmark pour l'acheminement transactionnel des e-mails (oui, US — mais on minimise tellement le contenu envoyé que ça reste défendable, j'y reviens).

Pour la sécurité du formulaire : Cloudflare Turnstile (anti-spam invisible, sans casse-tête utilisateur contrairement à reCAPTCHA), un honeypot, et un rate-limit applicatif de cinq soumissions par heure et par IP. Pas de bot ne passe.

Le tour de magie : pas de backend stateful

Le workflow ressemble à ceci. Un client remplit le formulaire de réservation. Le serveur Next.js valide les données, calcule l'estimation, vérifie Turnstile côté serveur, puis envoie deux mails via Postmark : un de confirmation au client, et un de notification au chauffeur. Le mail au chauffeur contient deux liens : « Accepter » et « Refuser ».

Ces deux liens ne pointent pas vers une base de données. Ils contiennent un token signé en HMAC qui embarque toutes les informations de la course (référence, client, adresses, date, prix). Quand Ghislain clique, le serveur vérifie la signature, génère un mail de confirmation au client (avec son numéro de course), et c'est terminé. Aucune donnée n'a été stockée côté serveur. La boîte mail Outlook de Ghislain joue le rôle de base de données.

// Token signé envoyé au chauffeur dans le mail de notification.
// Aucune persistance côté serveur : tout est dans l'URL.
const token = signBookingToken({
  ref,
  clientName,
  clientEmail,
  clientPhone,
  pickup,
  destination,
  when,
  priceEur,
});
const acceptUrl  = `${siteUrl}/accepter-course?t=${token}`;
const declineUrl = `${siteUrl}/refuser-course?t=${token}`;

Le secret HMAC est connu uniquement du serveur, donc personne ne peut forger un lien d'acceptation. Le token expire après quelques jours. Si Ghislain veut consulter l'historique, il ouvre Outlook : c'est sa source de vérité. Pas besoin de back-office, pas de mot de passe à mémoriser, pas d'interface à former.

Le geocoding qui ne fuit pas

Sur les sites de taxi qu'on voit habituellement, l'autocomplétion d'adresses appelle directement Google Maps depuis le navigateur du client. Conséquence : Google reçoit l'adresse personnelle du client + son IP + son user-agent, dès qu'il commence à taper, avant même qu'il ait validé quoi que ce soit. C'est un transfert hors UE qui mérite, à minima, un consentement préalable.

Sur taxighis.com, l'autocomplétion passe par notre propre API Next.js (`/api/autocomplete`), qui interroge la Base Adresse Nationale et OpenRouteService côté serveur. Le client n'a aucun contact direct avec ces services. Son IP n'arrive jamais ni chez OVH d'OpenRouteService, ni chez data.gouv.fr. On a vérifié à la trace réseau avec Playwright : zéro requête vers un domaine externe quand vous tapez « 1 avenue de la République ».

Le score RGPD

Quand on liste honnêtement la chaîne des sous-traitants d'un site taxi conventionné CPAM, on s'attend au pire — c'est un domaine où l'article 9 du RGPD (données de santé) plane sur la moindre destination renseignée (un trajet vers un hôpital, ça révèle un état de santé). Voici ce qu'on a finalement :

• Cédric Santiago (moi) — hébergement et infogérance, en France, sous engagement contractuel.
• OpenRouteService (Allemagne) — geocoding européen, sous-traitance UE.
• Base Adresse Nationale (France) — autocomplétion FR.
• Cloudflare Turnstile (US) — anti-spam, intérêt légitime art. 6.1.f.
• Postmark (US) — SMTP transactionnel, encadré par les SCC + Data Privacy Framework.
• Microsoft Outlook (Irlande, opérations US) — boîte mail du chauffeur.

Six sous-traitants, dont quatre en UE et deux aux US sous DPF. Pas de cookie de mesure d'audience, pas de pixel publicitaire, pas de bandeau de consentement. Le seul cookie technique éventuel est celui de Turnstile pendant la durée du challenge — exempté de consentement par la délibération CNIL 2020-091.

Pour les données de santé potentiellement révélées (destination = hôpital, mention d'une dialyse dans le champ « Remarques »), on s'appuie sur l'article 9.2.h du RGPD couplé au secret professionnel des transporteurs sanitaires (article L.1110-4 du Code de la santé publique). C'est documenté noir sur blanc dans la politique de confidentialité du site.

Combien ça coûte (et combien ça tient)

Coûts mensuels récurrents pour Ghislain : zéro pour Next.js (hébergé sur l'infra mutualisée que je gère), zéro pour OpenRouteService et BAN (free tier suffisant pour le volume), zéro pour Cloudflare Turnstile (free), Postmark facturé à l'envoi (~5 € par mois pour 1500 transac/mois). Domaine et certificat SSL : ~10 € par an. Total annuel hors temps de dev : moins de 100 €.

Côté maintenance : pas de DB à backupper, pas de CMS à mettre à jour, pas d'extension à patcher après un CVE WordPress. Le site est statique, il survit indéfiniment au changement d'envie du chauffeur. Le jour où Ghislain veut un nouveau service, on ajoute une page Next.js, on redéploie en cinq minutes.

Pour qui ça marche, pour qui ça ne marche pas

Cette architecture est taillée pour les TPE qui veulent simplifier, pas digitaliser. Elle marche très bien pour :

• Les chauffeurs indépendants qui prennent les demandes par mail/téléphone (1 à 3 chauffeurs)
• Les artisans et professions de service avec un volume modéré de demandes (10-50 par jour)
• Les professionnels conventionnés (taxi CPAM, kiné, ostéo) qui veulent un formulaire de prise de rendez-vous léger
• Tout site vitrine avec un formulaire de contact ou de devis qui doit être RGPD-strict

Elle ne convient pas aux flottes importantes qui ont besoin de dispatch en temps réel, de géolocalisation des chauffeurs en direct, ou d'un back-office multi-utilisateurs. Là, il faut un vrai backend (Next.js + Postgres + WebSockets, par exemple). Mais 80 % des PME que je croise n'ont pas ce besoin — elles l'ont peut-être imaginé en regardant les démos des SaaS, c'est tout.

En résumé

Taxi Ghis tourne sur du Next.js statique, six sous-traitants documentés (quatre en UE), zéro base de données, zéro cookie de tracking, et une boîte Outlook qui sert de source de vérité. Le site coûte moins de 100 € par an à faire tourner, ne demande aucune maintenance applicative, et la PdC tient sur une page sans euphémisme. C'est l'inverse exact de la roadmap que vous propose un commercial Booking-clone — et c'est probablement ce dont a besoin votre indépendant ou votre TPE.

Si vous êtes chauffeur (taxi, VTC, conventionné), thérapeute, artisan, et que vous cherchez un site de prise de rendez-vous qui ne sente pas la place de marché américaine, parlons-en : la stack est rodée, la PdC est prête, et le délai de mise en ligne est mesuré en semaines, pas en mois.