01Objet et Statut du Document

Cahier des Charges Fonctionnel et Technique · Édition Publique V4 · 18 septembre 2026

Finalité : définir les fonctions attendues de OùQuandQui, leurs règles de calcul, leurs données, leurs limites et leurs critères de validation. Ce référentiel organise le développement et rend les engagements du produit consultables.

Statut : document de conception. Les exigences du produit, les spécifications proposées et les arbitrages ouverts sont distingués des fonctionnalités disponibles. Une fonction décrite constitue une cible de développement, sauf indication explicite de sa disponibilité.

Périmètre : trajet routier, arrêts carburant, profil local, covoiturage, transports publics, mobilités douces, comparaison des possibilités et Journal de Mobilité. Les modalités de réalisation sont réparties en lots.

État de référence : PR 4 fusionnée, commit 7bce0ea9988b3fad041175b615b5bb40302bfcda. Le développement du 18 septembre ajoute le contrat de service public, le gabarit poids lourd et la sélection des alternatives ; le service avancé n’est pas encore activé. La section 31 formalise les décisions de cette édition.

Exigences Fondatrices

• Ouvrir l’application à l’usage personnel et au public, sans compte technique ni clé API à fournir par les visiteurs.

• Commencer par la France ; documenter la couverture effective de chaque source, y compris les écarts entre métropole et outre-mer.

• Distinguer véhicules légers et poids lourds ; traiter le revêtement de la route comme une préférence distincte du véhicule.

• Calculer et choisir un trajet avant de rechercher les stations ou les possibilités de covoiturage.

• Rendre le trajet principal nettement visible en bleu et afficher ses alternatives en bleu clair.

• Appliquer les options « éviter les péages » et « éviter les autoroutes » au trajet et aux détours.

• Prendre en compte le véhicule, notamment la voiture avec caravane, sans annoncer une compatibilité de gabarit non vérifiée.

• Rechercher les stations au plus tôt, selon un compromis proche ou autour d'une distance choisie.

• Afficher chaque station sur la carte, ouvrir sa fiche d'informations et permettre son enregistrement.

• Conserver localement le véhicule, les adresses et les stations favorites.

• Regrouper les classements sur une seule fiche lorsqu'une station remplit plusieurs critères.

• Présenter séparément les montants et les durées, sans demander une valeur du temps en euros par heure.

• Distinguer les données observées, les estimations et les informations indisponibles.

• Étendre progressivement la comparaison au covoiturage, aux transports publics, aux mobilités douces et au bilan CO₂e.

Conventions de Lecture

Les identifiants TRA-01, STA-01, etc. sont stables. Une exigence modifiée conserve son identifiant et reçoit une entrée au journal des décisions. Sauf mention EXIGENCE ou VISION, les règles détaillées sont des PROPOSITIONS destinées à validation. Les verbes « doit » et « interdit » définissent la cible de recette après cette validation.

02Vision et Périmètre

VISION : comparer comment aller quelque part, quand, avec qui et à quel coût, sans réduire la décision à un classement opaque. Montrer les données, les compromis et les incertitudes ; laisser la personne choisir.

OùQuandQui ? est le produit global. DragonRoute est son module routier, pas une seconde application concurrente. Le changement de nom visible ne doit pas précéder la réalité fonctionnelle ni casser les adresses publiques existantes.

EXIGENCE d'hébergement : héberger le site et ses aperçus sur GitHub. Un service de données externe n'est pas un changement d'hébergement ; son usage, ses conditions et les informations transmises doivent toutefois être explicités.

Hors Périmètre du Premier Lot Routier

Pas de compte distant, paiement, messagerie, publication d'annonces, communauté ou réputation ; pas de guidage vocal ni de navigation continue en arrière-plan ; pas de trafic temps réel affirmé sans source ; pas de cartographie hors ligne complète ; pas de recharge électrique ; pas de classement multimodal tant que les sources ne sont pas branchées. Ces exclusions concernent le premier lot, pas nécessairement la vision finale.

03État de Réalisation

La Présentation expose la vision ; le Cahier des Charges définit les comportements attendus. L'état de réalisation ci-dessus reste indépendant du périmètre cible.

04Usages et Parcours de Référence

Pas besoin de créer un compte pour préparer un déplacement. Le profil local est facultatif.

La préparation se fait à l'arrêt. Un futur mode en déplacement devra réduire les interactions ; il n'est pas inclus dans la première livraison.

05Arborescence et Écrans

Architecture Cible

1. Mon trajet : départ, arrivée, date/heure lorsqu'elles sont prises en charge, voyageurs, véhicule et options.
2. Mes possibilités : routes routières puis Tapis Volant multimodal, comparaison et choix.
3. Sur mon trajet : stations, puis covoiturage et autres étapes réellement disponibles.
4. Mon profil : véhicule(s), adresses, préférences, favoris, données locales.
5. Mon journal : seulement à partir du lot Empreinte.

Le premier écran reste une application utilisable, sans page marketing préalable. Le bouton principal est « Trouver mon trajet ». Les paramètres carburant ne sont pas nécessaires pour calculer une route.

UX-01 à UX-08 · Règles d’Interface

06Saisie, Géocodage et Position

Territoire initial confirmé : France. La disponibilité effective en métropole et outre-mer est qualifiée séparément pour chaque source ; cette décision ne vaut pas certification nationale de couverture. L'interface signale un départ ou une arrivée hors couverture des sources nécessaires. L'extension Europe est un lot à décider, pas une conséquence implicite de l'affichage mondial d'une carte.

07Routage et Alternatives

EXIGENCE : trouver le trajet avant les stations ; route principale bleue, alternatives bleu clair ; éviter péages et autoroutes.

Options de Route

