Comment Kargit calcule un trajet

Principes de calcul, hypothèses retenues et techniques d'accélération, avec l'impact de chacune sur le résultat. Les valeurs chiffrées sont celles du code au moment de la rédaction (référence entre parenthèses) : si une constante change, cette page doit être mise à jour.

1. Vue d'ensemble

Un calcul se déroule toujours dans le même ordre :

1. Adresses → coordonnées (géocodage, avec cache).
2. Itinéraire(s) demandé(s) à un moteur de routage : distance, durée et tracé. C'est lui qui fournit le temps de conduite.
3. Bornes candidates : celles situées dans un couloir autour du tracé, projetées dessus (position le long du trajet + détour).
4. Recherche du meilleur plan de recharge : un algorithme de plus court chemin choisit où s'arrêter et jusqu'à quel niveau de batterie recharger, selon le critère du mode (coût, temps ou compromis).
5. Coût réel des recharges : pour chaque arrêt envisagé, le tarif le moins cher applicable (opérateur, moyen de paiement, abonnement, heure, puissance).
6. Péages du tracé retenu, calculés à part et ajoutés au total.
7. Variantes proposées à côté du résultat : sans abonnement, péage inversé, itinéraires alternatifs (durée seulement).

2. Itinéraire

• Géocodage : service principal au choix dans l'admin (LocationIQ ou Photon auto-hébergé), avec repli sur l'autre, puis OpenRouteService et Nominatim (voir section 12 quater), et un cache mémoire puis en base.
• Moteur de routage principal : OpenRouteService auto-hébergé (graphe France, profil voiture, pondération « le plus rapide »). OSRM (public) sert à deviner des couloirs alternatifs, et GraphHopper auto-hébergé apporte un candidat supplémentaire (parfois meilleur, par exemple via la RN147 à Poitiers). ORS compte souvent plus lent que GraphHopper, OSRM et Google Maps (Corse : Bonifacio → Bastia 3 h 30 avec ORS, 2 h 41 avec GraphHopper) : quand GraphHopper trouve le même itinéraire (distance à 2 % près), la durée retenue est la moyenne des deux (ORS pessimiste, GraphHopper optimiste sur les routes sinueuses ; tracé et profils de GraphHopper), sans appel de plus.
• Itinéraire par défaut : parmi les candidats, celui de durée minimale (et non de distance) est retenu.
• Sans péage : ORS avec l'option « éviter les autoroutes à péage », plus le profil sans péage de GraphHopper. Les couloirs OSRM ne sont pas utilisés dans ce mode, car leur milieu tombe presque toujours sur une autoroute payante. Un trajet évité comme demandé a un péage de 0 € (le moteur garantit l'absence d'autoroute payante).
• Hors de France : le graphe ORS ne couvre que la France ; le calcul retombe alors sur OSRM, sans évitement des péages (un avertissement est affiché).
• Étapes : un trajet avec étape est un seul itinéraire forcé par ces points (pas d'alternatives). ORS et GraphHopper le calculent en parallèle (le temps de calcul reste celui du plus lent, pas la somme) et, si c'est le même itinéraire, la durée est la moyenne des deux (sinon le plus rapide est gardé). Les étapes sont situées sur le tracé dans l'ordre demandé (chacune est cherchée après la précédente : une étape qui revient au point de départ n'est plus placée avant les autres).

• Profil de vitesse par tronçon : avec l'itinéraire, le routeur fournit le type de route et la vitesse de chaque tronçon, qui servent à la consommation (section 3) et à la durée de conduite quand la vitesse maximale sur autoroute est plafonnée (kilomètres d’autoroute). ORS : étapes (distance, durée) et catégorie de voie « autoroute » (extra_info waycategory) ; GraphHopper : classe de route et vitesse limite/moyenne par tronçon (path details). OSRM n'en fournit pas. Un itinéraire sans profil retombe sur une vitesse constante déduite de sa vitesse moyenne.

3. Consommation et autonomie

La consommation dépend de la vitesse réelle de chaque tronçon : énergie d'un tronçon = distance × consommation de référence (fiche véhicule, kWh/100 km, proche du WLTP à ~90 km/h) × facteur météo × facteur vitesse du tronçon. Elle est ramenée en points de batterie (SOC) par rapport à la capacité utile du véhicule. Les énergies cumulées le long du trajet sont précalculées : l'énergie d'un arc borne → borne est une simple différence, sans ralentir la recherche.

Vitesse de croisière d'un tronçon : 130 km/h sur autoroute (limite légale ; plafonnée par « vitesse maximale sur autoroute », qui ajuste aussi la durée, voir section 2) ; ailleurs, la vitesse moyenne du tronçon ramenée à la limite légale immédiatement supérieure (30, 50, 70, 80, 90, 110) ou, avec GraphHopper, la vitesse limite OSM ; toujours plafonnée par le réglage « vitesse maximale sur autoroute » (90, 110 ou 130 km/h, défaut 130). Les tronçons à 80-90 km/h réduisent donc la consommation par rapport à la référence.

Dénivelé (septembre 2026) : ORS renvoie l'altitude du tracé (données SRTM, environ 5 km d'échantillonnage, lissée sur 3 échantillons pour ne garder que le relief de fond : le relief ondulé est déjà compris dans la consommation de référence, calée sur ABRP). Par intervalle, énergie = énergie à plat + montée × masse × g / 0,85 (rendement batterie → roues) − descente × masse × g × 0,5 (la régénération ne rend que la moitié de l'énergie potentielle), sans jamais descendre sous zéro. Masse = masse à vide de la fiche technique + 100 kg (passager et bagages) ; les masses des 210 véhicules ont été relevées sur fiches-auto.fr, ev-database.org, meilleurelectrique.fr, auto-data.net et les fiches constructeur (colonne « Masse à vide » de l'onglet Véhicules, source en infobulle), avec repli 1150 kg + 7 kg par kWh de batterie (véhicule générique). Les itinéraires GraphHopper/OSRM, sans altitude, l'empruntent à l'itinéraire ORS voisin (au moins 35 % du tracé en commun, sinon relief ignoré). Ordres de grandeur (Mégane 60, météo standard) : Grenoble → Briançon +12,7 points de batterie (+6,6 kWh/100 km), Briançon → Grenoble −1,1, Chambéry → Modane +7,2, Modane → Chambéry −2,8, Nice → Barcelonnette +17,3, Rennes → Nice +11,1 sur 1204 km, Rennes → Tours +1,5. Calculé une fois par itinéraire : aucun impact mesurable sur les temps de calcul (ORS 116 ms sans altitude, 117 avec). Le détour vers une borne n'inclut pas le relief.

Hypothèses non modélisées : température réelle, vent réel, préconditionnement de la batterie. Les détours vers une borne sont comptés au taux de consommation moyen du trajet, à plat (leur vitesse et leur relief sont inconnus). La vitesse moyenne d'une étape du routeur est une approximation de la vitesse de croisière (ronds-points et virages la tirent vers le bas, d'où l'arrondi à la limite légale).

4. Recharge : puissance, durée, paliers

