Politique éditoriale — Diamond Signal

URL publique : https://diamond-signal.com/editorial-policy Source de vérité versionnée : ce fichier dans le repo git. Dernière révision : 2026-05-11.

Préambule

Diamond Signal est un terminal d'analyse statistique appliquée au sport. Le service publie des projections de probabilités, des écarts de calibration et des indicateurs de forme calculés à partir de modèles statistiques ouverts. Ce n'est pas un sportsbook, ce n'est pas un service de pronostics, ce n'est pas un site de paris, et ce n'est pas non plus un service de conseil financier. Cette distinction n'est pas un détail marketing — elle structure toute la production éditoriale du projet.

Diamond Signal analyse, mesure et publie. Il appartient au lecteur — qu'il soit analyste, journaliste sportif, fantasy player, chercheur, fan exigeant ou décisionnaire — d'interpréter et d'agir comme il l'entend dans le respect des lois de sa juridiction.

La présente politique formalise ce que Diamond Signal écrit, ce qu'il n'écrit jamais, et comment cette discipline est garantie dans tous les textes publiés par le service ou en son nom.

Périmètre d'application

La politique éditoriale s'applique à tout texte sortant émis par Diamond Signal ou son équipe, sans exception, notamment :

Aucune surface publique n'est exemptée. Si un nouveau canal est ouvert (forum, Discord, blog), il rejoint automatiquement le périmètre dès sa mise en ligne.

Nature du service — ce qu'il est, ce qu'il n'est pas

Diamond Signal est :

• un terminal d'analyse statistique sportive (MLB, NHL aujourd'hui ; d'autres ligues étudiées sans calendrier public) ;
• un agrégateur de modèles statistiques ouverts (notation dynamique avec extensions MoV, repos, voyage, météo, park factors, bullpen, ERA/SV%, etc.) ;
• un fournisseur de projections de probabilités calibrées et auditables ;
• un journal de bord public traçant chaque modification de modèle, chaque incident, chaque retrait de contenu.

Diamond Signal n'est pas :

• un sportsbook ni un opérateur de paris ;
• un service de pronostics, de tipster, ou de conseil de mise ;
• un service de conseil financier ou d'investissement ;
• un courtier sur prediction markets (Polymarket, Kalshi, etc.) ;
• un robot autonome qui agit pour le compte de l'utilisateur.

Le terme « favorisé / défavorisé » est utilisé pour décrire le résultat statistique d'une analyse de match : l'équipe dont la probabilité projetée de victoire est supérieure à 50 % est « favorisée » par le modèle. C'est un constat statistique, pas une recommandation. La sortie d'un match favorisé ne préjuge en rien de l'action que l'utilisateur doit entreprendre — la seule action attendue de Diamond Signal est de lire et comprendre.

Vocabulaire — ce qui est employé

Le lexique de Diamond Signal est celui de l'analyse statistique appliquée, pas celui du parieur :

Vocabulaire — ce qui est strictement interdit

Les formulations suivantes ne doivent jamais apparaître dans un texte publié :

1. Mention nominative d'un sportsbook (DraftKings, FanDuel, Bet365, PrizePicks, BetMGM, Caesars, Bwin, Unibet, Winamax, Betclic, Pinnacle, ParionsSport, Stake, PointsBet, etc.). On peut référer à un « marché de prédiction » ou « plateforme de marchés », jamais nommer un opérateur spécifique.
2. Verbes du pari en français comme en anglais : parier, miser, jouer son argent, placer un pari, bet on, place a wager, gamble, gambling, ainsi que leurs dérivés substantivés (parieur, bettor, gambler, punter).
3. Vocabulaire du pronostic : pronostic, pronostiquer, tipster, tip du jour, my pick, lock of the day, banger pick, mortal lock. Diamond Signal publie des projections statistiques, pas des pronostics.
4. Jargon parieur : moneyline, parlay, spread bet, prop bet, teaser, over/under bet, +EV bet, units risked, juice/vig, handle, cover the spread, hammer the bet, bookies.
5. Promesses de gain : easy money, sure thing, can't miss, free money, guaranteed win/profit/return/payout, money-back guarantee (sauf au sens strict d'un remboursement SaaS), argent facile, gain garanti, profit garanti, sans risque, risk-free, 100 % garanti.
6. Cotes américaines explicites (+250, -180, +135) hors contexte pédagogique encadré expliquant qu'il s'agit d'une convention de prediction market et non d'une invitation à miser.