TRA-09 · Contraintes strictes : elles s'appliquent au trajet direct, aux alternatives, aux trajets d'accès aux stations, aux prises en charge et aux exports. Si le moteur ne peut les appliquer à une opération, cette opération s'arrête avec explication. Aucun repli silencieux vers une route non contrainte.

TRA-10 · Recalcul : changer une contrainte annule les anciennes comparaisons. Les préférences cochées restent cochées en cas de panne. Les désactiver exige une action de la personne.

TRA-11 · Statut d'application : conserver requested, applied, unsupported, unverified. « Appliquée par le moteur » ne signifie pas « garantie sur le terrain ». Une contrainte explicitement non prise en charge bloque les résultats présentés comme conformes.

08Véhicule, Caravane et Camion

EXIGENCE : mémoriser son véhicule et prendre en compte les véhicules encombrants, notamment une voiture tractant une caravane.

Le contrat routier développé utilise les mètres pour le gabarit, les tonnes pour le poids total et la charge par essieu, les litres pour le carburant. Les unités sont affichées aux champs et conservées dans le contrat fournisseur ; les autres contrats peuvent utiliser les kilogrammes si la conversion explicite est testée. Les plages techniques doivent être définies avec le fournisseur retenu ; aucune limite arbitraire ne sera présentée comme une réglementation.

09Stations, Recherche et Intention d’Arrêt

Sens des Trois Intentions

Le mode actuel utilise des distances routières depuis le départ saisi. La cible ci-dessus précise davantage le sens de « sur mon trajet » et exige une adaptation du calcul, pas un simple changement de libellé.

STA-01 · Origine active : avant départ, origine du trajet. Une actualisation ponctuelle depuis « Ma position » remplace explicitement l'origine après confirmation et recalcule. Pas de progression supposée, pas de suivi permanent implicite.

STA-02 · Fenêtre : cible et tolérance sont des distances positives en kilomètres ; la borne basse est max(0, cible - tolérance) et la haute min(longueur restante, cible + tolérance). Si la cible dépasse le trajet, afficher la limite avant recherche. Le curseur a un champ numérique équivalent et fonctionne au clavier.

STA-03 · Zone vide : dire « Aucune station trouvée dans cette zone avec ces critères ». Proposer des actions explicites : élargir, modifier le carburant ou réduire les filtres. Ne jamais élargir automatiquement ou affirmer que le territoire ne contient aucune station.

STA-04 · Sources : priorité aux données officielles disponibles ; conserver l'identifiant source stable, prix par carburant, date de chaque prix, ruptures, localisation, adresse, horaires et services. Un nom d'enseigne absent n'est pas reconstitué depuis une intuition sur l'adresse.

STA-05 · Présélection : le corridor géographique sert à trouver des candidates, pas à mesurer leur accessibilité. Une station de l'autre côté d'une autoroute ou d'une rivière exige un accès routier calculé.

STA-06 · Couverture : afficher reçues, candidates examinées, effectivement comparées, réponses partielles et filtres. « Optimal » signifie meilleur parmi les stations comparées, pas meilleur de France ni de tout le trajet.

STA-07 · Limites actuelles à rendre configurables : corridor 12 km, prélèvements environ tous les 30 km, maximum 24 points et 20 candidates dans le prototype. Ce sont des compromis techniques, pas une preuve d'exhaustivité. Une limite atteinte entraîne une indication de couverture partielle et une pagination ou relance ciblée proposée.

STA-08 · En aval : la station doit être rattachée à une portion encore à parcourir. Ne pas classer comme « sur le trajet » une station déjà dépassée sans présenter le retour nécessaire et demander accord.

STA-09 · Carburant : un prix inconnu, invalide ou une rupture déclarée pour le carburant choisi exclut la station des comparaisons chiffrées correspondantes. Elle peut rester visible avec son état, sans faux zéro.

STA-10 · Filtres proposés : détour maximal, services nécessaires, enseignes exclues, ouverture connue à l'arrivée. Une valeur inconnue ne satisfait pas un filtre strict ; une option explicite peut afficher séparément les stations « à vérifier ».

STA-11 · Carte : points numérotés stables pendant la recherche, contrastés, activables au clavier et au clic. Sélectionner un point ouvre la même station que sélectionner sa fiche. Le favori ne modifie pas son rang automatiquement.

STA-12 · Liste : présenter les recommandations puis permettre l'accès à toutes les stations réellement comparées, pas seulement aux trois gagnantes. Tri indiqué et réversible. Une carte ne doit pas être l'unique moyen d'accéder aux informations.

10Coûts et Classements Carburant

EXIGENCE : supprimer la question « Temps €/h ». Le temps reste une durée. Une conversion monétaire du temps n'est pas introduite par défaut dans les classements.

Variables et Périmètres

CAL-01 · Achat : achat_s = L × p_s.

CAL-02 · Carburant du détour : volume_detour_s = deltaD × c / 100 ; cout_detour_s = volume_detour_s × p_reference. Proposition initiale : p_reference = p_s, explicitement nommé « estimation au prix de cette station ». Le coût exact du carburant déjà dans le réservoir n'est pas connu.

CAL-03 · Comparaison : cout_compare_s = achat_s + cout_detour_s + deltaFrais, seulement si toutes les composantes revendiquées sont connues. Si les frais supplémentaires sont inconnus, afficher le sous-total « achat + carburant du détour » et indiquer les exclusions. Ne pas l'appeler coût total du voyage.

CAL-04 · Différences négatives : un petit écart numérique peut être traité selon une tolérance documentée. Un écart significatif négatif indique un changement de route ou d'hypothèse : ne pas le masquer par max(0, ...). Revalider le trajet de référence ou présenter explicitement une nouvelle proposition, avant de la classer comme simple détour.

