TAP

Le projet en une phrase

TAP est une plateforme de régulation de transport pour les sociétés de taxis conventionnés CGSS à La Réunion.

TAP remplace des tableaux Excel et une gestion papier par un outil web qui aide une régulatrice à organiser les trajets médicaux de ses patients, à suivre la facturation et à rester conforme à la réglementation sur les données de santé. Le projet est aujourd’hui fonctionnel et sécurisé ; sa mise en production dépend d’une décision commerciale de l’entreprise, pas d’un point technique restant à finir.

Ce qui a motivé ce projet

À La Réunion, les sociétés de transport conventionnées CGSS assurent des trajets médico-sociaux pour des milliers de patients, et ce quotidien s’accompagne de contraintes fortes. Une régulatrice y passe huit heures par jour, deux cent vingt jours par an, à gérer les appels, les affectations et les tournées, sur un terrain qui ne pardonne rien : routes sinueuses, temps de trajet imprévisibles, zones sans réseau. À cela s’ajoute la sensibilité des données manipulées, patients, prescriptions, traçabilité des transports, alors même que les outils à disposition se limitent le plus souvent à des tableaux Excel, à des carnets et à une logistique tenue à la main.

Pendant des années, ces sociétés ont fonctionné ainsi, et la productivité en a pâti. C’est dans ce contexte que mon chef m’a confié ce projet, avec un cahier des charges qui en posait les bases : périmètre fonctionnel, exigences réglementaires, contraintes techniques, hébergement envisagé. Le choix de m’atteler à ce projet ne m’appartenait donc pas ; ce qui relevait de moi, en revanche, c’était la manière de le mener, à savoir la démarche, les décisions d’architecture et la méthode de travail avec l’IA. C’est ce processus, du cahier des charges jusqu’à l’hébergement, que je détaille ici.

Aperçu de l’interface

Les données affichées (patients, courses, montants) sont des données de démonstration fictives, générées pour les besoins de ces captures et clairement identifiées comme telles dans l’interface (badge « DÉMO »).

Le choix de la stack

Une approche structurée : du cahier des charges à l’architecture

Le projet a démarré avec un cahier des charges qui définissait :

• Le périmètre fonctionnel (ce que l’application doit faire, et ce qu’elle ne fait pas).
• Les contraintes réglementaires (RGPD, données de santé, traçabilité).
• Les exigences non fonctionnelles (performance, disponibilité, sécurité).
• Les contraintes techniques (stack envisagée, hébergement).

Ce document a été ma boussole. À chaque choix technique, à chaque compromis, je revenais au cahier des charges pour vérifier que je restais dans le cadre défini.

Ce cahier des charges avait été rédigé avec l’aide de l’IA par une personne solide sur le fond métier, réglementaire et opérationnel, mais sans formation technique. Le dimensionnement d’infrastructure qui en ressortait visait large, pensé pour une échelle que le projet n’a pas vocation à atteindre avant longtemps. Une partie de mon travail a donc consisté à reprendre ce cadrage au fur et à mesure que je prenais la mesure du besoin réel, pour aligner l’infrastructure sur l’usage effectif plutôt que sur ce qu’un outil de génération pouvait suggérer sans le filtre d’une expertise technique. Le cahier des charges a posé le cap ; l’ajuster à la réalité du terrain a fait partie du travail.

Les ADR : documenter la pensée

J’ai documenté chaque décision d’architecture dans des ADR (Architecture Decision Records). La structure est toujours la même : Contexte → Décision → Conséquences.

• ADR-001 : Monorepo avec Turborepo.
• ADR-002 : Multi-tenant via Supabase RLS et organization_id.
• ADR-004 : Fournisseur SMS différé, derrière un adaptateur remplaçable.
• ADR-006 : Portail B2B multi-tenant différé.
• ADR-010 : Solveur de tournées, d’un microservice Python à une heuristique TypeScript native.
• ADR-012 : MapLibre + PMTiles pour le rendu carte.

Les ADR ne sont pas là pour faire joli. Quand je suis revenu sur un choix trois mois plus tard, ils m’ont rappelé pourquoi j’avais pris telle direction, quelles alternatives j’avais écartées, quelles conséquences j’avais anticipées. C’est un outil que je ne pensais pas utile, et que je ne peux plus ignorer aujourd’hui.

