Règles de rédaction de TOUT texte public de la Vitrine — libellés de modules, phrases éditoriales (générées ou non), infobulles, page Méthodologie, billets, textes d'interface. À charger AVANT d'écrire ou de modifier le moindre texte affiché sur le site, y compris dans une maquette destinée à devenir le site.
Vérifier le rendu responsive AVANT de pousser toute modification frontend (composant, CSS, layout, template de section). À utiliser dès qu'une PR touche `components/`, `app/**/*.css`, `app/page.tsx` ou une page statique de `public/` : dérouler la checklist des viewports (desktop cibles, frontières de breakpoints, mobile 375), tester le débordement horizontal et TOUS les états dynamiques du composant, puis remplir la case « Vérification responsive » du template de PR. Déclencheurs : « vérifie le mobile », « responsive », « breakpoint », « ça déborde », toute retouche de globals.css ou d'un composant de section.
Rédiger ou réviser la page Méthodologie PUBLIQUE (public/methodologie/index.html) au bon registre : pour le grand public, transparente et scientifique, mais SANS jargon interne (noms de raffineurs, de tables, de colonnes) ni détails qui exposeraient la propriété intellectuelle ou les droits des médias. À utiliser dès qu'on écrit, simplifie ou révise une section de la métho, ou qu'un passage est jugé « trop technique », « trop interne » ou « pas pour le public ». Complète synchro-methodologie (qui dit QUOI/QUAND mettre à jour ; celui-ci dit COMMENT l'écrire). Déclencheurs : « rédige la métho », « simplifie la métho », « c'est trop technique », « vulgarise cette section », « la métho parle aux devs ».
Garder la page Méthodologie (public/methodologie/index.html) ET les docs vivantes du pipeline (public/docs/horaire-refiners-2026.html, workflow-vitrine-2025-swimlanes.html) TOUJOURS synchronisées avec le comportement réel du pipeline. À utiliser pour toute PR (vitrine, aws-refiners, aws-infra) qui touche un calcul, un seuil, un horaire, la collecte, une représentation graphique ou un raffineur — déterminer les sections/docs impactées et proposer la mise à jour. Aussi : remplir la section « Impact méthodologie » du template de PR, et vérifier la véracité des déclarations des collègues avant tout merge.
Diagnostique pourquoi une section du site Vitrine (treemap des enjeux, partis, etc.) affiche des données périmées ou erronées, en distinguant un bug de transformation frontend d'un problème de raffineur/backend. À utiliser quand on signale des données « périmées », « pas à jour », « figées » ou « erronées » dans un module, ou qu'un onglet jour/semaine/mois semble incorrect. Déclencheurs : « données périmées », « pas à jour », « le treemap montre du vieux », « trouve pourquoi ».
Change l'horaire (cron / fréquence) d'un raffineur du pipeline radar. À utiliser quand on demande de modifier QUAND ou à quelle FRÉQUENCE un raffineur tourne (ex. « fais tourner radar-issues-score à 8h »). Le changement se fait dans le repo aws-infra, PAS dans vitrine-showcase. Déclencheurs : « change l'horaire du raffineur », « fais tourner à Xh », « fréquence de rafraîchissement », « modifie le cron », « planifie le raffineur ».
Ajoute une nouvelle section data-bound au site Vitrine (afficher une table Athena sur la page). À utiliser quand on demande d'ajouter ou d'afficher une section, un module ou un bloc alimenté par des données (scores de partis, enjeux, etc.), de brancher une nouvelle table, ou d'activer une table dormante de scripts/tables.json. Déclencheurs : « ajoute une section », « affiche la table X », « nouveau module data », « branche les données ».
Garde-fou — refuse d'ajouter un chemin de déploiement AWS (S3, CloudFront, configure-aws-credentials) au repo vitrine-showcase. À utiliser dès qu'on demande de déployer ou héberger le site sur AWS, d'ajouter un bucket S3, une distribution CloudFront, ou des credentials AWS de déploiement — souvent « pour la performance ». Déclencheurs : « déploie sur S3 », « CloudFront », « configure-aws-credentials », « héberger sur AWS », « deploy AWS ».