CAL-05 · Temps : détour et durée totale sont séparés. Le temps du plein, l'attente et l'entrée/sortie ne sont inclus que s'ils sont connus ou paramétrés ; sinon préciser « hors temps du plein ». Aucun zéro supposé pour une durée absente.

CAL-06 · Coût du voyage : la quantité achetée n'est pas égale à la quantité consommée sur le trajet. Pour le voyage, estimer distance × consommation / 100 × prix_reference, puis ajouter les autres composantes disponibles. Ne pas ajouter à nouveau l'intégralité du plein.

CAL-07 · Précision : calculs sans arrondi intermédiaire ; valeurs monétaires arrondies à deux décimales à l'affichage, prix carburant à trois, distances selon leur précision utile. Pour les tris, les montants comparés sont ramenés au centime ; les égalités restent explicites.

Exemple de Recette Entièrement Fictif

Trajet de référence 100 km, quantité 40 L, consommation 6,2 L/100 km. Station A : 1,80 EUR/L, détour 6 km et 8 min. Achat 72 EUR ; détour 0,372 L, soit 0,6696 EUR ; sous-total affiché 72,67 EUR. Station B : 1,78 EUR/L et aucun détour : 71,20 EUR. Si des frais sont inconnus, ces nombres ne sont pas un coût total intégral.

Badges et Ordre

Une différence inférieure à la précision des hypothèses ne doit pas être présentée comme une supériorité certaine. Les classements sont calculés sur les mêmes paramètres, quantités et périmètres.

11Ajout d’un Arrêt et Conservation du Trajet

ARR-01 · Référence immuable : conserver un identifiant de route, sa géométrie, ses étapes, son fournisseur, sa date et ses contraintes. La route avec arrêt est un nouvel objet lié à cette référence, pas un écrasement silencieux.

ARR-02 · Conservation : une station se rattache à une section du trajet sélectionné. La méthode choisie doit préserver les parties hors détour, ou signaler explicitement que le moteur recalcule une route différente. Les points de passage d'ancrage ne doivent pas créer de demi-tours ni de mauvaises chaussées.

ARR-03 · Matrice et variantes : ne pas soustraire la durée d'une variante lente à des accès calculés sur une autre route rapide. Une matrice non contrainte ou sans référence à la variante ne suffit pas à garantir un détour cohérent. Si nécessaire, réduire le nombre de candidates et calculer chaque trajet via station avec les contraintes requises.

ARR-04 · Confirmation : avant ajout, vérifier la route complète, actualiser km/minutes/coûts, montrer le tracé et laisser confirmer si le résultat diffère de la comparaison. En cas d'échec, l'ancien trajet valide reste identifiable et l'arrêt n'est pas marqué comme confirmé.

ARR-05 · Suppression : retirer l'arrêt restaure la route de référence sans conserver des coûts ou marqueurs de sélection obsolètes.

ARR-06 · Nombre d'arrêts : un arrêt carburant dans le premier lot. Plusieurs arrêts ordonnés sont une évolution ; elle requiert recalcul cumulatif et autonomie par segment. Ne pas laisser ajouter un deuxième arrêt si l'interface ne sait conserver que le dernier.

ARR-07 · Sortie vers navigation : toute application externe reçoit les points qu'elle peut accepter ; avertir si contraintes ou variante ne sont pas exportables. Une ouverture externe ne prouve pas qu'elle reprend le même parcours.

12Autonomie et Usage en Déplacement

VISION : autonomie. EXIGENCE : trouver une station proche lorsque le plein devient urgent. Ces deux besoins ne doivent pas être confondus avec une assistance d'urgence.

Le futur suivi continu doit traiter perte GPS, sortie de route, pause/reprise, consommation inconnue et changement de réseau. Il ne se déduit pas d'un simple bouton de géolocalisation.

13Fiches Stations et Favoris

14Profil, Adresses et Données Personnelles

EXIGENCE : enregistrer véhicule, adresses et stations. VISION : profil local d'abord.

Limites proposées héritées du prototype : 50 adresses, 100 stations favorites, nom 80 caractères, adresse 250, import 100 000 octets. Elles sont des protections initiales documentées, à revoir lors de l'ajout du journal. Un dépassement produit un message utile, jamais une troncature silencieuse.

Le stockage local n'est pas un coffre-fort chiffré. Prévoir un inventaire des données transmises : géocodeur reçoit les lieux recherchés ; routeur reçoit des coordonnées et contraintes ; fournisseur de tuiles reçoit des requêtes cartographiques. « Sans compte » ne signifie donc pas « aucune donnée sort de l'appareil ».

15Covoiturage

La vision inclut conducteurs, passagers, embarquement, détour, frais partagés et consentement. Le prototype ne possède actuellement qu'un lien externe.

L'accès à des offres implique de vérifier autorisations, conditions, quotas et couverture. Un lien vers un site public ne donne pas le droit technique ou contractuel d'en aspirer les annonces.

16Transports Publics et Mobilités Douces

Transports Publics

Marche, Vélo et Vélo Partagé

17Tapis Volant et Boussole

VISION : prix, temps, CO₂e, vie privée, accessibilité et choix éthiques visibles, pondérés par la personne. Les nombres et exemples de la présentation sont des maquettes, pas des valeurs de production.

BOU-01 · Deux étages : appliquer d'abord les contraintes strictes ; classer ensuite les possibilités admissibles selon les préférences. Un faible coût ne compense ni un gabarit incompatible ni une arrivée trop tardive.

BOU-02 · Comparabilité : même départ/arrivée, même date, mêmes voyageurs et périmètre de coûts. Si une solution n'a pas de prix, la montrer comme incomplète et ne pas la classer devant les autres grâce à une absence de donnée.