ADR-010, en détail : d’un microservice Python à une heuristique maison

La première version du solveur de tournées était un microservice Python utilisant OR-Tools, la bibliothèque d’optimisation combinatoire de Google, capable de résoudre des problèmes de type PDPTW (Pickup & Delivery with Time Windows). Sur le papier, l’outil était le bon choix technique.

Le déployer en serverless sur Vercel a posé un problème réel. Deux facteurs se sont combinés : le binaire OR-Tools pèse environ 75 Mo, ce qui provoque des cold starts trop lents pour le temps de réponse attendu par une régulatrice, et surtout, un problème de routage entre les deux runtimes du même projet. Next.js renvoyait systématiquement sa propre erreur 404 avant même que Vercel ne puisse aiguiller la requête vers la fonction Python : symptomatiquement, l’endpoint de santé /api/solver/health ne répondait jamais, comme si la fonction Python n’existait pas. Cinq tentatives de correction successives (exclure la route dans le middleware, retirer un préfixe dupliqué du routeur FastAPI, déplacer le fichier de configuration à la racine du bon répertoire, ajouter des rewrites Next.js) ont chacune corrigé une hypothèse plausible sans résoudre le symptôme, en grande partie parce que je diagnostiquais à distance, sans accès direct aux logs du tableau de bord Vercel pour voir où la requête se perdait réellement.

Une recherche sur la façon dont des projets open source de référence en optimisation de tournées (VROOM, KaRRi) hébergent leur solveur a confirmé que le problème n’était pas seulement une question de configuration : aucun d’entre eux ne tourne en serverless, tous utilisent un conteneur qui reste actif en permanence. J’allais à contre-courant d’un pattern que la communauté avait déjà écarté pour de bonnes raisons.

En reprenant le problème à froid, un fait a changé la donne : le volume réel de courses à optimiser est de quelques dizaines par jour, très loin de l’échelle pour laquelle OR-Tools est pensé. Et la nature du besoin, des horaires de dialyse répétés plusieurs fois par semaine, quasiment fixes, se prête bien à une heuristique simple (regroupement par compatibilité d’horaires, puis plus proche voisin sur une distance à vol d’oiseau corrigée) qui reste très proche de l’optimum sans les contraintes d’hébergement d’un binaire lourd.

J’ai donc supprimé le microservice Python et réimplémenté le solveur en TypeScript natif, directement dans l’application. Résultat : un calcul qui prenait 1 à 3 secondes de cold start (avec un plafond de 30 secondes en cas d’échec) se fait désormais en quelques millisecondes, sans service à héberger ni facturer séparément. Le compromis assumé, c’est un plan légèrement moins optimal qu’un vrai solveur combinatoire sur des cas de figure complexes ; à l’échelle réelle du projet, l’écart est marginal, et l’interface expose d’ailleurs ces indicateurs comme des estimations, pas comme des valeurs garanties.

Position des chauffeurs : pointage plutôt que suivi continu

La carte des chauffeurs du cockpit n’affiche pas un flux GPS animé, et pour une raison technique dure : la capture de position continue n’est pas fiable dans une PWA (l’application web du chauffeur) puisqu’elle s’interrompt dès que le chauffeur ouvre une application de navigation ou éteint l’écran. Le système capture donc la position au moment des évènements qui comptent (prise en charge, dépose), et l’affiche avec son âge plutôt que de simuler un direct qu’elle ne peut pas garantir.

C’est un principe assumé dans la conception : ne jamais afficher une position comme « en direct » si elle ne l’est pas. Les captures de cette page en sont la preuve, le badge « DÉMO » et la mention « vu il y a X min » sont dans l’interface elle-même, pas ajoutés après coup pour cet article.

La discipline du périmètre : savoir différer

Deux autres ADR illustrent le même réflexe que la stack de tournées : ne pas construire ce qui n’est pas encore nécessaire. Le fournisseur SMS retenu au départ, Twilio, s’est révélé poser un problème de conformité (société américaine soumise au CLOUD Act, pour des SMS qui, par leur contenu, relèvent indirectement de la donnée de santé) : plutôt que de changer de fournisseur dans l’urgence, l’intégration a été placée derrière un adaptateur remplaçable, pour pouvoir basculer vers un prestataire européen sans réécrire la logique métier. Le portail B2B multi-tenant prévu pour les donneurs d’ordres (hôpitaux, cliniques) a lui été purement différé : le construire avant d’avoir validé le produit avec un premier client réel aurait immobilisé du temps sur une brique qu’aucun des parcours métier actuels ne requiert.