Cette liste n'est pas exhaustive. Le filtre technique (cf. section suivante) maintient la liste à jour ; ce document liste les catégories majeures.

Garantie technique — le filtre ZeroGamblingFilter

L'application n'autorise aucun texte sortant qui n'a pas été soumis au filtre Python growth/zero_gambling_filter.py. Le filtre :

• Compile une bibliothèque de patterns regex couvrant toutes les catégories ci-dessus, en français et en anglais (mode UNICODE + IGNORECASE).
• Renvoie un verdict clean / not clean avec sévérité maximale (INFO / WARNING / BLOCKER) et la liste des hits trouvés.
• Inclut des whitelist contextuelles documentées (par exemple « Paris » la ville n'est pas confondu avec « les paris » sportifs ; « spread » au sens statistique est distingué de « spread bet »).
• Persiste chaque vérification dans deux registres complémentaires :
  • un audit JSONL local versionnable Git (preuve forensic offline) ;
  • la table Supabase gambling_filter_audit (append-only via trigger SQL qui rejette les UPDATE et DELETE, RLS service_role only).

Le filtre est fail-safe : un faux positif coûte 30 secondes de réécriture ; un faux négatif compromet la politique. La règle interne est explicite : bloquer trop est toujours préférable à bloquer pas assez.

L'audit log est conçu pour qu'un examinateur externe puisse vérifier combien de textes ont été passés au filtre, combien ont été bloqués, et sur quelle base, sur n'importe quelle période. Le tableau de bord /admin/audit rend ces statistiques accessibles à l'équipe en interne.

Processus de revue humaine

Le filtre technique est nécessaire, pas suffisant. Tout texte sortant passe également par une revue humaine selon le tableau suivant :

Aucune publication automatique n'est faite sans qu'au moins un humain ait validé le texte final, sauf l'exception explicitement encadrée à la section suivante (débriefings post-match SEO), en plus du filtre.

Exception : débriefings post-match SEO

Diamond Signal publie également, sur les URL canoniques /[locale]/debriefings/[sport]/[matchup], des débriefings post-match auto-générés par modèle de langage (Gemini Flash en production, Mistral Small en fallback). Cette surface ne suit pas la règle de revue humaine systématique — elle constitue la seule exception à la règle générale ci-dessus.

Pourquoi une exception

Trois propriétés rendent ce type de contenu compatible avec une publication automatique :

1. C'est du contenu rétrospectif, pas prospectif. Un débriefing décrit un match qui est déjà passé : il commente le score final, la performance des partants, la cohérence du modèle avec le résultat observé. Il ne propose, ni explicitement ni implicitement, d'action future au lecteur — il n'oriente pas un choix de mise car il n'y a plus rien à miser sur un match terminé.
2. C'est un volume incompatible avec une revue manuelle. L'objectif SEO du dispositif est d'occuper la longue traîne (~10 000 à 40 000 pages par an, multi-sport, multi-langue). Aucune équipe ne peut relire ce volume sans perdre la fraîcheur éditoriale qui fait la valeur de l'indexation Google (la page doit être en ligne dans les heures qui suivent la fin du match).
3. L'incident éventuel est borné et corrigible. Une page débriefing non conforme reste de la prose statistique — pas une recommandation d'investissement ni un appel à miser. Le retrait sous 48 h via le journal de bord (cf. § Erratum & retraits) couvre le risque résiduel sans nécessiter une revue ex ante systématique.

Les quatre garde-fous techniques

Avant qu'un débriefing soit servi à un visiteur, le pipeline applique quatre contrôles indépendants. La défaillance d'un seul d'entre eux empêche la publication.

1. Filtre ZeroGamblingFilter identique à celui appliqué aux autres surfaces. Aucun pattern de pari, aucune cote, aucun verbe de mise. Un hit bloque la publication et logue l'incident dans gambling_filter_audit.
2. Validation algorithmique du format. Le service refuse les sorties LLM qui ne contiennent pas les sections attendues dans la langue cible, qui sont plus courtes que le seuil minimum (≥ 1500 mots), ou qui mentionnent des modèles internes incohérents avec le positionnement public (par exemple toute référence directe à des noms d'algorithmes de rating non utilisés dans la doc publique). Un score qualité numérique est calculé ; un score insuffisant empêche la publication même si le filtre ZeroGambling passe.
3. Audit log append-only. Chaque appel LLM est tracé dans la table Supabase api_usage_tracking (trigger qui rejette UPDATE et DELETE). Le contenu publié est consultable dans debriefing_pages avec son score qualité, le verdict des filtres et la date de publication. Un examinateur externe peut reconstruire à tout moment l'historique exact de ce qui a été généré, validé, publié, retiré.
4. Mécanisme de retrait automatique. Toute mise à jour applicative peut basculer une page de is_published = TRUE à FALSE en une requête ; la page disparaît immédiatement de l'index sitemap et retourne 404 au crawler suivant. Le retrait n'a pas besoin de passer par un déploiement.

Périmètre de l'exception

L'exception est strictement limitée aux pages post-match servies sur /[locale]/debriefings/.... Elle ne s'applique pas :

• aux contenus pré-match (analyses publiées avant la fin du match) ;
• aux push notifications, emails ou posts sociaux qui pointeraient vers un débriefing avant validation ;
• à toute surface qui ne serait pas une page web crawlable indépendante (par exemple un widget intégré à /app).

Toute extension de l'exception à une autre surface exige une mise à jour explicite de la présente politique, datée et committée dans ce fichier.

Erratum & retraits

Si malgré le filtre et la revue, un texte non conforme est publié :

1. Retrait immédiat dès détection (suppression du tweet, du post Reddit, dépublication de l'email, mise à jour de la landing). Le retrait n'attend pas la correction.
2. Entrée publique dans le journal de bord dans les 48 h, catégorie correction, sévérité au minimum minor. L'entrée décrit factuellement :
   • quel texte a été publié,
   • sur quelle surface et à quelle heure,
   • comment il a échappé au filtre + à la revue (analyse de cause),
   • quelle action corrective a été prise pour éviter la récidive (nouveau pattern dans le filtre, double review obligatoire, etc.).
3. Mise à jour du filtre si la cause est un manque de couverture des patterns. La modification est versionnée Git, le FILTER_VERSION est incrémenté.

Aucune entrée n'est jamais supprimée du journal. Si une rectification est nécessaire après publication de l'erratum, on ajoute une note datée en fin de l'entrée — la même règle d'immutabilité que pour le journal.

Ton éditorial

• Factuel. Pas d'enthousiasme commercial déplacé, pas d'euphémisme. Les chiffres sont cités tels qu'ils sont, gains comme pertes.
• Sans promesse implicite. Aucune formulation ne doit suggérer qu'un utilisateur gagnera de l'argent en consommant Diamond Signal. Les performances passées ne préjugent pas de la précision future, et ce point est rappelé sur les surfaces principales.
• Avec mention de l'âge minimum (18+) et de la légalité juridictionnelle partout où un nouvel utilisateur peut atterrir (signup, landing, footer, premier email).
• Multilingue. Le contenu est produit en français, anglais, espagnol, portugais (Brésil), italien et allemand. La même politique éditoriale s'applique aux six langues. Les patterns du filtre couvrent FR + EN nativement ; un audit manuel est fait sur les textes ES/PT/IT/DE jusqu'à ce que les patterns soient étendus.

Mises à jour de cette politique

Cette politique est un document vivant. Elle est révisée :

• À chaque modification structurelle du filtre (ajout d'une catégorie majeure, changement d'algorithme).
• À chaque incident éditorial documenté dans le journal.
• À chaque évolution de positionnement éditorial du service.
• Au minimum une fois par an, lors de la rétrospective annuelle de conformité.

Toute modification est faite par commit dans le repo (docs/editorial-policy.md), ce qui crée automatiquement une trace Git horodatée et signée. Les versions historiques restent consultables sur GitHub. Le fichier apps/web/legal/editorial-policy-fr.md est synchronisé manuellement avec ce document à chaque mise à jour, afin que la page publique /editorial-policy reflète toujours la dernière révision.

La date de dernière révision figure en tête du présent document.

— L'équipe Diamond Signal