BOU-03 · Vue sans score : toujours pouvoir lire et trier les valeurs brutes. Le score ne remplace ni euros, ni minutes, ni kg CO₂e.

BOU-04 · Filtres éthiques : exclusions/préférences d'opérateur ou d'enseigne explicites et réversibles. La liste d'acteurs ne constitue pas un jugement éditorial caché.

BOU-05 · Vie privée et liberté : commencer par des attributs factuels sourcés : compte requis, partage de localisation, licence connue, export disponible. Pas de note numérique tant qu'un barème vérifiable et sa gouvernance n'ont pas été approuvés.

BOU-06 · Accessibilité : les besoins indispensables sont des contraintes, pas seulement un curseur. Les préférences de confort peuvent être pondérées séparément.

Algorithme Proposé pour les Critères Numériques

Version initiale limitée aux critères mesurables et disponibles pour toutes les solutions du groupe comparé : coût, durée, CO₂e. Pour un critère à minimiser, n_i = (x_i - min_i) / (max_i - min_i). Si toutes les valeurs sont égales, n_i = 0. Poids de l'utilisateur w_i >= 0, somme strictement positive ; score de coût S = somme(w_i × n_i) / somme(w_i) ; plus petit = meilleur selon ces poids et ce groupe.

Cette normalisation dépend du groupe de solutions. Ajouter une option peut changer les scores ; le groupe est donc figé pendant l'interaction, puis un recalcul explicite actualise la comparaison. Aucun score comparable entre deux recherches différentes n'est promis.

BOU-07 : un critère actif manquant rend la solution « comparaison incomplète » ; ne pas renormaliser les poids différemment pour chaque candidat. Proposer un groupe comparable ou demander de désactiver le critère pour tout le groupe.

BOU-08 : si tous les poids sont nuls, aucune recommandation pondérée ; revenir au tri choisi. Afficher la contribution de chaque critère et enregistrer la version de la formule avec le résultat.

BOU-09 : les ex æquo restent ex æquo à la précision affichée. L'ordre secondaire déterministe utilise durée, puis coût connus, puis identifiant ; il ne devient pas une supériorité morale ou scientifique.

Cette formule est une PROPOSITION à valider, pas une formule imposée par la présentation. Sa recette doit inclure variations de poids, valeurs manquantes, égalités, changement de groupe et absence de solution admissible.

18Empreinte et Journal de Mobilité

19Recharge Électrique, Navigation et Hors Ligne

Recharge Électrique · Lot Futur

ELE-01 : profil véhicule avec connecteurs compatibles, capacité utile et consommation. ELE-02 : distinguer puissance nominale de borne, puissance admissible et courbe de charge ; ne pas calculer tout le temps de charge par une simple division par la puissance maximale. ELE-03 : prix avec unité, abonnement, frais d'occupation et date ; tarifs inconnus non comparés comme gratuits. ELE-04 : disponibilité horodatée et provenance ; jamais une garantie à l'arrivée. ELE-05 : stratégie de réserve et arrêts multiples, avec hypothèses de température/consommation déclarées si utilisées. Fournisseurs et périmètre à décider avant développement.

Installation et Fonctionnement Dégradé

OFF-01 : installer la PWA peut rendre l'interface accessible sans réseau ; aucune promesse de nouveau calcul ou de nouveaux prix hors ligne sans moteur et données adaptés.

OFF-02 : un trajet sauvegardé est un instantané daté. Il est consultable comme tel, sans trafic ni prix rafraîchis simulés. Les données personnelles ne sont pas stockées dans un cache public partagé.

OFF-03 : une mise à jour du cache ne supprime ni le profil ni les données d'autres applications. Les aperçus n'installent pas le service worker de production.

OFF-04 : ne pas télécharger massivement les tuiles d'un fournisseur qui ne l'autorise pas. Le vrai hors ligne nécessite une source et une licence adaptées.

OFF-05 : Organic Maps est une piste de la présentation. Liens profonds, formats d'échange et reprise des contraintes doivent être étudiés avant promesse d'intégration. Un benchmark séparé décidera PWA, hybride ou natif ; aucune réécriture automatique du produit.

20Modèle de Données Commun

PROPOSITION technique : les fournisseurs sont adaptés vers un contrat interne versionné. Les écrans et la Boussole ne lisent pas directement les formats propres à OSRM, ORS ou aux opérateurs de transport.

Conventions

Coordonnées GeoJSON [longitude, latitude] en WGS84 dans le contrat ; conversion explicite vers [latitude, longitude] pour Leaflet. Distances en mètres, durées en secondes, montants accompagnés d'une devise, volumes en litres, CO₂e en kilogrammes. Dates ISO 8601 avec fuseau/offset pour les instants ; conserver le fuseau de service pour les horaires locaux. null signifie inconnu ; un champ absent n'est pas un zéro.

Valeur Sourcée Commune

{
  "value": null,
  "unit": "EUR",
  "status": "unavailable",
  "sourceId": "provider-id",
  "declaredAt": null,
  "fetchedAt": "2026-09-17T18:00:00Z",
  "validUntil": null,
  "methodVersion": null,
  "reason": "Tarif non fourni"
}

États proposés : observed, estimated, unavailable, stale. Une estimation possède une méthode ; une observation porte sa date lorsqu'elle existe ; une date de consultation ne se substitue pas à la date de la donnée. Les schémas JSON exécutables et migrations sont un livrable du premier lot d'architecture, non fournis implicitement par cet exemple.

21États, Erreurs et Concurrence

ERR-01 : chaque calcul porte requestId et révision ; toute réponse d'une révision dépassée est ignorée, même si l'annulation réseau a échoué.

ERR-02 : un échec carburant ne supprime pas la route valide. Un échec de carte ne détruit pas la liste. Un schéma de secours est nommé comme tel, pas présenté comme une carte routière complète.