La sécurité : une exigence qui structure tout

TAP manipule des données de santé. L’article 9 du RGPD interdit leur traitement sauf fondement juridique spécifique. Cette contrainte a guidé chaque choix d’architecture, chaque ligne de code, chaque décision d’infrastructure.

J’ai adopté une approche de sécurité par la conception (security by design), en superposant plusieurs couches de protection.

Gestion des secrets et des clés API

La clé service_role de Supabase contourne toutes les politiques RLS. Si elle fuit, c’est toute la base qui est exposée.

J’ai donc structuré le projet comme suit :

• La clé anon (publique) est utilisée côté client, avec RLS pour contrôler l’accès.
• La clé service_role n’est utilisée que dans le code serveur (API Routes, Server Components).
• Les variables d’environnement sont stockées dans un fichier .env.local non versionné.

Pas de NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY. Pas de clé dure. Pas de compromis.

Row Level Security (RLS) : la porte d’entrée obligatoire

Supabase expose la base de données directement via l’API. Sans RLS, n’importe qui avec la clé anon peut lire ou modifier toutes les tables. J’ai donc activé RLS sur chaque table.

alter table public.organizations enable row level security;
alter table public.organizations force row level security;

alter table public.rides enable row level security;
alter table public.rides force row level security;

Avec RLS activé et sans politiques définies, une table est complètement inaccessible. C’est le comportement par défaut que j’ai choisi : rien n’est accessible tant que je n’ai pas explicitement défini qui peut accéder à quoi. Sur les tables métier, je force en plus la RLS (FORCE ROW LEVEL SECURITY) : même une requête qui passerait par le propriétaire de la table reste soumise aux politiques, ce qui ferme la porte à un bug applicatif qui utiliserait service_role par erreur côté client.

Politiques RLS : des règles granulaires

J’ai écrit des politiques pour chaque table, en suivant le principe du moindre privilège.

-- Isolation multi-tenant : chaque table métier filtre sur organization_id
create policy rides_select_same_org on public.rides
  for select to authenticated
  using (organization_id = public.current_organization_id());

-- Seuls une régulatrice ou un dirigeant peuvent créer une course
create policy rides_insert_regulateur_dirigeant on public.rides
  for insert to authenticated
  with check (
    organization_id = public.current_organization_id()
    and created_by = auth.uid()
    and (
      public.has_role('regulateur'::public.user_role)
      or public.has_role('dirigeant'::public.user_role)
    )
  );

Autre garde-fou du même ordre : un trigger empêche un utilisateur de s’élever lui-même en dirigeant, ou de se transférer vers une autre organisation, en modifiant son propre profil.

-- Tout rôle autre que dirigeant : interdit de changer organization_id, role ou actif
if new.organization_id is distinct from old.organization_id then
  raise exception 'Modification interdite : organization_id'
    using errcode = '42501';
end if;

if new.role is distinct from old.role then
  raise exception 'Modification interdite : role'
    using errcode = '42501';
end if;

Les politiques RLS ajoutent implicitement des clauses WHERE à chaque requête. C’est la base de données qui applique les règles d’accès, pas le code applicatif. Un bug dans l’application ne peut pas contourner ces contrôles.

Authentification et sessions

TAP utilise Supabase Auth avec des tokens JWT, signés avec des clés asymétriques. Un JWT (JSON Web Token) est un jeton auto-porteur : il contient, encodé et signé numériquement, l’identité de l’utilisateur et quelques métadonnées le concernant, de sorte que le serveur peut vérifier qui fait la requête sans avoir à interroger la base de données à chaque appel, il lui suffit de contrôler la signature. Les tokens sont automatiquement envoyés par les clients Supabase lorsque l’utilisateur est connecté, et je m’en sers pour :

• Valider l’identité à chaque requête.
• Injecter auth.uid() dans les politiques RLS.
• Gérer les sessions et les rafraîchissements.