• Courbe de charge par véhicule : table de paliers de SOC (puissance moyenne par palier) — 1 271 lignes pour 211 véhicules (dont le générique « standard »). Recalibrage de septembre 2026 (scripts/recalibrate_charging_curves.py) : chaque courbe garde sa forme mais est mise à l'échelle (plafonnée à la puissance DC max) pour donner un temps 10 → 80 % réaliste, tiré des mesures du Supertest 2024 d'Automobile Propre quand le modèle y figure (ID.7 Pro 27 min, Cupra Born 28, Volvo EX30 28, Scénic 38, Peugeot e-208 29, ID.3 Pro 32, Renault 5 30) ou du temps constructeur + 10 à 15 % de marge (Ioniq 5 / EV6 : 20 min, Model 3 GA 30, Niro EV 47, Leaf e+ 50, Dacia Spring 52…). Mégane E-Tech 60 : 10 → 80 % en 35 min (34 à 38 min mesurés, 30 annoncés), 10 → 100 % en environ 1 h ; la charge 80 → 100 % est longue pour tous les véhicules (10 → 100 % : 43 min pour une Ioniq 5, 55 à 75 min pour la plupart des autres). Les formes elles-mêmes restent des approximations par famille de plateforme documentées dans db/seed_charging_curves.sql. À défaut de courbe : 2 paliers (100 % de la puissance DC max jusqu'à 70 % de SOC, puis 40 % au-delà). 22/09/2026 : 41 véhicules ajoutés (recherche sourcée par famille de plateforme -- Stellantis eCMP/eCMP2/STLA, VW MEB, Hyundai/Kia E-GMP 400V/800V, BYD LFP, Renault-Nissan AmpR Small, BMW FAAR/Neue Klasse, Mercedes MFA2/EVA2, Toyota e-TNGA, Xpeng SEPA 2.0, MG MSP, Honda, Ford, Smart SEA -- voir scripts/recalibrate_charging_curves.py pour le détail par véhicule et les sources). Pour une plateforme encore absente de la base, la forme est reprise d'un véhicule de la plateforme la plus proche déjà calibrée puis remise à l'échelle sur la cible 10 → 80 % propre à ce véhicule (mesurée indépendamment quand trouvée, sinon constructeur + marge comme les autres). 25/09/2026 : 130 véhicules ajoutés, dont la Dacia Spring 2e génération (commandes ouvertes le 08/09/2026), les modèles électriques vendus neufs qui manquaient encore et les modèles d’occasion courants (Renault Zoé ZE50 R110/R135, Nissan Leaf 40 kWh en CHAdeMO, Kona et e-Niro 64 kWh de 1re génération, BMW i3, e-Golf, e-208/e-2008/Corsa-e 50 kWh, anciennes Model 3/S/X, e-tron, I-Pace, EQC…), avec les années dans le libellé. Même méthode (une source par champ, forme de courbe de la plateforme la plus proche, recalage sur la cible 10 → 80 % du véhicule) ; les cibles sont lues dans scripts/vehicles_batch_20260925.json (statut par véhicule : mesure indépendante, équivalence, constructeur + marge, ou estimation EV Database quand rien d’autre n’a été trouvé). Le catalogue ne couvre que les versions capables de recharge rapide DC : Zoé ZE40 ou ZE50 sans option CCS, Twingo Electric, Smart EQ, Kangoo Z.E. n’y figurent pas (aucune borne de la base ne pourrait les recharger). Famille e-3008 73 kWh (e-3008, ë-C5 Aircross, Grandland, Compass) : 10 → 80 % commun de 40 min. Les fiches qui décrivent une ancienne version portent désormais leurs années (Spring 2021-2025, Mini Cooper SE F56, EQA 250, EV6 77,4 kWh, RZ 300e, XC40 Recharge), la version actuelle ayant sa propre fiche.
• Puissance moyenne d'une recharge = énergie / temps, c'est-à-dire la moyenne harmonique des paliers traversés (chaque point de SOC représente la même énergie : le temps d'un palier est sa portion de SOC divisée par sa puissance), plafonnée par la puissance de la borne et par la puissance DC max du véhicule. La puissance de la borne est celle du connecteur du véhicule (stations_query.py, 25/09/2026) : pour une voiture en CHAdeMO (Nissan Leaf), c’est la puissance de la prise CHAdeMO de la fiche borne, et 50 kW quand elle est inconnue (CHAdeMO porté par le même point qu’un CCS) ou pas crédible (au-delà de 100 kW : Ionity déclare 350 kW pour les CHAdeMO de ses « Multicharger », limités à 50 kW d’après son support ; les CHAdeMO déclarés chez Ionity et Electra existent bien, une prise par station environ) -- avant, elle héritait de celle du CCS (« 300 kW » chez Allego) ; Leaf e+ Paris → Lyon : 83 → 96 min de recharge. Voitures en CCS : inchangé, sans coût ajouté à la recherche. Correction de septembre 2026 : la version précédente faisait la moyenne arithmétique des puissances, ce qui surestimait la puissance dès qu'on traverse des paliers lents (Mégane E-Tech 60, 28 → 100 % : 34 min annoncées, 43 min avec le bon calcul, + 4 min d'arrêt). Effet sur les plans : temps de recharge cumulé Rennes → Lille 75 → 89 min, Paris → Marseille 105 → 132 min.
• Durée d'un arrêt = énergie / puissance moyenne + 4 minutes forfaitaires (se garer, brancher, payer). Le temps facturé (tarifs au temps) reste la charge pure.
• Niveaux de recharge par pas de 5 % : la batterie visée à chaque arrêt est un multiple de 5 % (précision : quelques points de SOC).
• Détour : un arrêt à une borne éloignée de l'axe ajoute 2 × la distance à vol d'oiseau borne–tracé à la distance parcourue, donc à l'énergie et au temps (à la vitesse moyenne du trajet). Le détour réel par la route n'est pas calculé pendant la recherche. Aires de l'autre sens (29/09/2026, retour d'un utilisateur : « un demi-tour sur autoroute pour aller chercher la station dans l'autre sens ») : une borne à moins de 500 m du tracé, à GAUCHE du sens de circulation, sur une portion roulée à 110 km/h ou plus, est vérifiée par GraphHopper (chemin réel « tracé 5 km avant → borne → tracé 5 km après », sens de circulation imposé aux deux points). Si ce chemin allonge le trajet de plus de 2 × détour estimé + 4 km, la borne est écartée des candidates (station_access.py, appelé par candidates_for_route). Verdict mémorisé par borne et par sens (secteur de 45°), en mémoire et en base (table station_access_checks) : une aire n'est vérifiée qu'une fois par sens. Sur les 20 trajets de test : 230 bornes vérifiées, 90 écartées (ex. « A7 - Aire de la Bouterne (direction Lyon) » en descendant : +55 km réels pour 0,6 km estimé ; IONITY Corbières Nord en allant vers le sud) ; 2 trajets sur 20 changent d'arrêt. Temps de calcul : inchangé une fois les verdicts mémorisés ; première vérification limitée à 2,5 s et 40 bornes par itinéraire (≈ +0,5 s par trajet la première fois). Carte : sur le trajet sélectionné, un trait fin montre le chemin réel vers chaque borne (sortie, accès, retour), demandé après l'affichage (POST /api/stop-access, GraphHopper, sans effet sur le temps de recherche). Depuis le 26/09/2026, ce temps de détour compte aussi dans le choix des bornes (graph.py et _search_native.pyx, arête de conduite) : en « le plus rapide » 1 min de détour pèse comme 1 min de charge, en équilibré au même prix de la minute, en « le moins cher » il ne sert qu'à départager deux coûts égaux. Avant, il n'était compté que dans la durée affichée : Model Y Propulsion Lille → Lyon choisissait un Superchargeur à 7 km de l'axe pour une minute de charge gagnée (7 h 36 → 7 h 27 avec la correction). Parité moteur compilé / Python : 432 recherches identiques ; temps de calcul inchangé. « Le plus rapide » tient compte du prix depuis le 29/09/2026 (retour d'un utilisateur, accord de Jérémy) : classement = coût + durée × 1 €/min (FAST_VALUE_OF_TIME_EUR_PER_MIN), au lieu de la durée seule. Le temps reste très prioritaire (un arrêt qui fait gagner 10 min pour 5 € de plus est toujours choisi), mais Kargit ne paie plus 12 € pour une minute : Limoges → Kembs (Model Y) prenait un Allego à 0,59 €/kWh pour gagner 1 min de détour sur le Superchargeur de Limoges à 0,32 €/kWh. Aller-retour Kembs ↔ Limoges : 922 min / 128,29 € → 931 min / 89,03 € ; Marseille → Toulouse (Model Y) : même durée, 33,39 → 24,33 € (le départage entre options aussi rapides était arbitraire). Le moteur compilé utilise sa formule « équilibré » avec cette valeur du temps (aucune recompilation). Temps de calcul : 0 à 0,1 s de plus selon le trajet (mesures sur 4 recherches).
• Recharges plafonnées : jamais au-delà de 100 %, jamais de décharge en cours de route.

Règles de confort (ajoutées car le plan mathématiquement le moins cher proposait des arrêts absurdes, par exemple +1 point de batterie pour 0,22 €) :

• Un arrêt doit apporter au moins 15 points de SOC ; sinon la recharge est reportée sur la borne précédente.
• Un arrêt d'où la destination n'est pas atteignable directement doit repartir à 65 % au moins (pas de demi-recharge qui impose de se rearrêter aussitôt).
• Contrepartie acceptée : le prix peut être un peu plus élevé que le minimum absolu. Si ces règles rendent un trajet infaisable, la recherche est relancée sans elles : elles ne rendent jamais un trajet infaisable.

Une limite optionnelle du nombre d'arrêts est aussi disponible (« m'arrêter moins souvent, quitte à payer plus »).

5. Choix des bornes candidates

L'ordre des bornes le long du trajet est obtenu en projetant chaque borne sur un sous-échantillon d'environ 300 points du tracé : imprécision de quelques centaines de mètres, sans effet sur le résultat.

Fiche borne (survol sur la carte). Elle ne change rien au calcul : elle est demandée à la volée au survol d'un arrêt (jamais pendant la recherche, donc sans effet sur sa durée) et rejoue le tarif de la borne pour cette session (énergie, durée et heure d'arrivée de l'arrêt). Les connecteurs viennent de la base IRVE : nombre de prises et puissance max par type (CCS, Type 2, CHAdeMO), recalculés à chaque import. L’IRVE ne donne la puissance que par point de charge : sur un point rapide qui porte aussi une prise Type 2 (courant alternatif) ou un CHAdeMO à côté du câble CCS, cette puissance ne vaut que pour le CCS ; ces prises-là sont affichées sans puissance, et un point Type 2 seul est plafonné à 43 kW (corrigé le 25/09/2026, la fiche affichait « Type 2 150 kW »). Position des bornes : l’import quotidien (scripts/import_irve.py) ne garde que les coordonnées situées en France métropolitaine, Corse comprise (colonnes consolidées puis coordonneesXY, une paire latitude/longitude inversée étant remise dans l’ordre) ; une borne sans position plausible est écartée, donc retirée de la base au passage suivant, outre-mer compris pour l’instant (25/09/2026 : Allego Saint-Clément-de-Rivière placée dans le golfe de Guinée, Tesla Val-de-Meuse au Kazakhstan -- cette dernière retrouve sa vraie position, 16 bornes d’outre-mer retirées). Depuis le 28/09/2026, chaque position est aussi soumise au géocodeur du serveur (Photon, recherche inverse dans un rayon de 2 km, 4 requêtes en parallèle, environ 3 s pour toutes les bornes) : une borne qui ne tombe pas en France est écartée (Allego Anglet placée dans la Manche, une borne Powerdot réellement en Belgique rattachée au Pas-de-Calais). Géocodeur injoignable : contrôle sauté, toutes les bornes gardées. Site en plusieurs fiches (28/09/2026) : un réseau qui republie ses bornes sous de nouveaux identifiants laisse l’ancienne déclaration dans le fichier (Allego : FRALLPEVCARS… de mars puis FREVCP… de septembre ; Ionity : fiches de 2023 à une prise sous les sites de 2026). Même opérateur et (a) à moins de 20 m, ou (b) jusqu’à 500 m avec au moins la moitié des prises en commun, sur des numéros d’au moins 6 chiffres (les numéros courts coïncident entre bornes différentes). Prises en commun (sans le préfixe : FRALLEGO9000571 = FREVCE9000571) ou fiche plus vieille de 6 mois : on ne garde que la déclaration la plus récente, sans additionner les prises. Prises différentes et même période (deux bornes Lidl d’un parking) : une seule fiche, prises additionnées. Les tarifs Electra régénérés chaque jour suivent la fiche gardée, les exclusions des utilisateurs aussi ; deux fiches portant chacune un tarif saisi à la main restent séparées. Sur la prod : environ 750 fiches en trop retirées (Electra, Allego, TotalEnergies, Ionity…). Les tarifs sont toujours au plus quatre lignes, chacune au prix de l'heure d'arrivée : le tarif retenu par le calcul (quel qu'il soit), la carte bancaire, l'appli de l'opérateur de la borne sans abonnement (seulement si elle est moins chère que la carte bancaire, ou toujours quand la borne n'a pas de prix par carte, comme Tesla) et le prix avec l'abonnement de cet opérateur (le moins cher) quand le calcul ne l'a pas retenu ; les abonnements d'un autre réseau ne sont affichés que s'ils sont le tarif retenu. Une ligne dont le prix varie selon l'heure (au moins deux plages de prix différents) porte « variable selon l'horaire » : un clic déplie sa grille horaire (une seule dépliée à la fois), montant de la session par plage. Heure d'arrivée connue : la plage cochée est celle de l'arrivée ; inconnue : la plus chère, comme dans le calcul. Sur ordinateur, la fiche reste ouverte quand on y amène la souris et pendant un déplacement de la carte (elle suit alors sa borne) ; elle se ferme quand la souris la quitte ou repart ailleurs sur la carte, et à chaque zoom ou dézoom (même règle que l'onglet Bornes). Sur la carte du trajet, une horloge dans la bulle de prix d'un arrêt signale que son tarif retenu varie selon l'heure (champ hourly des arrêts de /api/plan et /api/trip-plan, même règle que l'onglet Bornes : tariffs.option_varies_by_hour, au moins deux plages horaires à des prix différents pour ce moyen de paiement / abonnement ; calculé après la recherche sur les seuls arrêts retenus, lignes de tarif déjà en cache).

Disponibilité des prises en direct (26/09/2026). Source : la consolidation nationale des données IRVE dynamiques du Point d’accès national (transport.data.gouv.fr, schéma etalab/schema-irve-dynamique, un point de charge par ligne : état en service / hors service, libre / occupé, état de chaque type de prise). Le serveur la relit toutes les 2 minutes (backend/app/live_status.py, environ 1,6 Mo compressé, calcul d’environ 0,5 s dans un fil d’arrière-plan) et la croise avec les points de charge de chaque borne, enregistrés par l’import IRVE (colonne stations.pdc_types). Affichée dans la fiche de borne (onglet Bornes et détail d’un arrêt) : « libres / total » par type de prise, prises et borne hors service, heure de la donnée avec un point vert qui pulse (maquette pack_disponibilite_D2). Règles, pour ne jamais afficher un chiffre faux : seulement les opérateurs dont le flux est vraiment en direct (mesuré le 26/09/2026 : Tesla, Ionity, Fastned, Izivia, Powerdot, Lidl, TotalEnergies, Engie Vianeo, Driveco ; Electra, Allego, Atlante, Freshmile et Leclerc publient avec des heures ou des mois de retard, rien n’est affiché pour eux) ; un opérateur dont le flux ne bouge plus depuis 1 h est ignoré automatiquement ; au moins la moitié des points de la borne doivent avoir un état connu, et le compte ne porte que sur ceux-là (un point absent du flux est le plus souvent un ancien identifiant resté dans le fichier des bornes) ; plus rien n’est affiché si la dernière relecture a plus de 10 minutes. La fiche relit la disponibilité chaque minute tant qu’elle reste ouverte. Effet sur le calcul : une borne dont tous les points sont connus et hors service est écartée des trajets (au moment de lister les bornes le long de l’itinéraire, api/_shared.py::candidates_for_route ; vérification en mémoire, sans effet mesurable sur la durée de recherche) ; rien n’est écarté quand la donnée a plus de 10 minutes. Ajout du 28/09/2026 : Allego suivi par le flux national borne par borne (seulement les bornes dont un point a changé d’état depuis moins de 24 h : 250 sur 402 le 28/09, les autres étant figées depuis des semaines, PER_STATION_OPERATORS) ; Electra lu à la demande dans l’API publique de leur carte (backend/app/electra_live.py) : une requête pour la station à l’ouverture de sa fiche, gardée 1 min, car leur flux national arrive par paquets avec plusieurs heures de retard ; Electra n’intervient pas dans le calcul des trajets (bornes hors service non écartées). Atlante : rien de fiable en direct (flux national figé, fichier de leur carte vieux d’environ 10 h). Ajout du 29/09/2026 : R3 suivi de la même façon qu’Allego, borne par borne (mesuré le 29/09 : dernier changement d’état il y a 1 min, 150 stations sur 165 avec un changement depuis moins de 24 h, 4 figées, 11 avec moins de la moitié de leurs points dans le flux). Pays voisins (29/09/2026, backend/app/eu_live.py), mêmes règles d’affichage : Suisse, flux officiel OFEN (data.geo.admin.ch, OICP), relu toutes les 2 min ; sans horodatage par point, Kargit note lui-même les changements d’état, et un opérateur n’est suivi que si l’un de ses points a changé depuis moins d’1 h : 503 stations sur 637 le 29/09, 7 min après le démarrage (GOFAST et Tesla absents ou figés) ; Pays-Bas, flux officiel NDW (OCPI, 17 Mo compressés), relu toutes les 4 min dans un processus à part (eu_live_nl.py : le décodage prend environ 5 s et 1 Go, il bloquerait sinon les recherches) ; une station n’est suivie que si l’un de ses points a changé depuis moins de 24 h (Tesla, E.ON, Valk… figés, écartés d’eux-mêmes) : 691 stations sur 791 le 29/09 ; Portugal, flux officiel DATEX II de MOBI.E (point d’accès national, fiche n° 149, libre accès, republié toutes les 5 min, ~36 Mo de XML) : un HEAD par minute, relu seulement quand son ETag change, dans un processus à part (eu_live_pt.py, ~23 s) ; fichier tronqué rejeté (balise de fin absente ou moins de 12 000 points), identifiant de point présent sur plusieurs sites ignoré ; même règle que la Suisse (changements notés par Kargit, opérateur suivi seulement si l’un de ses points a changé depuis moins d’1 h) : 2 077 stations sur 2 229 lors du test du 29/09 ; Royaume-Uni, flux « open data » imposés par les Public Charge Point Regulations 2023, seuls ceux ouverts sans inscription : MFG (OCPI, 3,6 Mo, relu toutes les 5 min, au-delà il répond 429) : 577 stations sur 591 ; « INOPERATIVE » chez MFG = prise sœur occupée (puissance partagée), comptée occupée ; GeniePoint publie aussi mais son flux refuse l’adresse du serveur (403, Cloudflare) ; InstaVolt, Osprey, Shell, IONITY, GRIDSERVE, Fastned : formulaire ou contrat exigé, rien; Italie (sources officielles sans compte ; ni la plateforme nationale PUN ni le compte « invité » d’Enel) : IONITY par le serveur de l’appli IONITY Direct (une fiche par station, état de chaque prise, 42 appels toutes les 5 min) et Free To X par sa page carte officielle (un appel toutes les 5 min, servie par un cache d’environ 5 min, retiré de l’heure affichée) : même règle que la Suisse (changements notés par Kargit, opérateur suivi seulement si l’une de ses prises a changé depuis moins d’1 h), 42 et 109 stations sur 42 et 109 ; Duferco à la demande, à l’ouverture de la fiche (jeton anonyme de sa carte publique, gardé 2 min), codes 1 et 9 libres, 2 et 5 occupés, 3, 4, 7 et 8 hors service ; Ewiva, Tesla, Fastned : aucun direct public ; Allego : données figées (jamais une prise occupée), non affichées; Electra dans tous les pays par leur API (BE, CH, DE, ES, LU, NL). Mesure du 29/09 (deux relevés à 3 min d’intervalle) : 166 changements d’état en Suisse, 1 014 aux Pays-Bas. Allemagne, Belgique (hors Electra), Espagne : pas de flux ouvert sans inscription (Mobilithek, clés à demander). Le flux national français ne sert plus qu’aux bornes françaises.

Fiche borne de l'onglet Bornes. Même présentation que la fiche des trajets, sans trajet donc sans « tarif retenu par le calcul » : elle utilise une session type de 30 kWh (25 min), comme les prix des repères, et affiche le prix effectif au kWh (frais de session et de temps répartis sur l'énergie), la puissance max, le nombre de prises, les connecteurs et les services à moins de 300 m. Les tarifs suivent la colonne « Abonnements à considérer » de droite (au départ : les abonnements déjà possédés, sans rien enregistrer sur le compte) : rien de coché = le tarif le moins cher avec abonnement (tous réseaux), l'appli de l'opérateur sans abonnement, la carte bancaire ; des abonnements cochés = une ligne par abonnement coché applicable à la borne, puis l'appli sans abonnement et la carte bancaire en repère, la moins chère étant cochée. Un abonnement réservé à ceux qui le possèdent déjà (Plug Inn Charge Pass) n'est jamais proposé tant qu'il n'est pas coché. Appel à la demande (/api/tariffs-map/station/{id}/card?map_view=true), sans effet sur la recherche de trajet. La fiche suit sa borne quand on déplace la carte ; un zoom ou un dézoom la ferme. La carte des tarifs n'affiche que des bornes chiffrées : les opérateurs sans prix vérifiable (Freshmile, Greenspot, voir pricing_policy.py) et les bornes sans aucun tarif connu ne sont ni dessinés, ni comptés, ni proposés dans le filtre des opérateurs.

6. Tarifs, coûts et modes

• Prix d'une recharge = frais de session + prix au kWh × énergie + prix à la minute × durée + frais de déverrouillage, pour la ligne de tarif retenue.
• Les trois modes de paiement : carte bancaire, appli de l'opérateur avec abonnement (un tarif par abonnement : ex. Allego Plus), appli sans abonnement (compte gratuit : ex. Allego Smart). À chaque arrêt, Kargit retient le moins cher des trois. Les cartes multi-réseaux (Plugsurfing, Mobilize...) ne sont jamais plus avantageuses que ces trois modes sur les tarifs en base.
• Tesla Supercharger : pas de paiement par carte bancaire sur ce réseau, on paie via l'appli Tesla. Le prix « non-Tesla » sans abonnement est donc un tarif d'appli sans abonnement, et le prix « membre » celui de l'abonnement Tesla Supercharging (11,99 €/mois). Pour un véhicule Tesla, ce prix membre est inclus d'office : le calcul l'applique sans abonnement ni frais mensuel (les lignes de l'abonnement deviennent des lignes sans abonnement, voir VEHICLE_BRAND et BRAND_INCLUDED_SUBSCRIPTIONS dans tariffs.py ; même mécanisme pour le Charge Pass Basic sur les bornes Plug Inn Fast Charge (véhicules Renault, Dacia, Alpine) ; marque lue sur le véhicule du calcul, y compris dans les processus parallèles et pour la fiche borne).
• Offres réservées (case « Réservé aux clients qui le possèdent » d'un abonnement, ex. Plug Inn Charge Pass, réservé aux véhicules Renault) : leurs tarifs ne comptent que si l'utilisateur déclare déjà posséder l'offre (coût mensuel alors nul) ; sinon elles sont exclues du calcul, donc jamais proposées ni testées comme abonnement à souscrire (owned_only_subscription_ids, appliqué en entrée de /plan et /trip, aucun coût dans la boucle de recherche). La variante « sans nouvel abonnement » garde les abonnements déjà possédés (avant, elle les excluait aussi : un abonnement possédé était ignoré dès que le calcul de base en préférait un autre, non possédé).
• Sélection du tarif : lignes applicables à la borne (une ligne spécifique à la borne l'emporte sur la ligne générique de l'opérateur pour le même moyen de paiement), filtrées par bande de puissance et par plage horaire. On prend la ligne de coût net minimal.
• Heure de départ inconnue : impossible de garantir un tarif à horaires variables. Pour chaque moyen de paiement / abonnement pris séparément, le pire cas horaire est retenu (prudence), puis le moins cher parmi ces pires cas. Préciser l'heure de départ peut donc baisser le prix affiché.
• Onglet Bornes (carte des tarifs) : prix calculés pour une session type (30 kWh, 25 min), à l'horaire de recharge à considérer — par défaut l'heure actuelle de l'appareil (la nuit, le prix de nuit ; mis à jour tout seul à chaque quart d'heure), ou une heure choisie dans le panneau. Le tarif est celui valable à cette heure (hour de /tariffs-map/stations, arrival_hour de la fiche), plus le pire cas. La bulle de la borne, la ligne cochée de sa fiche et la plage cochée de sa grille horaire (dépliable par « variable selon l'horaire » sur chaque ligne dont le prix varie, une seule à la fois) donnent toujours le même prix ; une horloge sur la bulle signale un prix variable selon l'heure. Sans heure envoyée (ancienne version de la page), retour au pire cas horaire.
• Filtre « Prise · kW » de l'onglet Bornes (29/09/2026) : types de prise (CCS, CHAdeMO ; une borne passe si elle a au moins une des prises choisies) et puissance minimale de la borne (50, 150 ou 300 kW, d'après sa puissance maximale), appliqués aux regroupements, aux bornes et à « Autour de moi » (PlugFilter, app/api/tariffs_map.py). Onglet Bornes seulement : les trajets gardent la prise du véhicule. Les bornes italiennes Electra et Free To X ont reçu leur type de prise le même jour (collecteurs prix_electra_it.py, prix_freetox_it.py), sans quoi ce filtre les aurait masquées.
• « Afficher sur la carte les prises dispo en direct » (fenêtre « Prise · kW », 29/09/2026) : la disponibilité des bornes affichées (donc déjà filtrées) en UN appel, POST /api/tariffs-map/availability-batch, après les prix ; la bulle reçoit « ● libres/total » (pastille verte s'il reste une prise libre, rouge sinon), comptés sur les prises du filtre, sinon CCS et CHAdeMO (un point qui porte les deux compte une fois : type le mieux fourni). Dispo inconnue : bulle inchangée. Flux en mémoire lus directement ; Electra et Duferco (demandés à l'opérateur) : au plus 40 par appel, 8 à la fois, gardés 1 à 2 min. Aucun effet sur la recherche de trajets. Présenté comme un sélecteur « Affichage » (Prix seuls / Prix + dispo en direct) ; le choix est retenu pour un utilisateur connecté (profil, colonne users.default_bornes_live, migration 20260929_bornes_live_pref.sql).
• Abonnements : le frais mensuel (et l'éventuel achat unique) est ajouté une seule fois au total s'il est utilisé ; un abonnement déjà possédé est gratuit. Un chemin ne peut engager qu'un seul abonnement payant.
• Cashback / crédit futur / points : ne sont jamais déduits du coût (depuis septembre 2026). Ils n'influencent ni le choix des arrêts, ni celui du tarif, ni celui de l'abonnement, ni le total affiché : ce total correspond à ce que l'on paie réellement (recharges + abonnement). Leur montant reste calculé (valeur plafonnée du programme) et affiché à part, à titre d'information. Option « Prise en compte du cashback » (Options avancées, décochée par défaut ; requête consider_cashback, mémorisée sur l'appareil et dans le profil) : si elle est cochée, 50 % du cashback (fixe, sans pondération par type de récompense) est retranché du coût utilisé uniquement pour comparer les tarifs et les plans (Dijkstra, choix de l'abonnement, « sans abonnement », top 3, abonnement manqué), car un cashback ne sert qu'une fois : recharge à 50 € avec 10 € de cashback comparée comme 45 €. Le moteur tient donc deux coûts : le coût de classement (rank_cost_eur) et le coût payé (total_cost_eur), qui ne déduit jamais le cashback ; les totaux affichés restent le coût payé. Seule une réduction immédiate (remise appliquée à la borne) est un vrai prix et se déduit du coût net ; la base n'en contient aujourd'hui aucune (les trois récompenses connues — Atlante, Engie Vianeo — sont des crédits futurs).
• Tarifs « exemple » : signalés dans le tableau des tarifs de l'onglet Données.

Trois modes de recherche existent côté calcul, et l'interface en présente quatre :

Le mode cost pur (coût seul, avec une durée infime en départage) existe dans le moteur mais n'est plus utilisé par l'interface : il ignore le temps et donnait par exemple un « sans abonnement » moins cher que « le moins cher », ce qui était déroutant.

6 bis. Sources des tarifs

• Fiches des bornes françaises (import IRVE quotidien, scripts/import_irve.py) : un même site déclaré plusieurs fois est réduit à une fiche, la déclaration la plus récente : fiches à moins de 20 m, ou à moins de 500 m avec des prises en commun, ou (depuis le 29/09/2026) du même nom à moins de 60 m (Allego « Rouillé-Pamproux ASF » et « Abbeville », déclarés en 2023 puis en 2024). Une déclaration plus vieille de 6 mois est écartée sans additionner ses prises ; sinon les prises des bornes voisines sont réunies. Seules les fiches qui portent un tarif saisi à la main sont protégées d'une fusion : les tarifs repris automatiquement par position (Electra, IONITY, Driveco, Tesla, pages de paiement Powerdot, Lidl, Izivia) ne bloquent plus la fusion (29/09/2026 : ils l'empêchaient pour les doublons IONITY, Lidl et Powerdot), la fiche gardée les reçoit à la relecture suivante. Puis les corrections de la table station_overrides sont appliquées (fiches IONITY masquées ou renommées d'après l'API officielle, voir IONITY). Audit en lecture seule : scripts/audit_bornes.sql.
• Pays voisins (29/09/2026) : les bornes sûres de Belgique, Suisse, Allemagne, Espagne, Luxembourg et Pays-Bas (puis, préparés en base locale le 29/09 après-midi : Italie, Royaume-Uni, Portugal — sans registre téléchargeable en Italie et au Royaume-Uni, stations prises à la source officielle de chaque opérateur ; au Portugal, registre national MOBI.E, prix final = [énergie du fournisseur + taxe IEC + frais MOBI.E + tarif de l'exploitant] × TVA, calculé pour le paiement sans compte et l'appli Galp, par créneau jour / nuit) sont publiées dans les tables du site par scripts/etranger/publier_prod.py, depuis la zone de travail etranger (onglet « Pays voisins ») : seulement les tarifs d'un opérateur au statut « sûr » ou lus dans l'API officielle de l'opérateur, jamais un statut « incertain » ni un tarif expiré ; seulement les stations qui ont un de ces tarifs ; pas les stations à horaires limités (même règle que Driveco) ; une station à moins de 30 m d'une borne française du même opérateur est écartée (doublon de l'IRVE) ; un même site déclaré plusieurs fois dans un registre (même opérateur à moins de 50 m : Aral pulse, EnBW, E-Flux…) ne garde qu'une fiche, celle qui a un prix propre, puis la plus puissante (157 fiches écartées le 29/09/2026). Chaque borne et chaque ligne de tarif porte son pays (stations.country, tariffs.country, « FR » pour tout ce qui existait) : une ligne ne s'applique qu'aux bornes de son pays (Allego, Lidl, Electra… n'ont pas les mêmes prix en France et en Belgique). Les abonnements portent la liste des pays où ils valent (subscriptions.countries) ; une offre valable en France et ailleurs reste une seule ligne. Tout est enregistré en euros : les prix en francs suisses sont convertis au taux de référence BCE du jour de la publication (le prix d'origine et le taux restent dans la source de la ligne) ; seul le prix en euros est affiché. Trajets : seulement les bornes des pays couverts par le graphe routier, réglage TRIP_COUNTRIES_CSV (config.trip_countries, « FR » tant que le graphe ne couvre que la France ; filtre dans stations_query.py, et abonnements pertinents lus sur les tarifs de ces pays). Le graphe France + pays voisins est fabriqué à part par deploy/server/osm-europe-build.sh (extraits Geofabrik fusionnés, filtrés sur les routes, ferries et navettes ; moteurs en service inchangés tant qu'on ne bascule pas). Onglet Bornes : la carte montre toujours toutes les bornes (France et pays voisins) ; la bascule « France | Europe » (France par défaut) ne filtre que la liste des opérateurs et celle des abonnements (paramètre zone des points d'accès, « fr » par défaut pour les applis qui ne l'envoient pas encore). Les scripts de prix français (Electra, IONITY, Driveco, Tesla, Powerdot, Lidl, Izivia, grille Allego) ne lisent et n'écrivent que les bornes et tarifs français. Les lieux à proximité des bornes étrangères (moins de 300 m) sont ajoutés à osm_amenities (country), que l'import des lieux français ne remplace plus.
• Principe : un tarif spécifique à une borne (une ligne par plage horaire) l'emporte sur le tarif générique de l'opérateur pour le même moyen de paiement et le même abonnement ; le générique sert de repli pour les bornes sans relevé. La colonne « Source » de l'onglet Tarifs indique l'origine et la date de chaque ligne. Seuls les tarifs valables en France sont modélisés.
• Electra (script scripts/update_electra_tariffs.py, relancé toutes les 24 h par le conteneur electra_tariffs_updater) : l'API publique du site d'Electra donne, pour chaque borne, ses paliers horaires ; le rapprochement avec nos bornes se fait par coordonnées (≈ 50 m) et les lignes « carte bancaire » de la borne sont entièrement remplacées à chaque passage. Le supplément de congestion (borne très occupée) n'est pas modélisé.
• Electra : grilles variables selon le jour (depuis septembre 2026, plus de la moitié des bornes) : Kargit n'a pas de notion de jour de la semaine, il retient donc, pour chaque heure, le prix du jour le plus cher de la semaine (choix prudent : le prix n'est jamais sous-estimé). Exemple : si l'heure creuse est à 0,39 € le mardi mais à 0,49 € les autres jours, on retient 0,49 €.
• Electra+ (Essential et Smart) : la remise est de 0,10 €/kWh (Essential) et 0,20 €/kWh (Smart) sur le prix affiché de la borne, à toute heure, uniquement via l'appli. Pour chaque ligne « carte bancaire » d'une borne, deux lignes « appli Electra » de même plage horaire sont donc calculées (prix − 0,10 et prix − 0,20, jamais sous zéro), régénérées en bloc à la fin de chaque relevé (regenerate_electra_plus). Les lignes génériques à 0,39 € / 0,29 € restent en repli pour les bornes sans relevé ; les tarifs Electra+ Smart à 0,49 € sur Atlante, Fastned et Ionity (réseau ChargeLeague) sont saisis à part et ne sont pas touchés.
• Driveco (depuis le 28/09/2026, script scripts/update_driveco_tariffs.py, relancé toutes les 24 h par le conteneur driveco_tariffs_updater) : Driveco ne publie pas de grille, chaque borne a son prix. Son appli officielle l'affiche point de charge par point de charge, même sans compte ; le script lit la même API que l'appli (exploitation.driveco.com/icpm, clé fournie par l'appli) : la carte, découpée en zones de 100 stations au plus, puis la fiche de chaque station (puissance, prix au kWh, frais fixes par session, gratuité). Prix vérifiés à la main dans l'appli le 28/09/2026 (Carrefour Market Cazouls-lès-Béziers : 0,51 €/kWh sur les points 50 kW, 0,55 €/kWh sur les points 200 kW). Une station qui mélange des puissances a une ligne par tranche de puissance (power_band_min_kw / power_band_max_kw, seuls les points de 43 kW et plus) ; à puissance égale, le prix le plus cher. Rapprochement par coordonnées (80 m) : les 356 bornes Driveco de l'IRVE retrouvées. 29/09/2026 : Driveco est aussi reconnu par son nom d'exploitant dans l'import IRVE (« DRIVECO », « DRIVECO Partner Network », surtout des concessionnaires) : 671 stations au lieu de 356 ; les stations qui ne sont pas ouvertes 24 h/24 d'après l'API (horaires d'atelier, quelques Carrefour Market fermés le soir) n'ont aucun prix et ne sont jamais proposées (décision de Jérémy : Kargit ne gère pas encore les horaires d'ouverture) ; environ 430 stations chiffrées. Aucun prix selon l'heure. Un point marqué gratuit dans l'API n'est pas repris (29/09/2026 : concession Hyundai de Villeneuve-d'Ascq, en pratique réservée aux clients ; à 0 € elle aurait attiré tous les trajets du coin), ni un prix nul. Les frais de stationnement (0,30 €/min, 15 min après la fin de la charge) ne sont pas dans l'API et ne sont pas modélisés, comme la congestion d'Electra. L'ancienne ligne générique (prix d'agrégateur) est supprimée : une borne sans relevé n'est pas chiffrée. Enregistré comme paiement « carte bancaire / sans compte ».
• IONITY (depuis le 28/09/2026, script scripts/update_ionity_tariffs.py, relancé toutes les 24 h par le conteneur ionity_tariffs_updater) : la page tarifs d'IONITY n'affiche que des prix minimums (« les prix varient selon la borne »). Le script lit l'API de l'appli officielle (adhoc-bff.ionity.cloud, sans compte, avec les en-têtes de l'appli) : pour chaque point, le prix « IONITY DIRECT » (sans compte ni abonnement), rangé en carte bancaire, une ligne par tranche de puissance ; points haute puissance (150 kW et plus) d'un même site à des prix différents : le plus cher. Constaté le 28/09/2026 : 0,62 ou 0,55 €/kWh selon le site (l'ancien découpage « autoroute / hors autoroute » se trompait sur 22 bornes), anciens points 50 kW et 43 kW AC à 0,39 ou 0,35 €/kWh. Appli sans abonnement (« Go ») : l'API ne le donne qu'à un compte connecté ; seuls les paliers vus dans l'appli sont écrits (DIRECT 0,62 → 0,59 ; 0,55 → 0,52), sur la tranche haute puissance. Motion / Power : montants inchangés (0,39 / 0,31 au palier bas, lignes génériques 0,44 / 0,35 sinon), désormais rattachés au palier réel de chaque borne. Rapprochement par coordonnées (250 m). Fiches corrigées d'après l'API (29/09/2026) : le fichier national garde les déclarations IONITY de mars 2023 (FRIONE…) à côté de celles de septembre 2026 (FRIOYP…) ; 28 sites étaient en double et 32 fiches de 2023 portaient le nom et l'adresse d'un site avec les coordonnées exactes d'un autre (« Troyes Sud » dessiné à Tours). Chaque jour, avant les prix, chaque fiche est comparée au site de l'API le plus proche (250 m, même nom) : sur un site, la fiche la plus récente au bon nom est gardée, les autres sont masquées ; un site sans fiche au bon nom garde sa fiche la plus récente, renommée avec le nom et l'adresse de l'API ; une fiche loin de tout site de l'API est masquée (ex. « Val Gelon » près de Troyes). Corrections écrites dans la table station_overrides, que l'import IRVE quotidien applique aussi. Garde-fous : aucune correction si l'API renvoie moins de 500 sites, ou s'il faudrait masquer plus de 40 % des fiches.
• Prix par borne lus sur la page officielle de paiement de l'opérateur (29/09/2026, script générique scripts/charger_prix_fr.py : rapprochement par coordonnées, une ligne par tranche de puissance, points de 150 kW et plus d'un même site au prix le plus cher, frais au temps « après N minutes » non modélisés ; la ligne générique de l'opérateur reste en repli pour les bornes non retrouvées) : Powerdot (page de paiement par QR code, scripts/prix_powerdot_fr.py : 1 117 bornes sur 1 136, surtout 0,59 / 0,56 / 0,60 €/kWh au lieu de 0,54 partout), Izivia (page de paiement par carte PayNow, scripts/prix_izivia_fr.py : 872 bornes sur 1 043 ; IZIVIA FAST à 0,35 €, 0,30 de 9 h à 11 h et de 15 h à 17 h, on garde le plus cher), Lidl (page de paiement direct ChargePoint, scripts/prix_lidl_fr.py : 874 bornes sur 880, 0,39 € presque partout). Rangés en carte bancaire (paiement sans compte).
• Electra : prix appli, pas carte (corrigé le 29/09/2026) : la page officielle go-electra.com/fr/price indique « Prix variable selon l'affluence entre 0.39-0.61 € TTC / kWh » avec l'appli et « à partir de 0.64 € » par carte bancaire / QR sans appli. Le prix de l'API est donc rangé en appli Electra sans abonnement ; aucun prix carte par borne n'est publié, Electra n'a donc plus de ligne carte bancaire (les deux lignes génériques 0,39 / 0,49 « représentatif mais non garanti » sont supprimées). Electra+ reste dérivé du prix affiché dans l'appli.
• Allego (29/09/2026, scripts/maj_grille_allego.py) : grille officielle par puissance (allego.eu/pricing, France) : jusqu'à 50 kW 0,49 carte / 0,47 Smart / 0,35 Plus ; au-delà 0,59 / 0,56 / 0,39.
• Tesla Supercharger : l'API de tesla.com/findus est protégée (Akamai) et refuse toute requête venant d'un serveur, même avec un navigateur automatisé. Les prix sont donc lus depuis le navigateur de l'administrateur : onglet « Prix Tesla » de l'admin (favori à glisser dans la barre de Chrome, puis clic sur la page tesla.com, ≈ 20 minutes, lecture volontairement lente), résultat déposé par POST /api/admin/tesla-prices. Le rapprochement se fait par coordonnées : le site Tesla le plus proche de la borne, à moins de ≈ 400 m. L'onglet indique la date du dernier relevé et signale un relevé de plus de 14 jours. Chaque import ajoute une entrée à l'historique de l'abonnement Tesla.
• Tesla : ce qui est enregistré : Tesla ne se paie que par l'appli Tesla (jamais par carte bancaire) : pour chaque borne, le prix « non-Tesla » (véhicule sans abonnement) est enregistré comme un tarif appli Tesla sans abonnement, et le prix « membre » comme celui de l'abonnement Supercharging dans la même appli, chacun soit à prix unique, soit par tranches horaires. Quand Tesla renvoie à la fois un prix unique et des tranches horaires, seules les tranches comptent (le prix unique est un repli périmé qui, ajouté aux tranches, faussait le prix retenu). Les frais de congestion (par minute) ne sont pas modélisés ; un prix hors de 0 à 3 €/kWh est ignoré. Les bornes devenues réservées aux Tesla ou introuvables dans la liste Tesla gardent leur ancien relevé (à surveiller : il n'est plus mis à jour).
• Plug Inn Fast Charge (réseau de charge rapide Renault/Mobilize, 72 bornes de 320 kW importées de l'IRVE le 21/09/2026, tarifs de renault.fr au 05/05/2026, confirmés par l'utilisateur) : carte bancaire 0,59 €/kWh pour tout conducteur ; Charge Pass Intense 0,39 €/kWh (5,99 €/mois, réservé aux Renault : proposé seulement si l'utilisateur déclare le posséder) ; Charge Pass Basic 0,46 €/kWh (gratuit) appliqué d'office aux véhicules Renault, Dacia et Alpine (comme le tarif membre Tesla pour les Tesla : BRAND_INCLUDED_SUBSCRIPTIONS), jamais aux autres marques ; il s'affiche comme un prix « appli, sans abo » et n'est pas listé dans les abonnements du conducteur (HIDDEN_SUBSCRIPTION_IDS), rien à cocher. Les frais de stationnement (0,30 €/min au-delà d'1 h) ne sont pas modélisés. Script : scripts/add_plug_inn_tariffs.py.
• R3 (réseau de recharge rapide du groupe DBT, 156 stations de 100 à 180 kW importées de l’IRVE le 29/09/2026, nom_operateur exactement « R3 » : EXACT_OPERATOR_RULES dans import_irve.py) : carte bancaire ou QR code 0,55 €/kWh, sans frais supplémentaires, tarif unique sur toutes les stations publiques (dbt.fr/comprendre-sa-recharge, relevé le 29/09/2026, concordant avec le champ tarification IRVE). La recharge normale (jusqu’à 22 kW, 0,36 €/kWh) n’est pas chargée, car Kargit ne garde que les bornes rapides. R3 n’a ni application ni abonnement : une seule ligne. Script : scripts/add_r3_tariffs.py.
• Autres réseaux (Ionity, Engie Vianeo, Atlante, Allego, Powerdot...) : tarifs relevés à la main sur des sources publiques (site de l'opérateur, comparateurs), sans mise à jour automatique ; la source et la date de chaque ligne figurent dans l'onglet Tarifs.

7. Recherche du meilleur plan (algorithme)

Les états du graphe sont des (borne, niveau de batterie). Deux types d'arêtes : conduire jusqu'à une borne suivante (ou la destination) sans coût, en consommant de la batterie ; recharger à la borne courante jusqu'à un palier de 5 % plus haut, au coût du tarif retenu. Une recherche de plus court chemin (Dijkstra) trouve la combinaison la moins coûteuse selon le mode.

• Étiquettes de Pareto : un état garde plusieurs étiquettes (coût, SOC réel) ; une étiquette n'est éliminée que si une autre coûte au plus autant et arrive avec au moins autant de batterie. Cela remplace un ancien découpage du SOC en tranches de 5 % qui écartait à tort de bons plans (jusqu'à 67 % plus cher).
• Tolérances de dominance : 0,1 centime pour le coût, 0,5 point pour le SOC. Elles ont été calibrées empiriquement : une tolérance trop large produisait un prix faussement bas (12,42 € affiché pour 17,39 € réels sur Rennes → Paris). Ne pas les agrandir sans re-vérifier contre une recherche quasi exacte.
• Portée maximale d'un trajet de conduite : borne physique valable pour tout label, qui coupe l'exploration des bornes hors de portée. Aucun effet sur le résultat.
• Heure réelle à chaque arrêt : le temps écoulé est suivi de nœud en nœud pour appliquer les bons tarifs horaires.
• Trajet infaisable : si aucun plan n'existe avec les bornes trouvées, le résultat l'indique honnêtement (feasible faux, raison par trajet) et porte une erreur « Calcul impossible… » dans warnings de /plan et /trip-plan, et dans errors[i] de /multi-plan (le résultat reste renvoyé) ; si la batterie de départ est au plancher (ex. départ à 10 % avec 10 % minimum à chaque arrêt), le message le dit ; la batterie théorique à l'arrivée sans recharge est affichée à titre indicatif.

8. Recherche d'un abonnement rentable

Dijkstra minimise le coût par session : le frais mensuel d'un abonnement n'apparaît qu'une fois, au total. Pour ne pas rater un abonnement rentable sur l'ensemble du trajet, on compare aussi des recherches « avec cet abonnement gratuit » et « sans aucun abonnement », puis on garde le meilleur total (frais compris, cashback ignoré par défaut : un abonnement n'est recommandé que si l'économie sur le prix des recharges dépasse son frais, par exemple Atlante Go n'est plus retenu sur un trajet isolé quand seul son crédit futur le rendait rentable ; avec l'option « Prise en compte du cashback » cochée, le total de classement — dont 50 % du cashback est déduit — sert à ces comparaisons, mais le total affiché reste le coût réellement payé : Atlante Go redevient alors choisi sur Paris → Marseille et Lille → Nice). Pour limiter le nombre de recherches complètes :

1. Borne sûre : un abonnement dont le coût fixe dépasse déjà le meilleur total connu n'est jamais testé. Sans perte de précision.
2. Borne heuristique : un survol rapide des bornes majore le gain possible ; si même cette estimation généreuse ne couvre pas le coût fixe, l'abonnement est écarté. Peut, dans de rares cas, écarter un abonnement dont l'avantage tient à une taille de session très particulière.
3. Top 5 : au-delà des 5 abonnements au gain estimé le plus élevé, on ne teste plus (3 jusqu'au 21/09/2026 ; passé à 5 quand la recherche est devenue ~7 fois plus rapide, MAX_TESTABLE_SUBSCRIPTIONS). Compromis explicite : un abonnement au-delà du top 5 pourrait, très rarement, être le vrai gagnant sans être testé. Effet constaté : sur 70 voyages tests, 2 résultats changent, tous deux en mieux (Paris ↔ Strasbourg : 55,80 € → 51,26 € avec Electra+ Smart, jamais testé dans le top 3).

8 bis. Abonnements mutualisés entre plusieurs trajets

Quand l'interface calcule au moins deux trajets en mode « le moins cher » (POST /api/multi-plan), le forfait d'un abonnement est compté une seule fois par mois pour l'ensemble des trajets, et non en entier à chaque trajet : Atlante Go (9,99 €/mois) perd sur chaque trajet pris seul mais peut gagner sur la somme. La fréquence de chaque trajet (« N fois par mois ») et le cashback pondéré (coût de classement, voir section 6) sont déjà dans le coût mensuel de chaque calcul ; le choix minimise le coût de classement total, les montants affichés restent ce que l'on paie.

1. Par trajet : calcul de base et calcul « sans nouvel abonnement » (comme pour un trajet seul), puis un calcul par abonnement candidat offert (les calculs que /trip-plan fait puis jette s'il perd).
2. Candidats : abonnements des opérateurs croisés, avec les deux bornes de la section 8 évaluées sur la somme des trajets (borne sûre : forfait ≥ meilleur total connu ; borne heuristique : gains estimés sommés < forfait), au plus 6, plus ceux que les trajets utilisent déjà seuls (jamais écartés).
3. Choix du sous-ensemble : modèle « un abonnement par trajet » sur les 2⁶ sous-ensembles (simple arithmétique sur les calculs précédents), puis calcul exact des 3 meilleurs sous-ensembles à plusieurs abonnements (tous offerts en même temps : ils se combinent au sein d'un trajet) et de l'union de ceux utilisés seuls. Le forfait n'est compté que pour les abonnements réellement utilisés.
4. Garantie : le résultat mutualisé n'est jamais plus cher (en coût de classement) que la somme des trajets calculés seuls.
5. Sorties : pour chaque trajet, le résultat final (avec les abonnements retenus offerts ; son subscriptions_required garde le vrai forfait, comme un calcul seul, à dédoublonner par identifiant) ; pooled_subscriptions (forfaits comptés une fois) ; totaux mutualisés et « trajets seuls » pour mesurer l'apport. Une erreur sur un trajet (adresse introuvable...) ne fait pas échouer les autres (results[i] vide, errors[i] renseigné).
6. Autres modes : « le plus rapide » et « sans abonnement » n'ont aucun abonnement à mutualiser : chaque trajet est calculé seul.

Vitesse (serveur OVH, aller-retour de ≈ 500 km par sens) : 2 trajets 4,5 s, 5 trajets 7,5 s (24 à 65 calculs en parallèle) ; c'est ce que l'interface mettait déjà en calculant les trajets l'un après l'autre. Cinq utilisateurs lançant en même temps 2 trajets : 9,7 à 11,5 s au pire.

9. Aller-retour et voyages à plusieurs trajets

• Retour = aller inversé (sans étape, même réglage péage) : le retour reprend l'itinéraire retenu de l'aller parcouru à l'envers, au lieu d'en redemander un au moteur, qui pouvait proposer un tout autre corridor. Conséquence : choisir une alternative pour l'aller change aussi le retour, et les durées aller et retour sont identiques.
• Recherche fusionnée : quand les trajets s'enchaînent réellement (pas de batterie ni d'heure imposées, même réglage péage, arrivée de l'un à moins de 2 km du départ du suivant), ils sont calculés en une seule recherche. L'optimum global peut alors être meilleur qu'une addition de trajets optimisés séparément (recharger un peu plus à l'aller sur une borne moins chère pour éviter un arrêt cher au retour). Jamais pire qu'un calcul séparé, qui sert de repli.
• Batterie à l'arrivée d'un trajet non terminal : au moins le plus grand entre le seuil demandé et la batterie nécessaire pour rejoindre la borne la plus proche du trajet suivant, + 0,05 point de marge d'arrondi (20 % si le trajet suivant n'a aucune borne candidate). Calculée sur l'itinéraire et les bornes réellement retenus pour le trajet suivant (donc l'aller inversé pour un retour), jamais sur un itinéraire recalculé à part : l'écart entre les deux rendait des retours faussement impossibles (26/09, Rennes ⇄ Roannes-Saint-Mary avec heure de retour : 13,55 % estimés, 13,69 % nécessaires). On ne suppose pas de recharge entre deux trajets, sauf si l'utilisateur impose une batterie de départ.
• Fréquence (« N fois par mois ») : un trajet à fréquence > 1 (comme un aller-retour ou une étape) passe par le moteur multi-trajets. Le plan de recharge est calculé une fois pour un passage ; distances, énergie, temps, péages et recharges sont ensuite multipliés par N, alors que le frais mensuel d'un abonnement n'est compté qu'une seule fois : c'est ce qui rend un abonnement rentable à haute fréquence. La fréquence ne change donc pas la recherche des bornes, seulement quels abonnements valent le coup (plus de candidats testés). Ce moteur fait plus d'étapes qu'un trajet simple (comparaisons « sans abonnement », abonnement manqué, variantes) ; elles ont été accélérées (voir section 12), sur Rennes → Lille, le surcoût par rapport à un trajet simple est passé d'environ +2,4 s à +0,3 s (fréquence 1) ou +1 s (fréquence 4, plus d'abonnements à tester).
• Mémoire de calcul : les recherches identiques d'un même voyage (comparaisons « sans abonnement », abonnement manqué…) sont mémorisées le temps de la requête.

10. Itinéraires alternatifs

• L'itinéraire proposé par défaut est toujours le plus rapide (durée minimale) : Kargit ne choisit pas de lui-même un tracé alternatif plus long pour faire baisser le coût, car cela exigerait de calculer le coût de chaque alternative (une recherche complète par tracé, voir section 12). Le plan de recharge est optimisé sur cet itinéraire.
• Exception : tracé sans borne connue (29/09/2026, graphe Europe). À l'étranger, seules les bornes au prix sûr sont en base : le tracé le plus rapide peut traverser une zone vide (Lille → Strasbourg par la Wallonie : aucune borne sur 240 km). Trajet simple (/api/plan) : si aucun plan n'est possible sur le tracé le plus rapide, les autres tracés du routeur sont essayés dans l'ordre et le premier faisable est retenu (coût : une recherche par tracé essayé, seulement quand la réponse serait sinon « impossible »). Aller-retour et étapes (/api/trip-plan) : si le tracé le plus rapide a plus de 150 km sans borne candidate (MAX_STATION_GAP_KM), le premier autre tracé sans un tel trou est pris (jamais en France, où les bornes sont bien plus rapprochées). Pas de changement quand l'utilisateur a choisi lui-même un tracé.
• Les alternatives affichées sur la carte ne portent que la distance, la durée et le tracé, fournis par le routeur. Chacune porte une bulle permanente « + XX min / XXX km » : l'écart de durée de conduite par rapport à l'itinéraire retenu (signe − si elle est plus rapide) et la distance totale de l'alternative. Il n'y a plus d'infobulle au survol, et aucun coût n'est calculé (il ne correspondait à aucun résultat réel et coûtait une recherche complète par alternative).
• Cliquer une alternative relance le calcul complet sur ce tracé : le coût, les arrêts et les péages affichés ensuite sont ceux de cet itinéraire.
• Alternatives générées : le trajet principal plus des variantes forcées par le milieu des couloirs OSRM (avec péage seulement), plus l'itinéraire GraphHopper ; deux tracés à moins de 2 % d'écart de distance sont considérés identiques.
• Gain mesuré : sur Rennes ⇄ Aurillac (4 itinéraires), 11,5 s → 7,4 s à résultat identique.

11. Péages

• Tarifs : classe 1 (véhicule léger), TTC, grilles officielles 2026 par concessionnaire (APRR/AREA, Sanef/SAPN, ASF, Cofiroute, Escota, A'Liénor, ATMB, SFTRF, ALIS, ARCOUR…), Arrêté du 28 janvier 2026 et sites des concessionnaires. Table toll_tariffs : prix pour une paire de gares.
• Gares croisées : celles dont la position est à moins de 300 m du tracé. Des noms d'une même gare physique sont fusionnés (à moins de 500 m).
• Système fermé : depuis chaque gare d'entrée, on cherche le tarif direct vers la gare la plus lointaine couverte par le barème : un seul montant par usage continu d'un réseau, quels que soient les échangeurs traversés.
• Barrières à prix fixe (entrée = sortie) : facturées une fois, sauf si elles sont comprises dans un tronçon exact. Exemples : viaduc de Millau (11,30 € hors été, 13,80 € du 15 juin au 15 septembre selon la date), A63 Atlandes 4,40 €, A150 Albea 4,20 €, ponts de Normandie 6,10 € et de Tancarville 2,90 €. A355 : tarif maximal de la grille modulée par horaire (5,40 €).
• Deux lectures du même tracé : le regroupement « gare la plus lointaine » est appliqué dans le sens de la route et dans le sens inverse ; on garde la lecture qui a le moins de tronçons estimés (à égalité, la plus chère, car une gare manquée ne fait que sous-compter). Une même route coûte donc exactement le même prix à l'aller et au retour (avant : jusqu'à ≈ 2 € d'écart, ex. Paris ↔ Lille 13,56 / 15,68 €). Deux routes différentes entre les mêmes villes (le routeur ne choisit pas toujours le même chemin dans les deux sens) peuvent en revanche donner deux prix.
• Tronçons estimés (« ≈ » devant le montant, sur la carte et dans les détails) : quand aucun tarif exact n'existe entre deux gares consécutives, estimation au tarif moyen au km des tronçons connus du même trajet (repli : moyenne de toute la base). Un péage à prix fixe situé strictement à l'intérieur d'un trou estimé est déduit de l'estimation (il en fait déjà partie). Plafond de longueur : un trou de plus de 58 km n'est jamais estimé (portion d'autoroute gratuite, traversée gratuite de Lyon…), sauf entre deux gares du même exploitant (plafond 130 km). Avant ce plafond, l'A20 gratuite entre Vierzon et Brive était comptée 34 € pour 291 km sur Paris → Toulouse (73 € affichés pour environ 37 € réels). Kilomètres payants : le routeur renvoie aussi, pour chaque itinéraire, quelles portions sont à péage d'après OpenStreetMap (ORS : extra_info « tollways », grâce au stockage Tollways ajouté à ors-config.yml ; GraphHopper : détail « toll »). Le graphe ORS a été reconstruit le 20 septembre 2026 (environ 40 min ; une première tentative le 19 avait été interrompue par la mise en veille du PC : la reconstruction doit se faire PC éveillé). L'ancien graphe est conservé dans J:\kargit-ors-data\graphs\car.bak-20260920 (retour arrière : le remettre sous le nom car et restaurer ors-config.yml.bak-20260919). Un trou estimé n'est facturé que sur ses kilomètres payants : l'A47 gratuite entre Saint-Étienne et Givors était comptée ≈ 8,5 € sur Rennes → Nice (131,99 € → 124,10 € ; Mappy annonce 115 €). Sans profil (routeur ne le fournissant pas), la distance entière est estimée comme avant. Aucun coût de calcul mesurable (ORS ≈ 70 ms avec ou sans) ; l'évitement des péages fonctionne toujours (0 km payant sur l'itinéraire « sans péage »).
• Barrières « système ouvert » (lignes « gare → SYSTÈME OUVERT » du barème APRR/AREA) : converties en péages à prix fixe. Exemple A77 (Dordives 6,00 + Le Tourneau 3,80 + Myennes 4,20 = 14,00 €). Les deux plates-formes d'une même barrière (Dordives Ouest / Est) ne sont comptées qu'une fois.
• Tarif gare-à-gare vérifié contre le tronçon parcouru (29/09/2026, retour d'un utilisateur) : un trajet peut passer près de deux gares d'un même réseau en quittant l'autoroute entre les deux. Une paire n'est retenue (au-delà de 10 km) que si la distance de son tarif reste dans [distance parcourue × 0,7 − 20 km ; × 1,3 + 30 km] (la « distance tarifaire » d'une paire de barrières dépasse souvent la distance réelle : Crolles → Chignin 51 km pour 31 km) et si au moins la moitié du tronçon est payante d'après le routeur ; sinon on essaie une sortie plus proche. Nancy ↔ Paris par la N4 : Coutevroult → Sommesous (17,70 €) n'est plus compté, le trajet quittant l'A4 à la sortie 16. Kembs ↔ Limoges : Saint-Maurice → Montluçon (tarif prévu pour 704 km, 83,10 €, sur 383 km parcourus) remplacé par Saint-Maurice → Chalon Sud 20,70 € + Deux-Chaises → Montluçon 3,30 €. Contrôle : 174 trajets de l'audit (87 paires de villes, deux sens) identiques avec et sans ce contrôle. Aucun effet sur la durée de recherche (calcul fait une fois, hors choix des bornes).
• Barrière de sortie qui paie la suite d’avance (30/09/2026, retour d’un utilisateur : Ivry → Bort-les-Orgues par l’A6 et l’A77, 29,47 € affichés pour 22,80 € réels) : le tarif Fleury-en-Bière → Val-de-Loing barrière (10 €) a une distance tarifaire de 120 km pour 35 km de trajet, car il paie aussi l’A77 qui suit. Il n’est plus écarté par le contrôle de distance (_pair_plausible : distance trop longue tolérée si l’une des gares est une « BARRIÈRE ») ; la portion ainsi payée d’avance (du côté de la barrière, jusqu’à la distance tarifaire moins 5 km) ne se paie pas une seconde fois : ni les barrières fixes qui s’y trouvent (Dordives à 300 m de la sortie, Le Tourneau sur l’A77), ni une estimation (l’A77 près de Gondreville). Myennes, au-delà, reste due. Sur les 20 trajets de test, seul Annecy → Grenoble change : 13,02 € estimés → 12,30 € exacts (Annecy Centre → Chambéry Nord 5,60 € + Chignin barrière → Crolles barrière 6,70 €).
• Péage payé dans un seul sens (29/09/2026, pont de l’île de Ré, payé seulement vers l’île, aller-retour compris) : colonne toll_gares.cap_payant (degrés, 0 = nord ; NULL = les deux sens). La gare n’est retenue que si le trajet la traverse à ±90° de ce cap (tolls._heading_matches, direction du tracé entre 200 m avant et après la gare).
• Péage obligatoire (29/09/2026, demandé par Jérémy : La Rochelle → Saint-Martin-de-Ré, seul accès par le pont à péage) : quand « sans péage » ne trouve aucun itinéraire (ORS « Route could not be found »), le serveur reprend l’itinéraire normal, compte le péage et le signale (toll_mandatory, affiché « péage obl. ») au lieu d’une erreur 400 (routing._mandatory_toll_routes).
• Exclusion d’une borne ou d’un tronçon de péage par l’utilisateur (29/09/2026, maquette pack_exclusion) : menu « ⋯ » sur chaque ligne de borne et de péage du détail, confirmation, puis recalcul du seul trajet concerné. Borne exclue : excluded_station_ids (déjà existant). Tronçon exclu : excluded_toll_zones (/api/plan, /api/trip-plan, chaque trajet de /api/multi-plan) = 4 points pris par le site sur le tracé réel du tronçon (à 20, 40, 60 et 80 % entre ses gares, 1 point pour une barrière) ; le routeur (ORS) évite un petit carré de 300 m autour de chacun (geo.points_avoid_polygon, au plus 24 carrés), donc l’autoroute à ces endroits sans couper les routes voisines, contrairement à l’ancien couloir en ligne droite entre les gares. Dans ce cas ORS quitte son mode précalculé : 2 à 3 s par itinéraire en prod (13 à 21 s sur le PC le 29/09 : Rennes → Paris, Paris → Lyon), GraphHopper n’est pas interrogé (il ne sait pas éviter une zone ; essayé avec des zones interdites : aussi lent et contournement incorrect). Depuis le 29/09 au soir, les itinéraires habituels (précalculés, instantanés) sont essayés d’abord : si l’un d’eux ne traverse aucune zone, il est retenu sans calcul lent (routing._routes_avoiding) ; sinon ORS calcule avec un délai porté de 30 à 120 s (avant : Rennes → Nice et Lille → Marseille finissaient en erreur 400 « timed out » sur le PC). Mesures du calcul lent avec 4 zones au milieu du trajet : prod 24,6 s Rennes → Nice, 18,1 s Lille → Marseille ; PC 30 s et plus. Avec de simples carrés, GraphHopper les contournait de justesse (+1,2 km sur Paris → Lyon, en restant sur le tronçon). Depuis le 29/09 au soir (accord de Jérémy), étape intermédiaire GraphHopper (routing._gh_route_excluding) : sur le tracé habituel qui passe par le tronçon, un couloir de 250 m de part et d’autre (un rectangle par km) va d’un bout à l’autre du tronçon ; la requête « car » y interdit les routes à péage et les autoroutes (in_excl && (toll == ALL || road_class == MOTORWAY), priorité 0), les routes locales qui le traversent restent permises. Préparation « landmarks » ajoutée au profil car (profiles_lm de gh-config.yml, 22 min sur le PC pour la France ; étape activée seulement si GRAPHHOPPER_LM_EXCLUSION=true ; en prod depuis le 30/09/2026 : landmarks du graphe Europe préparés en 31 min sur une copie puis bascule, GraphHopper à 22 Go de mémoire ; exclusion mesurée en prod 1,5 s Paris → Lyon, 2,9 s Lille → Marseille, contre 18 à 25 s avec ORS sur les longs trajets) pour que cette requête sans raccourcis CH reste rapide ; les recherches habituelles restent en CH, inchangées. ORS n’est plus qu’un dernier recours (GraphHopper absent ou sans résultat, ou mode sans péage). Un seul calcul lent par trajet (le retour reprend l’aller à l’envers) ; depuis le 29/09 ces itinéraires sont gardés en mémoire (200 au plus, routing._avoid_cache) et deux requêtes identiques simultanées n’en lancent qu’un (les modes « le moins cher » et « le plus rapide » du même recalcul, un changement de mode ensuite). Exemple : Paris → Lyon sans le tronçon Fleury-en-Bière → Villefranche-Limas passe par l’A77 et l’A79 (499 km au lieu de 461, péage 28,67 € au lieu de 41,30 €). Exclusions propres au trajet, gardées dans l’adresse de la page et dans les favoris, oubliées après « Modifier mes trajets ou options » + nouveau calcul. Au passage, les gares d’un tronçon exact sont affichées dans le sens du trajet (la grille étant symétrique, Paris → Lyon affichait « Villefranche-Limas → Fleury-en-Bière »).
• Noms des gares APRR réparés (29/09/2026) : le fichier source (data.gouv.fr, « Tarifs autoroutes APRR ») coupe « entrée sortie » au premier espace (« SAINT » → « MAURICE CHALON SUD » au lieu de « SAINT MAURICE » → « CHALON SUD ») : 9 098 paires sur 21 505 n'étaient jamais reconnues. Noms reconstruits sans ambiguïté (un vrai nom de sortie apparaît avec au moins 3 entrées), puis 36 noms APRR/AREA rattachés à leur gare (même nom normalisé, ou nœud OpenStreetMap formant un seul échangeur). Script : scripts/fix_aprr_gare_names.py (simulation par défaut, --vraiment ; --gares --vraiment pour les gares). Restent sans gare : Amboise, Châlons La Veuve / Mourmelon, Fontenay-sur-Loing, Gidy, Gondreville A77, « La Folie-B/Paris », Reims Sud, Savigny, Saint-Germain-les-Vergne, Saint-Martin-Bellevue, Saint-Michel-de-Maurienne, Isle-d'Abeau Centre, Tours-Monnaie. A79 (ALIAE, Montmarault → Digoin, flux libre) importée le 29/09/2026 : la grille officielle (data/tolls/ALIAE-A79-Tarifs-2026.pdf, page 3, tableaux en image relevés à la main) donne les prix classe 1 entre ses 9 points (extrémités, échangeurs du Montet, de Montbeugny et de Molinet, bords des deux sections gratuites), modélisés comme un système fermé : 9 gares aux positions OpenStreetMap des portiques et échangeurs, 21 paires. Traversée complète 4,20 € (= portiques « Transit » 1,00 + 1,90 + 1,30 de la page 2). Tarif de base ; le tarif réduit des véhicules très faible émission (Crit'air 0, 3,20 € la traversée) n'est pas appliqué, comme ailleurs. Script : scripts/import_toll_a79.py. Jonction entre réseaux : un trou de moins de 5 km entre gares d'exploitants différents sans paire commune (fin de l'A79 à 2 km de la barrière APRR de Deux-Chaises) n'est pas estimé. Kembs → Limoges : 86,20 € avant ces corrections, 31,30 € en tarifs exacts (Fontaine-Larivière 3,10 + Saint-Maurice → Chalon Sud 20,70 + A79 4,20 + Deux-Chaises → Montluçon 3,30).
• Sans péage : si l'évitement est appliqué, aucun calcul de péage n'est fait (0 €).
• Regroupement par groupe exploitant : les tronçons consécutifs du même groupe (écart de moins de 3 km) sont fusionnés en un seul pour l'affichage, de la première gare d'entrée à la dernière gare de sortie, prix additionnés ; le tronçon fusionné garde en plus la part estimée de son montant (estimated_price_eur) et n'affiche « ≈ » que si cette part atteint 10 % du montant (Lyon → Marseille : 0,42 € estimés sur 28,52 € s'affiche donc comme un tarif exact). Groupes : Vinci Autoroutes (ASF, Cofiroute, Escota, Arcour, Atlandes, Arcos, Albea — leurs grilles se recouvrent et l'import étiquette « ASF » des gares Cofiroute), APRR / AREA, Sanef / SAPN, les autres à part. Un tronçon estimé prend le groupe de sa gare de sortie (ou d'entrée) si elle a des tarifs, sinon celui du tronçon suivant. Exemple Rennes → Nice : 23 petits tronçons avant, 3 après (Vinci, APRR, Vinci), pour le même total (132,03 €) ; Paris → Marseille : 2 tronçons.
• Somme des tronçons : le total affiché est toujours la somme des tronçons visibles sur la carte.

12. Techniques pour accélérer le calcul, et leur impact

Le temps d'attente annoncé à l'écran est une estimation calibrée sur la durée des calculs précédents et sur la complexité du voyage (un aller-retour ou une étape allonge le calcul), pas une prédiction exacte.

12 bis. Limites de débit et protection contre l'aspiration

Module app/ratelimit.py. Tout est en mémoire (un seul processus en production : compteurs partagés par construction, remis à zéro à chaque redémarrage ou mise en service). Coût par requête ≈ 20 µs, aucun effet mesurable sur la vitesse (serveur : aller simple 0,5 s, aller-retour 1,5 s, 5 allers-retours simultanés 3,7 s avant comme après). Un refus renvoie 429 (limite de débit) ou 503 (plafond de calculs simultanés) avec le corps {"detail", "retry_after"} et l'en-tête Retry-After (secondes).

• Adresse réelle du visiteur : X-Forwarded-For n'est cru que si la connexion directe vient d'un proxy de confiance (Caddy, réseau Docker) ; Caddy y met l'adresse du visiteur, on lit la dernière entrée. Un client qui l'envoie lui-même ne peut pas se faire passer pour une autre adresse. Les adresses de RATELIMIT_EXEMPT_CIDRS (boucle locale par défaut : tests de charge, sondes) ne sont jamais limitées ; en développement, y ajouter le réseau Docker.
• Calculs (/plan, /trip-plan, /multi-plan) : budget en jetons pondérés par le coût réel (1 par /plan, le nombre de trajets pour /trip-plan, la somme pour /multi-plan ; un aller-retour en 4 variantes = 8 jetons). Visiteur anonyme : 60 jetons/min et 600/h par adresse ; connecté : 180/min et 1 800/h par compte ; au plus 300/min par adresse dans tous les cas (plusieurs comptes depuis une même connexion).
• Plafond de calculs simultanés : 8 calculs en même temps (MAX_CONCURRENT_CALCULATIONS) ; au-delà, attente de 10 s au plus, puis 503. Sous charge normale (5 allers-retours simultanés) il n'intervient jamais.
• Carte des tarifs et onglet Bornes : 300 requêtes/min par adresse (chaque déplacement de carte coûte environ 2 appels : bornes + dispo en direct) ; géocodage 60/min ; jamais plus de 500 bornes par réponse. Détection d'aspiration : au-delà de 300 zones (cellules de 0,5°) différentes lues en 10 minutes — un humain en voit bien moins — l'adresse est bloquée 24 h (429). L'endpoint qui renvoyait toutes les variantes de tarif d'une borne (/tariffs-map/station/{id}/tariffs, inutilisé par le site) est réservé à l'administrateur.
• Comptes : inscription 3 par 10 min et 10 par heure par adresse (3/h auparavant : une panne d’inscription le 25/09/2026 bloquait jusqu’à 1 h après trois essais) ; mot de passe oublié 3/h par adresse et 1 e-mail/10 min par adresse mail (réponse toujours identique, le compte existe ou non) ; connexion : 10 échecs en 15 minutes pour (adresse + e-mail), puis blocage de 30 s doublé à chaque échec supplémentaire (1 h au plus), et 60 tentatives/15 min par adresse tous e-mails confondus.
• Taille des requêtes (au moins égale aux limites de saisie du site) : adresses 250 caractères, 8 étapes par trajet, 12 trajets, 200 entrées par liste d'exclusions/possessions, 8 trajets pour /multi-plan, pseudo 40, prénom 60, e-mail 254, mot de passe 128, nom d'un favori 120, nom du formulaire de contact 120, message 5 000 ; la configuration d'un favori et celle enregistrée dans le journal des recherches sont bornées à 20 000 caractères.
• Erreurs 500 : message générique pour le public (« Erreur interne. Réessayez dans quelques instants. »), le détail reste dans les journaux du serveur.

12 ter. Statistiques de visites (sans cookie)

Mesure d'audience sans cookie ni identifiant conservé (donc sans bandeau de consentement : conditions d'exemption de la CNIL). Code : app/stats.py (collecte, catégories, purge) et app/api/stats.py (POST /api/collect public, GET /api/admin/stats réservé à l'administrateur). Le script du site envoie un signe par changement de vue (Trajets / Bornes), un signe de vie toutes les 15 à 30 s et quelques événements (calcul lancé, résultats affichés, clic « S'abonner », favori enregistré, inscription, borne ouverte, lien partagé) ; il ne stocke rien sur l'appareil. L'appli Android envoie les mêmes signes (AppStats.kt) : le serveur la reconnaît à son identifiant « KargitApp-Android/… » et range ses visites à part (colonne platform = app, navigateur « Appli Android ») ; le bouton Site / Appli filtre toute la page (sauf inscriptions, favoris et trajets les plus calculés, dont l'origine n'est pas connue). L'opposition faite depuis les mentions légales ouvertes dans l'appli y arrête aussi la mesure.

• Jamais stocké : adresse IP, user-agent, adresse saisie, propriété d'événement libre (seuls le nom de l'événement — 40 caractères de a-z 0-9 _ — et des compteurs sont gardés). Par visite : appareil (mobile / tablette / ordinateur), navigateur, système, langue, domaine du referrer (jamais le chemin), vue d'entrée et vues consultées, pages vues, temps actif cumulé (au plus 30 s par signe de vie), compteurs d'événements.
• Visiteur = sha256(sel du jour + IP + user-agent), tronqué à 20 caractères. Le sel est aléatoire, gardé en base (stats_salts) et supprimé après 48 h : deux jours ne peuvent plus être reliés, même avec la base. Le « visiteur » des totaux est donc la somme des visiteurs uniques par jour. Visite = même visiteur, coupée après 30 min sans signe.
• Requêtes ignorées (réponse 204 identique, rien n'est révélé) : en-tête DNT: 1 ou Sec-GPC: 1 ; robots connus (user-agent) ou absence d'Accept-Language ; corps de plus de 1 Ko ou illisible ; plus de 120 signes/min pour une même adresse (limite propre, hors budget des calculs). L'opposition explicite passe par l'indicateur local kargit_no_stats=1 lu par le script du site.
• Conservation : visites (stats_sessions) 13 mois ; à la purge quotidienne (retention.py), les jours plus vieux sont cumulés dans stats_daily (chiffres par jour et répartitions, sans limite de durée) puis supprimés. Au-delà de 13 mois, la médiane de durée est approchée d'après les tranches de durée et il n'y a plus de détail par visite.
• Page admin : visiteurs (uniques par jour, cumulés), visites, pages vues, durée moyenne et médiane, pages par visite, taux de rebond (visite d'une seule page et moins de 10 s d'activité), calculs, résultats affichés, clics « S'abonner », inscriptions (table des comptes) et favoris, avec la période précédente de même longueur ; série par jour, semaine ou mois ; répartitions (appareil, navigateur, système, referrer, vue, langue, entrée, durée) ; entonnoir visite → calcul → résultats → clic ; carte de chaleur jour × heure (fuseau Europe/Paris) ; trajets les plus calculés en villes seulement (jamais d'adresse), et seulement ceux vus au moins 3 fois ; temps réel (dernier signe de moins de 5 min / 30 min). Fenêtre de 24 mois au plus ; requêtes SQL groupées, sans effet sur les calculs.
• Vitesse : un signe = une petite écriture en base (médiane ≈ 30 ms de bout en bout, mesurée pendant que 5 allers-retours étaient calculés) ; aucun traitement lourd en ligne, agrégats faits à la lecture de la page admin.
• Clics « S'abonner » par abonnement (onglet Abonnements) : en plus de l'événement ci-dessus, chaque clic envoie l'identifiant de l'abonnement à POST /api/subscribe-click, qui incrémente un simple compteur par jour et par abonnement (subscribe_clicks) — aucune donnée sur la personne (ni IP, ni empreinte, ni visite). Mêmes filtres que la collecte (DNT / GPC, robots, opposition locale, corps de plus de 1 Ko) et au plus 20 clics/min comptés par adresse ; un identifiant inconnu est ignoré. La liste de l'onglet affiche, pour chaque abonnement, deux colonnes : le total et les 7 derniers jours (aujourd'hui compris, fuseau Europe/Paris) via GET /api/admin/subscribe-clicks. Compteurs démarrés le jour de la mise en ligne (pas de reprise des clics passés, qui n'étaient pas rattachés à un abonnement).

12 quater. Géocodage des adresses (LocationIQ ou serveur local)

Le géocodage transforme l'adresse tapée en coordonnées, une fois par adresse (résultat gardé en mémoire puis dans la table geocode_cache, donc une adresse déjà vue ne rappelle aucun service). Code : app/routing.py (geocode, geocoder_primary, _geocode_local).

• Deux services au choix, réglables sans redéploiement : Admin › Réglages du calcul › « Géocodage des adresses ». LocationIQ (service externe, quota gratuit puis payant) ou Local = Photon auto-hébergé sur le serveur (données OpenStreetMap France + pays voisins depuis le 29/09/2026, conteneur kargit_photon ; garde-fou (29/09/2026) : si l'adresse finit par un pays étranger (« Genève, Suisse », « Salou, Tarragonais, Espagne ») et que Photon répond dans un autre pays, on passe au géocodeur suivant, LocationIQ, qui couvre le monde (routing._requested_foreign_country ; avec l'index France seule, « München, Bayern, Deutschland » tombait dans le Pas-de-Calais) ; à l'inverse, sans pays nommé, si la première réponse est étrangère et qu'une ville française du même nom figure parmi les 5 premières, elle l'emporte (« Valence » → Drôme et non Valencia ; un simple village homonyme ne suffit pas : « Cologne » reste Köln, « Mons » la ville belge), gratuit, sans quota). Le choix est enregistré en base (app_settings, clé geocoder) et pris en compte en moins de 30 s par tous les processus (relecture périodique) : repasser d'un service à l'autre = un clic.
• Chaîne de repli : service choisi → l'autre service → ORS (si clé) → Nominatim public. On passe au suivant si le service est en panne, injoignable, hors quota ou, pour le service local, s'il ne trouve rien (LocationIQ dira alors « introuvable » ou trouvera). Le géocodeur local n'est jamais bloquant : délai maximal 3 s.
• Défaut sécurisé : tant que l'admin n'a rien choisi, le principal reste LocationIQ (GEOCODER_DEFAULT_PRIMARY). L'admin refuse de choisir « Local » si Photon ne répond pas (/status) ou si GEOCODER_LOCAL_URL est absent.
• Installation / mise à jour de Photon : deploy/server/photon-install.sh (téléchargement du dump OpenStreetMap publié par GraphHopper, vérification md5, import France + les 10 pays voisins (COUNTRY_CODES, noms en français, anglais, allemand, italien, espagnol et néerlandais ; France seule jusqu'au 29/09/2026 : « Bruxelles », « Munich », « Londres » donnaient un hameau français homonyme) avec un nouvel index construit à côté, puis vidage du cache des adresses (table geocode_cache et mémoire du backend, redémarré), qui gardait les réponses de l'ancien index, puis bascule sans coupure). Le service se déclare dans docker-compose.prod.yml (profil geocoding, ajouté à COMPOSE_PROFILES dans /opt/kargit/.env). Automatique tous les 3 mois (cron posé par deploy/release.sh, 1er janvier/avril/juillet/octobre à 1h15) ; visible avec sa date, sa durée et le nombre de lieux dans l'onglet « Tâches planifiées » de l'admin (état écrit par le script, jamais déclenché par le backend -- même principe que les sauvegardes). Priorité volontairement basse (site en production sur le même serveur) : téléchargement bridé en débit, décompactage et import à priorité CPU/disque minimale -- s'effacent automatiquement dès qu'une recherche a besoin de la machine, la tâche prend juste plus longtemps (1h30 à 2h30 environ) plutôt que de ralentir un visiteur.
• Compromis : Photon et LocationIQ s'appuient tous deux sur OpenStreetMap, mais LocationIQ ajoute des sources complémentaires et une tolérance aux fautes de frappe parfois meilleure. Comparaison faite le 21/09/2026 sur 63 requêtes françaises (villes, adresses, lieux, fautes de frappe, codes postaux ; scripts/compare_geocoders.py) : 42 résultats identiques au mètre près, la plupart des autres à moins de 1 km ; Photon répond en 16 ms en médiane contre 200 ms pour LocationIQ (jusqu'à 1,2 s pour ce dernier). Photon est meilleur sur les fautes de frappe (« Marseile », « Bordeau », « Strasbourgh » trouvés, LocationIQ se trompe ou échoue), les codes postaux seuls (« 35000 » → Rennes ; LocationIQ répondait en Algérie) et « Gare de Rennes » (10 km d'écart, Photon est sur la gare). Points faibles de Photon : une adresse dont le numéro n'existe pas dans OpenStreetMap tombe sur la rue ou sur un commerce voisin (1 à 5 km d'écart sur les gros numéros de rues très longues : « 20 rue Nationale, Lille », « lyon 3eme » → une agence). Index France : 19,5 millions de lieux, 5,8 Go sur disque, environ 4 Go de mémoire pour le service.
• Suivi : la page admin affiche l'état du service local et le nombre de réponses de chaque service depuis le démarrage du serveur (y compris les replis). Le script scripts/compare_geocoders.py compare les deux services sur une soixantaine d'adresses.
• Suggestions pendant la frappe (site) : jusqu'ici, le navigateur interrogeait directement la Géoplateforme, Photon public et Nominatim à chaque frappe (l'IP du visiteur leur était envoyée). Un proxy backend est prêt (GET /api/suggest, GET /api/suggest/reverse -- app/api/suggest.py) : Géoplateforme + notre géocodeur local en parallèle pour la France (même charge sur ces deux services qu'avant, juste depuis notre IP) ; Photon PUBLIC (reste de l'Europe) en plus, en parallèle, mais en meilleur effort non bloquant (sauté sans attendre si sollicité il y a moins de 300 ms) pour ne jamais multiplier par le nombre de visiteurs le trafic vu par ce service public gratuit depuis une seule IP serveur ; Nominatim en tout dernier recours. Limite dédiée (SUGGEST_RULES, app/ratelimit.py) : 12 requêtes/10 s puis 60/min par IP. Pas encore branché côté site (le sélecteur de suggestions appelle encore les services tiers directement) -- CSP (connect-src) à resserrer une fois que ce sera fait.

12 quinquies. Sites étrangers et langues (pas encore en production)

Kargit en anglais, allemand, espagnol, italien et néerlandais (kargit-ev.com, kargit.uk, kargit.de, kargit.es, kargit.it, kargit.nl, kargit.be/fr|nl, kargit.ch/de|fr|it) -- détails dans docs/LOCALISATION.md. Le calcul est le même partout : seul l'affichage change.

• Monnaie et unités : affichage seulement. Tous les calculs (coûts, classement, abonnements, péages) restent en euros et en kilomètres. Sur kargit.uk les montants sont convertis en livres et les distances en miles (km/h → mph, kWh/100 km → mi/kWh) ; sur kargit.ch en francs suisses. Taux : BCE du jour (GET /api/fx, app/api/fx.py, gardé 6 h, taux de secours si la BCE ne répond pas). Un montant converti est donc arrondi à l'affichage ; il n'influence jamais le choix des bornes.
• Tarifs : ceux des bornes situées en France uniquement, comme sur kargit.fr.
• Langue des comptes : retenue à l'inscription (site de départ) pour les mails et la newsletter ; aucun effet sur le calcul.
• Coût en vitesse : aucun sur le calcul. Côté navigateur, la traduction de l'affichage (assets/i18n.js) ne tourne que sur les sites étrangers ; kargit.fr ne fait rien de plus.

13. Limites connues et hypothèses à garder en tête

• Durée = conduite (routeur, sans trafic) + charge + 4 min par arrêt + détours. Ni attente aux bornes, ni pauses repas.
• Bornes toujours libres, à leur puissance nominale ; la puissance réellement délivrée dépend de la température de la batterie, du partage de puissance entre prises, etc.
• Prix valables à la date du jour (les tarifs à horaires sont appliqués à l'heure d'arrivée estimée si l'heure de départ est connue). Certains prix sont des estimations signalées « exemple ».
• Consommation : facteurs météo et vitesse simplifiés, pas de dénivelé ni de vent réel.
• Cashback ignoré dans le total affiché (information seulement) et, sauf option « Prise en compte du cashback » cochée (50 % pour la comparaison), dans le classement ; péages classe 1 uniquement, parfois estimés ou incomplets (voir section 11).
• Précision des niveaux de batterie : pas de 5 % ; règles de confort qui peuvent coûter quelques centimes par rapport à un plan sans contrainte.
• Deux calculs identiques donnent le même résultat ; un résultat qui change traduit un changement de paramètre ou de données (tarifs, bornes, péages), pas de l'aléatoire.