ERR-03 : une nouvelle recherche invalide les anciens résultats avant d'en afficher d'autres. Une erreur de recalcul d'arrêt ne confirme pas cet arrêt ; l'état précédent est conservé comme précédent.

ERR-04 : les réponses partielles sont identifiables. Pas de « tout va bien » global si la moitié des recherches station a échoué.

ERR-05 : erreurs 429/quotas, délais dépassés et absence de résultat ont des messages distincts. Respecter Retry-After lorsqu'il existe, limiter les tentatives et éviter les boucles automatiques.

ERR-06 : valeurs infinies, négatives impossibles, géométries vides, caractères HTML et réponses hors schéma sont rejetés ou neutralisés. Ne jamais injecter le contenu d'une source dans du HTML exécutable.

22Fournisseurs et Architecture d’Hébergement

Fournisseurs et Arbitrages

La documentation ORS expose l'évitement des péages/autoroutes et des restrictions dimensionnelles pour certains profils. Cela ne prouve ni l'adéquation d'un profil caravane, ni la disponibilité gratuite d'un volume d'usage, ni l'application des mêmes options à une matrice. Ces points nécessitent une recette fournisseur.

API à Clé et Hébergement GitHub

ARC-01 : un site statique ne protège pas un secret distribué à ses visiteurs. Une clé injectée dans un fichier JavaScript reste lisible ; la placer dans un secret GitHub Actions puis la compiler côté navigateur ne la rend pas secrète.

ARC-02 : EXIGENCE CONFIRMÉE. L’expérience publique ne demande aucune clé API ni compte technique aux visiteurs. L’ancienne saisie de clé personnelle est retirée du parcours. Les secrets d’exploitation restent côté serveur, hors dépôt, liens, journaux, captures et exports.

ARC-03 : pour un service public sans clé utilisateur, choisir soit un fournisseur autorisant une clé publique limitée, soit une architecture serveur approuvée. Un serveur protège le secret mais constitue une décision d'infrastructure ; ne pas ajouter Cloudflare ou un autre hébergement sans accord.

ARC-04 : chaque adaptateur expose ses capacités et limites : modes, exclusions, variantes, étapes, dates, gabarit, matrice, attribution, quotas, couverture. L'interface se fonde sur ce contrat de capacités, pas sur des boutons hardcodés optimistes.

ARC-05 : le remplacement d'un fournisseur passe par des tests de contrat et une vérification de ses conditions. Aucun changement silencieux qui transfère davantage de données à un tiers.

23Fraîcheur, Cache et Fiabilité

Les seuils ci-dessous sont des PROPOSITIONS produit, pas des garanties des sources. Ils seront ajustés et versionnés après tests réels.

DAT-01 : tester une source vivante avant activation, puis régulièrement selon son importance, avec fréquence approuvée. Les tests automatisés déterministes n'envoient pas de recherches massives aux services publics.

DAT-02 : un diagnostic indique les composants indépendants : carte, géocodage, routage, carburants, autres sources. Un succès réseau n'atteste pas la justesse métier.

DAT-03 : limites de débit respectées par fournisseur et par périmètre applicable. Un délai dans un navigateur ne garantit pas à lui seul le respect d'un quota global pour tous les visiteurs.

24Accessibilité, Sécurité et Qualité

La signalisation, les circonstances réelles et les vérifications du conducteur restent déterminantes. Le produit ne doit pas transformer des données routières potentiellement incomplètes en promesse de sécurité, d'ouverture ou de conformité réglementaire.

25Plan de Recette Exécutable

Chaque exigence d'un lot reçoit : test associé, type de preuve, résultat et commit. Les cas ci-dessous forment le noyau obligatoire ; ils ne remplacent pas les critères dans les tables précédentes.

Niveaux de Preuve

1. Unitaires : formules, filtres, égalités, conversions, validations, migrations, dates et provenance.
2. Contrats fournisseurs : requêtes construites, capacité et réponse normalisée, erreurs/quotas. Jeux enregistrés anonymisés et versionnés.
3. Navigateur simulé : parcours reproductibles, clavier, erreurs, stockage, carte réelle avec données simulées.
4. Tests vivants limités : requêtes réellement acceptées, contraintes réellement prises en compte, fraîcheur/couverture ; cadence respectueuse et aucune donnée privée dans le rapport.
5. Inspection humaine : lisibilité du tracé et compréhension des coûts, scénario caravane, mobile réel, pertinence des recommandations.

Pour « sans autoroutes », obtenir des attributs de tronçons ou une preuve documentée du fournisseur. Une route différente sur la carte ne suffit pas à prouver l'exclusion. Pour le gabarit, prévoir des cas connus de restriction et vérifier également les limites de couverture ; ne pas faire de tests de conduite risqués.

26Lots, Dépendances et Ordre de Livraison

Les jalons J0–J9 de la présentation décrivent la vision. Ils ne sont ni des jours de travail, ni une estimation de délai. Les lots ci-dessous proposent un ordre de réalisation contrôlable.

Le premier cycle de développement donne priorité à la fiabilité du routage et des arrêts. Les autres modules sont intégrés par lots successifs. L'identité OùQuandQui peut être harmonisée progressivement sans retarder les corrections utiles de DragonRoute.

27Registre des Arbitrages

Il n'est pas nécessaire de résoudre les quinze décisions pour corriger la carte. En revanche, DEC-01/02/04 doivent être réglées avant d'annoncer routes contraintes et alternatives fiables avec stations.

28Critères d’Achèvement et Livrables

Une fonctionnalité est terminée seulement lorsque son comportement, ses erreurs, ses limites et sa preuve sont présents. Un bouton, une maquette ou un test qui ne vérifie que le chargement ne suffisent pas.