Les clés de signature sont rotées régulièrement.

Chiffrement des données

Supabase chiffre toutes les données au repos (AES-256) et en transit (TLS). Pour les données de santé, j’ai ajouté une couche supplémentaire : les champs sensibles sont chiffrés au niveau de l’application avant d’être stockés. J’utilise l’extension Vault de Supabase pour stocker les clés de chiffrement.

En-têtes de sécurité HTTP

J’ai configuré plusieurs en-têtes dans next.config.js :

• Content-Security-Policy (CSP) : restreint les sources de contenu.
• Strict-Transport-Security (HSTS) : force les connexions HTTPS.
• X-Frame-Options : empêche le clickjacking.
• X-Content-Type-Options : empêche le MIME-sniffing.

Hébergement sur OVHCloud

OVHCloud héberge les serveurs en France, ce qui évite tout transfert de données hors de l’Union européenne. L’infrastructure est conçue pour la conformité RGPD.

Construire le contexte : la vraie valeur ajoutée

Le code généré par l’IA n’est que la partie visible de l’iceberg : ce qui a réellement pris du temps, et qui a fait toute la différence, c’est la construction du contexte qui l’entoure.

Le CLAUDE.md : le cerveau partagé

Le fichier CLAUDE.md a été un travail considérable. Il décrit :

• Les principes de conception (inspirés de Linear, Notion, Stripe).
• Les patterns d’architecture adoptés.
• Les contraintes métier et techniques.
• Les bonnes pratiques du projet (TypeScript, Tailwind, sécurité).
• Les décisions clés et leur justification.

Ce document est si important parce que c’est lui qui donne le contexte à Claude : quand je lui demande de générer une nouvelle fonctionnalité, il dispose déjà en mémoire de toute l’architecture du projet et ne repart donc jamais de zéro.

C’est la différence entre “avoir un assistant qui code” et “avoir un outil qui comprend le projet”. Le CLAUDE.md transforme l’IA d’un générateur de code en un outil de conception.

L’IA comme outil principal : une relation qui s’apprend

J’ai utilisé Claude Code intensivement, non pas en mode “génère-moi ceci”, mais en mode dialogue.

Le cycle de travail

1. Je pose une question – une problématique d’architecture ou de conception.
2. Claude propose – une solution, des alternatives, parfois des contre-arguments.
3. Je creuse – je demande des précisions, je confronte avec le cahier des charges.
4. Je tranche – c’est moi qui décide de la direction à prendre.
5. Claude génère le code – une première version structurée.
6. Je relis – chaque ligne, chaque fonction, chaque structure.
7. Je reconduis – je reprends ce qui est bon, je modifie ce qui ne l’est pas.

Ce cycle m’a permis d’avancer à un rythme que je n’aurais jamais atteint seul, même si c’est toujours moi qui garde la main sur les décisions.

Trouver les points de friction

Mon vrai travail, sur ce projet, a été de découvrir les points de friction :

• L’IA génère une structure de données. Est-elle adaptée aux requêtes qu’on va faire ?
• Elle propose une logique d’affectation. Tient-elle la route dans tous les cas ?
• Elle suggère un pattern d’authentification. Est-il compatible avec la RLS ?

Ce sont des questions que je suis seul à pouvoir poser, parce que je connais le projet, son contexte et son cahier des charges bien mieux que ce que l’IA pourrait en déduire : elle ne peut tout simplement pas les voir venir.

Reconnaître les patterns, pas coudre des solutions

Je ne réinvente pas la roue : lorsqu’un pattern existe déjà, que ce soit dans React, Supabase ou Next.js, je m’appuie dessus plutôt que d’en recréer un. Mon travail consiste à :

• Reconnaître les patterns qui s’appliquent à mon problème.
• Les adapter au contexte de TAP (temporalité, données de santé, RGPD).
• Les intégrer proprement.

L’IA en génère le squelette ; à moi, ensuite, d’en assembler les pièces.

Le skill pour la documentation

J’ai développé un skill Claude pour produire de la documentation au format DOCX. Il prend le code, les ADR, le contexte, et génère une documentation structurée, prête à être partagée avec l’équipe ou le chef de projet.

La documentation est le ciment du projet. Sans elle, le code devient vite incompréhensible.

L’observation terrain : la dernière pièce

