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 cycle de vie d'une course en 6 étapes

Pour rendre l'architecture concrète, voici ce qui se passe entre le moment où un patient clique sur « Réserver » et celui où le chauffeur reçoit son mail de confirmation finale.

1. Saisie — le client remplit le formulaire. L'autocomplétion d'adresse passe par `/api/autocomplete` côté serveur, jamais directement vers BAN ou ORS. L'IP du visiteur n'arrive pas chez les sous-traitants.
2. Validation et estimation — le serveur Next.js valide la cohérence des données (téléphone FR, dates futures, adresses non vides), interroge OpenRouteService pour la distance routière, calcule le prix selon la grille tarifaire applicable (heures pleines / creuses, suppléments), et vérifie le token Cloudflare Turnstile côté serveur.
3. Confirmation immédiate au client — un mail récapitulatif est envoyé via Postmark. Le client reçoit le détail de sa demande et un rappel : la course n'est validée qu'après acceptation du chauffeur.
4. Notification au chauffeur — Ghislain reçoit en parallèle un mail structuré dans sa boîte Outlook avec deux liens signés HMAC : « Accepter » et « Refuser ». Le mail contient toutes les infos opérationnelles utiles à 6h du matin (adresse, téléphone, distance estimée).
5. Décision du chauffeur — Ghislain clique depuis son téléphone. Le serveur vérifie la signature HMAC (rejet si altérée ou expirée), extrait les données depuis le token, déclenche le mail correspondant.
6. Confirmation finale au client — un dernier mail confirme l'acceptation avec le numéro de course et le téléphone direct du chauffeur (ou explique poliment le refus avec invitation à recontacter). Côté serveur, plus aucune trace : le cycle est terminé.

Six étapes, deux mails côté client, un mail côté chauffeur, un clic de validation. Aucune base de données touchée, aucun compte créé, aucune session ouverte. Le serveur ne sait littéralement plus rien de la course après les 30 secondes du formulaire — la mémoire est dans Outlook.

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 ».

Postmark et ses alternatives EU

C'est la seule concession non-EU de la stack. Postmark est basé aux États-Unis (Wildbit Inc.) et adhère au EU-US Data Privacy Framework — encadrement juridique reconnu par la Commission européenne en juillet 2023, qui sécurise le transfert. Pour minimiser l'exposition, le contenu des mails est volontairement réduit : pas de pièces jointes, pas de tracking pixel, pas d'open tracking activé.

Pour les clients qui exigent 100 % UE (administrations publiques, secteur santé strict, marchés publics), quatre alternatives crédibles avec mêmes capacités transactionnelles.

• Tipimail (Brevo) — France, basé à Paris. Filiale de Brevo, gère 100 milliards de mails/an. SMTP transactionnel + API REST. Pricing comparable à Postmark.
• Mailjet — France, basé à Paris (groupe Sinch depuis 2019, opérations FR conservées). SMTP + API + tracking optionnel désactivable.
• Brevo — France, ex-Sendinblue. Plus marketing-oriented mais offre transactionnelle solide.
• Mailtrap — Pologne (Railsware). Bonne option pour les setups dev/staging + prod, infrastructure 100 % UE.

Sur Taxi Ghis on a tranché en faveur de Postmark pour deux raisons : la qualité de délivrabilité (taux de placement boîte de réception > 99 % vs ~95 % chez les français), et le DPF qui suffit juridiquement pour un transporteur conventionné CPAM. Si vous êtes administration publique ou marché public, basculer sur Tipimail ou Mailjet reste 10 minutes de configuration côté Next.js.

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 (HeiGIT, Allemagne) — geocoding européen, sous-traitance UE pure.
• Base Adresse Nationale (Etalab, France) — autocomplétion FR.
• Cloudflare Turnstile (Cloudflare Germany GmbH pour les sujets EU) — anti-spam en mode `managed` invisible, sans cookie de tracking, intérêt légitime art. 6.1.f.
• Postmark / Wildbit Inc. (US) — SMTP transactionnel, encadré par le EU-US Data Privacy Framework (décision adéquation Commission UE de juillet 2023).
• Microsoft Outlook (Irlande, opérations US) — boîte mail du chauffeur, contrat client direct (Microsoft 365 Business).

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.