Contenu Obligatoire de Chaque PR

• Identifiants d'exigences et décisions concernés ; périmètre inclus/exclu.
• Implémentation et éventuelle migration de données ; aucune modification étrangère au lot.
• Tests déterministes et contrôles des contraintes métier.
• Rapport lié au commit exact, aperçu identifiable et captures ordinateur/mobile.
• Preuves de données vivantes lorsque la fonctionnalité dépend d'une nouvelle capacité externe.
• Résultat des contrôles accessibilité et limites des navigateurs effectivement testés.
• Sources, dates, conditions d'utilisation et risques résiduels.
• Procédure de retour à la version précédente sans effacer les profils.
• Validation éditoriale et fonctionnelle des changements d'expérience par la responsable du produit ; les tests automatisés ne valent pas autorisation de publication.

LIV-01 : l'aperçu doit afficher son numéro de PR et son commit. LIV-02 : le rapport doit concerner exactement cette version. LIV-03 : une publication ne peut pas déclarer vert un rapport d'un ancien commit. LIV-04 : l'échec d'un test obligatoire bloque la publication concernée. LIV-05 : aucun original documentaire écrasé ; versions datées conservées.

Gabarit de Ticket

Titre : [ID] Verbe + résultat utilisateur
Origine : EXIGENCE / VISION / PROPOSITION validée par DEC-xx
Situation initiale :
Comportement attendu :
Entrées, unités, valeurs autorisées :
Sorties et provenance :
Contraintes et dépendances :
Erreurs et données manquantes :
Effets sur les autres écrans et données persistées :
Critères d'acceptation :
Tests / captures / requêtes vivantes :
Hors périmètre :
PR et commit livrés :
Validation du produit : en attente / validé / à corriger

29Traçabilité des Exigences

30Sources et Journal des Versions

Références du Produit

• Présentation de OùQuandQui, édition initiale du 16 septembre 2026 : vision du produit, modules et feuille de route. Consultable dans l'onglet Présentation de ce dossier.
• Exigences routières : calculer le trajet avant les arrêts ; proposer l'évitement des péages et des autoroutes ; prendre en compte le véhicule et le gabarit ; chercher des stations selon l'urgence ou une distance cible ; regrouper les badges ; afficher des points de station avec leurs fiches ; enregistrer adresses et favoris ; distinguer le trajet principal en bleu des alternatives en bleu clair.
• PR 4 DragonRoute, état de référence ab129e4 ; code source et fiches DragonRoute-Trajet-Arrets.md, DragonRoute-Profil-Stations.md.

Références Techniques · 17 septembre 2026

• OSRM : API de routage et alternatives. Une capacité de l'API n'atteste pas son activation dans chaque instance.
• OpenRouteService : options et restrictions. Source des capacités candidates ; compte, contrat, profil caravane et combinaison des opérations restent à vérifier.
• IGN : calcul d'itinéraire et capacités du service. Options réellement examinées avant proposition d'un raccordement.
• OpenStreetMap : politique d'utilisation des tuiles. Référence à vérifier lors de toute évolution de cache ou de hors ligne.
• W3C : WCAG 2.2. Référence de l'objectif d'accessibilité ; la cible de confort 44 × 44 pixels proposée ici ne doit pas être confondue avec le minimum de tous les critères AA.

Références Complémentaires · Validation par Lot

• Impact CO₂ : transport et API.
• Données horaires SNCF référencées et transport.data.gouv.fr.
• Organic Maps.
• Politique du service Nominatim public : conditions d'utilisation à vérifier avant toute évolution du géocodage.
• Flux officiel des prix des carburants : source déjà utilisée par le prototype ; contrats et fraîcheur à contrôler avant extension.

Les prix, quotas, offres gratuites et droits d'utilisation des fournisseurs ne sont pas figés ici. Ils doivent être vérifiés à la date du raccordement ; aucun abonnement ou service payant n'est autorisé par ce cahier seul.

Journal

Règle de maintenance : une nouvelle idée est ajoutée au registre et rattachée à un lot ; elle ne modifie pas silencieusement le périmètre d'une PR en cours. Une décision validée précise qui l'a validée, quand, les exigences touchées et le motif.

31Accès Public, France et Véhicules

Décisions Confirmées

PUB-01 : application destinée à un usage personnel et public. Préparer un trajet ne nécessite ni compte technique ni clé fournie par un visiteur. Les données personnelles du profil restent locales tant qu’aucune synchronisation consentie n’est développée.

PUB-02 : territoire initial : France. La couverture s’évalue par fonction et par fournisseur ; aucune carte mondiale ni réponse ponctuelle ne constitue une preuve d’exhaustivité. Les écarts métropole/outre-mer et les zones sans données doivent rester visibles.

PUB-03 : véhicules légers et poids lourds distincts. Une caravane ne devient pas un poids lourd par une conversion implicite. Tant que son profil n’est pas validé, le calcul est refusé explicitement plutôt que remplacé par un trajet voiture. Un utilitaire exige également un profil qualifié avant toute promesse de gabarit.

PUB-04 : poids lourd : cinq valeurs strictement positives exigées, hauteur, largeur et longueur totale en mètres, poids en charge et charge maximale par essieu en tonnes. Charge par essieu inférieure ou égale au poids total. Bornes techniques de la première implémentation : 6 m, 6 m, 40 m, 100 t, 30 t respectivement. Ces bornes ne sont pas des limites réglementaires ni des validations de conformité. Matières dangereuses et transport exceptionnel hors de ce lot.

PUB-05 : les mêmes exclusions et valeurs de gabarit sont transmises au trajet direct, aux alternatives et à chaque trajet via station. Un champ manquant, une réponse incohérente, une limitation de quota ou un accès refusé ne déclenche jamais un retour silencieux au routage voiture.

