Vue d'ensemble : entrées, protection contre la surcharge, cycle de répartition en six
étapes, optimiseur en option, adaptateurs, charges. Rangs et domaines : une seule liste
pour le moteur ; les domaines ne servent qu'à l'affichage de l'app, un chauffe-eau peut
être servi en dernier. Encadré : une borne détectée arrive en fin de liste.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ry3vBrJT1tHdxAaXdCWi6L
Navigation : « EMS — moteur à règles » (pages de fonctionnalités, précédées
de « Comment le moteur décide »), « Optimiseur » (Présentation, Protocole,
Contrat, Écrire un optimiseur), « API » (ex-« Référence »). Aucun fichier
existant déplacé : les URL publiées restent valides.
Protocole : prose courte qui renvoie à OPTIMIZER_PROTOCOL.md du moteur
pour le sens ; tableaux, listes fermées et règles nommées générés depuis
le contrat. Contrat servi tel quel (copie octet pour octet).
reference.md, resté un bouchon, devient l'accueil de la section API.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Nouvelle page fonctionnalites/prevision-pv (FR/DE/EN, dans la nav) : courbe
horaire jusqu'à la fin du lendemain par plan, correction de température et
plafond onduleur (modèles déterministes publics, aucun apprentissage),
« plafond optimiste », « une heure sans donnée est un trou, jamais un zéro »,
fourchette météo (qualifie la météo seulement), météo horaire, mise en
service, règle centrale de la Community (affiché et enregistré localement,
jamais utilisé pour décider), consommation de base « à venir », données qui
sortent, optimiseur seulement comme interface prévue.
Tarifs (3 langues) : section BETA « tarif saisi », exposé et non utilisé pour
décider ; les tarifs dynamiques restent en roadmap.
FAQ (3 langues) : réponse « données » réécrite avec la liste de ce qui sort ;
« Predict AI », `optimizer-plugin` et « socket Unix » retirés ; la prévision
physique passe dans Community, Pro garde les prévisions apprises.
Accueil : « sans dépendance au cloud ». Tableau des fonctionnalités : trois
lignes. Fiche OpenMeteo : lien vers la page, plafond appliqué par le moteur.
Sources : INTERFACE.md et DESIGN_PREVISION_PV.md (feature/forecast-protocol-1.1),
CONTRACT_A v4, CONSIGNE-app-etm66-prevision.md. Aucune donnée du banc.
Vérifié comme en CI : génération, --check et mkdocs build --strict passent.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
`theme.font: {text, code}` faisait injecter par Material, dans le <head> de
chacune des 316 pages, un preconnect vers fonts.gstatic.com et une feuille
depuis fonts.googleapis.com (Sans 300/300i/400/400i/700/700i + Mono
400/400i/700/700i). Chaque visite transmettait donc l'IP du visiteur à Google
AVANT tout consentement.
Ce qui rendait ça gênant n'est pas la règle en soi, c'est l'asymétrie : le site
vitrine a fait exactement l'inverse en T10, délibérément, pour cette raison
(jurisprudence LG München 2022, doctrine CNIL) et pour ne pas contredire « vos
données ne sortent pas de chez vous ». La doc affichait donc le contraire de
l'engagement que le produit met en avant, sur le même nom de domaine.
Correctif : `theme.font: false` retire les deux balises ; les 16 woff2 viennent
du dépôt du site — mêmes fichiers, mêmes unicode-range (latin + latin-ext pour
les accents), déjà éprouvés en production depuis juin. Les 16 blocs @font-face
sont repris tels quels plutôt que réécrits, avec les chemins adaptés. Material
lit `--md-text-font` / `--md-code-font`, qu'extra.css définit.
312 Ko d'actifs, servis localement.
⚠️ LES ITALIQUES SONT DÉSORMAIS SYNTHÉTISÉES, et c'est la contrepartie à
connaître. Google servait 4 fontes italiques que nous n'avons pas (aucun fichier
italique dans le dépôt du site, aucune IBM Plex installée sur la machine de
build) : le navigateur incline donc la romaine. Visible sur les intertitres en
italique des blocs générés — `_Einstellungen:_`, `_Gemessene Größen:_`. Pour y
remédier : récupérer les woff2 italiques depuis le dépôt officiel IBM/plex (OFL)
et ajouter les @font-face correspondants. La méthode est celle déjà documentée
au T10 du site, et je ne l'ai pas prise d'office — c'est un ajout de binaires
depuis Internet.
Vérifié sur le site construit, et pas seulement sur le <head> :
· 0 url() externe dans toute la CSS
· 0 preconnect
· 0 ressource (link/script/img/iframe) chargée depuis un tiers — le seul hôte
cité est docs.etm-powersync.fr lui-même, par les <link rel="canonical">
· les 16 woff2 présents dans le build, 16 références, 0 chemin cassé
· build --strict sans avertissement
La seule mention restante de Google dans le dépôt est le commentaire d'extra.css
qui explique pourquoi elle n'y est plus.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signalé sur /de/appareils/bornes/goecharger/ : la page était allemande sur deux
lignes et anglaise sur tout le reste. Le diagnostic a séparé deux choses que
j'avais mises dans le même sac le 2026-10-12.
LA LIGNE DE PARTAGE, écrite en tête du générateur :
• les LIBELLÉS QUE NOUS ÉCRIVONS (en-têtes de colonnes, titres de section,
oui/non, « Documentation fabricant ») → TRADUITS. Ils ne désignent rien à
l'écran, l'anglais n'y était qu'une friction. REF devient REF_I18N, trois
jeux de 20 libellés.
• le CONTENU VENANT DE NYMEA (noms de modèles, clés de registres, libellés de
champs comme « MAC address », unités) → VERBATIM, en anglais. Ce sont
exactement les chaînes que l'installateur lit DANS L'APP, qui tourne en
en_US. Les traduire rendrait la doc inutilisable pour retrouver un champ à
l'écran.
Et la pièce qui change l'expérience plus que la traduction elle-même : une note
`verbatim`, générée dans la langue de la page, en tête du bloc de référence.
Sans elle le mélange FR/EN passe pour une traduction bâclée ; avec elle c'est
une convention que le lecteur comprend.
L'injection devient sensible à la langue : `locale_of()` déduit la langue du
suffixe du fichier et `process()` rend le bloc en conséquence. Sans ça le même
bloc partait à l'identique dans les trois versions.
TAGLINES ET TITRES — i18n/devices.yaml, 52 entrées
Le tagline vivait en paragraphe libre, écrit UNE SEULE FOIS à la création de la
page : il restait donc en anglais sur les trois versions, y compris la
FRANÇAISE. Il entre dans le bloc badges, donc il est régénéré, donc traduisible
pour toujours. 52 taglines en fr et de ; l'anglais retombe sur l'amont.
Les traductions vivent dans le dépôt de DOC et pas dans les meta.json : trois
des cinq dépôts plugins sont des dépôts nymea amont que l'AGENTS.md interdit de
modifier. Repli sur l'amont pour toute entrée absente.
Deux titres s'affichaient en FRANÇAIS sous /de/ et /en/ — « Compteur ABB B2x »,
« Borne ABB Terra AC » : corrigés, dans la page et dans la nav.
Deux coquilles AMONT corrigées au passage, repérées en relisant les 57 entrées :
meta.json annonçait « Bestel » pour Vestel et « Easeex » pour Easee. Signalées
comme corrections, pas comme traductions, dans i18n/devices.yaml.
48 FICHES FR ÉTAIENT DANS UN ANCIEN FORMAT, ET MENTAIENT
Trouvé en vérifiant : 48 fiches FR n'avaient pas de marqueur `__badges_*__`.
Leurs badges étaient du HTML figé, écrit une fois — goecharger affichait
« NIGHTLY » alors que PORTING_STATUS dit `stable` depuis. Elles sont migrées au
format canonique : badges générés, donc exacts, plus titre localisé, tagline et
intertitre. Reste `hvac/homeconnect.md`, orpheline (plugin hors PORTING_STATUS).
NAV : UN CONSTAT QUI ÉVITE DE REFAIRE L'ESSAI
`literate-nav` ne lit que son `nav_file` : la substitution par suffixe de
mkdocs-static-i18n ne s'y applique PAS. Un `SUMMARY.de.md` généré n'était lu par
personne et la barre latérale allemande gardait les noms français. Testé, puis
retiré — et la raison est écrite dans le générateur pour que personne n'y
revienne. Les libellés de nav passent par `nav_translations` : 31 éléments
traduits par langue au lieu de 29.
RÉFÉRENCE API : LAISSÉE EN ANGLAIS, DÉLIBÉRÉMENT
Les 23 pages de l'API n'ont pas de variante par langue. Leur traduire les
libellés aurait fait voir du FRANÇAIS aux lecteurs /de/ et /en/ par le repli —
une régression. Créer 46 variantes pour traduire dix libellés aurait triplé
28 000 mots de contenu généré pour un gain nul : le reste de la page (noms de
méthodes, de champs, de types, descriptions) est l'API elle-même, et ce sont les
chaînes qu'on écrit dans ses requêtes. À la place, une note explique dans les
trois langues POURQUOI cette référence est en anglais.
Vérifié : build --strict sans avertissement, les deux générateurs rendent « Doc à
jour » en --check, et la fiche goecharger relue dans les trois langues.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
mkdocs.yml : plugin i18n en mode `suffix` (page.md = fr, page.de.md,
page.en.md), fr par défaut, fallback_to_default, un index de recherche par
langue, et nav_translations — 29 éléments traduits par langue, vérifié au
build. i18n est placé AVANT literate-nav et search : il réécrit l'arbre des
fichiers par langue, les autres doivent voir l'arbre déjà localisé.
navigation.instant est RETIRÉ de theme.features. Ce n'est pas un arbitrage de
confort : il est incompatible avec le lien contextuel du sélecteur de langue de
mkdocs-static-i18n, et l'avertissement fait ÉCHOUER `mkdocs build --strict`.
Le sélecteur l'emporte — atterrir sur la même page dans l'autre langue vaut
plus qu'un chargement instantané qui renvoie à l'accueil. Le commentaire est à
l'endroit du retrait, pas ailleurs.
Vérifié que literate-nav et static-i18n cohabitent, plutôt que supposé : build
construit, nav de /de/ relue dans le HTML produit (« Geräte », « Kompatibilität »,
liste des appareils bien dépliée).
CI : --locales fr,de,en sur la génération ET sur le contrôle d'idempotence. Et
une étape qui manquait — gen_api_reference.py n'était pas dans le pipeline, sa
sortie ne se propageait donc qu'au prochain passage manuel.
requirements.txt : mkdocs-static-i18n >= 1.3.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