Lessons learned, un an après

Quelques enseignements rétrospectifs, après plusieurs centaines de courses passées par le formulaire et un an de retours utilisateurs.

• Le mail comme « base de données » fonctionne mieux que prévu — Ghislain n'a jamais eu besoin d'historique applicatif, la recherche Outlook (par nom, date, adresse) couvre 100 % des besoins de retrouver une course passée.
• Le token HMAC suffit largement — pas un seul cas de tentative de forge depuis la mise en prod. Le secret est dans `.env` côté serveur, le token est limité dans le temps (7 jours), et personne dans la rue ne va deviner le HMAC.
• L'autocomplétion BAN bat Google sur le rural — beaucoup d'adresses du Territoire de Belfort et des Vosges ne sont tout simplement pas indexées sur Google Maps, mais sont dans la BAN. Sur la périphérie, on a même eu de meilleurs résultats que les apps taxi nationales.
• Le formulaire sans bandeau cookie crée un effet psychologique fort — plusieurs patients âgés ont commenté positivement « ah, ça change, on n'a rien à valider ». La friction supprimée se voit autant que la performance technique.
• Le SEO local ne demande rien d'extraordinaire — entre la rédaction soignée des contenus de localisation (Belfort + communes desservies) et l'absence de bandeau qui ralentit le rendu, la home se positionne sans backlinks payants sur « taxi conventionné Belfort » et « VSL Territoire de Belfort ».

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é CPAM), 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 politique de confidentialité est prête, et le délai de mise en ligne est mesuré en semaines, pas en mois.

Sources et références

Les références juridiques, techniques et institutionnelles qui ont guidé l'architecture et la conformité du projet, vérifiées à jour mai 2026.

1. EUR-Lex — Règlement (UE) 2016/679 RGPD, Article 9 (catégories particulières de données, dont santé) : https://eur-lex.europa.eu/eli/reg/2016/679/oj
2. Légifrance — Code de la santé publique, Article L.1110-4 (secret professionnel des transporteurs sanitaires) : https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000041721185
3. Légifrance — Article 82 Loi n° 78-17 Informatique et Libertés : https://www.legifrance.gouv.fr/loda/article_lc/LEGIARTI000037813978
4. CNIL — Délibération n° 2020-091 (cookies & traceurs, exemption mesure d'audience) : https://www.cnil.fr/fr/cookies-et-autres-traceurs-la-cnil-publie-des-lignes-directrices-modificatives-et-sa-recommandation
5. CNIL — Guide pratique du formulaire de contact : https://www.cnil.fr/fr/securite-des-donnees-personnelles-les-bonnes-pratiques-formulaire-en-ligne
6. Commission européenne — Décision d'adéquation EU-US Data Privacy Framework (juillet 2023) : https://commission.europa.eu/document/fa09cbad-dd7d-4684-ace2-be9a59a44d70_en
7. Etalab / data.gouv.fr — Base Adresse Nationale (BAN), référentiel officiel : https://adresse.data.gouv.fr/
8. Etalab — API d'autocomplétion BAN (documentation) : https://adresse.data.gouv.fr/api-doc/adresse
9. OpenRouteService — HeiGIT, Heidelberg University : https://openrouteservice.org/
10. OpenRouteService — Pelias geocoding documentation : https://openrouteservice.org/dev/#/api-docs/geocode
11. Cloudflare Turnstile — documentation officielle (mode managed sans cookie) : https://developers.cloudflare.com/turnstile/
12. Postmark — EU-US Data Privacy Framework certification : https://postmarkapp.com/eu-privacy
13. Next.js — Documentation officielle (Standalone output, déploiement) : https://nextjs.org/docs/app/api-reference/config/next-config-js/output
14. Brevo / Tipimail — alternative SMTP transactionnel française : https://www.brevo.com/fr/produits/email-transactionnel/
15. Mailjet — alternative française : https://www.mailjet.com/fr/
16. Caisse Nationale d'Assurance Maladie — convention transports sanitaires : https://www.ameli.fr/transporteur-sanitaire
17. RFC 2104 — HMAC : Keyed-Hashing for Message Authentication : https://www.rfc-editor.org/rfc/rfc2104