PUB-06 : routes non revêtues : piste de préférence à instruire, pas troisième catégorie de véhicule. Aucun filtre fictif, aucune promesse de franchissement, de droit d’accès ou d’état du chemin. Un fournisseur et des données adaptés restent nécessaires.

Contrat d’Accès et Activation

PUB-07 : POST /api/route accepte uniquement deux ou trois points GeoJSON, les exclusions péages/autoroutes/ferries, un véhicule léger ou HGV et la demande booléenne d’alternatives. Pas d’URL amont libre ni de clé client. Le serveur reconstruit la requête vers une destination fixe et ne renvoie que géométrie, distances, durées et segments validés.

PUB-08 : aucun secret de routage dans le navigateur, les exports ou les rapports. Les coordonnées et le gabarit sont transmis au service puis au fournisseur ; la finalité est indiquée avant le calcul. Les historiques d’adresses ne sont pas envoyés en bloc. Politique de conservation des tiers à qualifier avant ouverture.

PUB-09 : GitHub reste l’hébergement du site et des aperçus. L’exécution d’un service secret ne relève pas de GitHub Pages. Le code serveur est préparé sans hébergeur imposé, compte créé ni dépense engagée. L’activation exige un choix d’infrastructure approuvé et les conditions d’usage des fournisseurs vérifiées.

PUB-10 : plafonds de requêtes avant ouverture, absence de dépassement payant non autorisé et surveillance des quotas. Les limites en mémoire du prototype ne constituent pas une protection financière durable : compteur partagé persistant ou plafond fournisseur dur, protections anti-abus et contrôle des redémarrages sont des préalables. CORS n’est pas une authentification.

PUB-11 : lorsque le service n’est pas activé, le routage léger standard demeure disponible sans exclusions. Une option avancée bloque avant géocodage avec un état explicite. Le nombre d’alternatives dépend du moteur ; absence d’alternative et indisponibilité de sa recherche sont distinguées.

Démonstration et Évolutions

PUB-12 : PROPOSITION COMMERCIALE. Une période de démonstration d’un mois ou davantage, puis une éventuelle facturation, sont envisagées. Durée, prix, conversion, conditions et budget restent à décider. Aucun paiement, abonnement, expiration automatique ni promesse d’essai illimité ne sont implémentés. Les coûts d’exploitation doivent être connus avant l’ouverture, pas découverts après la démonstration.

Condition d’hébergement commercial : GitHub Pages ne doit pas être utilisé pour héberger un site principalement destiné à fournir un logiciel commercial en ligne. Avant une offre payante, prévoir une solution d’hébergement conforme et explicitement approuvée ; le dépôt peut rester sur GitHub. L’hébergement actuel du prototype n’est pas modifié. Source : limites officielles de GitHub Pages, consultées le 18 septembre 2026.

PUB-13 : recharge de véhicules électriques reportée aux évolutions ultérieures ; le premier module carburant n’implique pas une couverture des bornes. Transports publics, covoiturage connecté, mobilités douces, Boussole et Empreinte restent dans le cahier global et leurs lots respectifs, sans données inventées.

Critères de Recette Complémentaires

Édition V3 du cahier / V4 du dossier centralisé, 18 septembre 2026 : accès public, France et véhicules confirmés ; architecture sans clé visiteur, activation séparée, hypothèse commerciale et critères de recette ajoutés. Les originaux restent conservés.

32Péages et Budget du Trajet

Objet et État

Demande : lorsque les routes à péage sont autorisées, estimer les péages du trajet choisi et présenter un budget lisible, avec le carburant consommé sur ce trajet. Comparer, lorsque les données le permettent, un itinéraire avec péages et un itinéraire sans péage, en conservant les autres contraintes du véhicule.

État : SPÉCIFIÉ, NON RACCORDÉ. Aucun montant de péage n’est actuellement calculé par le prototype. Le service de routage préparé ne fournit pas de tarifs. Cette édition précise les exigences ; elle n’active ni fournisseur, ni compte, ni dépense. Rattachement : lot routier L1, en complément de CAL-03, CAL-06 et PUB-03/05. Activation soumise aux règles PUB-08/10.

Exigences Fonctionnelles

PEA-01 · Tarif du Trajet Sélectionné. Estimer un aller simple pour la géométrie effectivement affichée, le sens, les entrées et sorties, le véhicule et, si nécessaire, la date et l’heure du passage. Ne pas facturer un autre trajet obtenu à partir des seuls points de départ et d’arrivée. Si le fournisseur ne permet pas de vérifier la concordance, afficher l’indisponibilité. Un aller-retour nécessite deux calculs ; aucune multiplication automatique par deux.

PEA-02 · Trois Montants Distincts. Afficher « Carburant estimé », « Péages estimés » et « Total estimé carburant + péages ». Le coût d’un plein acheté demeure dans la comparaison des stations ; ce n’est pas le coût du carburant consommé pendant le déplacement. Les frais de stationnement, de ferry ou autres frais ne sont pas implicitement inclus : afficher les postes exclus ou leurs montants séparément.

PEA-03 · Comparaison Avec et Sans Péage. Sur demande, comparer les véritables trajets calculés avec les mêmes points, véhicule et autres contraintes : durée, distance, carburant et péages. « Péages autorisés » ne signifie pas « péages obligatoires ». L’absence d’alternative ne donne lieu à aucun tracé ni prix inventé. Ne pas qualifier une route de « moins chère » lorsque des postes nécessaires à la comparaison manquent. Présenter le temps supplémentaire en minutes, sans conversion imposée en euros par heure.