Contrairement au “design thinking”, je n’ai pas commencé par observer les régulatrices. Le projet a été construit à partir du cahier des charges, des spécifications recueillies, de la documentation réglementaire, et de ma connaissance des systèmes de régulation.

L’observation terrain est la dernière pièce. Elle viendra après le déploiement :

1. Bascule vers un hébergement certifié HDS pour la production commerciale.
2. Déploiement progressif auprès de sociétés pilotes.
3. Observation des régulatrices en situation réelle.
4. Ajustements basés sur les retours.

Le produit est conçu à partir des besoins exprimés et du cadre défini. Puis il est confronté à la réalité du terrain. C’est cette confrontation qui permet d’affiner, pas l’observation préalable qui ne vaut jamais un vrai usage en conditions réelles.

Ce que j’ai retenu de ce projet

La sécurité n’est pas une option

C’est une contrainte qui structure tout. Le RGPD, les données de santé, la RLS, le chiffrement, les en-têtes HTTP – chaque choix technique a été filtré par le prisme de la sécurité. C’est ce qui donne sa cohérence au projet.

L’IA est un outil, pas un magicien

L’IA génère du code, mais c’est moi qui le relis, qui le comprends, qui le corrige et qui décide de le conserver ou non. C’est moi, également, qui pose les bonnes questions, qui repère les points de friction et qui valide chaque choix : l’IA reste un accélérateur de réflexion, non un remplaçant.

Je tape moi-même une minorité des lignes de ce projet ; Claude Code en écrit l’essentiel. Ça ne réduit pas le travail, ça le déplace ailleurs que dans le clavier. Le renoncement à OR-Tools après cinq tentatives de déploiement ratées, le choix de différer le portail B2B, la bascule vers une RLS forcée sur chaque table : rien de tout ça ne se lit dans un diff de code, ça se lit dans le nombre de fois où j’ai dû trancher, revenir en arrière et documenter pourquoi. Compter les lignes tapées à la main pour évaluer l’ampleur d’un projet passe à côté de l’essentiel du travail.

Le contexte est plus important que le code

Un projet sans contexte tourne en rond. Le CLAUDE.md, les ADR, le cahier des charges – c’est ce qui structure la réflexion. C’est ce qui permet de prendre des décisions cohérentes sur la durée.

La documentation n’est pas optionnelle

J’ai passé des heures à documenter. Des ADR, des specs, des commentaires dans le code. C’est un investissement qui a payé à chaque fois que je suis revenu sur une partie du projet après plusieurs semaines.

L’observation est la dernière étape, pas la première

On ne conçoit pas un produit en observant des utilisateurs. On le conçoit à partir d’un besoin exprimé et d’un cadre défini. Et on l’observe pour l’affiner. L’ordre est important.

Apprendre sur le tas, en étant seul à porter le sujet

Je suis, dans les faits, le seul informaticien du service. Cela a fait de moi le chef de projet sans que le titre en soit officiellement posé, et sans relecture technique en interne pour challenger mes choix au fil de l’eau. C’est une vraie liberté, mais aussi une responsabilité : j’ai appris énormément, et vraiment sur le tas, en confrontant chaque décision directement à la réalité du terrain plutôt qu’à une hiérarchie technique qui n’existe pas dans ce service.

Le vrai enseignement de cette solitude technique, c’est qu’il aurait fallu consigner l’avancement au fil de l’eau et le signaler plus régulièrement. Sans relecture interne, la seule trace fiable de la progression du projet, c’est ce que j’en communique moi-même. Je le sais maintenant pour la suite : mieux vaut noter et remonter l’état d’avancement de façon régulière et lisible, plutôt que d’essayer de reconstituer plusieurs mois de décisions a posteriori.

Concrètement, cela s’est traduit par un dossier de planification versionné avec le reste du code, tenu à jour au fil des sessions avec Claude Code, en complément du CLAUDE.md et des ADR. Sans être un journal de bord parfait, il est devenu ma boussole pour savoir où j’en suis réellement et où je vais, plutôt que de reconstruire l’état du projet de mémoire à chaque point d’étape.