PEA-04 · Véhicule et Classe Tarifaire. Séparer le profil de routage de la classification tarifaire. Recueillir les caractéristiques réellement requises par le fournisseur pour la voiture, l’attelage ou le poids lourd ; expliciter hauteur, masses et essieux selon son contrat. Une caravane n’hérite ni automatiquement du tarif voiture seule, ni automatiquement du tarif poids lourd. Afficher l’hypothèse de catégorie retenue ; en cas d’ambiguïté, demander la précision nécessaire ou annoncer un tarif indisponible. Ne pas afficher une classe comme certaine si elle n’est pas qualifiée.

PEA-05 · Données Incomplètes. Distinguer quatre états : « Sans péage confirmé », « Estimation disponible », « Estimation partielle » et « Tarif indisponible ». Une liste vide, une erreur, une absence de couverture ou une option d’évitement cochée ne suffisent pas à justifier 0 €. Une estimation partielle présente le sous-total connu et les tronçons manquants ; aucun total global complet n’est affiché. Une panne tarifaire ne masque pas le trajet valide : sa carte et son coût carburant peuvent rester visibles avec l’état incomplet.

PEA-06 · Actualisation Cohérente. Toute modification de trajet, alternative, arrêt, véhicule, paramètre tarifaire ou date pertinente invalide immédiatement l’ancien tarif et relance le calcul approprié. Une réponse tardive d’une ancienne recherche ne peut pas remplacer la nouvelle. Après ajout d’une station, recalculer les péages sur tout le trajet modifié : ne pas additionner aveuglément des devis de tronçons qui recouvrent le même paiement.

PEA-07 · Source et Hypothèses. Associer au devis le fournisseur, la date de récupération, la date de validité si disponible, la devise EUR, les caractéristiques retenues et la couverture. Préciser « estimation », sans promesse de prix garanti. Ne pas supposer de réduction par abonnement ou télépéage ; sélectionner un tarif ordinaire compatible avec le moyen de paiement retenu. Des tarifs alternatifs sont des choix, pas des montants à additionner.

PEA-08 · Interface Sans Lecture Obligatoire des Avertissements. Rendre les options indisponibles identifiables et non activables avant la recherche, avec un motif court visible à proximité. Distinguer « En cours », « Indisponible » et « Sans péage » au niveau du montant lui-même. Les précisions détaillées peuvent être dépliables ; l’état essentiel ne doit pas être caché dans un paragraphe ou un diagnostic technique. Ne pas ajouter un calculateur factice pour représenter une fonctionnalité future.

Contrat de Calcul

PEA-09 · Formules et Arrondis. Pour une consommation moyenne déclarée constante : carburant_estime = distance_km × consommation_L_100km / 100 × prix_reference_EUR_L. La distance est celle du trajet retenu, détours compris. Le prix de référence et sa date sont affichés ; la consommation peut différer selon le véhicule, la charge et les conditions. Aucun péage moyen au kilomètre n’est utilisé comme substitut à un tarif documenté.

peages_estimes = somme des paiements distincts applicables à ce trajet, après sélection d’un seul tarif applicable par paiement. total_carburant_peages = carburant_estime + peages_estimes, uniquement si les deux composantes sont disponibles et la couverture tarifaire complète. Calculer avec la précision source, puis arrondir l’affichage final au centime. Les variations de péage induites par une station alimentent deltaFrais de CAL-03 uniquement si les deux devis sont comparables et complets. Les différences, y compris négatives, restent expliquées ; aucun double comptage du détour ou du plein.

PEA-10 · Réponse Normalisée à Développer. Prévoir un résultat attaché à l’identifiant et à la révision du trajet : status (no_tolls, estimated, partial, unavailable), amountEur (nombre non négatif ou null), knownSubtotalEur pour un résultat partiel, provider, fetchedAt, tariffValidAt si connu, hypothèses du véhicule et du paiement, éléments tarifaires et avertissements. Pour un résultat partiel ou indisponible, amountEur = null ; seul un résultat no_tolls dûment confirmé autorise zéro comme absence de péage. Les notices de couverture et de tarif ne sont jamais ignorées. Ce contrat est une extension future, absente de l’actuel service PUB-07.

Données et Conditions de Raccordement

HERE Routing documente une réponse tarifaire par section, des variations selon les caractéristiques du véhicule ou le paiement et une estimation sans garantie d’exactitude exhaustive. La requête tarifaire compte comme transaction supplémentaire. Il s’agit d’un candidat à évaluer, pas d’un fournisseur choisi ou activé. Source : documentation officielle HERE sur les péages, consultée le 18 septembre 2026.

Avant raccordement : vérifier couverture France, prise en charge tarifaire réelle des caravanes, correspondance au trajet choisi, fraîcheur, cas sans péage, licences d’affichage, coûts, quotas et protection des données. Valider des exemples contre les tarifs des exploitants concernés. Une capacité d’évitement des péages ne prouve pas une capacité à en calculer le prix. Les offres commerciales ne sont pas figées dans ce document.

Critères de Recette

Confort Routier et Caravane

Le besoin de confort consiste à privilégier les axes principaux et à éviter les routes étroites ou non revêtues, lorsque le moteur et les données le permettent. Il reste distinct du véhicule déclaré et de sa classe de péage. Le mode poids lourd ne constitue pas une garantie de largeur, d’état de chaussée ou de sécurité pour une caravane. Les préférences de confort restent à qualifier, sans approximation silencieuse par le seul profil poids lourd ; les limitations et la signalisation réelles demeurent déterminantes.

Édition V4 du cahier / V5 du dossier centralisé, 18 septembre 2026 : estimation des péages, budget carburant + péages, états incomplets, règles tarifaires de l’attelage et critères de recette ajoutés. Les versions antérieures sont conservées. Aucune activation du calcul tarifaire dans l’application à cette étape.