Il y a aussi une raison plus terre-à-terre au choix de Vercel comme hébergement de développement : mon chef n’est pas développeur, il ne peut pas juger l’avancement du projet en lisant du code. Vercel déploie automatiquement une préversion accessible par simple lien à chaque changement poussé sur le dépôt, ce qui lui permet de voir l’état réel de l’application sans rien installer et sans avoir à comprendre la stack technique. Bien qu’absent des ADR, ce mécanisme est devenu de fait mon principal outil de reporting visuel au quotidien.

Perspectives

Le socle technique de TAP est posé : sécurité, architecture, cœur fonctionnel de régulation. Le projet reste cela dit en développement actif, pas en phase de clôture. La suite ne dépend plus uniquement de moi : le passage à un hébergement certifié HDS, le choix des sociétés pilotes et le rythme du déploiement sont des décisions commerciales et organisationnelles qui reviennent à mon chef, et elles n’ont pas encore été arbitrées à ce jour. Ma part du travail s’arrête à la livraison d’un outil fonctionnel et correctement sécurisé ; le calendrier de la suite ne dépend pas de mes choix.

En résumé

TAP est un projet réel : un cahier des charges professionnel, des utilisateurs cibles clairement identifiés, des contraintes réelles (données de santé, RGPD, géographie), une sécurité pensée dès la conception, une stack moderne, et une approche de l’IA assumée. L’IA génère, je relis et je reconduis. Le contexte, documenté dans le CLAUDE.md et les ADR, est ce qui fait la différence.

Compétences mobilisées

Cette section relit le projet sous l’angle « défi rencontré, solution retenue, résultat concret », le format attendu par un lecteur qui n’a pas le temps de tout lire mais veut savoir ce que je sais faire.

Concevoir une architecture qui protège des données de santé. Défi : livrer un SaaS traitant du NIR, des prescriptions et de la traçabilité, sous contrainte RGPD article 9, sans budget d’infrastructure. Réponses : RLS forcée sur toutes les tables métier, filtrage par organization_id injecté depuis les métadonnées JWT, trigger PostgreSQL qui interdit à un utilisateur non-dirigeant de modifier son propre rôle ou son organisation, chiffrement applicatif AES-GCM au-dessus du chiffrement Supabase pour les champs sensibles, clé service_role cantonnée au serveur. Résultat : une isolation multi-tenant qui reste vraie même en cas de bug applicatif, puisqu’elle est appliquée par la base et non par le code.

Substituer une heuristique maison à un solveur externe. Défi : le microservice Python OR-Tools initialement retenu produisait des cold starts de 1 à 3 secondes en serverless, avec un plafond à 30 secondes en cas d’échec, incompatible avec le temps de réponse attendu par une régulatrice. Réponse : après cinq tentatives de correction du routage entre runtimes Next.js et Python, réimplémentation d’un solveur en TypeScript natif directement dans l’application (regroupement par compatibilité d’horaires, plus proche voisin sur distance Haversine corrigée). Résultat : calcul ramené à quelques millisecondes, un service en moins à héberger, une facturation à l’appel évitée.

Piloter un projet en tant que seul informaticien du service. Défi : jouer sur trois rôles simultanés (développeur, chef de projet, interlocuteur métier) sans relecture technique interne, avec un cahier des charges initial rédigé par IA par une personne non technique et surdimensionné. Réponses : ADR versionnées pour chaque décision structurante, dossier de planification tenu au fil des sessions Claude Code, choix de Vercel comme préversion cliquable pour donner à un chef non technique une manière concrète de constater l’avancement, retour argumenté et progressif sur les points du cahier des charges à réajuster. Résultat : un projet livré et documenté de façon reprise-friendly, dont la mise en production dépend désormais d’un arbitrage commercial et non d’une brique technique manquante.

Utiliser Claude Code sans lui déléguer la décision. Défi : intégrer l’IA au flux de travail sans que le code livré soit une accumulation de suggestions non filtrées. Réponses : cycle question → proposition → confrontation au cahier des charges → arbitrage → génération → relecture ligne à ligne, CLAUDE.md maintenu comme mémoire partagée du projet, points de friction identifiés en amont (une structure de données proposée tient-elle la charge des requêtes prévues ?). Résultat : une minorité de lignes tapées à la main, l’essentiel des arbitrages assumé par moi, ce qui se lit dans l’historique des décisions plutôt que dans les diffs.