• Statut : Accepté, partiellement remplacé par l'ADR 0033 : un toucher sur une brique la pose directement, sans sélection ni « Ajouter à la table ». Partiellement remplacé aussi par l'ADR 0041 : hors connexion, consultation seule, sans préparation de fusion ni tentative conservée
• Portée : MVP

Contexte

ÉtymoLogique doit tester rapidement une interaction de manipulation utilisable au toucher comme à la souris. Le produit vise des sessions courtes, mais le codex et les explications bénéficient aussi d'un grand écran. Maintenir plusieurs applications natives retarderait la validation du cœur ludique.

Décision

Le MVP sera une application web responsive installable en tant que Progressive Web App.

L'interface partagera le même modèle d'interaction sur mobile et ordinateur, avec des alternatives accessibles :

• glisser-déposer ou sélection suivie de « Ajouter à la table » ;
• réorganisation au pointeur, au toucher ou au clavier ;
• confirmation explicite de la fusion ;
• mise en page adaptée plutôt que réduction uniforme de l'écran desktop.

Le shell de l'application et le dernier catalogue publié pourront être mis en cache. La consultation du codex pourra fonctionner hors connexion. Les opérations modifiant l'état autoritaire — ouverture de pli, consommation d'énergie, attribution d'une découverte et synchronisation — nécessiteront une validation serveur.

Hors connexion, aucune tentative n'est préparée ni conservée (ADR 0041).

Options envisagées

Applications natives iOS et Android

Écartées pour le MVP : elles offrent une intégration système supérieure, mais multiplient les surfaces à maintenir avant validation du gameplay.

Application desktop

Écartée : elle facilite le glisser-déposer, mais correspond moins bien aux sessions courtes et réduit la portée du test.

Site web non installable

Écarté : proche techniquement, mais moins adapté au retour régulier lié aux plis et à la reprise de session.

Conséquences

Positives

• une base d'interface pour mobile et desktop ;
• déploiement et expérimentation rapides ;
• installation facultative ;
• partage simple d'un prototype ;
• stratégie hors connexion progressive.

Négatives

• comportement variable des PWA selon les plateformes ;
• gestes tactiles et glisser-déposer à tester soigneusement ;
• notifications et tâches d'arrière-plan non garanties partout ;
• nécessité de gérer cache, migration et incompatibilité de catalogue.

Critères de réévaluation

Réévaluer si les tests montrent une limitation critique des interactions, si une fonctionnalité native devient centrale ou si la distribution en boutique devient une exigence produit.

• Statut : Accepté

Contexte

Une simple liste de chaînes ne peut pas représenter les changements de langue, les graphies, les sens ni les relations historiques. Interroger une source externe à chaque tentative rendrait la jouabilité et la qualité imprévisibles. Une génération automatique risquerait de valider des rapprochements faux.

Décision

Le contenu linguistique jouable sera un graphe éditorial publié par versions immuables. Une nouvelle publication crée une nouvelle version ; elle ne modifie pas silencieusement le sens d'une partie déjà jouée.

Le modèle distingue au minimum :

Les relations utilisent un vocabulaire contrôlé, notamment : héritage, emprunt, dérivation, composition, adaptation et apparentement. « Ressemble à » n'est pas une relation étymologique jouable.

Les identifiants sont stables et indépendants de la graphie. Corriger un accent ou une translittération ne doit pas créer artificiellement une nouvelle brique.

Chaque fait publié possède :

• une ou plusieurs sources ;
• un niveau de confiance : établi, probable ou discuté ;
• un état de relecture ;
• la version dans laquelle il apparaît ;
• si nécessaire, une note expliquant la simplification ludique.

Options envisagées

Liste de mots et préfixes

Écartée : simple au début, mais incapable de distinguer formes, sens et relations.

Dictionnaires externes interrogés à la volée

Écartés comme autorité d'exécution. Ils peuvent aider l'édition, mais leurs schémas, licences, disponibilité et analyses diffèrent.

Validation par modèle génératif

Écartée : non déterministe, difficile à sourcer et insuffisante pour garantir l'exactitude.

Conséquences

Positives

• résultats déterministes et explicables ;
• contenu testable et reproductible ;
• corrections et migrations traçables ;
• prise en charge de plusieurs écritures et analyses concurrentes ;
• séparation entre fait linguistique et représentation ludique.

Négatives

• coût éditorial important ;
• modèle plus riche qu'un dictionnaire de chaînes ;
• besoin d'outils de saisie, de revue et de migration ;
• impossibilité de promettre une couverture exhaustive.

Critères de réévaluation

Le vocabulaire et les entités pourront évoluer après un premier lot réel de contenu. La nature éditoriale et versionnée du graphe ne devra être remise en cause que si une autre approche offre la même traçabilité et la même qualité.

• Statut : Accepté, secret des recettes verrouillées remplacé par l'ADR 0027 ; nombre d'emplacements fixé à deux par l'ADR 0032. Le reste de la recette (variantes, transformations, résultats de tentative) reste en vigueur.

Contexte

La concaténation stricte est facile à comprendre, mais elle ne représente ni les variations de forme ni les chemins historiques. À l'inverse, une évaluation libre rendrait les résultats arbitraires et difficiles à expliquer.

Décision

Une fusion réussit uniquement lorsqu'elle correspond à une recette éditoriale publiée et accessible.

Une recette contient :

• un identifiant stable ;
• une liste ordonnée d'emplacements ;
• pour chaque emplacement, les briques ou variantes acceptées ;
• les préconditions de progression ;
• une suite de transformations contrôlées ;
• un résultat linguistique ;
• les objets et pistes débloqués ;
• une définition courte du résultat dans son sens actuel, et son sens littéral lorsqu'il diffère ;
• une explication courte et une explication détaillée ;
• les références aux faits linguistiques qui la justifient.

Les transformations sont des données explicites, pas du code libre. Leur vocabulaire initial peut inclure :

• ajout ou retrait d'une voyelle de liaison ;
• allomorphie ;
• adaptation de graphie ;
• adaptation phonétique décrite ;
• suffixation ou préfixation ;
• emprunt via une forme intermédiaire ;
• composition avec ordre documenté.

Le moteur compare des identifiants et variantes autorisées, jamais des saisies libres. Toutes les entrées reçues par l'API sont validées côté serveur : nombre d'ingrédients, type, ordre, appartenance au catalogue actif et possession des briques.

Une recette ne prétend pas nécessairement que le mot a été historiquement « fabriqué » par l'opération que réalise le joueur. L'explication distingue l'analogie ludique du chemin attesté.

Résultats de tentative

• discovery : recette valide et résultat nouveau ;
• known : recette valide déjà découverte ;
• hintable : proposition correspondant à un indice éditorial sûr ;
• locked : recette réelle mais préconditions non remplies ;
• invalid : aucune correspondance.

Le serveur ne renvoie pas l'identifiant ou les ingrédients secrets d'une recette verrouillée.

Remplacé par l'ADR 0027 : le catalogue est publié en fichiers statiques, et les recettes d'un fascicule paru y sont lisibles. Le serveur fait toujours foi pour valider une fusion et modifier la réserve et le codex.

Options envisagées

Concaténation stricte

Écartée comme règle unique : trop peu expressive et pédagogiquement trompeuse dans de nombreux cas.

Évaluation libre par dictionnaire ou IA

Écartée : résultats non maîtrisés, couverture incohérente et risques d'erreurs.

Grammaire linguistique universelle

Écartée pour le MVP : complexe, fragile et inutile pour un catalogue éditorial fini.

Conséquences

Positives

• logique déterministe, testable et expliquée ;
• difficulté contrôlable ;
• transformations rendues visibles ;
• aucune saisie arbitraire à modérer.

Négatives

• chaque solution doit être conçue ;
• les variantes acceptables doivent être anticipées ;
• le moteur ne reconnaît pas automatiquement une solution réelle absente du catalogue ;
• frustration possible si une variante plausible n'est pas éditée.

Critères de réévaluation

Enrichir le vocabulaire de transformations à partir des besoins réels du contenu. N'introduire une évaluation ouverte que si elle peut rester déterministe, sourcée et sûre.

• Statut : Accepté, complété par l'ADR 0012 : les briques étant rationnées, la fermeture est complétée par une simulation de réserve.

Contexte

Le joueur ne peut pas saisir un mot arbitraire pour créer une brique. Toute brique indispensable doit donc provenir d'une graine, d'une fusion, d'un jalon ou d'un pli. Une dépendance circulaire ou un tirage manquant peut bloquer définitivement la progression.

Décision

Chaque version du contenu définit un graphe d'obtention distinct du graphe linguistique :

• les nœuds sont les objets déblocables ;
• une hyperarête de recette relie plusieurs ingrédients à ses résultats ;
• les graines, jalons et récompenses déterministes sont des sources ;
• les plis sont des sources conditionnelles avec un ensemble d'éligibilité explicite.

Avant publication, un validateur calcule une fermeture par point fixe :

1. initialiser l'ensemble avec les graines et récompenses garanties ;
2. ajouter le résultat de toute recette dont les ingrédients et préconditions sont satisfaits ;
3. ajouter les récompenses de jalons devenus satisfaits ;
4. répéter jusqu'à ce qu'aucun objet ne soit ajouté ;
5. comparer l'ensemble obtenu aux objets déclarés atteignables.

Le validateur échoue si :

• une brique requise n'est pas atteignable ;
• une recette du chemin critique dépend uniquement d'un tirage aléatoire ;
• un cycle n'a aucun point d'entrée ;
• un pli peut se retrouver sans récompense valide ni compensation ;
• une précondition référence un contenu absent ou d'une autre version ;
• une recette accessible exige une brique que le joueur ne peut posséder à ce stade.

Le système doit aussi simuler les états importants, notamment nouveau joueur, joueur ayant épuisé un pool de pli et migration depuis la version précédente.

Les contenus optionnels peuvent être volontairement inatteignables seulement s'ils sont explicitement marqués comme non publiés ou réservés à une future version. Ils ne comptent alors pas dans le codex visible.

Options envisagées

Relecture manuelle

Écartée comme seul contrôle : les chemins combinatoires dépassent rapidement ce qu'une revue peut garantir.

Déblocage de secours universel

Écarté : masquerait les erreurs de graphe et rendrait la progression incohérente.

Plis purement aléatoires

Écartés pour les briques indispensables : aucune garantie de progression ni de test reproductible.

Conséquences

Positives

• absence d'impasse connue dans une version publiée ;
• changements de contenu testables en intégration continue ;
• visualisation possible des zones trop linéaires ou trop dépendantes des graines ;
• base solide pour calculer des plis utiles.

Négatives

• modèle de progression et outils dédiés à maintenir ;
• fermeture simple insuffisante pour certaines contraintes temporelles ou quantitatives ;
• besoin de scénarios supplémentaires lorsque l'économie se complexifie.

Critères de réévaluation

Ajouter une simulation d'états ou un solveur plus riche si des coûts, choix exclusifs ou événements temporels rendent la fermeture monotone insuffisante.

• Statut : Accepté

Contexte

Le contenu relie exactitude linguistique, règles de fusion et progression. Une erreur de saisie peut créer une fausse explication ou bloquer une branche. Modifier directement les données de production ne permet ni revue ni reproduction.

Décision

Le contenu suit un pipeline distinct du déploiement applicatif :

1. édition dans un format structuré soumis à un schéma ;
2. validation locale des types, références, identifiants et vocabulaires contrôlés ;
3. revue linguistique des sources, relations, formulations et niveaux de confiance ;
4. validation ludique des recettes, préconditions, récompenses et indices ;
5. analyse globale de l'atteignabilité, des cycles et des pools de plis ;
6. compilation en artefact immuable optimisé pour le client et le serveur ;
7. publication avec un identifiant de version et un rapport de validation ;
8. migration explicite des progressions si les identifiants ou déblocages changent.

Les identifiants sont opaques et stables. Ils ne contiennent pas de graphie susceptible d'être corrigée.

La publication est refusée en cas :

• de référence cassée ;
• de source obligatoire absente ;
• de relation non relue ;
• de recette ambiguë dans le même état de progression ;
• d'objet visible inatteignable ;
• de translittération sans convention déclarée ;
• de récompense de pli invalide.

Les avertissements peuvent couvrir les niveaux de confiance discutés, les familles incomplètes et les déséquilibres non bloquants.

Le catalogue publié ne contient que les données nécessaires à l'expérience. Les notes internes, brouillons et informations sensibles restent hors de l'artefact client.

Options envisagées

Modification directe en base de production

Écartée : peu révisable, non reproductible et risquée.

Contenu embarqué dans le code

Écarté : mélange les cycles de publication, complique la revue éditoriale et empêche les outils spécialisés.

CMS générique comme unique validation

Écarté : utile comme interface future, mais insuffisant pour valider un hypergraphe de progression.

Conséquences

Positives

• qualité contrôlée avant exposition ;
• catalogue reproductible côté client et serveur ;
• retour arrière vers une version connue ;
• possibilité d'ajouter ensuite une interface éditoriale sans changer les règles.

Négatives

• investissement initial dans schémas, compilateur et validations ;
• publication moins immédiate ;
• migrations nécessaires pour certaines corrections.

Critères de réévaluation

Le format d'édition et l'interface pourront changer. Les étapes de validation et la production d'un artefact versionné restent obligatoires.

• Statut : Accepté

Contexte

L'étymologie traverse plusieurs langues et systèmes d'écriture. La langue de l'interface, la langue d'un mot et la convention utilisée pour translittérer une forme sont trois dimensions différentes. Le premier lot de contenu n'est pas encore choisi.

Décision

L'architecture de données sera multilingue dès le MVP, sans exiger que plusieurs langues d'interface ou un grand nombre de langues jouables soient livrés.

Le système distingue :

• locale d'interface : libellés, explications et formats destinés au joueur ;
• langue linguistique : langue d'un lexème ou d'un morphème, avec période ou variété si nécessaire ;
• système d'écriture : alphabet, abjad, syllabaire ou autre système d'une forme ;
• forme originale : texte éditorial conservé en Unicode ;
• translittération : représentation selon une convention identifiée ;
• traduction ou glose : sens présenté dans une locale d'interface.

Les références utilisent des identifiants stables plutôt que les libellés traduits. Le modèle autorise plusieurs formes et translittérations pour un même objet, sans les transformer en briques distinctes par défaut.

Le rendu :

• affiche toujours le nom complet de la langue dans la locale d'interface (« grec ancien », « latin », « français ») ; les codes de langue restent strictement internes et n'apparaissent jamais au joueur, même sous forme abrégée ;
• respecte la direction d'écriture au niveau du fragment ;
• utilise des polices de repli couvrant les écritures publiées ;
• n'impose pas une translittération lorsqu'une forme originale suffit ;
• affiche ensemble forme originale et translittération lorsque cela aide le public visé ;
• applique une normalisation Unicode uniquement aux comparaisons techniques prévues, jamais en remplaçant silencieusement la graphie éditoriale.

Les règles de fusion ne dépendent pas de chaînes localisées. Une recette référence des objets linguistiques et ses explications possèdent leurs propres traductions.

Options envisagées

Modèle centré uniquement sur le français

Écarté : il conduirait à mélanger traduction, translittération et identité linguistique, puis à une migration coûteuse.

Tout traduire dès le MVP

Écarté : l'architecture générique ne justifie pas le coût d'une interface et d'un catalogue entièrement localisés avant validation.

Translittération comme objet collectionnable indépendant

Écartée par défaut : elle dupliquerait artificiellement les découvertes. Une convention de lecture peut toutefois être récompensée comme connaissance, séparément des briques.

Conséquences

Positives

• ajout de langues sans refonte du domaine ;
• meilleure fidélité des formes historiques ;
• localisation de l'interface indépendante du contenu jouable ;
• recettes stables entre locales.

Négatives

• contraintes Unicode, directionnelles et typographiques dès le départ ;
• tests nécessaires avec plusieurs écritures même si le lot initial est restreint ;
• coût de traduction des explications à anticiper.

Critères de réévaluation

Réviser les conventions d'affichage avec des spécialistes des écritures effectivement publiées. Ne pas réduire la séparation entre locale, langue, écriture et translittération.

• Statut : Accepté, partiellement remplacé par l'ADR 0041 : plus d'opérations en attente rejouables, hors connexion la PWA ne fait que consulter. Partiellement remplacé aussi par l'ADR 0070 : compte facultatif rattaché au profil invité, connexion par lien et code envoyés par e-mail, plusieurs appareils par joueur. Le reste de la décision reste en vigueur.

Contexte

Le jeu doit reprendre une progression, calculer la recharge d'énergie et empêcher qu'un changement d'horloge locale ou une requête falsifiée n'accorde des récompenses. La PWA doit néanmoins rester réactive et tolérer une connexion intermittente.

Décision

Le serveur est l'autorité sur :

• la version de catalogue active pour une partie ;
• les graines, découvertes et briques possédées ;
• la résolution finale d'une fusion ;
• l'énergie, sa prochaine échéance et l'ouverture des plis ;
• les récompenses, jalons et migrations de progression.

Le client conserve un cache local pour :

• le catalogue autorisé ;
• une projection de la progression confirmée ;
• l'état visuel de la table ;
• les préférences non sensibles ;

Toute commande serveur contient un identifiant d'idempotence généré par le client. Le serveur valide le schéma, l'identité technique, la version du catalogue, les préconditions et les droits avant une mutation. Une réponse en conflit provoque une resynchronisation explicite ; le client ne transforme pas un échec en succès local.

Le MVP peut utiliser un profil invité associé à un identifiant aléatoire d'installation et à un secret stocké de manière adaptée à la plateforme. Ce profil ne contient pas de nom, d'adresse électronique ou d'autre donnée personnelle. La récupération multi-appareil et la conversion vers un compte feront l'objet d'une décision séparée avant collecte de données d'identité.

Les écritures côté serveur sont transactionnelles : consommation d'énergie, tirage et attribution de récompense réussissent ou échouent ensemble.

Options envisagées

État uniquement local

Écarté : simple et très privé, mais incompatible avec une économie fiable, les migrations contrôlées et une future synchronisation.

Client autoritaire avec synchronisation occasionnelle

Écarté : l'horloge, l'énergie et les récompenses seraient facilement incohérentes ou falsifiables.

Compte obligatoire dès le premier lancement

Écarté pour le MVP : friction et collecte de données non nécessaires pour tester le jeu.

Conséquences

Positives

• économie cohérente ;
• commandes rejouables sans doubles récompenses ;
• collecte d'identité minimale ;
• client réactif grâce aux projections locales ;
• chemin futur vers la synchronisation.

Négatives

• backend requis même pour un jeu essentiellement solo ;
• ouverture de pli indisponible sans connexion ;
• perte possible du profil invité si le stockage local disparaît ;
• résolution de conflits et migrations à concevoir.

Critères de réévaluation

Créer un nouvel ADR avant d'ajouter compte nominatif, authentification fédérée, synchronisation multi-appareil ou récupération de progression.

• Statut : Accepté, partiellement remplacé par l’ADR 0011. Le contenu des plis, les doublons et les raretés relèvent désormais de l’ADR 0011. L’énergie, la recharge et l’absence de paiement restent régies par le présent ADR. Depuis l’ADR 0012, les plis sont aussi la seule source d’exemplaires de briques ; l’énergie ne limite toujours pas les fusions, et une tentative ratée ne consomme rien. Partiellement remplacé aussi par l’ADR 0020 : l’énergie compte deux charges, et des sabliers gagnés contre de l’encre avancent la recharge ; l’absence de paiement reste en vigueur.

Contexte

Les plis peuvent relancer l'exploration en apportant une nouvelle brique, mais un hasard non maîtrisé peut bloquer la progression. L'énergie fournit un rythme de retour, avec un risque de frustration ou de conception manipulatrice. La monétisation n'est pas nécessaire pour valider le cœur du jeu.

Décision

Le MVP inclut des plis gratuits limités par une énergie dédiée. Cette énergie n'est jamais requise pour fusionner des briques déjà obtenues.

Principes :

• la capacité, la durée de recharge et le contenu des plis sont des paramètres versionnés d'équilibrage ;
• douze heures constitue la première hypothèse de recharge, sans être codée en dur ;
• le serveur calcule l'énergie à partir d'instants fiables ;
• l'interface affiche la disponibilité et l'heure estimée sans fausse urgence ;
• aucun paiement, publicité récompensée, monnaie premium ou achat de recharge ;
• le chemin critique dispose toujours d'une voie déterministe.

Lors de l'ouverture, le serveur construit un pool à partir :

• des règles d'équilibrage actives ;
• des briques que le joueur ne possède pas ;
• de ses préconditions satisfaites ou du niveau auquel la brique peut être utile ;
• d'au moins une recette ou piste que la récompense peut ouvrir ;
• des exclusions éditoriales et de la protection contre les doublons inutiles.

Le tirage et l'attribution sont atomiques et idempotents. Le résultat enregistre la règle d'équilibrage utilisée afin de permettre un diagnostic sans journaliser de donnée personnelle.

Si aucun objet n'est éligible, le pli fournit une compensation définie, par exemple un indice, ou est remplacé par une récompense déterministe. Il ne renvoie jamais silencieusement un pli vide.

Options envisagées

Aucun pli

Non retenu pour le MVP : il empêcherait de tester cette boucle secondaire importante, bien qu'elle puisse être retirée si elle dégrade le jeu.

Plis purement aléatoires

Écartés : ils peuvent produire doublons, impasses et frustration.

Monétisation immédiate

Écartée : elle ajoute conformité, attentes économiques et biais de conception avant validation du plaisir.

Énergie consommée à chaque fusion

Écartée : elle décourage l'expérimentation, qui est le cœur du jeu.

Conséquences

Positives

• boucle de retour testable sans pression financière ;
• récompenses adaptées à la progression ;
• expérimentation illimitée sur le contenu possédé ;
• paramètres ajustables sans modifier les faits linguistiques.

Négatives

• économie serveur à construire et observer ;
• système potentiellement perçu comme artificiel même sans paiement ;
• calcul d'éligibilité plus complexe qu'une table aléatoire ;
• obligation de concevoir une fin de catalogue satisfaisante.

Critères de réévaluation

Retirer ou modifier l'énergie si les tests ne montrent pas de valeur ludique. Toute monétisation future exige un ADR couvrant éthique, conformité, contrôle parental, transparence des probabilités et politique de remboursement.

• Statut : Accepté

Contexte

La rareté d'une brique, son apparition dans un pli et le moment où elle est jouable peuvent changer après un test. Ces paramètres ne sont pas des propriétés linguistiques. Les mélanger aux faits rendrait une correction d'équilibrage difficile à distinguer d'une correction scientifique.

Décision

Le catalogue comporte deux couches référencées par identifiants :

Couche linguistique

Elle contient formes, langues, sens, morphèmes, relations, sources, niveaux de confiance et explications factuelles.

Couche ludique

Elle contient recettes jouables, graines, jalons, visibilité, difficulté, indices, groupes de progression, poids de rareté et de type des plis, garantie de nouveauté, conversion des doublons en encre et récompenses.

La couche ludique référence la couche linguistique, jamais l'inverse. Un objet linguistique peut exister sans être jouable. Une brique ou une recette ne peut pas inventer un fait absent de la couche linguistique validée.

Les versions des deux couches sont associées dans un manifeste de publication. Un ajustement de poids de pli peut publier une nouvelle version ludique réutilisant exactement la même version linguistique. Une correction de relation publie une nouvelle version linguistique et déclenche la revue des recettes dépendantes.

Le niveau de confiance d'une étymologie ne détermine pas sa rareté. La rareté reflète uniquement la progression du jeu et doit employer un vocabulaire visuel différent.

Options envisagées

Un document unique par mot

Écarté : pratique pour l'affichage, mais mélange vérité linguistique, état du joueur et paramètres temporaires.

Copier les faits dans chaque recette

Écarté : duplication, divergences et corrections incomplètes.

Déduire automatiquement tout l'équilibrage du graphe

Écarté : des métriques peuvent assister l'équipe, mais la qualité d'une progression reste une décision de design.

Conséquences

Positives

• rééquilibrage sans altération des sources ;
• audit clair des corrections ;
• réutilisation d'un même fait dans plusieurs recettes ;
• possibilité de tester plusieurs progressions sur un catalogue commun.

Négatives

• deux cycles de version à coordonner ;
• compilation nécessaire pour une vue client efficace ;
• dépendances à invalider lorsqu'un fait change.

Critères de réévaluation

Le format physique peut être combiné pour le déploiement, mais les responsabilités et versions logiques doivent rester séparées.

• Statut : Accepté

Contexte

Le MVP doit vérifier si les joueurs comprennent la fusion, utilisent les indices et reviennent ouvrir un pli. Une collecte exhaustive ou des journaux contenant les propositions brutes créeraient un risque de vie privée sans améliorer nécessairement les décisions.

Décision

L'observabilité suit les principes de minimisation, finalité explicite, durée limitée et agrégation.

Les événements produit autorisés couvrent :

• démarrage et fin des étapes du tutoriel ;
• tentative de fusion classée par résultat ;
• découverte d'une recette ;
• demande d'un niveau d'indice ;
• ouverture de pli et catégorie de récompense ;
• reprise après disponibilité d'un pli ;
• erreur technique catégorisée.

Un événement contient uniquement :

• un identifiant d'événement ;
• un identifiant technique pseudonyme à rotation ou portée limitée ;
• un horodatage ;
• la version de l'application, du catalogue et de l'équilibrage ;
• des identifiants internes nécessaires à l'analyse ;
• des propriétés énumérées et validées.

Il ne contient jamais de nom, adresse électronique, adresse réseau complète conservée comme propriété analytique, texte libre, contenu de stockage local, en-têtes d'authentification ou autre donnée personnelle inutile.

Les journaux applicatifs utilisent des codes d'erreur et identifiants de corrélation non personnels. Les charges utiles utilisateur, secrets et jetons sont exclus ou expurgés avant émission. Les erreurs de validation sont visibles par des métriques structurées, pas par la copie de la requête.

Le serveur :

• valide chaque événement selon un schéma et une liste de propriétés autorisées ;
• limite le débit et la taille ;
• rejette les propriétés inconnues au lieu de les stocker ;
• sépare télémétrie produit et journaux opérationnels ;
• applique des durées de conservation documentées ;
• restreint les accès et trace les consultations administratives.

Le produit explique la collecte et offre les contrôles requis avant une diffusion publique. Les métriques agrégées sont privilégiées lorsqu'un suivi individuel n'est pas indispensable.

Options envisagées

Aucune télémétrie

Non retenue : elle rendrait les hypothèses du MVP difficiles à évaluer. Les tests qualitatifs restent néanmoins indispensables.

Enregistrement de toutes les sessions

Écarté : intrusif, volumineux et susceptible de capturer des données imprévues.

Fournisseur analytique choisi immédiatement

Écarté : le besoin et le contrat de données doivent précéder le choix d'un service tiers.

Conséquences

Positives

• indicateurs utiles avec exposition réduite ;
• schémas auditables et testables ;
• moindre risque de fuite dans les journaux ;
• indépendance initiale vis-à-vis d'un fournisseur.

Négatives

• certaines analyses exploratoires seront impossibles a posteriori ;
• effort de gouvernance, rétention et contrôle d'accès ;
• identifiants limités moins adaptés aux cohortes longues.

Critères de réévaluation

Tout nouvel événement doit justifier sa finalité et sa durée. Toute session replay, expérimentation personnalisée ou intégration tierce nécessite une revue dédiée de la vie privée et de la sécurité.

• Statut : Accepté, partiellement remplacé par l'ADR 0012. Un doublon ajoute désormais un exemplaire à la réserve, et, depuis l'ADR 0019, chaque doublon rapporte aussi de l'encre : la moitié du barème sous le plafond, le barème complet au-delà. Depuis l'ADR 0020, l'encre s'échange aussi contre des sabliers (1 goutte) et l'indice coûte 30 gouttes. Le tirage, les raretés, la garantie et la transparence restent régis par le présent ADR. Partiellement remplacé aussi par l'ADR 0015 : les légendaires inconnues sont regroupées en une ligne, sans leur nombre ; et par l'ADR 0016 : un pli ne tire que parmi les briques de son fascicule, et la garantie se compte par fascicule. Partiellement remplacé aussi par l'ADR 0035 : le poids d'une brique est celui de sa seule rareté, sans poids de type ni répartition par classe. Partiellement remplacé enfin par l’ADR 0043 : la garantie de nouveauté ne vise plus les légendaires, qui se partagent une chance fixe, et une légendaire connue n’a plus sa propre ligne de chance.
• Remplace partiellement : ADR 0008, pour le contenu des plis

Contexte

L'ADR 0008 prévoyait des plis qui ne donnent que des briques nouvelles et utiles, sans doublon. Ce fonctionnement remplit le codex trop vite : chaque pli est une nouveauté garantie, et la découverte perd de sa valeur. Or l'attente, la surprise et la rareté font partie du plaisir de collection.

Il faut ralentir le remplissage sans rendre le jeu frustrant, ni bloquer la progression.

Décision

Tirage

Chaque pli tire une brique dans tout le catalogue du pli, y compris les briques déjà possédées. Les doublons sont donc possibles et assumés.

La probabilité d'une brique dépend de deux paramètres d'équilibrage :

• Type : les suffixes ont un poids légèrement supérieur aux préfixes (1,25 contre 1), car ils se combinent plus souvent.
• Poids d'une brique : poids de sa rareté × poids de son type, réparti entre les briques de même rareté et de même type.

Ces valeurs sont des paramètres versionnés de la couche d'équilibrage (ADR 0009). La rareté ne dépend jamais du niveau de confiance d'une étymologie.

Il y a exactement quatre niveaux de rareté, chacun avec sa forme. Pour les trois premiers, le nombre de côtés croît avec la rareté : triangle, carré, pentagone. Le diamant, réservé aux légendaires, est à part : il ne suit pas cette progression et se reconnaît à sa silhouette, un losange étiré nettement plus haut que large. Ce vocabulaire reste distinct du cercle des états de retour et des traits de la confiance éditoriale. La forme est toujours accompagnée de son libellé ou d'un nom accessible ; ses couleurs sont fixées par la charte (identité).

Doublons et encre

Remplacé par l'ADR 0012 : un doublon ajoute un exemplaire (5 au plus par brique) ; le barème d'encre ci-dessus ne s'applique qu'au-delà de ce plafond.

• Un doublon augmente le nombre d'exemplaires de la brique (×2, ×3…) et rapporte des gouttes d'encre, d'autant plus que la brique est rare.
• L'encre s'échange contre des indices, 10 gouttes dans la démonstration.
• Plus tard, elle pourra peut-être servir à forger une brique choisie, sous réserve d'un ADR dédié.
• L'encre n'est ni achetable ni convertible en argent.

Garantie de nouveauté

• Tant qu'il reste des briques inconnues, une brique nouvelle est garantie au plus tard au 6ᵉ pli après la dernière nouveauté.
• Le compteur est visible par le joueur.
• Quand toutes les briques sont connues, chaque pli donne un doublon et de l'encre.

Transparence

L'écran des plis affiche en permanence :

• les chances par rareté et par type ;
• les chances exactes de chaque brique, les briques inconnues restant en silhouette avec leur rareté ;
• l'état de la garantie ;
• l'encre disponible ;
• l'historique des tirages.

Les pourcentages affichés sont calculés à partir des poids réels, jamais arrondis de manière trompeuse.

Garde-fous conservés

• Les briques indispensables au tutoriel et au chemin critique ne dépendent jamais d'un tirage aléatoire (ADR 0004) : elles viennent de la réserve de départ et des plis de jalon, dont le contenu est déterministe (ADR 0012).
• L'énergie ne limite que les plis, jamais les fusions.
• Aucun paiement, aucune publicité et aucune monnaie premium dans le MVP.
• Le tirage et l'attribution restent atomiques, idempotents et calculés par le serveur.

Rythme visé

Une simulation de 20 000 parties sur le catalogue de démonstration (4 briques de départ, 5 à découvrir) donne :

Avec la garantie au 6ᵉ pli et un pli toutes les 12 heures, le catalogue de démonstration se complète en environ deux semaines, sans série de malchance interminable. Ces chiffres seront recalculés à chaque version du catalogue.

Options envisagées

Nouveauté garantie à chaque pli (ADR 0008)

Écartée : le codex se remplit trop vite et les plis perdent leur intérêt.

Hasard pur, sans garantie

Écarté : la simulation montre des séries de plus de 150 plis pour 10 % des joueurs, ce qui est trop frustrant.

Doublons sans compensation

Écartés : un doublon doit toujours rapporter quelque chose.

Conséquences

Positives

• La découverte redevient rare et désirable, et les briques rares créent de vrais moments forts.
• Les doublons gardent une valeur grâce à l'encre et aux indices.
• Le rythme de remplissage est réglable par les poids et la garantie, sans toucher aux faits linguistiques.
• Toutes les chances sont transparentes.

Négatives

• Une économie de plus (l'encre) à équilibrer et à surveiller.
• Le risque d'une perception « machine à sous » si les chances ou la garantie ne sont pas clairement affichées.
• Le rythme doit être recalculé à chaque ajout de briques.

Critères de réévaluation

Revoir les poids et la garantie si le taux de nouveauté observé s'écarte nettement de la simulation, ou si les tests montrent de la frustration. Toute monétisation liée aux plis ou à l'encre exige un nouvel ADR couvrant l'éthique, la conformité (notamment les règles sur les coffres à butin), le contrôle parental et la transparence des probabilités.

• Statut : Accepté, partiellement remplacé par l'ADR 0016 : le filet d'utilité se compte par fascicule et choisit sa brique parmi celles du fascicule. Partiellement remplacé aussi par l'ADR 0019 : un doublon sous le plafond rapporte, en plus de son exemplaire, la moitié du barème d'encre. Partiellement remplacé enfin par l’ADR 0043 : le filet d’utilité ne choisit jamais une légendaire. Le reste du présent ADR reste en vigueur.
• Remplace partiellement : ADR 0011, pour la valeur des doublons
• Complète : ADR 0004 (atteignabilité avec quantités), ADR 0007 (consommation sous autorité serveur), ADR 0008 (rôle des plis)

Contexte

Jusqu'ici, une brique obtenue restait utilisable sans limite. Le joueur pouvait donc tout essayer dès qu'il possédait les briques, et les doublons n'avaient de valeur que par l'encre. Le codex se remplissait vite, et les plis perdaient leur intérêt une fois les briques connues.

Nous voulons que chaque brique compte : le joueur dispose d'un nombre limité d'exemplaires, et les plis sont le seul moyen d'en obtenir de nouveaux. Il faut le faire sans punir l'expérimentation, qui reste le cœur du jeu, et sans créer d'impasse.

Décision

Réserve et exemplaires

• Chaque brique connue a un nombre d'exemplaires : c'est la réserve du joueur.
• La connaissance est permanente : une brique à zéro exemplaire reste dans le codex, marquée épuisée.
• Au début, le joueur reçoit une réserve de départ (démonstration : 4 briques × 2 exemplaires). Elle permet les premières découvertes sans ouvrir de pli.
• Ensuite, seuls les plis donnent des exemplaires. Les jalons ne donnent plus de brique directement : ils offrent un pli de jalon, dont le contenu est déterministe et déclaré dans le graphe d'obtention.
• Plafond : 5 exemplaires par brique. Un exemplaire reçu au-delà se change en gouttes d'encre, selon la rareté (barème de l'ADR 0011).

Consommation

Règle d'expérience : se tromper ne coûte rien, réussir consomme. Le joueur ne peut pas poser plus d'exemplaires qu'il n'en possède. Quand il ne lui reste qu'un exemplaire d'une brique utile à plusieurs mots, il doit choisir quel mot écrire : c'est une décision de jeu voulue.

Plis

• Chaque pli donne un exemplaire d'une brique :
  • brique nouvelle : 1 exemplaire ;
  • brique connue : +1 exemplaire (« De retour ! » si elle était épuisée) ;
  • réserve pleine : de l'encre.
• La garantie de nouveauté au 6ᵉ pli est conservée (ADR 0011).
• Filet d'utilité : si la réserve ne permet plus aucune découverte, le 5ᵉ pli consécutif ouvert dans cet état contient forcément une brique qui en rend au moins une possible. Le compteur est visible. Si aucune brique seule ne suffit, le pli donne une brique manquante d'une recette encore à découvrir.

Atteignabilité

La fermeture monotone de l'ADR 0004 ne suffit plus, puisque des quantités sont consommées. Le validateur ajoute donc une simulation de réserve :

• un joueur qui ouvre des plis finit toujours par pouvoir découvrir chaque mot publié ;
• aucune recette du chemin critique n'exige plus d'exemplaires que le plafond ;
• la réserve de départ permet au moins trois découvertes distinctes ;
• le filet d'utilité trouve toujours une brique éligible.

Autorité serveur

La réservation est locale et purement visuelle. La consommation, en revanche, fait partie de la transaction de découverte : vérification de la recette, décrément des exemplaires et ajout au codex réussissent ou échouent ensemble, de façon idempotente. Une fusion hors ligne est mise en file d'attente et rejouée à la reconnexion. Elle ne consomme qu'une fois, au moment où le serveur l'accepte.

Rythme visé

Simulation sur le catalogue de démonstration (9 mots, 9 briques, réserve de départ 4 × 2, plafond 5, un pli toutes les 12 heures, joueur qui découvre dès que c'est possible) :

Retenu : filet au 5ᵉ pli, une brique par pli. Avec 22 plis en médiane, soit environ onze jours, le rythme reste proche de celui de l'ADR 0011 (24 plis), mais les séries de malchance sont bornées. La taille du pli, le plafond, la réserve de départ et le seuil du filet sont des paramètres d'équilibrage (ADR 0009).

Options envisagées

Briques illimitées (situation précédente)

Écartée : les doublons perdent leur sens et le codex se remplit trop vite.

Consommation à chaque tentative

Écartée : l'expérimentation deviendrait punitive, et une erreur pourrait vider la réserve en quelques gestes.

Rationnement sans filet

Écarté : la simulation montre des séries de plus de 150 plis sans progrès possible pour quelques joueurs.

Plusieurs briques par pli

Non retenue pour l'instant : elle accélère le rythme, mais demande un rituel de révélation multiple. Elle reste une option d'équilibrage.

Conséquences

Positives

• Chaque exemplaire a de la valeur, et les doublons redeviennent désirables.
• Les plis restent utiles même quand toutes les briques sont connues.
• Le choix du mot à écrire avec un exemplaire rare crée de vraies décisions.
• Le rythme est réglable sans toucher aux faits linguistiques.

Négatives

• Un joueur peut se retrouver sans découverte possible pendant quelques plis. Le filet borne cette attente, mais elle existe.
• Une quantité de plus à synchroniser, à valider et à expliquer.
• Le principe « essayer ne coûte rien » devient « se tromper ne coûte rien ». L'interface doit rendre le coût d'une découverte lisible (compteur, « −1 », exemplaires utilisés sur la fiche).
• Le validateur d'atteignabilité devient une simulation, plus coûteuse qu'une fermeture.

Critères de réévaluation

Revoir le plafond, la réserve de départ, le seuil du filet ou la taille du pli si les tests montrent plus de deux jours sans découverte possible pour un joueur actif, ou si le taux d'abandon augmente après l'épuisement de la réserve de départ.

• Statut : Proposé, partiellement remplacé par l’ADR 0058 : d’autres langues que les trois du MVP entrent quand une chaîne étymologique d’un mot publié passe par elles ; l’absence de variété reste en vigueur
• Complète : ADR 0002 (entités du graphe), ADR 0006 (formes, écritures et translittérations), ADR 0009 (points d'ancrage de la couche ludique)

Contexte

Le prototype décrit chaque brique par un objet plat : un libellé avec son trait d'union (« géo- »), une glose, un type et une rareté. Chaque recette y mélange le mot, son sens littéral, sa définition et son explication. Ce format a suffi pour éprouver le design. Il ne permet pas de sourcer un fait, de relier philo- à -phile, de montrer les formes d'un mot dans plusieurs langues, ni de réutiliser un mot découvert comme ingrédient.

L'ADR 0002 nomme les entités du graphe, mais ne dit ni comment elles se relient, ni lesquelles deviennent des briques. Nous commençons avec quatre types d'objets : langue, mot, préfixe et suffixe. Il faut un schéma relationnel logique, indépendant de toute base de données, que le pipeline de contenu (ADR 0005) pourra valider.

Le schéma détaillé, ses diagrammes et ses exemples sont dans le modèle de données.

Décision

Un supertype pour les mots, préfixes et suffixes

• Mots, préfixes et suffixes sont des unités lexicales. Ils partagent une table unite_lexicale, avec un discriminant nature, et deux sous-types exclusifs : mot et affixe.
• Compositions, relations étymologiques, sources et briques référencent toutes unite_lexicale. Un mot découvert peut donc redevenir un ingrédient (biologie + -iste) sans exception dans le modèle.

La langue est un contexte, pas une brique

• Une langue n'est pas une unité lexicale. Chaque unité appartient à exactement une langue.
• La langue a sa carte dans le codex, mais une brique ne peut, par construction, référencer qu'une unité lexicale : aucune langue ne se pose sur la table.
• Les langues forment une généalogie (langue_parente_id). Le MVP compte trois langues, sans variété : grec ancien, latin et français. Une forme tardive ou médiévale reste rattachée à sa langue, et la précision éventuelle va dans l'explication.
• Les noms affichés sont traduits par locale. Les codes restent internes (ADR 0006).

Un étymon est une unité d'une langue source

• Il n'y a pas de type « étymon » ni « racine ». Le grec gê est un mot du grec ancien.
• géo- est un préfixe du français, relié à gê par une relation forme_de_composition.
• philo- et -phile sont deux unités françaises distinctes, reliées au même grec phílos. Le codex les rapproche en remontant la relation, et chacune garde sa position.
• Un étymon qui n'est ni une brique ni le résultat d'une recette n'a pas de carte propre dans le codex. Il apparaît au verso des cartes qui en descendent et sur la carte de sa langue.

Formes, sens et translittérations séparés

• Une unité a une forme canonique et, si nécessaire, des allomorphes et des graphies anciennes. Aucune de ces formes ne crée une nouvelle brique : quand une recette emploie un allomorphe (phil- dans philanthrope), elle le déclare comme transformation.
• Le texte d'une forme est stocké sans trait d'union. La position vient de la nature de l'unité, conformément à la règle d'affichage des briques.
• Les gloses (« terre ») et les définitions actuelles appartiennent aux sens, et sont traduites par locale.
• Une translittération appartient à une forme et à une convention déclarée.

Homographes : deux unités, deux cartes

• Deux unités de même langue, de même nature et de même forme (a- « sans », du grec, et a- « vers », du latin ad-) sont des homographes : deux unités, deux briques, deux cartes.
• Le critère est l'origine. Même origine et sens différents : une unité avec plusieurs sens. Origines différentes : deux unités.
• Aucun numéro ne les distingue. Le joueur les reconnaît aux autres attributs de la carte : la glose affichée sur la brique et l'étymon visible au verso. Le validateur refuse deux homographes dont la glose ou l'étymon sont identiques.

Composition n-aire et relations binaires

• Une composition analyse un mot en parties ordonnées. Chaque partie désigne une unité, le sens mobilisé, la forme employée et son segment dans le mot résultat (pour le surlignage).
• Le sens littéral et les transformations (élision, voyelle de liaison, allomorphie…) appartiennent à la composition.
• Un mot peut avoir plusieurs compositions : une synchronique, jouable, et une historique, ou deux analyses « discutées ».
• Une relation étymologique relie une unité source à une unité cible, avec un type contrôlé : héritage, emprunt, dérivation, forme de composition, adaptation, apparentement. La composition n'en fait pas partie, car elle n'est pas binaire.

Tout ce qui est affirmé est un fait

• Unités, formes, sens, compositions et relations partagent le supertype éditorial fait. Il porte la confiance, l'état de relecture, les sources et la note de simplification.
• Les notes internes restent hors de l'artefact publié.

Couche ludique : points d'ancrage seulement

• Une brique référence une unité lexicale, la forme affichée et le sens affiché. Une unité a au plus une brique, et une brique une seule unité. Une recette référence une composition.
• Les cartes du codex sont dérivées des unités et des relations, pas stockées. Une unité a sa carte si et seulement si elle est référencée par une brique ou par le résultat d'une recette.
• Le détail de la couche ludique (recettes, raretés, plis, réserve) fera l'objet d'un travail séparé.

Versionnage par instantanés

Chaque publication est un instantané immuable. Le schéma ne porte pas de colonnes temporelles : les identifiants sont opaques et stables, et les changements de nature ou les suppressions passent par une migration explicite.

Options envisagées

Une table unique « brique » pour tout

Écartée : elle mélange faits et équilibrage (ADR 0009), duplique les formes grecques dans chaque brique et ne sait pas relier deux briques à un même étymon.

Un type « étymon » ou « racine » à part

Écarté : un étymon est déjà un mot ou un morphème d'une langue. Un type à part dupliquerait les formes, les sens et les sources, et forcerait à décider arbitrairement ce qui est « racine ».

La langue comme brique jouable

Écartée : la langue n'est pas un ingrédient d'un mot. Elle donne le contexte d'une forme. La poser sur la table brouillerait la distinction entre emprunt et composition.

Une seule brique « philo » dont la recette fixe la position

Écartée : préfixe et suffixe ont des formes, des sens et des couleurs différents. La position fait partie de l'identité de la brique.

Des tables séparées pour les mots et les affixes, sans supertype

Écartée : chaque composition, relation et brique aurait besoin de deux clés étrangères exclusives, ou d'une référence polymorphe impossible à contraindre.

Le libellé avec trait d'union comme donnée

Écarté : « géo- » mélange forme et rendu. Le trait d'union est une convention d'affichage, et une brique n'est jamais affichée en texte brut.

Une brique par forme, allomorphes compris

Écartée : philo- et phil- deviendraient deux briques, deux compteurs d'exemplaires et deux tirages dans les plis. Le joueur ne comprendrait pas pourquoi philo- ne suffit pas, et l'allomorphie cesserait d'être une transformation expliquée.

Des variétés de langue distinctes

Écartées pour le MVP : grec ancien et koinè, ou latin classique et médiéval, fragmenteraient le codex en cartes de langue peu remplies et multiplieraient le coût éditorial, sans différence perceptible pour le joueur.

Une carte pour chaque étymon

Écartée : le codex se remplirait de cartes obtenues sans découverte, ce qui diluerait la valeur de chaque fusion.

Des homographes numérotés

Écartés : un « a¹ » ou « a² » n'apprend rien au joueur. La glose et l'étymon suffisent à distinguer les deux cartes et portent un vrai contenu.

Conséquences

Positives

• Un même fait (gê → géo-) sert au codex, aux recettes et aux explications, sans copie.
• Mot comme ingrédient, chaînes de langues et analyses concurrentes sont possibles sans cas particulier.
• Toute affirmation est sourçable et relue de la même manière.
• La langue ne peut pas devenir une brique par erreur de saisie.
• Le modèle reste indépendant de tout choix de stockage.

Négatives

• Plus de tables qu'un dictionnaire de chaînes, et plus de saisie éditoriale : chaque brique demande au moins une unité, une forme, un sens et une relation vers sa source.
• Les sous-types exclusifs et l'absence de cycles demandent des contraintes que tous les stockages n'offrent pas. Le validateur de publication doit les vérifier.
• Le codex doit calculer ses cartes à partir des relations. La compilation du catalogue (ADR 0005) devra les précalculer pour le client.
• Deux homographes posent sur la table deux briques de même forme et de même couleur : seule la glose les distingue, et un mauvais choix donne un échec qui peut sembler injuste.
• Sans variété de langue, certaines précisions historiques (latin médiéval, formation savante moderne) ne passent que par l'explication.

Critères de réévaluation

Revoir le schéma après la saisie d'un premier lot réel de contenu, en particulier si :

• des cas fréquents ne rentrent pas dans le vocabulaire de relations ou de transformations ;
• la distinction entre affixe et élément de composition n'est d'aucune utilité ;
• des briques ont besoin de plusieurs formes jouables pour une même unité ;
• les joueurs confondent des homographes, ou demandent à collectionner les étymons ;
• un contenu réel exige de distinguer des variétés d'une même langue ;
• un cinquième type d'objet collectionnable (famille, écriture…) remet en cause le supertype.

• Statut : Proposé, partiellement remplacé par l'ADR 0022 : un fascicule publie désormais de 20 à 30 mots. Le rythme, les sources, la complétude et le reste de la publication restent en vigueur. Partiellement remplacé aussi par l'ADR 0032 : la fermeture porte sur les paires ordonnées de briques, la table n'en acceptant que deux. Partiellement remplacé enfin par l'ADR 0052 : une ressemblance de chaînes qui trompe peut être déclarée comme trompe-l’œil et expliquée ; les exclusions restent inchangées. Remplacé enfin par l’ADR 0060 pour les sources : Wikidata devient la seule source de vérité, les références savantes et le Wiktionnaire ne comptent plus, et les rôles reference et reperage disparaissent.
• Complète : ADR 0002 (sources et confiance), ADR 0004 (atteignabilité par fascicule), ADR 0005 (circuit d'édition), ADR 0013 (tables source et fascicule)

Contexte

Le modèle de données décrit les langues, mots, préfixes et suffixes, mais pas leur origine ni leur rythme d'arrivée. Deux questions restent ouvertes.

• D'où viennent les faits ? Le Wiktionnaire offre une couverture très large et des données déjà structurées (extraites par Wiktextract et diffusées sur kaikki.org). Mais ses étymologies sont inégales et rarement sourcées. Son texte est sous licence CC BY-SA 4.0 : tout contenu qui en dérive doit être redistribué sous la même licence. Les références savantes (TLFi, Bailly, Gaffiot, Chantraine…) sont plus sûres, mais aucune n'est sous licence libre : on peut les citer, pas les copier.
• Comment le catalogue grandit-il ? Un joueur qui a tout découvert doit recevoir de nouveaux mots. Chaque apport doit rester cohérent : toutes les briques nécessaires présentes, aucune combinaison réelle laissée sans réponse.

Décision

Le Wiktionnaire repère, les références attestent

• Le Wiktionnaire (français et anglais) est une source de repérage. Il sert à proposer des candidats : unités, formes, relations et compositions. Aucun de ses textes n'est copié dans le catalogue.
• Chaque import est un fichier daté, conservé hors du catalogue publié. Un fait proposé par un import naît à l'état brouillon.
• Les gloses, définitions, sens littéraux et explications sont rédigés par l'équipe.
• La licence du catalogue reste donc un choix libre de l'équipe, tranché depuis par l'ADR 0017 : CC BY-SA 4.0.

Sources de référence et niveaux de confiance

Une source a un rôle : reference (dictionnaire ou ouvrage qui fait autorité) ou reperage (Wiktionnaire, outils d'extraction). Liste de départ, extensible par l'équipe éditoriale :

Règles de publication :

• Le Wiktionnaire seul ne suffit jamais pour publier, quel que soit le niveau de confiance.
• Chaque lien entre un fait et une source indique l'entrée ou la page consultée, et l'édition utilisée.

Le fascicule, unité de publication du contenu

Le contenu arrive par fascicules, comme les grands dictionnaires qui paraissaient par livraisons successives. Le mot « pli » reste réservé au pli scellé que le joueur ouvre.

• Rythme : un fascicule environ tous les 30 jours. Ce délai est un paramètre d'équilibrage (ADR 0009).
• Taille : 20 à 40 mots par fascicule, mots croisés compris (voir plus bas). La fourchette est aussi un paramètre d'équilibrage.
• Contenu : un fascicule déclare la liste complète des unités dont il a besoin : ses mots, et tous les préfixes, suffixes et mots qui servent d'ingrédients à ses recettes. Les langues en découlent.
• Unicité : un mot n'est le résultat que d'un seul fascicule. Un préfixe, un suffixe ou un mot déjà publié peut être repris comme ingrédient par un fascicule suivant : c'est la même unité, avec le même identifiant, jamais une copie.
• Présentation au joueur : un fascicule ne dévoile jamais son contenu. Son annonce, sa fiche sur l'écran des plis et sa présentation n'affichent que des nombres : mots, préfixes, suffixes et langues, légendaires exclues (ADR 0015). Avant sa parution, même ces nombres restent cachés. Dans le codex, les silhouettes gardent leur piste de sens.
• Publication : chaque fascicule est une nouvelle version immuable du catalogue (ADR 0002), qui passe tout le circuit de l'ADR 0005.
• Plis : dès sa publication, le fascicule a son propre pli, qui porte sa jaquette et ne tire que parmi ses briques (ADR 0016). Le joueur peut fusionner des briques de fascicules différents.

Complétude : aucune combinaison réelle sans réponse

Un fascicule N n'est publiable que si les deux règles suivantes sont vraies sur l'ensemble des fascicules 1 à N :

1. Autonomie : tout ingrédient d'une recette du fascicule est publié, dans ce fascicule ou dans un fascicule précédent.
2. Fermeture : pour toute suite ordonnée de briques publiées, jusqu'au nombre maximal de briques sur la table, si une source de référence atteste un mot formé de ces éléments, ce mot est publié avec sa recette. La règle couvre aussi les mots déjà publiés utilisés comme ingrédients (biologie + -iste).

Conséquences pour l'édition :

• Un nouvel affixe peut créer des mots croisés avec les briques des anciens fascicules. Ils appartiennent au nouveau fascicule et comptent dans ses 20 à 40 mots. On choisit donc les affixes d'un fascicule en tenant compte de ce qu'ils ouvrent.
• La recherche des combinaisons candidates est outillée : un script parcourt les suites de briques publiées et interroge l'import du Wiktionnaire pour trouver les mots qui s'analysent ainsi. Chaque candidat est ensuite vérifié dans une source de référence. Une simple ressemblance de chaînes ne prouve jamais une combinaison (ADR 0003).
• Exclusion déclarée : une combinaison attestée peut être écartée si le mot est archaïque ou offensant. L'exclusion est enregistrée avec sa raison et relue. Le joueur qui la tente reçoit un retour honnête, jamais un échec qui laisserait croire que le mot n'existe pas. Un mot rare ou technique n'est pas une raison d'exclusion, pas plus qu'un mot emprunté en bloc dont les parties sont celles des briques (grec khronikós, de khrónos et -ikós) : l'un et l'autre sont publiés avec leur recette. Une simple ressemblance de chaînes (antique, du latin antiquus) ne forme pas une combinaison et n'appelle ni recette ni exclusion.

Suivi et correction

• À chaque nouveau fascicule, un nouvel import du Wiktionnaire est comparé au précédent. Un changement qui touche un fait déjà publié ouvre une tâche de revue, jamais une modification automatique.
• Une correction publie une nouvelle version et suit les migrations de l'ADR 0005.

Options envisagées

Importer le Wiktionnaire comme source de contenu

Écartée : le catalogue entier deviendrait CC BY-SA 4.0 par dérivation, les étymologies non sourcées entreraient dans le jeu, et une modification d'une page du Wiktionnaire pourrait changer un fait publié.

Importer seulement les données structurées du Wiktionnaire

Écartée : formes et relations extraites restent une adaptation de la base, soumise au partage à l'identique, et la vérification resterait nécessaire.

Publier en « probable » avec le Wiktionnaire seul

Écartée : le niveau de confiance deviendrait un reflet de la source disponible, plus du consensus. Le joueur n'aurait aucun moyen de le savoir.

Contenu publié en continu, mot par mot

Écartée : chaque ajout devrait passer seul la validation d'atteignabilité et de complétude, le rythme serait illisible pour le joueur, et les mots croisés arriveraient au hasard.

Mots croisés hors budget

Écartée : un affixe très productif (-logie) ferait exploser la taille d'un fascicule et le travail éditorial du mois.

Pas de règle de fermeture

Écartée : le joueur qui combine deux briques de fascicules différents pour former un mot réel recevrait un échec. Le jeu contredirait la langue.

Conséquences

Positives

• Tout fait publié repose sur une source de référence, et le Wiktionnaire accélère le travail sans en devenir l'autorité.
• La licence du catalogue reste un choix libre (CC BY-SA 4.0 depuis l'ADR 0017).
• Le joueur reçoit un apport régulier et cohérent : chaque fascicule se joue sans brique manquante.
• Les fusions entre fascicules sont encouragées et jamais punies par un faux échec.

Négatives

• Rédiger toutes les gloses, définitions et explications demande un vrai travail éditorial : environ 20 à 40 fiches par mois.
• Les références savantes sont souvent payantes ou consultables seulement en ligne : l'équipe doit y avoir accès.
• La règle de fermeture croît avec le catalogue : plus il y a de briques, plus un nouvel affixe ouvre de combinaisons à vérifier. Le script de candidats devient indispensable.
• Les exclusions déclarées demandent une réponse de jeu dédiée, à concevoir.
• Le rythme des plis (ADR 0012) doit être recalculé à chaque fascicule : un joueur actif doit pouvoir découvrir la plupart des mots d'un fascicule avant le suivant.

Critères de réévaluation

• Un fascicule ne peut pas être bouclé en 30 jours à cause de la rédaction ou de la vérification.
• La règle de fermeture impose plus de la moitié des mots d'un fascicule en mots croisés.
• Les joueurs actifs épuisent un fascicule en moins de 10 jours, ou n'en découvrent pas la moitié avant le suivant.
• L'équipe décide d'une licence libre compatible avec CC BY-SA : l'import direct du Wiktionnaire pourrait alors être reconsidéré. C'est le cas depuis l'ADR 0017, qui maintient toutefois le Wiktionnaire en source de repérage.

• Statut : Accepté, précisé par l'ADR 0027 : le secret tient à l'interface, pas aux fichiers publiés. Partiellement remplacé par l'ADR 0036 : la chance des légendaires est toujours affichée, même nulle ; le secret porte sur leur nombre et leur nature. Partiellement remplacé aussi par l’ADR 0043 : une légendaire trouvée n’a plus sa propre ligne de chance, un mot légendaire reste sans silhouette même quand sa légendaire est trouvée, et le compte des légendaires trouvées, briques et mots, s’affiche toujours, même à 0
• Remplace partiellement : ADR 0011, pour l'affichage des chances des briques légendaires inconnues
• Complète : ADR 0014 (fascicules dans le codex)

Contexte

Avec les fascicules (ADR 0014), le joueur veut savoir où il en est : quelles cartes appartiennent à quel fascicule, et combien il lui en reste à trouver. Le codex affichait jusqu'ici un compteur global et quelques silhouettes.

Mais un compteur exact dévoile tout, y compris le nombre de briques légendaires (forme : diamant). Or la découverte d'une légendaire doit rester une surprise : le joueur ne doit pas savoir combien il en existe, ni combien il lui en manque. L'ADR 0011 imposait d'afficher, sur l'écran des plis, la chance exacte de chaque brique, légendaires inconnues comprises, chacune avec sa silhouette. Cela révèle leur nombre.

Décision

Le codex s'organise par fascicule

• Chaque carte indique son fascicule. Une langue appartient au fascicule qui l'a introduite.
• Le codex propose un tri par fascicule, qui regroupe les cartes sous un titre par fascicule, et un filtre par fascicule.
• Chaque fascicule a son compteur de complétude (« 10 / 11 cartes »), avec une barre de progression. Toucher un fascicule n'affiche que ses cartes.
• Les compteurs des filtres par type suivent le fascicule choisi.

Des silhouettes pour ce qui reste à découvrir

• Toute carte encore inconnue d'un fascicule publié apparaît en silhouette, avec sa piste de sens et, pour une brique, sa rareté. Elle compte dans le compteur de son fascicule.

Les légendaires restent secrètes

• Une brique légendaire inconnue n'a ni carte, ni silhouette, et n'entre dans aucun compteur.
• Un mot qui exige une légendaire inconnue est traité de même, pour ne pas la trahir. Sa silhouette apparaît dès que la légendaire est trouvée.
• Une légendaire trouvée a sa carte, mais ne compte jamais dans les totaux : sinon le total changerait à sa découverte et trahirait les autres. Elle apparaît à part : « 1 légendaire trouvée », avec le diamant.
• Un fascicule est donc « complet » quand toutes ses cartes non légendaires sont découvertes.

Écran des plis : chances exactes, nombre caché

• Remplace, dans l'ADR 0011, l'obligation d'afficher la chance de chaque brique pour les légendaires inconnues.
• Les légendaires inconnues sont regroupées en une seule ligne : « Légendaires inconnues », avec le diamant et la somme exacte de leurs chances. Leur nombre n'est jamais affiché.
• Les chances par rareté, par type et pour chaque autre brique restent exactes et affichées. Une légendaire trouvée retrouve sa propre ligne.
• La garantie de nouveauté et le filet d'utilité ne changent pas.

Options envisagées

Compteurs exacts, légendaires comprises

Écartée : le joueur saurait combien de légendaires existent et combien il lui en manque. La surprise disparaît.

Aucun compteur

Écartée : le joueur ne saurait pas où il en est dans un fascicule, alors que c'est ce qui donne envie de le terminer.

Silhouette de légendaire sans compteur

Écartée : chaque silhouette dévoile une légendaire à venir.

Garder le détail des légendaires inconnues sur l'écran des plis

Écartée : une ligne par légendaire inconnue révèle leur nombre, et annule le secret gardé dans le codex.

Conséquences

Positives

• Le joueur voit sa progression par fascicule, et sait quand il l'a complété.
• Une légendaire reste une vraie surprise, dans le codex comme dans les plis.
• La transparence des chances est préservée : la probabilité d'obtenir une légendaire reste exacte et affichée.

Négatives

• « Complet » ne veut pas dire « tout trouvé » : il peut rester des légendaires. Le texte doit rester honnête et ne jamais annoncer qu'il ne reste plus rien.
• La garantie de nouveauté peut trahir l'existence d'au moins une légendaire : si toutes les autres briques sont connues, le message de garantie reste affiché. Le nombre, lui, reste caché.
• Un mot qui dépend d'une légendaire n'est visible qu'après elle : le validateur doit vérifier qu'aucun indice public (piste, lien, filiation) ne le dévoile avant.
• Depuis l'ADR 0027, les fichiers d'un fascicule paru sont publics : un joueur qui les lit peut y trouver ses légendaires. Le secret vaut pour l'interface : écrans, compteurs, silhouettes et manifestes.

Critères de réévaluation

• Les joueurs perçoivent le regroupement des légendaires comme un manque de transparence.
• Une règle de transparence sur les coffres à butin exige le détail par objet.
• Les tests montrent que « complet » avec des légendaires encore cachées est ressenti comme trompeur.

• Statut : Accepté, partiellement remplacé par l'ADR 0035 : le pli d'un fascicule ne tire que ses préfixes et ses suffixes, jamais un mot. Partiellement remplacé aussi par l’ADR 0043 : la garantie de nouveauté et le filet ne portent que sur les briques non légendaires du fascicule. Le reste du présent ADR reste en vigueur.
• Remplace partiellement : ADR 0011, pour le catalogue du tirage et le compteur de la garantie ; ADR 0012, pour le compteur du filet d'utilité
• Complète : ADR 0014 (fascicules), ADR 0015 (légendaires secrètes)

Contexte

Jusqu'ici, un pli tirait une brique dans tout le catalogue, et sa jaquette tournait parmi dix modèles selon le numéro du pli. Avec les fascicules (ADR 0014), deux besoins apparaissent :

• donner une identité à chaque fascicule, visible à chaque ouverture ;
• laisser le joueur choisir ce qu'il cherche : les briques nouvelles d'un fascicule récent, ou des exemplaires d'un ancien fascicule pour refaire sa réserve.

Avec un seul catalogue, plus il y a de fascicules, moins un pli a de chances de donner une brique du fascicule qui intéresse le joueur.

Décision

Une jaquette par fascicule

• Chaque fascicule a sa propre jaquette. Tous les plis de ce fascicule la portent.
• La jaquette ne dit que le fascicule, que le joueur a choisi. Ni son motif ni sa couleur ne trahissent la brique tirée, sa rareté ou sa langue. La palette reste limitée aux neutres et à l'Ambre.
• Les dix jaquettes existantes sont attribuées aux fascicules n° 01 à 10, dans l'ordre : Rosette, Argile, Aleph, Boustrophédon, Routes des mots, Arbre des langues, Lapidaire, Casse, Lettrine, Palimpseste. Chaque fascicule suivant demande une jaquette nouvelle.

Choisir un fascicule, puis ouvrir son pli

• L'écran des plis commence par le choix d'un fascicule parmi ceux qui sont parus. Chaque fascicule y montre sa jaquette, ses briques connues (légendaires inconnues exclues, ADR 0015) et les exemplaires en réserve.
• Une fois le fascicule choisi, l'écran d'ouverture s'affiche. Le joueur peut revenir au choix à tout moment, sauf pendant une ouverture.
• Le joueur peut ouvrir le pli de n'importe quel fascicule paru, à tout moment, en particulier pour refaire sa réserve d'anciennes briques.
• L'énergie reste unique : une charge ouvre un pli, quel que soit le fascicule.

Catalogue d'un pli

• Remplace, dans l'ADR 0011, le tirage « dans tout le catalogue du pli » : un pli tire uniquement parmi les briques de son fascicule, c'est-à-dire ses briques nouvelles et les briques qu'il reprend comme ingrédients.
• Poids, raretés, doublons, plafond et encre ne changent pas. Les chances affichées sont celles du fascicule choisi.

Garantie et filet par fascicule

• Garantie de nouveauté : le compteur de 6 plis se tient par fascicule. Il ne porte que sur les briques inconnues de ce fascicule.
• Filet d'utilité : le compteur de 5 plis se tient par fascicule, et la brique utile garantie est choisie parmi ses briques. Si aucune brique du fascicule ne peut rendre une découverte possible, l'écran le dit et invite à choisir un autre fascicule.

Options envisagées

Jaquette du dernier fascicule paru, tirage dans tout le catalogue

Écartée : le joueur ne choisit rien, et plus le catalogue grandit, moins il a de chances d'obtenir une brique précise.

Rotation des jaquettes des fascicules parus selon le numéro du pli

Écartée : la jaquette ne dirait plus rien du contenu, et l'identité de chaque fascicule se perdrait.

Garantie et filet communs à tous les fascicules

Écartés : un joueur pourrait remplir le compteur sur un fascicule déjà complet, puis voir la garantie profiter à un autre, ou l'inverse. Un compteur par fascicule reste lisible.

Conséquences

Positives

• Chaque fascicule a une identité visible dans le codex, sur l'écran des plis et à chaque ouverture.
• Le joueur choisit ce qu'il cherche, et peut refaire sa réserve d'anciennes briques sans subir la taille du catalogue.
• La probabilité d'une brique reste stable quand de nouveaux fascicules paraissent.

Négatives

• Une étape de plus avant chaque ouverture.
• Le rythme calculé dans l'ADR 0012 (22 plis en médiane sur un catalogue unique) doit être recalculé par fascicule.
• Une brique reprise par plusieurs fascicules s'obtient dans chacun d'eux : ses chances réelles dépendent des choix du joueur.
• Au-delà de dix fascicules, chaque nouveau fascicule demande une jaquette nouvelle.

Critères de réévaluation

• Les joueurs trouvent l'étape de choix lourde, ou ouvrent presque toujours le même fascicule.
• Le rythme par fascicule s'écarte nettement de la cible (un joueur actif doit pouvoir découvrir l'essentiel d'un fascicule avant le suivant).
• Le filet renvoie souvent vers « un autre fascicule » : il faudrait alors un filet commun.

• Statut : Accepté
• Portée : tout le dépôt, le futur catalogue publié et l'application
• Complète : ADR 0014 (licence du catalogue, laissée ouverte)

Contexte

• Le dépôt est public, mais n'avait encore aucune licence : par défaut, tous les droits sont réservés, et personne ne peut ni réutiliser ni contribuer en sécurité.
• L'ADR 0014 laissait ouverte la licence du catalogue. Aucun texte du Wiktionnaire n'y est copié, donc le choix est libre.
• Le dépôt mélange trois natures d'œuvres : du code (démos HTML, CSS, JavaScript, scripts Python, workflows), du contenu (dossier de conception, ADR, puis gloses, explications et relations du catalogue) et une identité (nom, logo, charte).
• L'intention : un projet ouvert, que chacun peut étudier, modifier et même exploiter, mais qu'aucun clone fermé ne peut s'approprier. Le jeu sera servi en ligne (ADR 0001, ADR 0007) : une licence qui ne couvre que la distribution de binaires ne suffit pas.

Décision

Trois périmètres, trois régimes

• Titulaire des droits : Guillaume MARTINEZ (© 2026). Les contributions sont reçues sous la licence du périmètre qu'elles touchent.
• L'AGPL oblige quiconque sert une version modifiée du jeu en ligne à publier ses sources sous la même licence.
• La CC BY-SA oblige tout dérivé du contenu à créditer ÉtymoLogique et à rester sous CC BY-SA 4.0.
• Un fork peut reprendre le code et le contenu, mais doit changer de nom et de logo.
• En cas de doute sur un fichier, les pages HTML relèvent du code pour leur structure et leurs scripts, et du contenu pour leurs textes.

Pas de clause non commerciale

L'usage commercial reste permis : la protection vient du copyleft, pas d'une interdiction. Le MVP ne comporte aucun paiement (ADR 0008), et cette décision n'en introduit pas.

Effet sur les sources

• Le catalogue sous CC BY-SA 4.0 devient compatible avec le texte du Wiktionnaire, sous la même licence.
• Cela remplit un critère de réévaluation de l'ADR 0014, sans changer sa décision : le Wiktionnaire reste une source de repérage, parce que ses étymologies sont rarement sourcées et qu'elles peuvent changer. La licence n'est plus un obstacle, la fiabilité l'est toujours. Un import direct demanderait un nouvel ADR.
• Les références savantes (TLFi, Bailly, Gaffiot…) restent citées, jamais copiées.

Options envisagées

Licences permissives (MIT, Apache 2.0, CC BY)

Écartées : n'importe qui pourrait reprendre le jeu et son catalogue dans une application fermée, ce que le projet veut précisément éviter.

Clause non commerciale (PolyForm Noncommercial, CC BY-NC-SA)

Écartée : ces licences ne sont pas libres au sens de l'OSI ni de la Free Software Foundation. La notion de « commercial » est floue (un site avec publicité, une école privée…), elle décourage les contributions, et CC BY-NC-SA n'est pas compatible avec le Wiktionnaire.

AGPL pour le code, CC BY-NC-SA pour le contenu

Écartée : elle cumule le flou du non-commercial et l'incompatibilité avec le Wiktionnaire, alors que le catalogue est justement ce qu'un clone voudrait copier.

GPL 3.0 plutôt qu'AGPL

Écartée : la GPL ne s'applique qu'à la distribution. Un service en ligne modifié pourrait garder ses sources fermées.

Tous droits réservés, code visible

Écartée : personne ne pourrait contribuer ni réutiliser, ce qui contredit l'ouverture souhaitée.

Conséquences

Positives

• Le projet est libre, et aucun dérivé, pas même un service en ligne, ne peut se fermer.
• Le catalogue peut accueillir des contributions et s'aligner un jour sur le Wiktionnaire, sans conflit de licence.
• Le nom protège l'identité : un joueur ne confond pas un fork avec le jeu.

Négatives

• L'AGPL rebute certaines entreprises et certains contributeurs, et interdit d'intégrer le code dans un produit fermé.
• Le double régime oblige à savoir si un fichier relève du code ou du contenu.
• Un concurrent peut exploiter commercialement un fork, s'il le garde ouvert et le renomme.
• Le titulaire seul ne pourra relicencier les contributions extérieures sans l'accord de leurs auteurs.

Critères de réévaluation

• Un modèle économique futur (paiements, ADR 0008) exige une double licence ou un accord de contribution.
• Un partenaire éditorial (dictionnaire, institution) ne peut fournir du contenu que sous une autre licence.
• Un fork fermé ou trompeur apparaît malgré la licence : il faudra alors envisager un dépôt de marque.

• Statut : Proposé, en partie repris par l'ADR 0020, accepté : les sabliers gratuits entrent dans le MVP, coûtent 1 goutte et avancent la recharge d'une énergie à deux charges. La boutique payante est abandonnée (15 octobre 2026) : aucun paiement dans l'application, et ce qui s'y rapporte ci-dessous ne s'applique plus. Un sablier s'échange désormais contre 10 gouttes, par un geste distinct ; le plafond de 12 sabliers par 24 h est supprimé, pour l'usage comme pour l'échange, le plafond de 36 sabliers détenus est supprimé, et le temps perdu n'est plus annoncé : voir l'ADR 0039.
• Portée : sabliers seulement. Les ADR 0008 et 0011 restent en vigueur : aucun paiement.
• Remplacerait partiellement, une fois accepté : ADR 0008, pour l'interdiction de tout paiement et de tout achat de recharge ; ADR 0011, pour l'usage de l'encre, qui pourrait aussi s'échanger contre des sabliers
• Complète : ADR 0007 (achats et usage sous autorité serveur), ADR 0009 (nouveaux paramètres d'équilibrage), ADR 0010 (données de paiement)

Contexte

Le jeu devra financer son contenu éditorial et son serveur. L'ADR 0008 écarte toute monétisation du MVP et demande qu'une future boutique fasse l'objet d'une décision couvrant l'éthique, la conformité, le contrôle parental, la transparence des probabilités et le remboursement. L'ADR 0011 ajoute les règles sur les coffres à butin.

Le levier le plus lisible est le temps d'attente entre deux plis : une charge d'énergie, rechargée en douze heures (hypothèse de l'ADR 0008). Il faut le rendre accélérable sans vendre de tirage, sans casser la rareté des briques (ADR 0012), et sans que le jeu ne se remplisse de fausse urgence.

Décision

Le sablier

• Un sablier fait avancer la recharge d'énergie d'une heure.
• Il ne s'utilise que pendant une recharge. Quand l'énergie est pleine, il est inutilisable : l'énergie ne dépasse jamais sa capacité.
• S'il reste moins d'une heure, le sablier termine la recharge. Avant de confirmer, l'interface indique le temps non utilisé (« 42 min seront perdues »).
• Le sablier achète du temps, jamais un tirage. Il ne change ni les chances, ni la garantie de nouveauté, ni le filet d'utilité, ni le contenu du pli. Il n'a aucun effet sur les fusions, que l'énergie ne limite jamais.

Plafonds

• Le plafond quotidien compte tous les sabliers, gratuits comme achetés.
• Un sablier gagné au-delà du plafond de détention reste en attente jusqu'à ce qu'une place se libère ; aucun lot ne peut être acheté s'il ferait dépasser ce plafond.
• Ces valeurs sont des paramètres versionnés d'équilibrage (ADR 0009).
• Avec un pli toutes les 12 h et le plafond atteint chaque jour, le rythme de découverte peut au plus doubler : le catalogue de démonstration se complète alors en environ six jours au lieu d'onze (22 plis en médiane, ADR 0012).

Obtenir des sabliers sans payer

• Certains jalons donnent un sablier en plus de leur pli.
• Le défi quotidien peut en donner un.
• L'encre s'échange contre un sablier, au même taux qu'un indice dans la démonstration (10 gouttes). L'encre reste non achetable et non convertible en argent.

La boutique n'est donc qu'un raccourci : tout ce qu'elle vend s'obtient aussi en jouant, et le jeu reste complet sans rien acheter.

Boutique

• On achète des lots de sabliers en euros, sans monnaie intermédiaire.
• Chaque lot affiche son prix TTC et son prix par sablier. Le prix par sablier baisse peu d'un lot à l'autre, sans « bonus » mis en avant.
• Aucune offre limitée dans le temps, aucun compte à rebours, aucune notification ni relance commerciale, aucune proposition d'achat affichée au moment d'une révélation ou d'un échec.
• La boutique est une entrée discrète de l'écran des plis. Le bouton « Utiliser un sablier » reste secondaire face au temps de recharge, toujours affiché avec l'heure du prochain pli.
• Les prix sont fixés dans un ADR ou un paramètre ultérieur.

Conformité et mineurs

• Un sablier est déterministe, mais il accélère l'accès à un tirage aléatoire. Avant l'ouverture de la boutique, une revue juridique est faite pour chaque territoire (en particulier les règles belges et néerlandaises sur les coffres à butin). La boutique est désactivable par territoire, sans effet sur le reste du jeu.
• Les chances, la garantie et le filet restent affichés en permanence (ADR 0011).
• Sur les magasins d'applications, le contrôle parental et la facturation de la plateforme s'appliquent. Sur le web, un plafond de dépense mensuel par défaut est proposé, modifiable par le titulaire du moyen de paiement.
• Aucun ciblage, aucune offre personnalisée selon le comportement de jeu.

Remboursement

• Un lot dont aucun sablier n'a été utilisé est remboursable pendant 14 jours.
• Avant le premier usage d'un sablier acheté, le joueur confirme qu'il renonce au droit de rétractation pour ce sablier.
• Un sablier remboursé est retiré de la réserve ; si le solde ne le permet pas, le remboursement porte sur les sabliers restants.

Autorité serveur et données

• Le serveur valide chaque reçu d'achat avant de créditer les sabliers ; le crédit est idempotent.
• Utiliser un sablier est une commande idempotente et transactionnelle : décrément du solde, avance de la recharge et mise à jour du plafond quotidien réussissent ou échouent ensemble (ADR 0007).
• Les données de paiement restent chez le prestataire ; le jeu ne conserve que l'identifiant de transaction et le lot (ADR 0010).
• Un joueur qui a payé ne doit pas perdre ses sabliers avec son profil invité : la boutique ne s'ouvre qu'après la décision sur la récupération de progression prévue par l'ADR 0007.

Options envisagées

Monnaie premium

Écartée : elle masque le prix réel, pousse à acheter des soldes inutilisables et reste interdite par l'ADR 0008.

Sabliers sans plafond quotidien

Écartés : un joueur pourrait vider un fascicule en une soirée, ce qui casse la rareté des briques, et la boutique deviendrait un achat de tirages en série.

Vendre des plis ou des briques

Écarté : c'est un coffre à butin payant, et vendre une brique contredit « aucune brique impossible à obtenir sans payer ». Le contenu reste de plus sous CC BY-SA (ADR 0017).

Publicité récompensée

Écartée : elle interrompt le rythme de réflexion et exige un suivi publicitaire incompatible avec l'ADR 0010.

Abonnement

Non retenu pour l'instant : il crée une attente de contenu régulier que le rythme des fascicules ne garantit pas encore.

Cosmétiques et achat de soutien

Reportés : jaquettes alternatives, thèmes ou achat unique de soutien feront l'objet d'une décision séparée.

Conséquences

Positives

• Une source de revenus simple à comprendre : du temps, à prix affiché.
• Les chances, la garantie et le filet ne dépendent jamais d'un paiement.
• Le joueur qui ne paie pas a accès aux mêmes briques, au même contenu et même aux sabliers.
• Le plafond quotidien borne à la fois la dépense et l'accélération du rythme.

Négatives

• Même plafonné, le sablier rapproche le jeu des mécaniques d'attente payante : la perception « payer pour attendre moins » est un risque pour l'image.
• Il faut un compte ou une récupération de progression, une revue juridique par territoire et une intégration de paiement.
• Deux nouveaux compteurs à expliquer (solde, plafond quotidien).
• L'équilibrage doit être simulé avec et sans sabliers.

Critères de réévaluation

• Plus de la moitié du revenu vient de moins de 2 % des joueurs, ou des joueurs atteignent le plafond de dépense chaque mois.
• Le taux d'abandon après complétion d'un fascicule augmente chez les joueurs qui utilisent des sabliers.
• Les joueurs qui ne paient pas jugent l'attente plus pénible après l'ouverture de la boutique.
• Une évolution légale sur les coffres à butin ou les achats intégrés dans un territoire ciblé.

• Statut : Accepté, partiellement remplacé par l'ADR 0020 : chaque pli rapporte aussi 2 gouttes de base, brique nouvelle comprise, et l'indice coûte 30 gouttes. Les bonus de doublon restent régis par le présent ADR.
• Remplace partiellement : ADR 0012, pour la valeur d'un doublon sous le plafond, qui ne rapportait qu'un exemplaire ; ADR 0011, pour la source de l'encre
• Complète : ADR 0018 (échange d'encre contre un sablier, proposé)

Contexte

Depuis l'ADR 0012, un doublon ajoute un exemplaire à la réserve, et l'encre ne vient que d'un exemplaire reçu alors que la brique en a déjà 5. Or chaque découverte consomme des exemplaires : une brique atteint rarement le plafond.

Une simulation de 5 000 parties sur le catalogue de démonstration (réserve de départ 4 × 2, deux fascicules, joueur qui découvre dès que possible) le confirme : le joueur termine la démo en 20 plis en médiane, et 78 % des parties ne rapportent aucune goutte. Les indices, et demain l'échange contre un sablier, sont donc hors de portée, et l'encre affichée à l'écran reste à zéro sans explication.

Décision

Tout doublon rapporte de l'encre, en plus de son effet sur la réserve.

• Le barème de la réserve pleine (ADR 0011) ne change pas. Sous le plafond, le doublon rapporte la moitié de ce barème, puisqu'il donne aussi un exemplaire.
• Une brique nouvelle ne rapporte pas d'encre : elle apporte déjà la découverte.
• L'indice coûte toujours 10 gouttes.
• La révélation et l'historique affichent les deux gains : « +1 exemplaire · ×3 · +1 goutte ».
• Les deux barèmes sont des paramètres versionnés d'équilibrage (ADR 0009). L'encre reste non achetable et non convertible en argent.

Rythme visé

Même simulation, avec la nouvelle règle :

Retenu : le demi-barème. Il donne environ un indice tous les dix plis, et au moins un indice à 90 % des joueurs sur la démo. Le barème complet rendrait les indices trop fréquents. La simulation ne dépense pas l'encre : un joueur qui prend des indices découvre plus vite, sans changer le nombre de plis requis par le filet.

Options envisagées

Garder l'encre au-delà du plafond seulement

Écartée : la plupart des joueurs ne voient jamais l'encre servir, et l'écran affiche une ressource qui reste à zéro.

Donner de l'encre à chaque découverte

Écartée : l'encre deviendrait une récompense de la réussite, alors qu'elle doit consoler le hasard du pli. Elle ferait aussi doublon avec le plaisir de la découverte.

Baisser le coût de l'indice

Écartée : sans source régulière d'encre, même un indice à 2 gouttes resterait inaccessible pour la plupart des joueurs.

Barème complet sous le plafond

Écarté : environ deux indices tous les dix plis, ce qui affaiblit la déduction.

Conséquences

Positives

• Un doublon n'est plus jamais « juste » un exemplaire : il fait toujours progresser quelque chose de visible.
• Les indices deviennent accessibles à tous les joueurs, à un rythme mesuré.
• L'échange d'encre contre un sablier (ADR 0018) aurait une source réelle.

Négatives

• Deux barèmes à expliquer au lieu d'un.
• L'encre circule davantage : il faudra surveiller le nombre d'indices utilisés par découverte.
• Le rythme devra être recalculé à chaque nouveau fascicule, comme les autres paramètres des plis.

Critères de réévaluation

• Plus d'un indice utilisé pour trois découvertes en moyenne : baisser le demi-barème ou augmenter le coût de l'indice.
• Des joueurs actifs qui n'ont pas pu prendre un indice après dix plis : relever le barème.

• Statut : Accepté, partiellement remplacé par l'ADR 0038 : le prix de l’indice croît avec son niveau (5, 10, 20, 40 et 80 gouttes) ; et par l'ADR 0039 : un sablier s'échange à part contre 10 gouttes, le plafond de 12 sabliers par 24 h est supprimé, pour l'usage comme pour l'échange, le plafond de 36 sabliers détenus est supprimé, et la feuille remplit l'énergie sans annoncer de temps perdu. Le reste du présent ADR reste en vigueur.
• Remplace partiellement :
  • ADR 0008, pour la capacité d'énergie (une charge) et pour l'interdiction d'avancer la recharge, qui ne vaut plus que pour les paiements ;
  • ADR 0011, pour l'usage de l'encre (indices seulement) et le prix de l'indice ;
  • ADR 0018, pour les sabliers gratuits, qui entrent dans le MVP, et leur prix en encre ; la boutique payante reste proposée pour après le MVP ;
  • ADR 0019, pour l'encre d'un pli qui donne une brique nouvelle et pour le prix de l'indice.

Contexte

Avec une seule charge rechargée en 12 h, un joueur qui ne vient qu'une fois par jour perd une charge sur deux : la recharge s'arrête dès que la charge est pleine, et il n'ouvre qu'un pli par jour au lieu de deux.

L'encre, depuis l'ADR 0019, sert aux indices. Nous voulons qu'elle serve aussi à gagner du temps, et garantir à un joueur qui ne paie pas au moins un pli offert tous les 3 jours grâce à l'encre changée en sabliers. Avec le barème de l'ADR 0019 (environ 1 goutte par pli) et un sablier à 10 gouttes, il faudrait près de 120 plis pour gagner un pli.

Décision

Deux plis en attente

• L'énergie compte 2 charges au plus. Une charge revient toutes les 12 h.
• La recharge tourne tant que l'énergie est sous 2. Quand les deux charges sont prêtes, le temps s'arrête et l'interface affiche « 2 / 2 : deux plis prêts », sans compte à rebours.
• Ouvrir un pli consomme une charge. Si l'énergie était pleine, la recharge repart de zéro ; sinon, la recharge en cours continue.
• Un joueur qui vient une fois par jour ouvre donc deux plis, comme celui qui vient deux fois. Le rythme maximal ne change pas : deux plis par jour.
• La capacité et la durée restent des paramètres d'équilibrage (ADR 0009).

Encre gagnée à chaque pli

Chaque pli rapporte donc au moins 2 gouttes. Les bonus de doublon de l'ADR 0019 et le barème de la réserve pleine de l'ADR 0011 s'ajoutent à cette base.

Sabliers gratuits dans le MVP

• Un sablier fait avancer d'une heure la recharge en cours. Il coûte 1 goutte. Certains jalons en donnent aussi.
• Il ne s'utilise que si l'énergie est sous 2. Le temps qui dépasse la charge en cours passe à la suivante ; il n'est perdu que si l'énergie atteint 2, et l'interface l'annonce avant de confirmer.
• Les plafonds de l'ADR 0018 s'appliquent : 12 sabliers utilisés par 24 h glissantes, 36 détenus au plus.
• Le sablier ne change ni les chances, ni la garantie, ni le filet. L'achat de sabliers contre de l'argent reste régi par l'ADR 0018, proposé, et n'est pas dans le MVP.

Indice

Un indice coûte 30 gouttes, soit l'équivalent de 30 sabliers, environ deux plis et demi. Le joueur choisit entre comprendre plus vite et ouvrir plus de plis.

Garantie du pli offert

Un joueur qui vient au moins une fois par jour ouvre ses 2 plis quotidiens, soit 6 plis en 3 jours. Il gagne au moins 6 × 2 = 12 gouttes, soit 12 sabliers, soit une charge de 12 h : au moins un pli offert tous les 3 jours, sans payer, par construction.

Simulation de 5 000 parties sur le catalogue de démonstration (réserve de départ 4 × 2, deux fascicules, joueur qui découvre dès que possible et change toute son encre en sabliers) :

L'encre gagnée pendant la démo (59 gouttes en médiane) permet aussi environ deux indices, si le joueur les préfère aux sabliers.

Options envisagées

Garder une seule charge

Écartée : elle pénalise le joueur qui vient une fois par jour et l'incite à revenir à heure fixe, ce qui ressemble à une fausse urgence.

Trois charges ou plus

Écartée pour l'instant : le joueur pourrait accumuler et ouvrir une longue série de plis, ce qui accélère le remplissage du codex et affaiblit le rituel.

Garantir le pli offert par le hasard des doublons seulement

Écartée : l'encre des doublons varie trop d'une partie à l'autre, et la garantie ne serait qu'une moyenne.

Sablier à 10 gouttes avec une base plus forte

Écartée : il faudrait 20 gouttes par pli, et tous les prix d'encre deviendraient difficiles à lire. Un sablier à 1 goutte donne une règle simple : une goutte, une heure.

Indice à 10 gouttes

Écarté : avec environ 3 gouttes par pli, le joueur aurait un indice tous les trois plis, ce qui affaiblit la déduction.

Conséquences

Positives

• Le joueur n'a plus besoin de revenir deux fois par jour pour ne rien perdre.
• L'encre a toujours une utilité immédiate et lisible : une goutte, une heure.
• Le pli offert tous les 3 jours est garanti par la règle, pas par la chance.
• La future boutique ne vend que ce qu'on gagne déjà en jouant.

Négatives

• Le codex se remplit plus vite : environ 7,5 jours au lieu de 10 sur la démo si toute l'encre devient des sabliers. Le rythme doit être recalculé par fascicule.
• L'indice coûte trois fois plus qu'avant : il faudra vérifier que les joueurs bloqués y ont encore accès.
• L'écran des plis affiche un compteur de plus (sabliers).

Critères de réévaluation

• Des joueurs qui viennent chaque jour mais n'obtiennent pas un pli offert tous les 3 jours : revoir la base d'encre ou le prix du sablier.
• Un fascicule complété nettement plus vite que prévu : réduire la base d'encre ou relever le prix du sablier.
• Des joueurs bloqués qui ne prennent jamais d'indice faute d'encre : baisser le prix de l'indice.

• Statut : Accepté
• Portée : logo, icône des pages, navigation du dossier et future application
• Complète : ADR 0017 (le logo reste réservé, hors des licences libres)

Contexte

• Le dossier affichait déjà un sceau « ÉL » : une tuile Corail inclinée, avec une ombre dure et des initiales en monospace. Ce sceau n'avait jamais été décidé comme logo, ni décrit.
• L'ADR 0017 réserve le nom et le logo : il faut savoir précisément ce qui est protégé.
• Dix pistes ont été comparées sur la page de travail du logo : sceau affiné, deux briques, trait d'union, accent aigu, miroir des écritures, racine, casse d'imprimerie, guillemets, généalogie d'une lettre et ligature ÉL. Chacune a été vue en grand, en logo horizontal, en nocturne, en monochrome et à 64, 32 et 16 px.

Décision

Le logo d'ÉtymoLogique est le sceau ÉL affiné (piste 01 de la page de travail).

Symbole

• Une tuile carrée à coins arrondis : rayon égal à 27 % du côté (12 pour 44).
• Aplat Corail (--c-action), bordure Encre (--fixed-ink) d'environ 5 % du côté.
• Ombre dure décalée d'environ 11 % du côté en x et en y, sans flou : Encre sur fond clair, Crème à 28 % (--dark-shadow) sur fond sombre.
• Inclinaison de −6°. Au survol, le sceau pivote jusqu'à +8° avec l'easing --ease-spring, et reste immobile sous prefers-reduced-motion.
• Les initiales ÉL, en serif gras (--serif), toujours en Encre fixe : jamais en blanc ni en Crème sur le Corail.

Logo horizontal

• Le sceau, suivi de « ÉtymoLogique » en serif gras, en Encre (--ink), avec un espace égal à environ un tiers du côté du sceau.
• Le nom s'écrit toujours avec un É majuscule accentué et un L majuscule.

Déclinaisons

• Couleur : sur Papier, Crème, Encre ou Nuit uniquement, jamais sur une couleur de ressource.
• Monochrome : tuile Crème, bordure, initiales et ombre en Encre (ou l'inverse sur fond sombre).
• Où le monochrome s'impose : sur la bande Corail du pied de page (un Corail sur Corail disparaîtrait) et sur la face des plis, dont la palette se limite aux neutres et à l'Ambre (ADR 0016).
• Taille minimale : 16 px pour le symbole seul, 24 px de haut pour le logo horizontal.
• Icône des pages : docs/assets/logo.svg, référencée par toutes les pages du dossier.

Interdits

• Pas d'autre couleur que le Corail pour la tuile, pas de dégradé, pas d'ombre colorée ni floue.
• Pas de déformation, pas d'autre inclinaison au repos, pas d'initiales en monospace ou en sans.
• Le sceau Ambre des plis reste un objet de jeu distinct : il est rond, et ce n'est pas le logo.

Options envisagées

Deux briques (étymo- / -logique)

Elle raconte bien la fusion, mais emprunte les couleurs du préfixe et du suffixe, ce qui leur donne un deuxième sens, et elle se lit mal à 16 px.

Trait d'union en brique Corail

L'idée est forte, mais le trait d'union disparaît dès 32 px. Il faudrait redessiner les proportions, sans garantie de lisibilité.

Miroir des écritures (É / Э)

Elle parle explicitement des langues, mais fait de Palimpseste, la couleur des langues, une couleur de marque.

Généalogie d'une lettre et ligature ÉL

Ce sont les pistes les plus originales et les plus nettes, mais elles rompent avec le sceau déjà présent sur toutes les pages. La généalogie demande en plus une explication.

Accent aigu, racine, casse d'imprimerie, guillemets

Elles sont trop courantes (accent, arbre), trop proches d'autres jeux (Scrabble), trop ambiguës (les chevrons ressemblent aux boutons d'un lecteur) ou illisibles en icône.

Conséquences

Positives

• Le logo garde la continuité avec le dossier existant : le changement est un affinage, pas une rupture.
• Il est très lisible en petit, et se décline en monochrome sans perte.
• Le Corail reste la seule couleur de marque, conformément à la charte.

Négatives

• Les initiales seules ne disent rien des langues : c'est le nom et le jeu qui portent l'étymologie.
• Les initiales sont encore composées avec les polices système de la charte. Avant toute publication hors du dossier (magasin d'applications, impression), le sceau devra être vectorisé à partir d'une police sous licence libre.

Critères de réévaluation

• Un test auprès de joueurs montre que le sceau est confondu avec un autre jeu ou une autre marque.
• La vectorisation dans une police libre dénature le dessin des initiales.
• Une identité propre à l'application (icône de magasin, écran de lancement) exige un symbole plus distinctif.

• Statut : Accepté, partiellement remplacé par l’ADR 0054 : les dix premiers fascicules sont plus gros et hebdomadaires ; le reste reste en vigueur à partir du onzième
• Remplace partiellement : ADR 0014, pour la taille d'un fascicule (20 à 40 mots) ; le rythme, les sources, la complétude et le reste de la publication restent en vigueur.
• Complète : ADR 0012 et ADR 0020 (rythme de découverte)

Contexte

L'ADR 0014 fixe de 20 à 40 mots par fascicule, un fascicule environ tous les 30 jours. Un état des lieux du Wiktionnaire montre que le corpus n'est pas une contrainte : des milliers de mots formés par préfixe ou suffixe, de quoi publier des centaines de fascicules (potentiel d'évolution). La question est donc : combien de mots un joueur peut-il découvrir en un mois ?

• Sur le catalogue de démonstration (9 mots), il faut environ 20 plis en médiane pour tout découvrir (ADR 0020), soit un peu plus de 2 plis par mot : chaque découverte consomme un exemplaire de chaque brique utilisée (ADR 0012).
• Un joueur assidu ouvre 2 plis par jour, plus un pli offert au moins tous les 3 jours grâce aux sabliers : environ 70 à 80 plis par mois.

En extrapolant linéairement :

Au-delà de 30 mots, un joueur assidu ne peut plus compléter un fascicule avant la parution du suivant : les fascicules s'empilent et le codex devient une dette.

Décision

• Un fascicule publie de 20 à 30 mots, mots croisés compris.
• Le rythme ne change pas : un fascicule environ tous les 30 jours (ADR 0014).
• Les deux valeurs restent des paramètres d'équilibrage (ADR 0009) : elles se recalculent par simulation sur chaque fascicule, avant publication.
• La fermeture (ADR 0014) s'applique toujours. Avec un plafond de 30 mots, les affixes très productifs (-able, -ment, dé-, in-) doivent être introduits quand peu de mots de base publiés peuvent les recevoir, pour que les mots croisés tiennent dans le plafond.

Options envisagées

Garder 20 à 40 mots

Écartée : à 40 mots, il faut plus d'un mois pour compléter un fascicule, même en jouant chaque jour.

Environ 100 mots par mois

Écartée : environ trois mois pour compléter un fascicule, et 3 à 4 mots à sourcer chaque jour pour l'équipe éditoriale.

Environ 100 mots tous les 60 à 90 jours

Écartée : même volume par mois, mais une attente trop longue entre deux nouveautés et un codex dont la progression se voit mal (100 silhouettes d'un coup).

Conséquences

Positives

• Un joueur assidu peut compléter chaque fascicule dans le mois, avec quelques jours de marge.
• La charge éditoriale reste d'environ un mot sourcé par jour.
• La complétude d'un fascicule (« 24 / 27 cartes ») reste lisible dans le codex.

Négatives

• Le choix des affixes d'un fascicule est plus contraint : un affixe qui ouvre trop de mots croisés doit attendre.
• Un joueur occasionnel ne complétera pas tous les fascicules dans le mois : les plis des anciens fascicules restent ouverts (ADR 0016), sans pénalité.
• L'extrapolation est linéaire, à partir d'un catalogue de démonstration de 9 mots : elle devra être confirmée par une simulation sur un vrai fascicule.

Critères de réévaluation

• La simulation d'un vrai fascicule de 30 mots dépasse 30 jours en médiane pour un joueur assidu : réduire le plafond ou revoir le rationnement.
• Les joueurs assidus complètent un fascicule en moins de deux semaines : relever le plafond.
• Les mots croisés ouverts par un affixe indispensable dépassent régulièrement le plafond.
• L'équipe veut publier ponctuellement beaucoup de contenu d'un coup (piste des fascicules spéciaux, voir le potentiel d'évolution) : un nouvel ADR devra le décider.

• Statut : Accepté
• Portée : cartes du codex (grille et carte agrandie), charte visuelle
• Complète : ADR 0015 (silhouettes des cartes inconnues)

Contexte

Les cartes du codex étaient plates : un bandeau de couleur, un mot, des métadonnées. La boussole veut pourtant « des mots mis en scène comme des objets précieux » (boussole), et le pilier Collection demande qu'une carte donne envie d'être trouvée.

Dix langages graphiques ont été comparés sur la même carte, « biologie », dans la page de travail des textures : filigrane, aplat découpé, gravure, trame, macro, contours, constellation, pochoir, demi-teinte et spécimen annoté. Deux traitements du texte posé sur la texture ont ensuite été essayés, puis écartés : un fond opaque et un voile flou.

Décision

Une silhouette par carte découverte

• Chaque carte découverte porte en fond une silhouette simple de ce que dit son sens : une double hélice pour biologie, une pousse pour bio-, un livre ouvert pour -logie, un buste de penseur pour philosophie, une chouette pour -sophie, un globe et ses continents pour géographie.
• Une carte de langue montre un objet de sa culture : rosace pour le français, aqueduc pour le latin, amphore pour le grec ancien. Jamais de drapeau, ni de parchemin ou de plume.
• Une carte inconnue garde ses hachures, son « ? » et sa piste, sans aucune texture : l'image trahirait le sens. Les légendaires inconnues restent absentes du codex (ADR 0015).
• La silhouette figure au recto, en grille et en carte agrandie. Le verso, dense en listes, reste sans texture.
• Elle suit la carte partout où celle-ci apparaît : codex, maquettes, exemples de la charte et du design système. Une fiche de découverte (table de fusion, accueil) n'est pas une carte et reste sans texture.
• Une silhouette par sens, partagée entre les langues : en règle générale, une silhouette n'appartient qu'à une carte, et deux cartes proches par le sens (géo-, géographie, géologie) prennent des sujets distincts. Exception : plusieurs cartes peuvent porter la même silhouette quand elles sont le même mot dans plusieurs langues, c'est-à-dire des unités reliées par un emprunt ou un héritage et qui gardent le même sens (philosophie, philosophia, φιλοσοφία). Le dessin ne dit rien de la langue : c'est la carte de langue qui porte l'objet de sa culture.

Style : l'aplat découpé (piste 02)

• Une seule teinte : Encre à 10 % d'opacité en grille, 8,5 % en carte agrandie. En mode nocturne, la même opacité de Papier sur fond sombre. Aucune couleur de ressource, aucun second ton, aucun dégradé.
• Aplat plein, un peu gras : formes pleines et traits épais. Les détails (nervures, lignes d'un livre, frise d'une amphore) sont évidés dans la couleur du fond de la carte, jamais dessinés dans un autre ton.
• Cadrage : la silhouette est grande, décentrée vers le bas ou la droite, et recadrée par le bord de la carte. Elle ne passe jamais sous le bandeau.
• Grammaire de dessin : épaisseurs, évidements, arrondis, cadrage, inclinaison et choix du sujet sont fixés dans la charte des textures. Toute nouvelle silhouette les respecte.
• Décorative : elle est masquée aux technologies d'assistance et ne porte aucune information de jeu (ni type, ni rareté, ni fascicule).

Le texte reste posé sur la texture

• Le texte se pose directement sur la texture, sans fond ni flou. Le texte principal (Encre) et le texte secondaire (Encre secondaire #44564D, 5,5:1 au pire en grille) gardent au moins 4,5:1.
• Le Gris encre (4:1) et le Corail profond (4,3:1) tombent sous le seuil sur la texture : sur une carte texturée, la note, les étiquettes et les liens passent en Encre secondaire, et un lien reste souligné.
• Seule exception : le sens littéral en pastille passe en Crème, cerné d'un filet Gris encre de 1 px, pour ne pas se confondre avec la silhouette.

Options envisagées

Neuf autres langages graphiques

Filigrane, gravure, trame, macro, contours, constellation, pochoir, demi-teinte et spécimen annoté ont été écartés. Ils sont trop fins pour la grille, trop abstraits, trop proches du cliché académique ou trop chargés sous les métadonnées. Ils restent sur la page de travail.

Fond opaque sous chaque texte

Écarté : chaque texte découpait la silhouette en rectangles, ce qui cassait l'image.

Voile flou sous chaque texte

Écarté : un flou aux bords fondus adoucit la découpe, mais brouille la silhouette. Il ajoute aussi une ombre molle, que la charte évite.

Couleur du type dans la texture

Écartée : une couleur n'a qu'un seul sens. Une texture Étincelle ou Glose ferait de la décoration avec une couleur de ressource, et deux surfaces colorées sur la même carte.

Conséquences

Positives

• Chaque carte devient un objet reconnaissable, qu'on a envie de collectionner.
• La texture renforce le sens du mot sans rien dire de la mécanique : la couleur garde son rôle.
• Le rendu est vectoriel et monochrome : il s'adapte à toutes les tailles et au mode nocturne sans second jeu de fichiers.
• Un même mot dans plusieurs langues partage sa silhouette : le joueur reconnaît la parenté, et un dessin sert plusieurs cartes.

Négatives

• Chaque carte publiée demande une silhouette : c'est un coût éditorial et graphique, au rythme des fascicules.
• Certains sens abstraits (étymo- « vrai », philo- « qui aime ») demandent des objets symboliques, plus ouverts à l'interprétation.
• Sous une texture dense, le texte perd un peu de contraste : il faut vérifier chaque nouvelle silhouette en grille et en carte agrandie.

Critères de réévaluation

• Un test montre que la texture gêne la lecture du mot ou des métadonnées, en grille ou sur petit écran.
• Le coût de production d'une silhouette par carte ralentit la publication des fascicules.
• Des joueurs lisent la texture comme un indice de jeu (rareté, famille, fascicule).

• Statut : Accepté, partiellement remplacé par l’ADR 0025 : la publication d’un fascicule est programmée par un manifeste serveur daté, et le manifeste public ne désigne que la version active. Partiellement remplacé aussi par l’ADR 0026 : le dépôt privé ne contient que des données et la CI qui les publie, jamais d’artefact compilé ni de logique. Partiellement remplacé enfin par l’ADR 0027 : un seul artefact public, recettes comprises, sans bucket privé ni projection du contenu ; le serveur fait toujours foi. Partiellement remplacé encore par l’ADR 0028 : seul le dossier de conception publie une préversion par branche ; l’application et l’infrastructure ne déploient que develop (hors-prod) et master (prod). Partiellement remplacé enfin par l’ADR 0041 : hors connexion, consultation seule, sans préparation de table. Partiellement remplacé par l’ADR 0070 pour l’identité : un joueur peut avoir plusieurs appareils et un compte facultatif, dont l’adresse n’est gardée qu’en empreinte. Le reste de la décision reste en vigueur.
• Portée : application du MVP (PWA, API, bases, hébergement), hors dossier de conception
• Complète : ADR 0001 (hors connexion), ADR 0005 (artefact publié), ADR 0007 (autorité serveur), ADR 0010 (journaux et télémétrie)

Contexte

Le dossier de conception fixe déjà les règles techniques du jeu, sans choisir de technologie : une PWA (ADR 0001), un catalogue compilé en artefact versionné (ADR 0005), un serveur qui fait autorité sur l’économie (ADR 0007) et une télémétrie minimale (ADR 0010).

Les contraintes posées pour l’application :

• front en React, servi par un service statique ;
• coût serveur minimal, serverless autant que possible ;
• forte préférence pour un cloud français (Scaleway, OVHcloud, Clever Cloud) ;
• deux données de nature opposée : le catalogue (mots, briques, recettes) change une fois par mois, au rythme des fascicules (ADR 0022) ; la progression des joueurs (réserve, découvertes, énergie, encre, sabliers, réglages) change à chaque action.

Le trafic d’un MVP est faible et irrégulier : payer des serveurs allumés en permanence n’a pas de sens.

Décision

Hébergement : Scaleway, région Paris, serverless

Tout est hébergé chez Scaleway, en région fr-par, sur des services facturés à l’usage :

• L’API démarre à 0 instance au repos. Elle passe à 1 instance minimum si le démarrage à froid dépasse 1 s au 95ᵉ centile sur l’ouverture d’un pli.
• L’infrastructure est décrite en code (OpenTofu ou Terraform, fournisseur Scaleway) et déployée par GitHub Actions. Chaque branche peut avoir sa préversion, comme le dossier aujourd’hui.
• Le cœur reste portable : conteneur OCI standard, PostgreSQL, stockage compatible S3.

Front : PWA React statique

• React et TypeScript, compilés en fichiers statiques. Un service worker (Workbox) met en cache la coque et le catalogue public autorisé.
• Les fichiers au nom haché sont en cache immuable. index.html, le service worker et le manifeste du catalogue ne sont pas mis en cache.
• IndexedDB conserve la projection de la progression confirmée et les commandes en attente (ADR 0007).
• Le front et l’API partagent le même domaine parent. CORS est limité à l’origine de la PWA, sans cookie tiers ni script tiers.

Catalogue : un artefact statique, sans aucune recette côté client

Le catalogue n’est pas une base de données. Le pipeline de l’ADR 0005 produit, pour chaque version, deux artefacts immuables :

• public : seulement ce que tout joueur peut voir dès le départ, sans rien apprendre du contenu : langues, systèmes d’écriture, fascicules parus et leurs jaquettes ;
• serveur : tout le reste, dont les briques, les recettes, les mots et leurs fiches, les poids et raretés des plis, les garanties, les plis de jalon et les légendaires.

Le client ne reçoit aucune recette, ni en clair, ni sous forme d’empreinte. Tout ce qui dépend de la progression est une projection calculée par le serveur pour chaque joueur, puis gardée en cache :

• les briques obtenues, avec leurs gloses, et la réserve ;
• les fiches des mots découverts, composition comprise ;
• les cartes inconnues visibles en silhouette, avec leur piste de sens, et les compteurs de chaque fascicule, sans aucune légendaire inconnue ni mot qui en dépend (ADR 0015) ;
• les chances du pli du fascicule choisi, les légendaires inconnues regroupées sur une seule ligne.

Ainsi, aucun mot à venir ni aucune légendaire ne se lit dans le code ou le stockage de la PWA.

• Un manifeste désigne la version active. Publier un fascicule consiste à déposer les deux artefacts puis à changer le manifeste. Revenir en arrière consiste à remettre l’ancien manifeste.
• L’API charge l’artefact serveur en mémoire au démarrage et relit le manifeste au plus toutes les 60 s. Le contenu ne passe par aucune requête SQL.
• Le format d’édition, dont le schéma proposé par l’ADR 0013, reste indépendant : l’artefact n’en est que la compilation.
• Les sources éditoriales non publiées et l’artefact serveur vivent dans un dépôt privé, déployé par sa propre CI. Le code reste public (ADR 0017). Les textes publiés restent sous CC BY-SA 4.0 : c’est leur date de révélation qui est retenue, pas leur licence.

Backend : une API en Rust

• Un seul service, sans état, écrit en Rust, livré dans une image de conteneur minimale. Pile de référence : tokio, axum et sqlx (requêtes vérifiées à la compilation).
• Des commandes, pas un CRUD : fusion, ouverture de pli, sablier, indice, synchronisation, télémétrie. Chaque commande porte un identifiant d’idempotence, la version du catalogue et la version d’état connue du client. La réponse renvoie le nouvel état confirmé. Un conflit renvoie 409 et déclenche une resynchronisation explicite.
• Toute fusion est résolue par le serveur, parce que le client n’a pas les recettes : succès, recette déjà connue, « presque », piste pas encore autorisée ou échec (game-design). Hors connexion, aucune commande n’est possible (ADR 0041).
• Les tirages de plis utilisent un générateur aléatoire cryptographique côté serveur, sauf les plis de jalon, dont le contenu est déterministe (ADR 0012). L’horloge du serveur seule fait foi pour l’énergie et les sabliers.
• Les types des commandes et de l’artefact sont décrits par un schéma unique, dont on génère les types TypeScript du front.

Progression : tables relationnelles PostgreSQL

L’état des joueurs est normalisé en tables relationnelles, pas stocké en document :

• joueur : profil invité, empreinte de son secret, version d’état, version de catalogue ;
• exemplaire : une ligne par joueur et par brique, avec contrainte CHECK entre 0 et 5 exemplaires ;
• decouverte : joueur, mot, date, numéro de découverte ;
• energie, encre, sablier : charges (2 au plus), prochaine échéance, soldes et plafond de 36 sabliers détenus, contrôlés par contraintes (ADR 0020). Le plafond de 12 sabliers par 24 h glissantes est vérifié dans la transaction, à partir des mouvements ;
• compteur_pli : par joueur et par fascicule, plis depuis la dernière nouveauté (garantie au 6ᵉ pli) et plis consécutifs sans découverte possible (filet au 5ᵉ pli) ;
• reglage : préférences non sensibles ;
• commande : identifiant d’idempotence unique et réponse mémorisée ;
• mouvement : journal en ajout seul des gains et consommations, pour l’audit et le support.

Règles :

• les identifiants du catalogue sont les identifiants opaques et stables de l’ADR 0005 ; la base de progression ne copie aucun texte du catalogue ;
• chaque commande est une transaction : énergie consommée, tirage, exemplaires, encre et mouvement réussissent ou échouent ensemble ;
• les migrations de schéma sont versionnées dans le dépôt et appliquées par le déploiement ; les migrations de progression, à la publication d’un fascicule, tournent dans un Serverless Job.

Identité et sécurité

• Profil invité (ADR 0007) : le client génère un identifiant d’installation et un secret aléatoire de 256 bits. Le serveur ne garde que l’empreinte du secret et délivre un jeton de session signé, valable 15 minutes, renouvelé avec le secret. Aucun nom ni adresse électronique.
• Le compte, la récupération et le multi-appareil restent soumis à l’ADR séparé prévu par l’ADR 0007.
• En-têtes : CSP stricte sans script tiers, HSTS, frame-ancestors 'none'.
• Chaque commande est validée par schéma, taille bornée, propriétés inconnues refusées. Débit limité par profil et par adresse réseau, sans conserver celle-ci.
• Moindre privilège : l’API lit le seul bucket privé du catalogue et n’accède qu’à sa base. Les secrets vivent dans Secret Manager, jamais dans le dépôt. La CI audite les dépendances (cargo audit, npm audit).
• Le code est public (ADR 0017) : aucune sécurité ne repose sur le secret du code. Seuls les clés, les réglages et l’artefact serveur restent privés.
• La télémétrie passe par la même API, dans des tables séparées de la progression (ADR 0010). Son identifiant pseudonyme est distinct de celui du joueur, calculé côté serveur et renouvelé chaque mois civil (ADR 0050, ADR 0072).
• Durées de conservation : commandes traitées 30 jours, événements de télémétrie bruts 90 jours puis agrégats seuls, journaux opérationnels 30 jours. Les purges tournent chaque jour dans un Serverless Job.

Options envisagées

Clever Cloud (application statique, application Rust, PostgreSQL, Cellar)

Déploiement très simple et sans démarrage à froid, mais pas d’arrêt complet : une instance et une base tournent en permanence, pour un coût fixe dès le premier jour. Écarté au profit d’un coût quasi nul au repos. Reste le repli si le serverless déçoit.

OVHcloud (Object Storage, Web PaaS ou Kubernetes, bases managées)

Solide et économique en charge continue, mais sans conteneurs ni base qui s’arrêtent à zéro. Écarté pour le MVP.

Catalogue en base de données

Une base pour un contenu qui change une fois par mois ajouterait coût, requêtes et risque de modification directe, que l’ADR 0005 écarte déjà. Écarté.

Recettes chez le client, en clair ou en empreintes salées

Elles permettraient de résoudre une fusion hors connexion. En clair, elles révèlent tout le codex et les légendaires. En empreintes, elles restent attaquables par force brute, vu le petit nombre de briques. Écarté : la fusion attend le serveur.

Backend en TypeScript

Il permettrait de partager le code des règles avec le front. Écarté au profit de Rust : démarrage à froid et mémoire minimaux, donc un coût serverless plus bas, et un typage strict des règles de l’économie. Le partage passe par un schéma commun et des types générés.

Un document JSON par joueur

Plus simple à faire évoluer, mais les invariants (plafond de 5, charges, soldes) ne seraient garantis que par le code. Écarté : les contraintes relationnelles protègent l’économie même en cas de bogue.

Fonctions serverless séparées par commande

Plus de pièces à déployer, de démarrages à froid et de code dupliqué pour un domaine petit et cohérent. Écarté au profit d’un seul conteneur.

Conséquences

Positives

• Coût au repos de quelques euros par mois, puis proportionnel au jeu réel.
• Montée en charge automatique de l’API sans état. Le catalogue en mémoire n’ajoute aucune charge à la base.
• Données hébergées en France, chez un fournisseur européen.
• Mots à venir, briques non obtenues et légendaires impossibles à lire dans le client.
• Invariants de l’économie protégés par la base et par les transactions.
• Retour arrière d’un fascicule en changeant une seule valeur.

Négatives

• Démarrage à froid possible au premier appel après une période creuse.
• Aucune fusion n’est résolue hors connexion : le joueur consulte seulement (ADR 0041).
• Le codex et la réserve dépendent d’une projection serveur : un premier lancement exige le réseau.
• Deux dépôts à tenir, le code public et le contenu privé.
• Rust demande plus de temps de développement, et le partage de code avec le front se limite aux types générés.
• Chaque nouvelle règle d’économie demande souvent une migration de schéma.
• Serverless SQL Database a des quotas et une latence de reprise à surveiller.
• Dépendance à un seul fournisseur, atténuée par des briques standards.

Critères de réévaluation

• Le coût de calcul de Serverless SQL dépasse celui d’une base PostgreSQL managée de petite taille pendant 2 mois : passer à la base managée, même moteur.
• Le démarrage à froid reste au-dessus de 1 s au 95ᵉ centile avec 1 instance minimum : réévaluer l’hébergement de l’API (Clever Cloud en repli).
• Les tests montrent que l’attente du réseau pour chaque fusion gêne le jeu hors connexion : rouvrir la question des recettes chez le client, par un nouvel ADR.
• Arrivée des comptes, du multi-appareil ou des paiements (ADR 0018) : revue de sécurité et de l’identité.

• Statut : Accepté, partiellement remplacé par l’ADR 0027 : la correspondance entre cartes et médias est dans le manifeste public du fascicule, et l’index global remplace le manifeste public ; et par l’ADR 0029 : les fichiers à venir attendent sous un préfixe illisible, et l’API suit l’index publié par la tâche de parution
• Portée : application du MVP (catalogue, médias, publication), hors dossier de conception
• Remplace partiellement : ADR 0024, pour la publication par un manifeste unique changé à la main
• Complète : ADR 0005 (artefact publié), ADR 0016 (jaquettes), ADR 0023 (silhouettes), ADR 0024 (catalogue public et serveur)

Contexte

L’ADR 0024 garde côté serveur tout ce qui dévoilerait le contenu avant que le joueur le débloque. Il ne dit rien des médias : les jaquettes des plis (ADR 0016) et les silhouettes des cartes (ADR 0023). Les faire passer par l’API coûterait des appels, des démarrages à froid et de la bande passante serverless, pour des fichiers qui ne changent jamais une fois publiés.

Or une silhouette trahit le sens d’une carte : une chouette ou une double hélice suffit à deviner un mot. Ce qui doit rester secret, c’est le lien entre une carte et son image, pas le fichier lui-même.

Par ailleurs, l’ADR 0024 publie un fascicule en changeant un manifeste à la main, le jour même. Avec un fascicule par mois (ADR 0022), il faut pouvoir préparer un ou plusieurs fascicules à l’avance et les voir paraître seuls, à la date prévue.

Décision

Les médias sont servis en statique, sous un nom opaque

• Les jaquettes et les silhouettes sont des fichiers statiques, déposés dans l’Object Storage public et servis par le CDN, en cache immuable. L’API ne sert jamais leurs octets.
• Chaque fichier porte un nom tiré de l’empreinte de son contenu (SHA-256 des octets, tronquée à 128 bits au moins), par exemple a3f9…c2.svg. Jamais le mot, jamais l’identifiant d’une carte, ni une empreinte de l’un ou de l’autre, que la force brute retrouverait sur un vocabulaire aussi petit.
• Le bucket public refuse le listing : on lit un fichier par son nom, on n’énumère pas le dossier.
• Aucune liste de silhouettes ne figure dans le code de la PWA ni dans le catalogue public. Le service worker met une silhouette en cache la première fois qu’elle s’affiche, sans jamais précacher un lot.

La correspondance vit dans l’artefact serveur, le lien dans la projection

• La correspondance entre chaque carte et son fichier est compilée par le pipeline (ADR 0005) dans l’artefact serveur, stocké dans le bucket privé. Elle n’entre ni dans PostgreSQL ni dans une autre base : le catalogue n’est pas une base de données (ADR 0024).
• L’API, qui a l’artefact en mémoire, ajoute l’URL de la silhouette à la projection du joueur, seulement pour les cartes qu’il a découvertes. Une carte inconnue n’a ni texture ni lien (ADR 0023). Une légendaire n’a de lien qu’une fois trouvée (ADR 0015).
• Les jaquettes des fascicules parus restent dans le catalogue public, comme le prévoit l’ADR 0024 : une jaquette ne dit que le fascicule (ADR 0016).

Un fascicule se prépare à l’avance et paraît seul, à sa date

• Un fascicule prêt est livré à l’avance : artefact public, artefact serveur, médias et migrations de progression. Plusieurs fascicules peuvent attendre en même temps.
• Un manifeste serveur, privé, liste les versions du catalogue et leur date d’effet, en UTC (par exemple n° 12 le 1ᵉʳ novembre à 00 h 00, n° 13 le 1ᵉʳ décembre). L’API en déduit la version active avec sa propre horloge, qui seule fait foi, comme pour l’énergie et les sabliers (ADR 0024). La bascule ne dépend donc pas de la relecture du manifeste toutes les 60 s.
• Le manifeste public, que lit la PWA, ne désigne que la version déjà active. Il ne mentionne jamais une version à venir, ni son nom, ni sa date, ni l’adresse de son artefact public.
• À chaque date d’effet, une tâche planifiée (Serverless Job) remplace le manifeste public et applique les migrations de progression de la nouvelle version. Ces migrations sont livrées et testées avec le fascicule, jamais écrites le jour même.
• Le pipeline refuse une livraison dont la date d’effet précède celle de la version active, ou dont les migrations n’ont pas été testées sur une copie de la progression.
• Un client resté sur l’ancienne version reçoit un 409 et se resynchronise (ADR 0024).
• Reporter ou annuler un fascicule en attente consiste à changer sa date ou à le retirer du manifeste serveur. Revenir en arrière après la parution reste un changement de manifeste.

Ce qu’un dump du stockage public révélerait

Au pire, des jaquettes et des silhouettes déjà livrées, sans nom de mot, sans ordre ni lien avec leur fascicule, et seulement si leur nom a été deviné ou divulgué. Aucune recette, aucune fiche, aucune brique ni aucune légendaire ne s’y trouve. Ce risque est accepté : un nom opaque n’est pas un contrôle d’accès, mais il protège une date de révélation, pas un secret (ADR 0024).

Options envisagées

Médias servis par l’API

Contrôle d’accès exact, mais chaque image coûterait un appel, un démarrage à froid possible et de la bande passante serverless, sans cache CDN partagé. Écarté.

URL signées à durée limitée

Plus étanches qu’un nom opaque, mais chaque projection devrait renouveler ses liens, et le cache immuable du CDN et du service worker serait perdu. Disproportionné pour protéger une date de révélation. Écarté.

Noms lisibles ou dérivés de l’identifiant

Pratiques à déboguer, mais le vocabulaire est petit : biologie.svg ou une empreinte de l’identifiant se devinent en quelques essais. Écarté.

Correspondance des médias en base de données

Elle placerait du contenu dans la base de progression, que l’ADR 0024 réserve aux joueurs. Écarté : la correspondance suit l’artefact serveur et ses versions.

Manifeste public qui liste les versions à venir

Il permettrait à la PWA de précharger le fascicule suivant, mais il révélerait son nom, sa date et l’adresse de son artefact public, jaquette comprise. Écarté.

Publication manuelle le jour de la parution

C’est la règle de l’ADR 0024. Elle exige une intervention humaine à heure fixe chaque mois et interdit de préparer plusieurs fascicules. Remplacée par la publication programmée.

Conséquences

Positives

• Les images ne coûtent aucun appel à l’API : elles profitent du CDN et du cache immuable.
• Aucune carte inconnue ni aucune légendaire ne se devine depuis le code ou le catalogue public.
• Un fascicule se prépare des jours ou des semaines à l’avance, et paraît à l’heure dite sans intervention.
• Reporter, annuler ou revenir en arrière reste un simple changement de manifeste.

Négatives

• Un lien de silhouette partagé est visible par n’importe qui : le nom opaque n’est pas un contrôle d’accès.
• Les médias d’un fascicule en attente sont déjà dans le stockage public, lisibles par qui en connaîtrait le nom.
• Hors connexion, une silhouette jamais affichée n’est pas en cache : la carte s’affiche alors sans texture.
• La tâche planifiée devient critique à chaque parution : un échec de migration doit bloquer la bascule du manifeste public et alerter.

Critères de réévaluation

• Des silhouettes ou des jaquettes d’un fascicule à venir circulent avant sa parution : ne déposer les médias qu’à la date d’effet, par la tâche planifiée.
• Une tâche planifiée de parution échoue ou dépasse 5 minutes : revoir l’ordre de la bascule et des migrations.
• Les joueurs hors connexion voient souvent des cartes sans texture : précacher les silhouettes des cartes découvertes à chaque synchronisation.

• Statut : Accepté, partiellement remplacé par l’ADR 0027 : les recettes d’un fascicule paru sont publiées dans l’artefact ; le dépôt du catalogue est public, et c’est voulu
• Portée : organisation des dépôts, pipeline de contenu, publication des fascicules
• Remplace partiellement : ADR 0024, pour le contenu du dépôt du catalogue (sources éditoriales et artefact serveur)
• Complète : ADR 0005 (pipeline), ADR 0017 (licences), ADR 0025 (publication programmée)

Contexte

Le projet est libre et son dépôt public (ADR 0017). Le catalogue est le jeu lui-même. Cet ADR le prévoyait d’abord privé, pour ne pas dévoiler les recettes sur GitHub ; l’ADR 0027 a renoncé à ce secret, et le dépôt du catalogue est public, volontairement. L’ADR 0024 prévoyait un dépôt privé pour « les sources éditoriales non publiées et l’artefact serveur », sans dire ce qu’il peut contenir d’autre.

Deux risques opposés :

• mettre du code dans le dépôt du catalogue le séparerait du code libre et fermerait une partie du jeu, contre l’esprit de l’AGPL, et ferait diverger deux bases de code ;
• mettre le contenu dans le dépôt de l’application mêlerait code et données, pour un contenu qui n’a pas le même rythme.

La publication programmée (ADR 0025) demande en outre de préparer plusieurs fascicules à part, dans un dépôt de données.

Décision

Deux dépôts, une frontière nette

• La règle tient en une phrase : le dépôt du catalogue contient des données, jamais de logique.
• Le dépôt du catalogue ne contient ni l’artefact public ni l’artefact serveur : ce sont des produits de compilation, déposés par la CI dans l’Object Storage (ADR 0024), jamais commités.

Le dépôt du catalogue : des données, rien d’autre

• Sources éditoriales : briques, mots, recettes, fiches, sources, poids et raretés des plis, garanties, plis de jalon, légendaires, dans le format d’édition validé par le schéma du dépôt public (ADR 0005, ADR 0013).
• Médias bruts : jaquettes (ADR 0016) et silhouettes (ADR 0023), sous des noms de travail lisibles. Le compilateur leur donne leur nom opaque à la publication (ADR 0025).
• Manifeste serveur : les versions du catalogue et leur date d’effet (ADR 0025).
• Migrations de progression déclaratives : des tables de correspondance (ancien identifiant, nouvel identifiant, ou retrait), jamais un script. L’outil qui les applique est dans le dépôt public.
• CI : le seul code toléré. Elle se limite à appeler les outils du dépôt public, dans une version épinglée (image de conteneur ou version publiée), pour valider, compiler, déposer les artefacts et les médias, et mettre à jour le manifeste serveur. Aucune règle de jeu, aucune validation, aucune transformation des données n’y est écrite.
• Les secrets de déploiement vivent dans Secret Manager et dans les secrets de la CI, jamais dans l’un ou l’autre dépôt (ADR 0024).

Le dépôt public : tout le reste

• Le schéma du format d’édition et de l’artefact, le compilateur, toutes les validations de l’ADR 0005 (références, sources, atteignabilité, recettes ambiguës, plis) et l’outil qui applique les migrations.
• Un jeu d’essai : un petit catalogue, fictif ou déjà publié, assez complet pour tester chaque validation, compiler un artefact et faire tourner l’API et la PWA en local, sans accès au dépôt du catalogue.
• Les exemples du dossier de conception restent des illustrations. Ils ne préfigurent aucun fascicule à venir.
• Toute évolution du format se fait d’abord dans le dépôt public. Le dépôt du catalogue adopte la nouvelle version en changeant l’épinglage de sa CI.

Licences et ouverture

• Le jeu servi en ligne ne dépend d’aucun code fermé : l’obligation de l’AGPL (ADR 0017) est remplie par le seul dépôt public.
• Le contenu reste sous CC BY-SA 4.0. Ce qui est révélé aux joueurs (fiches des cartes découvertes, gloses, jaquettes, silhouettes) peut être repris sous cette licence. La date de révélation est retenue, pas la licence (ADR 0024).
• Le dépôt du catalogue est public, à toute étape : l’ADR 0027 publie déjà les recettes d’un fascicule paru, et le secret tient à l’interface, non au dépôt. Ses sources ne contiennent aucun secret : les secrets de déploiement vivent hors des dépôts.

Options envisagées

Tout dans le dépôt de l’application

Simple, mais le code et le catalogue n’ont ni le même rythme ni les mêmes relecteurs, et chaque fascicule en préparation encombrerait l’historique du code. Écarté.

Compilateur et validations dans le dépôt du catalogue

Plus pratique pour faire évoluer le format et le contenu ensemble, mais une partie du jeu deviendrait fermée, invérifiable et impossible à reprendre par un fork. Écarté.

Sous-module Git dans le dépôt de l’application

Il lierait les deux dépôts dans un seul arbre et ferait dépendre chaque clone de l’avancement du catalogue. Écarté.

Contenu chiffré dans le dépôt de l’application

Un seul dépôt, mais la clé deviendrait un secret de plus à protéger, pour un contenu que l’artefact publie de toute façon à la parution. Écarté.

Garder le dépôt du catalogue privé

Il garderait les fascicules en préparation hors de vue, mais il ferait d’un secret de dépôt une protection que l’ADR 0027 a jugée inutile, et il fermerait aux contributeurs la lecture du catalogue. Écarté.

Conséquences

Positives

• Le catalogue se prépare et se livre à part du code, dans un dépôt de données simple à relire.
• Tout le code reste libre, vérifiable et reprenable : aucune règle ne se cache dans le dépôt du catalogue.
• Un contributeur travaille entièrement dans le dépôt public, grâce au jeu d’essai.
• Le dépôt du catalogue, fait de données, est simple à relire et à auditer, par tous.

Négatives

• Deux dépôts à tenir, et un épinglage de version à suivre à chaque évolution du format.
• Le jeu d’essai doit rester assez riche pour couvrir toutes les validations.
• Les fascicules en préparation sont lisibles sur GitHub : la découverte d’un fascicule peut être gâchée avant sa parution.
• Un fork peut reprendre le catalogue sous CC BY-SA 4.0, mais pas le nom ni le logo (ADR 0017).
• Le contenu ne reçoit pas de contributions publiques directes : une proposition passe par une issue, puis par une saisie dans le dépôt du catalogue.

Critères de réévaluation

• Une règle de jeu ou une validation apparaît dans la CI du dépôt du catalogue : la déplacer dans le dépôt public.
• Des contributeurs veulent proposer du contenu directement : étudier un circuit de contribution qui ne dévoile rien.
• Le contenu d’un fascicule fuite depuis le dépôt du catalogue : revoir ses accès et ses secrets.

• Statut : Proposé, partiellement remplacé par l'ADR 0029 : un fascicule à venir attend sous staging/, illisible, jusqu'à sa promotion dans public/ ; le reste reste en vigueur
• Remplace partiellement :
  • ADR 0003, pour le secret des recettes verrouillées ;
  • ADR 0024, pour les deux artefacts (public et serveur), la projection du contenu par joueur et le bucket privé du catalogue ;
  • ADR 0025, pour la correspondance entre cartes et médias, tenue dans l'artefact serveur ;
  • ADR 0026, pour la règle qui n'envoie jamais les recettes au client.
• Précise : ADR 0015 (le secret des légendaires tient à l'interface, pas aux fichiers)
• Complète : ADR 0005 (forme de l'artefact), ADR 0007 (données du joueur), ADR 0010 (ce qui n'est jamais stocké)

Contexte

L'ADR 0024 compile deux artefacts : un public, presque vide, et un serveur, qui contient tout le reste. Le client ne reçoit que la projection calculée pour chaque joueur. L'ADR 0025 garde dans l'artefact serveur le lien entre une carte et sa silhouette, et l'ADR 0026 refuse d'envoyer une recette au client.

Ce montage protège un secret fragile. La fiche d'un mot découvert donne déjà sa composition, donc sa recette. Une recette encore inconnue se partage en une phrase sur un forum. Pour ce secret, le serveur doit pourtant :

• tenir un second artefact et un bucket privé ;
• calculer et servir une projection de contenu pour chaque joueur ;
• servir chaque fiche par l'API, au lieu du CDN.

Ce qu'il faut vraiment garantir, c'est qu'aucun fascicule ne se lise avant sa parution et que l'état du joueur ne soit jamais falsifiable. Le serveur fait foi, que les recettes soient publiques ou non.

Décision

Un seul artefact, public, en trois niveaux

Le pipeline de l'ADR 0005 compile, pour chaque version, un seul artefact. Il est déposé dans l'Object Storage public, derrière le CDN, avec le listing refusé (ADR 0025).

• Chemins en hash de contenu : chaque manifeste et chaque ressource est rangé sous l'empreinte SHA-256 de son contenu, comme les médias de l'ADR 0025. Un fichier publié ne change jamais : il se met en cache sans limite, et une brique reprise par un fascicule suivant garde le même fichier.
• L'index global est le seul fichier modifiable. Il prend la place du manifeste public de l'ADR 0025 : il ne liste que les fascicules déjà parus, jamais un fascicule à venir.
• Parution programmée : elle suit l'ADR 0025. Les fichiers sont déposés à l'avance. À la date d'effet, une tâche planifiée ajoute le fascicule à l'index global et applique les migrations. Avant cette date, aucun chemin n'est publié, et l'empreinte d'un contenu inconnu ne se devine pas.
• Corrections : une ressource corrigée a un nouveau hash, donc un nouveau manifeste, donc un nouvel index. Les versions restent immuables (ADR 0002).
• Jamais dans l'artefact : note_interne, brouillons, faits rejetés ou non_retenue, état de relecture, imports du Wiktionnaire, manifeste serveur daté. Ils restent dans les sources du dépôt du catalogue (ADR 0026).

Ce qui change dans les ADR 0024, 0025 et 0026

• ADR 0024 : plus d'artefact serveur, plus de bucket privé du catalogue, plus de projection de contenu par joueur. L'API lit le même artefact public, le garde en mémoire et relit l'index global. La projection du joueur ne contient plus que son état (réserve, découvertes, énergie, encre, sabliers, compteurs) : des identifiants et des nombres, jamais de texte du catalogue.
• ADR 0025 : la correspondance entre une carte et sa silhouette est dans le manifeste de son fascicule, pas dans un artefact serveur. Les médias gardent leur nom opaque, et le service worker ne précache toujours aucun lot.
• ADR 0026 : le dépôt du catalogue ne contient toujours que des données, et il est public. Ce qu'il compile pour un fascicule paru, recettes comprises, est publié dans l'artefact.
• L'hébergement, le backend Rust, les tables PostgreSQL, l'identité, la sécurité et la publication programmée de ces ADR restent en vigueur.

Les recettes sont publiques, le serveur fait foi

• Remplace, dans l'ADR 0003, la phrase « le serveur ne renvoie pas l'identifiant ou les ingrédients secrets d'une recette verrouillée ». Une fois le fascicule paru, ses recettes sont lisibles dans ses fichiers.
• En ligne, le client peut prévisualiser une fusion à partir des recettes publiques, pour répondre sans attendre. Hors connexion, la tentative attend toujours le réseau (ADR 0024) : aucun résultat n'est présenté comme acquis.
• Le serveur fait foi pour toute règle et toute mutation (ADR 0007). Dans une seule transaction, il :
  • valide la recette, son ordre et ses préconditions ;
  • vérifie que la réserve contient un exemplaire de chaque brique utilisée ;
  • consomme les exemplaires, ajoute la découverte au codex et donne les récompenses.
• Il en va de même pour l'énergie, les plis, la garantie et le filet, l'encre, les sabliers et leurs plafonds, les indices et les jalons.
• Si le serveur contredit la prévisualisation, le client affiche la réponse du serveur.

Les légendaires restent secrètes dans l'interface

• Précise l'ADR 0015 : ni silhouette ni compteur ne trahissent une légendaire inconnue à l'écran. Les fichiers d'un fascicule paru, eux, la contiennent.
• Le manifeste ne porte que des compteurs hors légendaires. La ligne « Légendaires inconnues » de l'écran des plis n'affiche que la somme de leurs chances.

Les données du joueur : les tables de l'ADR 0024

La progression reste dans les tables relationnelles PostgreSQL de l'ADR 0024. Le modèle de données en donne le schéma logique et y ajoute l'historique des plis, les indices, les jalons atteints et les migrations. Les propositions de fusion ne sont jamais stockées : la télémétrie ne compte que les résultats (ADR 0010).

Options envisagées

Garder deux artefacts et la projection de contenu (ADR 0024)

Écarté : un second artefact, un bucket privé et une projection de contenu par joueur, pour protéger des recettes que les fiches découvertes et le bouche-à-oreille dévoilent déjà.

Chemins hachés par une clé privée du backend

Les chemins ne se liraient qu'avec l'aide du serveur, même après la parution. Mais le backend devrait transmettre chaque chemin, et changer de clé renommerait tous les fichiers. Écarté : le hash de contenu suffit à garantir la seule chose retenue, rien avant la date.

Un seul fichier par version du catalogue

Écarté : chaque correction ou parution ferait retélécharger tout le catalogue.

Résolution des fusions par le client seul

Écartée : réserve, codex, encre et sabliers deviendraient falsifiables (ADR 0007).

Conséquences

Positives

• Un seul artefact à compiler, déposer et relire. Plus de bucket privé ni de projection de contenu.
• Les fiches, recettes et médias passent par le CDN, sans appel à l'API.
• En ligne, la table répond tout de suite. Le serveur garde seul l'autorité sur l'état du joueur.
• Un fascicule se prépare à l'avance et paraît seul, à la date prévue.

Négatives

• Dès la parution, un joueur curieux peut lire toutes les recettes et légendaires d'un fascicule, et les partager.
• Le client et le serveur doivent lire les recettes de la même façon, sinon la prévisualisation est démentie. Un schéma commun et des tests partagés limitent ce risque.
• Un fascicule paru ne s'efface pas des caches : seule une nouvelle version peut le corriger.

Critères de réévaluation

• Des solutions publiées dès la parution réduisent nettement la part de joueurs qui cherchent par eux-mêmes : revenir aux deux artefacts de l'ADR 0024.
• La prévisualisation du client est souvent démentie par le serveur.
• Un besoin de secret après la parution (événement, légendaire à durée limitée) : étudier des chemins hachés par une clé privée.

• Statut : Proposé
• Portée : branches, fusions et déploiements des dépôts design, content, app et infra
• Remplace partiellement : ADR 0024, pour la préversion par branche, réservée désormais au dossier de conception
• Précise : ADR 0026 (le code public est réparti entre les dépôts design, app et infra ; le dépôt content est public et sans logique)
• Complète : ADR 0025 (la parution programmée s’applique dans chaque environnement)

Contexte

Le projet vit dans quatre dépôts :

L’ADR 0024 dit seulement que « chaque branche peut avoir sa préversion ». Rien ne fixe quelles branches existent, lesquelles déploient, ni vers quel environnement. Or une préversion par branche de l’application demande une base, un bucket et une API par branche : c’est coûteux, et le catalogue privé risque d’y fuiter.

Deux environnements suffisent au MVP : hors-prod, pour éprouver une livraison, et prod, celle des joueurs. Chaque dépôt n’a pas besoin du même circuit : le dossier de conception n’a pas de hors-prod, l’application a besoin de versions identifiables.

Décision

Branches et environnements par dépôt

Règles communes

• Une branche de feature se tire de develop, ou de master pour design. Elle revient dans sa branche d’origine par une pull request, CI verte.
• develop rejoint master par une pull request. master ne reçoit rien d’autre, et ne contient donc que ce qui est déjà passé en hors-prod.
• master et develop sont protégées : ni push direct, ni réécriture d’historique.
• Pas de branche release/ ni hotfix/. Un correctif urgent suit le même chemin : feature, develop, hors-prod, master, et, pour app, un tag.
• Seul design publie ses branches de feature. Une branche de feature de content, app ou infra ne déploie rien : sa CI valide et teste, sans publier.

App : le tag fait la prod

• Les tags suivent SemVer, vX.Y.Z, et se posent sur un commit de master.
• Une fusion sur master sans tag ne déploie rien. Seul le tag déclenche la prod.
• L’image publiée en prod est reconstruite depuis le commit tagué et porte le numéro du tag. Revenir en arrière, c’est redéployer le tag précédent.

Content : la date fait la parution

• master et develop publient le même format d’artefact (ADR 0027), chacun dans l’Object Storage de son environnement.
• La parution programmée (ADR 0025) s’applique dans les deux environnements : fusionner un fascicule sur master ne le fait pas paraître avant sa date.

Infra : un code, deux inventaires

• Les modules sont communs aux deux environnements. Aucun fichier de code n’est propre à la prod ou à la hors-prod.
• Chaque environnement a son inventaire : variables, dimensionnement, noms, domaines, et son état distant, séparé de l’autre.
• La branche choisit l’inventaire : develop applique l’inventaire hors-prod, master celui de prod. Une modification de module passe donc en hors-prod avant la prod ; une modification d’inventaire de prod passe par develop sans effet en hors-prod.
• Sur une pull request, la CI produit le plan de l’environnement cible, sans l’appliquer.

Options envisagées

Trunk-based : une seule branche master pour tous les dépôts

Plus simple, mais chaque fusion part en prod. Le catalogue et l’application n’auraient plus d’endroit où s’éprouver avant les joueurs. Retenu pour design seul, qui n’a pas de hors-prod.

Gitflow complet, avec branches release et hotfix

Utile quand plusieurs versions vivent en parallèle. Le MVP n’en a qu’une en prod : ces branches doubleraient les fusions et les risques d’oubli (un hotfix non reporté dans develop). Écarté.

Préversion par branche de feature pour tous les dépôts

Promise par l’ADR 0024. Pour app et infra, elle multiplie bases, buckets et coûts ; pour content, elle expose des fascicules non parus sur des adresses de plus. Écarté hors design.

App : master déploie la prod à chaque fusion, sans tag

Plus direct, mais une version en prod n’aurait pas de numéro stable, et le retour en arrière passerait par une nouvelle fusion. Écarté.

Infra : un dossier de code par environnement

Chaque environnement évoluerait librement, mais la hors-prod cesserait d’éprouver le code de la prod. Écarté au profit d’un code unique et de deux inventaires.

Conséquences

Positives

• Tout ce qui arrive en prod est d’abord passé en hors-prod, pour les trois dépôts qui déploient.
• Une version de l’application en prod se nomme, se retrouve et se redéploie par son tag.
• La hors-prod éprouve le même code d’infrastructure que la prod ; seules les valeurs changent.
• Deux environnements seulement à payer, surveiller et protéger.

Négatives

• Une branche de feature d’app ou d’infra ne se voit pas déployée avant sa fusion dans develop : les essais concurrents se partagent la hors-prod.
• Un correctif urgent attend le passage par develop et la hors-prod.
• develop et master peuvent diverger si une fusion develop → master tarde ; il faut la faire souvent.
• Poser un tag reste un geste manuel pour app.

Critères de réévaluation

• Plus d’une livraison sur quatre de la prod attend qu’un autre essai libère la hors-prod : envisager des préversions éphémères pour app.
• Un incident en prod ne peut pas attendre le passage par develop : réintroduire une branche hotfix/*.
• Deux versions de l’application doivent vivre en prod en même temps : réintroduire des branches release/*.
• Un troisième environnement devient nécessaire (recette éditoriale, démonstration) : ajouter un inventaire et sa branche.

• Statut : Proposé, partiellement remplacé par l’ADR 0049 : l’index publie la date du prochain fascicule, et rien d’autre de lui. Le reste du présent ADR reste en vigueur.
• Portée : stockage du catalogue publié, droits sur l'Object Storage et tâche de parution
• Remplace partiellement :
  • ADR 0025, pour les fichiers d'un fascicule à venir, déposés à l'avance dans le stockage public, et pour l'horloge de l'API qui décide seule de la bascule ;
  • ADR 0027, pour le dépôt à l'avance protégé par des chemins qui ne se devinent pas.
• Complète : ADR 0024 (hébergement), ADR 0028 (un bucket par environnement)

Contexte

L'ADR 0027 publie le catalogue dans l'Object Storage, lisible par nom et sans listage. Un fascicule prêt y est déposé à l'avance (ADR 0025). Jusqu'à sa date, seul le secret de ses chemins le protège : un chemin en hash de contenu ne se devine pas, mais il suffit qu'il fuite, par un journal, une capture ou une erreur de CI.

L'ADR 0025 le reconnaît : « un nom opaque n'est pas un contrôle d'accès ». Il prévoit de ne déposer les médias qu'à la date d'effet si des fichiers à venir circulaient. Ce qu'il faut garantir, c'est qu'aucun fichier d'un fascicule ne se lise avant sa parution, même par qui connaît son chemin. Et cela sans deuxième bucket, que l'ADR 0027 a justement supprimé.

Chez Scaleway, une politique de bucket au format 2023-04-17 ne contient que des autorisations : tout ce qu'elle n'autorise pas est refusé, et une règle Deny n'a aucun effet. Elle peut viser un préfixe (bucket/prefixe/*) et borner un listing par la condition s3:prefix. Elle prime sur les ACL d'objet, et aucune condition ne porte sur les tags d'un objet.

Décision

Un bucket, deux préfixes

• Les chemins sous chaque préfixe gardent la forme de l'ADR 0027 : index.json, puis manifestes et ressources en hash de contenu.
• Le calendrier des parutions, staging/parutions.json, liste les fascicules en attente, leur date d'effet en UTC et le chemin de leur manifeste. Comme l'index, il ne cite que des manifestes : seul le manifeste cite les ressources de son fascicule (cartes, recettes, exclusions, médias). Il remplace le manifeste serveur daté de l'ADR 0025, qui n'a plus de place dans un artefact unique.

Une liste blanche, fixée par l'infrastructure

La politique du bucket est écrite et appliquée par le dépôt d'infrastructure. Personne d'autre ne la modifie. Elle n'autorise que ceci :

• Tout le reste est refusé, y compris le listing anonyme et toute écriture dans public/ par la CI du catalogue. Même une CI mal réglée ne peut donc rien publier en avance.
• La tâche de parution a sa propre identité et sa propre clé, rangée dans Secret Manager. Elle ne peut modifier ni la politique, ni les droits, ni un autre bucket.
• Aucune ACL d'objet, aucun tag et aucune règle datée ne servent au contrôle d'accès.

La parution promeut les fichiers, puis l'index

À chaque date d'effet, la tâche planifiée de l'ADR 0025 :

1. lit le calendrier et retient les fascicules dont la date est passée ;
2. lit le manifeste de chaque fascicule dans staging/ et copie vers public/, sous le même chemin relatif, les ressources qu'il cite, puis le manifeste lui-même. Un fichier déjà présent dans public/, par exemple une brique reprise, n'est pas recopié : son contenu est identique ;
3. applique les migrations de progression ;
4. écrit en dernier le nouveau public/index.json.

• Tant que l'index n'est pas écrit, rien ne paraît : un fichier promu sans index n'est lisible que par qui connaît déjà son chemin, le jour même.
• La tâche est idempotente : relancée, elle ne recopie rien et réécrit le même index.
• Reporter ou annuler un fascicule revient à changer ou retirer sa ligne du calendrier. Revenir en arrière après la parution consiste à restaurer une version antérieure de l'index, que le versionnement du bucket conserve.
• Les fichiers restent dans staging/ après la parution. C'est la CI du catalogue qui les supprime.

L'API suit l'index publié

• L'API lit le catalogue comme le client, sans clé, dans public/. Elle ne voit un fascicule qu'une fois l'index publié.
• Cela remplace, dans l'ADR 0025, la bascule décidée par la seule horloge de l'API. La date d'effet reste celle du calendrier, mais c'est la tâche de parution qui l'exécute. Si elle échoue, le fascicule ne paraît ni pour le client ni pour l'API.
• L'horloge du serveur fait toujours foi pour l'énergie, les sabliers et les plafonds (ADR 0024).

Options envisagées

Chemins en hash de contenu seulement (ADR 0027)

Aucune infrastructure en plus, mais un chemin qui fuite livre le fichier avant sa date. Écarté : c'est justement le risque à fermer.

ACL d'objet ou tags, changés par la tâche à la parution

Chez Scaleway, la politique de bucket prime sur les ACL d'objet, et aucune condition ne porte sur les tags. Écarté : ce ne serait pas un contrôle d'accès.

Politique réécrite par la tâche à chaque parution

La tâche devrait pouvoir écrire la politique, donc s'accorder n'importe quel droit, et l'infrastructure verrait chaque mois une dérive. Écarté.

Règles datées dans la politique (aws:CurrentTime)

Aucune tâche à écrire, mais les dates de parution et les préfixes des fascicules seraient écrits dans le dépôt public de l'infrastructure. Écarté : c'est l'information qu'on protège.

Un bucket privé pour les fascicules à venir

Même garantie, mais un deuxième bucket, que l'ADR 0027 a supprimé. Écarté : un préfixe suffit.

Conséquences

Positives

• Aucun fichier d'un fascicule à venir ne se lit avant sa date, même par qui connaît son chemin. Le critère de réévaluation de l'ADR 0025 sur les médias en circulation est levé.
• Un seul bucket, une seule politique, fixe et relue avec l'infrastructure.
• Ni la CI du catalogue ni une erreur de chemin ne peuvent publier en avance : seule la tâche de parution écrit dans public/.

Négatives

• La tâche de parution devient le seul chemin de publication. Si elle échoue, rien ne paraît et il faut une alerte ; si elle dépasse sa durée maximale, la parution est retardée.
• La promotion recopie chaque fichier d'un fascicule : un peu de stockage et de temps en plus à chaque parution.
• La tâche détient une clé qui peut écrire dans public/. Une fuite de cette clé permettrait de publier en avance ou de remplacer l'index.

Critères de réévaluation

• Une parution dépasse 5 minutes ou échoue deux fois de suite : revoir la copie, par exemple en ne promouvant que l'index et les fichiers absents de public/.
• Scaleway propose une condition sur les tags d'objet ou une identité de charge de travail : réétudier le marquage des objets, ou supprimer la clé statique de la tâche.
• Le besoin de secret s'étend après la parution (recettes, légendaires) : étudier un préfixe lisible par la seule API.

• Statut : Proposé, partiellement remplacé par l’ADR 0069 : le serveur accorde les graines d’un fascicule quand il est débloqué pour le joueur, et non plus à sa parution. Le reste du présent ADR reste en vigueur.
• Portée : couche ludique du catalogue, manifeste de fascicule, données du joueur
• Précise : ADR 0012 (réserve de départ), ADR 0004 (graines comme sources), ADR 0009 (paramètres d'équilibrage)
• Complète : ADR 0027 (contenu du manifeste), le modèle de données (couche ludique et données du joueur)

Contexte

L'ADR 0012 donne au joueur une réserve de départ : quelques briques, en quelques exemplaires, qui permettent les premières découvertes sans ouvrir de pli. Le game-design en fait des graines et fixe une règle d'amorçage : au moins trois recettes immédiatement réalisables, avec assez d'exemplaires pour les réaliser toutes.

Rien ne dit pourtant où ces graines sont déclarées, ni quand le joueur les reçoit. Le modèle de données les range dans la couche ludique sans leur donner de forme. L'application ne peut donc pas accorder la réserve de départ, et le validateur ne peut pas vérifier la règle d'amorçage.

Les fascicules paraissent chaque mois (ADR 0022) et chacun est autonome : il déclare toutes les unités dont il a besoin. Un joueur qui arrive au troisième fascicule doit pouvoir commencer comme celui qui était là au premier.

Décision

Les graines appartiennent au fascicule

• Un fascicule déclare ses graines : une liste de briques, chacune avec un nombre d'exemplaires de 1 à 5 (le plafond de l'ADR 0012).
• Une graine est une brique d'une unité déclarée par ce fascicule, comme résultat ou comme ingrédient.
• Une brique n'est semée qu'une fois par fascicule.
• Les graines sont un paramètre d'équilibrage (ADR 0009) : les changer ne touche à aucun fait linguistique.

Le validateur vérifie l'amorçage

En avertissement :

• avec ses seules graines, un fascicule permet au moins trois recettes, toutes réalisables ensemble avec les exemplaires semés ;
• le premier fascicule (le plus petit numéro) déclare des graines.

Un fascicule suivant peut ne rien semer : il s'appuie alors sur les plis et sur les briques déjà acquises.

Le manifeste les publie

Le manifeste de fascicule porte graines : brique_id et exemplaires, triés par brique. Comme les recettes, elles sont lisibles dès la parution (ADR 0027).

Le serveur les accorde une fois par fascicule

• Le serveur accorde à un joueur les graines de chaque fascicule paru qu'il n'a pas encore reçues, à sa première synchronisation où ce fascicule est paru, dans une seule transaction.
• Chaque exemplaire accordé est un mouvement de motif depart. Une table graine_accordee (joueur, fascicule) garantit qu'un fascicule ne sème qu'une fois, même si la commande est rejouée.
• La réserve reste plafonnée à 5 exemplaires par brique. Au-delà, rien n'est accordé pour cette brique. Les graines ne rapportent jamais d'encre.
• Accorder des graines incrémente la version_etat du joueur, comme toute mutation.

Options envisagées

Une réserve de départ globale, dans la configuration de l'application

Plus simple, mais l'équilibrage sortirait du catalogue et de sa validation. Chaque changement demanderait un déploiement de l'API. Écarté.

Des graines accordées seulement à la création du profil

Un joueur arrivé avant un fascicule ne recevrait jamais les graines de ce fascicule. Chaque fascicule devrait alors se jouer sans amorçage pour les anciens, avec amorçage pour les nouveaux. Écarté : le semis par fascicule traite tous les joueurs de la même façon.

Des graines sous forme de pli de jalon déterministe

Les plis de jalon (ADR 0012) donnent un contenu déterministe, mais ils coûtent un geste au joueur et n'existent pas encore. Écarté pour la réserve de départ ; les jalons restent l'outil des récompenses suivantes.

Conséquences

Positives

• La règle d'amorçage est vérifiée à chaque validation du catalogue.
• Chaque fascicule reste autonome, pour les nouveaux comme pour les anciens joueurs.
• L'équilibrage de la réserve de départ se change sans déploiement de l'API.

Négatives

• Un joueur ancien reçoit des exemplaires gratuits à chaque fascicule qui sème : les graines d'un fascicule suivant doivent rester modestes.
• Une table et un motif de mouvement de plus dans les données du joueur.

Critères de réévaluation

• Les graines des fascicules suivants déséquilibrent le rythme des joueurs anciens (plus de découvertes sans pli que prévu par la simulation de l'ADR 0012).
• Les jalons et leurs plis déterministes suffisent à amorcer chaque fascicule.

• Statut : Proposé
• Portée : dépôt App (PWA et API)
• Précise : ADR 0024 (« un schéma unique, dont on génère les types TypeScript du front ») et ADR 0001 (PWA)

Contexte

L'ADR 0024 exige que les types des commandes et de l'artefact soient décrits par un schéma unique, dont on génère les types TypeScript de la PWA. Il ne dit ni où vit ce schéma, ni comment il est produit. Il choisit React et un service worker Workbox sans fixer l'outillage.

Deux voies existent : écrire le schéma à la main, puis en générer le Rust et le TypeScript ; ou tirer le schéma des types Rust, qui portent déjà la validation (deny_unknown_fields, formats, bornes).

Décision

Les types Rust sont la source de vérité

• Les requêtes et réponses de l'API, et les formats de l'artefact lus par la PWA, sont des types Rust annotés (serde, utoipa).
• La commande etymo-api openapi en tire contrat/openapi.json (OpenAPI 3.1), versionné dans le dépôt.
• La PWA en génère ses types TypeScript (openapi-typescript), versionnés eux aussi.
• La CI régénère les deux fichiers et échoue s'ils diffèrent de ceux du dépôt : aucun contrat ne dérive en silence.

La PWA est compilée par Vite

• Vite, React et TypeScript strict ; vite-plugin-pwa produit le service worker Workbox et le manifeste d'application.
• Le service worker précache la coque seulement. Les fichiers hachés du catalogue sont mis en cache à la première lecture ; l'index est revalidé à chaque lancement (ADR 0025, ADR 0027).
• Tant que le CDN ne pose pas d'en-têtes, la CSP stricte est posée dans la page à la compilation, avec les seules origines de l'API et du catalogue.

Options envisagées

Schéma écrit à la main, code généré des deux côtés

Un seul fichier neutre, mais la génération de Rust depuis OpenAPI produit des types moins précis que ceux écrits à la main, et la validation se répartirait entre le schéma et le code. Écarté.

Types TypeScript écrits à la main

Écarté : c'est précisément la dérive que l'ADR 0024 veut éviter.

Create React App, Next.js

Create React App n'est plus maintenu. Next.js suppose un serveur pour ce qui fait sa valeur, alors que la PWA est servie en fichiers statiques. Écartés.

Conséquences

Positives

• Un seul endroit pour changer une commande : le type Rust, qui la valide aussi.
• Une dérive entre l'API et la PWA casse la CI, pas la production.

Négatives

• Deux fichiers générés à régénérer et à versionner à chaque changement du contrat.
• Le schéma dépend des capacités d'utoipa pour décrire les types Rust.

Critères de réévaluation

• Un second client (application native, outil éditorial) a besoin du contrat sans la chaîne Rust.
• utoipa ne sait plus décrire fidèlement un type du contrat.

• Statut : Accepté, partiellement remplacé par l'ADR 0033 : table pleine, une troisième brique ne remplace plus rien ; seul un dépôt sur une case pleine la remplace
• Remplace partiellement : ADR 0003, pour le nombre d'emplacements d'une recette ; ADR 0014, pour le périmètre de la règle de fermeture
• Complète : ADR 0013 (tables recette et emplacement)

Contexte

L'ADR 0003 décrit une recette comme une liste ordonnée d'emplacements, sans en fixer le nombre. La vision du jeu laissait la question ouverte (« combien de briques une recette peut-elle utiliser sans devenir illisible ? ») et les maquettes montraient un rail de trois cases au plus, alors que la démonstration jouable n'en a que deux. La règle de fermeture de l'ADR 0014 dépend de ce nombre : elle couvre toute suite de briques « jusqu'au nombre maximal de briques sur la table ».

Sans limite fixe, le nombre de combinaisons à vérifier croît très vite, la table devient dense sur mobile et le retour « presque » perd sa lisibilité.

Décision

• La table de fusion a exactement deux emplacements, numérotés 1 et 2. Il n'est pas possible de fusionner trois briques ou davantage en une fois.
• Fusionner n'est actif que lorsque les deux emplacements sont remplis. Une seule brique ne se fusionne pas.
• Une troisième brique ne s'ajoute jamais à la table : elle remplace celle de l'emplacement visé (le deuxième par défaut sur mobile), qui revient à la réserve sans rien consommer.
• Une recette a exactement deux emplacements. Chacun accepte une ou plusieurs briques (variantes admises, ADR 0003). Le serveur refuse toute tentative qui ne contient pas exactement deux briques.
• Une découverte consomme donc toujours deux exemplaires : un de chaque brique.
• Fermeture : la règle de l'ADR 0014 porte sur les paires ordonnées de briques publiées. Une composition de trois parties ou plus n'est pas jouable telle quelle et n'entre pas dans la fermeture.
• Un mot plus long se formera en cascade, deux par deux, quand un mot découvert pourra redevenir une brique (biologie, puis biologie + -iste), comme le décrit le potentiel d'évolution.
• L'indice de niveau 2, « nombre d'ingrédients », n'apprend plus rien : il devient « nature des deux briques » (préfixe, suffixe ou mot), dans l'ordre des emplacements.

Options envisagées

Trois briques au plus

Écartée : le rail de trois cases est serré sur un écran de 390 px, le nombre de combinaisons à fermer passe du carré au cube du nombre de briques, et un « presque » sur trois briques est difficile à formuler sans donner la solution.

Nombre libre, fixé par chaque recette

Écartée : le joueur ne sait jamais quand sa proposition est complète, et la fermeture n'a plus de borne vérifiable.

Conséquences

Positives

• geste simple et identique sur mobile et ordinateur : deux cases, un « + », un bouton ;
• fermeture bornée et vérifiable : pour n briques publiées, n × n paires ordonnées au plus ;
• retour « presque » lisible : ordre inversé, ou une seule des deux briques juste ;
• coût d'une découverte constant et prévisible pour l'équilibrage des plis.

Négatives

• les mots de trois éléments ou plus ne sont pas jouables dans le MVP, sauf à les analyser en deux parties dans une composition synchronique relue ;
• l'indice « nature des deux briques » en dit un peu plus que l'ancien « nombre d'ingrédients » ;
• la cascade par mots-ingrédients reste à concevoir.

Critères de réévaluation

• Des mots essentiels à un fascicule ne peuvent s'analyser en deux parties sans trahir leur histoire.
• Les tests montrent que les joueurs cherchent spontanément à poser une troisième brique et ne comprennent pas le refus.

• Statut : Accepté
• Remplace partiellement : ADR 0001, pour la sélection suivie de « Ajouter à la table » ; ADR 0032, pour la troisième brique qui remplace celle de l'emplacement visé
• Complète : ADR 0032 (deux emplacements), la démonstration de la table et le mouvement

Contexte

L'ADR 0001 prévoyait sur mobile un geste en deux temps : toucher une brique pour la sélectionner, puis « Ajouter à la table ». Les maquettes cernaient la brique sélectionnée d'un anneau Corail. L'ADR 0032 fixe deux emplacements, et remplace la brique de l'emplacement visé quand la table est pleine.

À l'essai de l'application, le double geste paraissait lent et l'anneau Corail se confondait avec une action. Le remplacement silencieux effaçait une hypothèse en cours sans que le joueur l'ait voulu. Et quand on retirait la première brique, la seconde glissait à sa place : l'ordre, qui fait partie de l'hypothèse, changeait tout seul.

Décision

Poser et retirer

• Un toucher ou un clic sur une brique de la réserve la pose dans la première case libre, sur mobile comme sur ordinateur. Il n'y a plus de sélection ni de bouton « Ajouter à la table ». Le glisser-déposer pose sur la case visée.
• Table pleine : rien ne se passe. Une troisième brique n'en remplace aucune. Seul un dépôt explicite sur une case pleine la remplace.
• Chaque brique garde sa case. Toucher une brique posée la rend à la réserve et laisse sa case vide ; l'autre brique ne bouge pas. Glisser une brique sur l'autre case les échange, ou la déplace si cette case est vide. Au clavier : flèches pour échanger, Suppr pour vider.
• Fusionner est le bouton principal, sur toute la largeur, suivi de Vider. Le retour de la tentative s'écrit dessous, en ligne.

Retours et mouvement

• Aucun anneau Corail sur une brique, posée ou non. Le focus clavier est un anneau Encre.
• Découverte (après la réponse du serveur, jamais avant) : les deux briques se rejoignent, deux ondes et des confettis (700 ms), puis la fiche s'ouvre. Un « −1 » s'envole une seule fois des briques utilisées.
• Refus doux : échec, « presque », combinaison écartée ou réserve insuffisante secouent brièvement la table (500 ms, mouvement), sans perte. Un mot déjà découvert ne secoue pas : sa fiche est rappelée.
• « Continuer » après une découverte : la carte se réduit et vole jusqu'à l'onglet Codex, qui la reçoit d'un rebond (620 ms, comme le vol de carte). Mouvement réduit : la fiche se ferme simplement.

Ce qui quitte l'écran de la table

• Les découvertes récentes ne s'affichent plus sous la table : le codex et son compteur Corail les portent seuls.

Options envisagées

Garder la sélection puis « Ajouter à la table »

Écartée : deux gestes pour un, et un anneau Corail qui ressemble à une action. Le toucher direct reste accessible : la brique est un bouton, et le clavier garde ses raccourcis.

Remplacer la dernière brique quand la table est pleine

Écartée : l'hypothèse change sans que le joueur l'ait demandé.

Tasser les briques quand on en retire une

Écartée : l'ordre des briques fait partie de l'hypothèse ; il ne doit changer que par un geste du joueur.

Conséquences

Positives

• une brique se pose en un geste, identique au doigt et à la souris ;
• l'hypothèse posée ne change que par un geste explicite ;
• la table ne porte que ce qui sert à la fusion.

Négatives

• un toucher involontaire pose une brique : un autre toucher la retire, sans rien consommer ;
• le remplacement d'une brique exige un glisser-déposer.

Critères de réévaluation

• Les tests montrent des poses involontaires fréquentes au toucher.
• Les joueurs cherchent à remplacer une brique d'un toucher sans y parvenir.

• Statut : Accepté
• Complète : ADR 0001 (PWA) et la règle « changer d'onglet conserve l'état de chaque écran » des interfaces

Contexte

Un rechargement de la PWA ramenait toujours à la table : l'onglet, les filtres du codex et la carte agrandie étaient perdus. Le bouton Précédent du navigateur ne ramenait pas non plus à l'écran d'avant. Or la PWA est servie en fichiers statiques (ADR 0024), sans réécriture d'adresse côté serveur.

Décision

• L'écran courant est tenu dans le fragment de l'adresse : #/table, #/codex, #/plis, #/reglages.
• Dans le codex, le fragment porte aussi la carte agrandie, par son identifiant opaque, et la vue : filtre par type, tri et fascicule (#/codex/unt_…?type=mot&tri=az&fascicule=0).
• Précisé à l'usage : la vue du codex (vue=recentes, familles, objectifs), le sens du tri (sens=inverse) et la section « En savoir plus » dépliée (plus=1, seulement avec une carte ouverte) y figurent aussi. L'atelier du pli d'un fascicule se lit dans #/plis/fsc_…. Le texte d'une recherche n'y figure jamais.
• Changer d'onglet ou ouvrir une carte ajoute une étape à l'historique ; changer un filtre ou le tri la remplace.
• Une adresse inconnue ou forgée retombe sur la table ; un identifiant de carte invalide est ignoré. L'adresse ne porte jamais de texte du catalogue.
• La table en cours, la réserve confirmée et les réglages restent gardés sur l'appareil (ADR 0007) : l'adresse ne décrit que ce qu'on regarde.

Options envisagées

Chemins d'adresse (/codex/unt_…)

Plus lisibles, mais chaque chemin devrait renvoyer index.html : l'Object Storage et le CDN n'ont pas de réécriture simple. Écarté pour le MVP.

État d'écran dans le stockage local

Il survivrait au rechargement, mais ne se partagerait pas et ignorerait le bouton Précédent. Écarté.

Conséquences

Positives

• un rechargement ou le bouton Précédent ramène au même écran ;
• une carte du codex se désigne par une adresse, sans rien dévoiler de son texte.

Négatives

• adresses avec un #, moins lisibles ;
• un identifiant de carte figure dans l'adresse : il reste opaque, mais il circule avec elle.

Critères de réévaluation

• Le CDN permet de servir index.html pour tout chemin de la PWA.
• Des adresses de cartes partagées révèlent une carte avant sa découverte.

• Statut : Accepté, partiellement remplacé par l’ADR 0043 : les légendaires n’ont plus de poids ; elles se partagent une chance fixe de 3 % par pli. Le reste du présent ADR reste en vigueur.
• Remplace partiellement : ADR 0011, pour le poids du type et la répartition du poids entre les briques d’une même classe ; ADR 0016, pour les briques que tire le pli d’un fascicule

Contexte

L’ADR 0011 pondère une brique par le poids de sa rareté multiplié par le poids de son type (les suffixes à 1,25), puis répartit ce poids entre les briques de même rareté et de même type. L’ADR 0016 fait tirer au pli d’un fascicule toutes ses briques, nouvelles ou reprises.

La recette de J3 sur le fascicule d’essai en a montré deux effets :

• un mot posé comme brique (mener, biologie) sortait du pli comme un affixe, alors qu’un mot se découvre ;
• une brique seule dans sa classe prenait tout le poids de la classe : mener, seul mot commun, avait 23 % de chances, contre 14 % pour chaque suffixe commun.

Décision

Seuls les préfixes et les suffixes se tirent

• Le pli d’un fascicule ne tire que parmi ses préfixes et ses suffixes. Un mot n’est jamais tiré d’un pli, même s’il sert d’ingrédient à une recette.
• La garantie de nouveauté et le filet d’utilité choisissent eux aussi parmi ces seules briques.

Le poids d’une brique est le poids de sa rareté

• La chance d’une brique est proportionnelle au poids de sa rareté, et à lui seul : commune 62, peu commune 26, rare 10, légendaire 2.
• Il n’y a plus de poids de type, ni de répartition du poids entre les briques d’une même classe. Deux briques de même rareté ont toujours la même chance.
• Les chances par type restent affichées : elles se déduisent des chances de chaque brique.
• Les poids restent des paramètres versionnés d’équilibrage (ADR 0009).

Options envisagées

Garder le poids de type et la répartition par classe (ADR 0011)

Écartée : la chance d’une brique dépend du nombre de ses voisines de classe, ce qui la rend difficile à comprendre et fait d’une brique isolée la plus fréquente du pli.

Laisser les mots dans le pli avec un poids de type faible

Écartée : un mot se découvre à la table ; le tirer d’un pli brouille la frontière entre découverte et collection.

Conséquences

Positives

• Une règle lisible : la rareté seule décide, et deux briques de même rareté ont la même chance.
• Le pli ne distribue que des affixes : les mots restent des découvertes.

Négatives

• Un mot qui sert d’ingrédient ne s’obtient plus par un pli : il doit venir de la réserve de départ (ADR 0030) ou d’une autre règle à décider. La validation d’atteignabilité (ADR 0012) doit le vérifier.
• Les suffixes ne sortent plus plus souvent que les préfixes. Le rythme des fascicules est à recalculer.

Critères de réévaluation

• Un mot ingrédient impossible à obtenir en quantité suffisante : décider comment une découverte donne des exemplaires de son mot.
• Des tests qui montrent trop peu de suffixes pour composer : revoir les raretés éditées plutôt que réintroduire un poids de type.

• Statut : Accepté
• Remplace partiellement : ADR 0015, pour ce que l’écran des plis laisse deviner des légendaires d’un fascicule
• Complète : ADR 0011 (transparence des chances)

Contexte

L’ADR 0015 garde le suspense sur les légendaires : une légendaire inconnue n’a ni silhouette ni place dans les compteurs, et les légendaires inconnues d’un pli forment une seule ligne, sans leur nombre.

L’écran des plis affiche les chances par rareté. Un fascicule sans légendaire affiche donc « Légendaire 0 % », ce qui révèle qu’il n’en contient aucune. Masquer la ligne dans ce cas éviterait de le révéler, mais l’écran n’afficherait plus toutes les probabilités du tirage. Or aucun texte français trouvé n’impose cet affichage pour un jeu gratuit. Les obligations connues viennent des magasins d’applications (Apple, Google), des engagements des consoliers (2019) et de PEGI (objets aléatoires payants classés PEGI 16 depuis juin 2026). Le choix repose sur la loyauté envers le joueur et la préparation de la boutique ; le conseil juridique dira si un texte s’applique.

Décision

• L’écran des plis affiche toujours la chance des quatre raretés, légendaire comprise, même quand elle vaut 0 %.
• Le suspense porte sur le nombre et la nature des légendaires : une légendaire inconnue n’a toujours ni silhouette, ni place dans les compteurs, ni ligne propre dans les chances de chaque brique ; les légendaires inconnues restent regroupées en une seule ligne, sans leur nombre (ADR 0015).
• Qu’un fascicule n’ait aucune légendaire devient lisible. C’est accepté.

Options envisagées

Masquer la ligne des légendaires quand il n’y en a aucune

Écartée : l’écran n’afficherait plus toutes les probabilités du tirage, ce qu’exigent les magasins d’applications et PEGI, et ce que la loyauté envers le joueur demande.

Afficher une chance arrondie ou une fourchette

Écartée : une chance affichée n’est jamais arrondie de manière trompeuse (ADR 0011).

Conséquences

Positives

• Les probabilités affichées sont complètes et exactes, loyales envers le joueur, conformes aux exigences des magasins et de PEGI, prêtes pour une boutique.
• Le nombre et la nature des légendaires restent secrets.

Négatives

• Un joueur sait qu’un fascicule ne contient aucune légendaire quand la ligne affiche 0 %.

Critères de réévaluation

• Le conseil juridique cite un texte, ou le cadre légal ou les règles des magasins changent sur l’affichage des probabilités.

• Statut : Accepté
• Portée : dépôt App (PWA)
• Complète : ADR 0031 (service worker produit par vite-plugin-pwa) et ADR 0024 (PWA statique, API serverless)

Contexte

Le service worker sert la coque de la PWA depuis son cache. Avec une mise à jour automatique en arrière-plan, un navigateur garde l’ancienne version jusqu’à un second chargement : après les déploiements de J2 et J3 en hors-prod, la nouvelle version n’était pas visible tout de suite, et on ne pouvait pas la valider directement.

La vérification doit tourner en continu. Or l’API est serverless et redescend à zéro instance sans trafic (ADR 0024) : une vérification qui l’appelle la tiendrait éveillée pour rien.

Décision

Détecter

• Le navigateur relit le service worker (sw.js) sur le CDN, là où la PWA est déposée en fichiers statiques et servie sans cache HTTP. L’API n’est jamais appelée pour cette vérification.
• La vérification a lieu à l’ouverture de la page, puis toutes les 60 secondes tant que l’onglet est visible et en ligne, au retour sur l’onglet et au retour du réseau.
• Chaque build change sw.js, qui porte l’empreinte de chaque fichier de la coque : toute nouvelle version déployée est détectée.

Annoncer

• La nouvelle version s’installe en attente. Un écran plein et opaque passe alors devant la PWA et bloque le jeu, avec une seule action : « Mettre à jour ».
• Le bouton active la nouvelle version et recharge tous les onglets ouverts. Recharger la page sans cliquer ramène le même écran.
• La table en cours est sauvegardée dans IndexedDB et survit au rechargement.

Présenter les nouveautés

• Cet écran servira aussi à afficher le changelog de la nouvelle version : ce qu’elle apporte au joueur, avant qu’il clique sur « Mettre à jour ».
• Le changelog sera livré avec la version, en fichier statique, et lu sur le CDN comme le reste de la vérification.

Options envisagées

Mise à jour automatique, sans écran

C’était le comportement initial (registerType: 'autoUpdate'). Écartée : l’ancienne version reste affichée jusqu’à un second chargement, et le joueur ne sait pas qu’il a changé de version.

Rechargement forcé et silencieux

Il aligne la version tout de suite, mais recharge la page sous les yeux du joueur, sans explication, et ne laisse aucune place au changelog. Écarté.

Interroger l’API sur sa version

Écarté : chaque vérification réveillerait l’API, qui doit pouvoir redescendre à zéro.

Bandeau non bloquant

Écarté : le joueur continuerait à jouer sur une coque qui n’est plus déployée, contre un contrat d’API qui peut avoir changé.

Conséquences

Positives

• Une version déployée est visible dès l’ouverture de la page, ou dans la minute pour un onglet déjà ouvert : un déploiement en hors-prod se valide directement.
• La vérification ne coûte qu’une requête statique au CDN et ne réveille jamais l’API.
• Le joueur voit pourquoi la page change, et, avec le changelog, ce qu’apporte la nouvelle version.

Négatives

• Le jeu est interrompu à chaque déploiement, même mineur, jusqu’au clic.
• Un onglet ouvert relit sw.js chaque minute : une requête de plus au CDN par joueur actif.
• Le délai de détection dépend du respect de no-cache par le CDN pour sw.js.

Critères de réévaluation

• Des déploiements assez fréquents pour que l’interruption gêne les joueurs.
• Un coût de requêtes au CDN qui devient notable.
• Un CDN qui met sw.js en cache malgré les en-têtes.

• Statut : Accepté, pour sa section « Prix des indices » remplacée par l’ADR 0051 (trois indices au choix, plus de niveaux ordonnés), et partiellement remplacé par l'ADR 0039 : les sabliers de jalon s'ajoutent sans plafond de détention, aucun n'est perdu ; et par l'ADR 0042 : un jalon atteint n'est plus accordé d'office, sa récompense attend que le joueur la récupère dans la page Quêtes, où les jalons quittent l'onglet « Objectifs » du codex. Le reste du présent ADR reste en vigueur.
• Remplace partiellement : ADR 0020, pour le prix de l’indice ; le reste de l’ADR 0020 reste en vigueur
• Complète : ADR 0012 et ADR 0004, pour le format des jalons d’un fascicule ; ADR 0018, pour les sabliers donnés par un jalon

Contexte

L’ADR 0020 fixe un indice à 30 gouttes, sans distinguer ses cinq niveaux : famille ou langue du résultat, nature des deux briques, présence d’une transformation, emplacement d’une brique connue, solution. Au même prix, le joueur n’a aucune raison de prendre un indice vague plutôt que la solution, et la déduction perd son intérêt.

Les jalons, eux, sont annoncés depuis l’ADR 0012 : ils offrent un pli au contenu déterministe, et certains donnent des sabliers. Leur format n’a jamais été défini, et le manifeste d’un fascicule publie une liste de jalons toujours vide. Le jalon J4 de la roadmap de l’App les livre avec les sabliers et les indices.

Décision

Prix des indices

• Le prix double à chaque niveau : 155 gouttes pour les cinq niveaux d’une recette.
• Les niveaux 1 à 3 coûtent 35 gouttes ensemble, près des 30 gouttes de l’ADR 0020, soit environ deux plis et demi d’encre.
• La solution seule coûte environ 13 plis d’encre, près d’une semaine de jeu gratuit : elle reste un dernier recours.
• Un indice porte sur une recette encore à découvrir, choisie parmi les silhouettes du codex. Une recette légendaire, cachée par l’ADR 0015, n’en reçoit pas.
• Les niveaux s’achètent dans l’ordre, un à la fois, et chacun ne se paie qu’une fois. Un niveau acquis reste lisible.
• Le barème est un paramètre d’équilibrage (ADR 0009). Les niveaux gratuits, débloqués par les essais, le temps ou les objectifs, restent prévus mais ne sont pas dans le MVP.

Format des jalons

Un fascicule déclare ses jalons dans son fichier éditorial, et le manifeste publié les reprend tels quels :

• Un jalon a une seule condition : un nombre de découvertes dans le fascicule. Les autres objectifs (famille, langues, transformations) viendront plus tard.
• Un jalon donne un pli, des sabliers, ou les deux ; jamais rien.
• Le serveur accorde un jalon une seule fois, dans la transaction de la découverte qui l’atteint, ou à la lecture de l’état si un jalon est publié après coup.
• Le pli de jalon suit les règles du pli (ADR 0012) : une brique dont la réserve est pleine se change en encre. Il ne consomme pas d’énergie et ne compte ni dans la garantie de nouveauté, ni dans le filet.
• Les sabliers donnés s’ajoutent à ceux détenus, dans la limite de 36 (ADR 0018). Au-delà, ils sont perdus pour l’instant.
• La récompense est affichée à l’avance dans l’onglet « Objectifs » du codex : un jalon n’est jamais un tirage.
• L’intégration des jalons au point fixe d’atteignabilité (ADR 0004) viendra avec l’étape 5 du pipeline.

Options envisagées

Garder un prix unique de 30 gouttes

Écartée : la solution coûterait autant que la famille du résultat, et un joueur bloqué irait droit à la solution.

Prix linéaire (10, 20, 30, 40, 50 gouttes)

Écartée : 150 gouttes au total, mais les premiers niveaux coûtent plus cher qu’aujourd’hui et la solution ne se distingue pas assez des niveaux qui la précèdent.

Conditions de jalon libres (familles, langues, transformations)

Écartée pour le MVP : elles demandent un langage de conditions et leur validation. Le nombre de découvertes suffit à rythmer un fascicule.

Récompense de jalon tirée au hasard

Écartée : l’ADR 0012 veut un pli de jalon déterministe, déclaré dans le graphe d’obtention, pour garantir les chemins critiques.

Conséquences

Positives

• Le joueur paie selon ce qu’il apprend : un indice vague reste abordable, la solution coûte cher.
• Les jalons ont un format vérifiable par le validateur et lisible par le serveur, sans nouveau langage.
• Les récompenses des jalons s’annoncent à l’avance, sans hasard.

Négatives

• Les cinq niveaux d’une recette coûtent 155 gouttes, cinq fois plus qu’un indice de l’ADR 0020.
• Des sabliers de jalon au-delà de 36 détenus sont perdus tant qu’aucun compteur en attente n’existe.
• Un jalon n’est pas encore pris en compte par la validation d’atteignabilité.

Critères de réévaluation

• Des joueurs bloqués qui n’achètent jamais le premier niveau : baisser le barème.
• Des joueurs qui achètent la solution sans passer par les niveaux 1 à 3 : relever l’écart.
• Un fascicule qui a besoin d’un objectif autre que le nombre de découvertes.
• Un jalon qui donne assez de sabliers pour dépasser régulièrement 36 détenus.

• Statut : Accepté, partiellement remplacé par l’ADR 0045 et l’ADR 0046 : l’encre ne s’obtient plus seulement en ouvrant des plis ; les quêtes, la carte de lecteur et le cadeau de bienvenue en donnent aussi, en quantité bornée, et le rythme reste borné. Le reste du présent ADR reste en vigueur.
• Remplace partiellement : ADR 0020 et ADR 0018, pour le prix du sablier (1 goutte), son achat implicite au moment de l'usage, le plafond de 12 sabliers par 24 h glissantes, sur l'usage comme sur l'échange, le plafond de 36 sabliers détenus et l'annonce du temps perdu avant de confirmer ; ADR 0038, pour les sabliers de jalon perdus au-delà de 36 détenus. Le reste de ces ADR reste en vigueur

Contexte

L'ADR 0018 plafonne l'usage : 12 sabliers utilisés par 24 h glissantes, gratuits comme achetés. L'ADR 0020 reprend ce plafond pour les sabliers du MVP.

Depuis l'ADR 0038, les jalons donnent des sabliers. Avec un plafond sur l'usage, un joueur qui en reçoit plusieurs ne peut pas s'en servir quand il en a besoin : sa récompense attend le lendemain. Le plafond ne doit pas retenir ce que le joueur a déjà gagné. Pour la même raison, le plafond de 36 sabliers détenus fait perdre des récompenses de jalon, ce que l'ADR 0038 notait comme une limite provisoire.

Par ailleurs, la feuille des sabliers proposait le plus grand nombre de sabliers sans perte et avertissait du temps perdu au-delà. À 11 h 59 du prochain pli, elle proposait 11 sabliers et expliquait qu'un 12ᵉ gaspillerait 59 minutes : le joueur devait choisir entre attendre une minute et lire un avertissement pour une perte négligeable.

Décision

Prix et échange

• Un sablier s'échange contre 10 gouttes d'encre, au lieu d'une. L'échange est un geste distinct, qui ajoute des sabliers à ceux détenus.
• Seuls les sabliers détenus s'utilisent. Utiliser un sablier ne prélève jamais d'encre.
• À ce prix, les 12 gouttes gagnées en 3 jours de jeu valent un sablier : l'encre sert d'abord aux indices, et les sabliers viennent surtout des jalons.

Plafonds

• Aucun échange entre ressources du jeu n'est plafonné. L'encre ne s'obtient qu'en ouvrant des plis : elle borne à elle seule le rythme, et un plafond d'échange ne ferait que retenir des gouttes déjà gagnées.
• Une commande d'échange porte au plus 1 000 sabliers : c'est une borne de la requête, pas une règle de jeu.
• Un sablier ne s'utilise toujours que si l'énergie est sous 2.
• Les sabliers d'un jalon s'ajoutent tous à ceux détenus : aucun n'est perdu.
• Une commande utilise au plus 24 sabliers, ceux qui remplissent une énergie vide.
• Le prix du sablier est un paramètre d'équilibrage (ADR 0009).

Boutique

• La boutique est un écran à part, ouvert depuis l'en-tête des plis et la carte de l'encre. Elle a deux sections :
  • Échanges : les ressources du jeu entre elles, aujourd'hui l'encre contre des sabliers, en lots de 1, 3 et 12 que la feuille permet d'ajuster ;
• Raccourcis : le joueur n'a pas à passer par la boutique quand une ressource manque. Sous les plis en attente, tant que l'énergie n'est pas pleine, un bouton propose « Remplir avec des sabliers » s'il en détient, sinon « Échanger contre des gouttes », qui ouvre directement la feuille d'échange.

Feuille des sabliers

• La feuille propose d'emblée le nombre qui remplit l'énergie : le temps restant avant 2 / 2, arrondi à l'heure supérieure, dans la limite des sabliers détenus et achetables.
• Ce nombre est aussi le maximum : le joueur ne peut pas dépenser un sablier qui ne servirait à rien.
• Aucun avertissement de temps perdu : seul le dernier sablier peut n'avancer qu'une partie de son heure, et la feuille affiche le temps réellement gagné.

Options envisagées

Garder 1 goutte le sablier, acheté au moment de l'usage

Écartée : à ce prix, l'encre achète le temps presque gratuitement, et l'achat implicite mélange deux gestes dans une même feuille.

Garder le plafond sur l'usage

Écartée : il retient les sabliers gagnés par les jalons, et le joueur ne comprend pas pourquoi une récompense déjà reçue est bloquée.

Garder l'avertissement de temps perdu

Écartée : l'avertissement porte sur moins d'une heure, et proposer un sablier de moins oblige le joueur à revenir pour quelques minutes.

Plafonner l'échange à 12 sabliers par 24 h

Écartée : l'encre ne s'achète pas et se gagne lentement (2 gouttes par pli, plus les doublons). Le plafond ne bornait donc que des gouttes déjà gagnées, obligeait à expliquer un second compteur et renvoyait le joueur au lendemain. Le plafond reste nécessaire pour l'achat en euros, où il borne la dépense (ADR 0018).

Échanger seulement depuis l'écran des plis

Écartée : l'échange se mêlait aux chances et à l'atelier du pli.

Conséquences

Positives

• Les sabliers gagnés s'utilisent quand le joueur le souhaite, et aucune récompense de jalon n'est perdue.
• Le rythme payé en encre reste borné par l'encre gagnée : 120 gouttes pour un pli de plus.
• Remplir l'énergie se fait en un geste, sans calcul ni avertissement.
• Le sablier a une valeur lisible face aux indices (5 à 80 gouttes).

Négatives

• Les sabliers gratuits accélèrent davantage le rythme : un joueur qui en a accumulé beaucoup peut remplir son énergie à chaque visite. L'énergie reste plafonnée à 2 plis en attente, ce qui limite le gain par visite.
• Un joueur qui a accumulé de l'encre peut l'échanger d'un coup contre plusieurs recharges : il renonce alors aux indices qu'elle aurait payés.
• Le dernier sablier peut perdre jusqu'à 59 minutes, sans que la feuille le dise.
• La promesse de l'ADR 0020 d'un pli offert tous les 3 jours grâce à l'encre ne tient plus : 12 gouttes font un sablier, soit une heure.

Critères de réévaluation

• Des jalons qui donnent assez de sabliers pour vider un fascicule en une journée.
• Des joueurs qui accumulent des centaines de sabliers : réintroduire un plafond de détention.
• Des joueurs qui échangent assez d'encre pour ouvrir plus d'un pli de plus par jour : réintroduire un plafond d'échange.
• Des joueurs qui n'échangent jamais d'encre : baisser le prix.

• Statut : Proposé, partiellement remplacé par l’ADR 0043 : un mot légendaire n’a ni silhouette ni forme de rareté avant d’être trouvé. Le reste du présent ADR reste en vigueur.
• Complète : ADR 0011 (raretés), ADR 0015 (légendaires secrètes), ADR 0035 (plis d’affixes)
• Remplace partiellement : la règle du codex selon laquelle une carte de mot ne porte jamais de rareté (codex.html)

Contexte

La rareté ne qualifie aujourd’hui que les briques élémentaires : elle fixe leur chance au pli et l’encre de leurs doublons. Une carte de mot n’en porte aucune. Pourtant, écrire un mot qui exige une brique rare demande plus de plis et plus de patience qu’un mot fait de briques communes. Rien ne le dit au joueur, et rien ne l’en récompense.

Depuis l’ADR 0035, un pli ne tire jamais un mot : la rareté d’un mot ne peut donc pas servir au tirage. Elle ne peut que se lire et récompenser.

Décision

La rareté d’un mot se déduit de ses briques

• La rareté d’un mot est la plus haute rareté parmi les briques qu’exige sa recette. Elle n’est pas éditée : aucune donnée à saisir, aucune relecture de plus.
• Un emplacement à variantes compte pour sa variante la moins rare ; un mot à plusieurs recettes, pour sa recette la moins rare. La rareté dit ce que le mot coûte au plus court.
• Seuls les préfixes et les suffixes ont une rareté publiée au pli. Un mot posé comme brique compte comme commun : il a déjà été gagné.
• Un mot qui exige une légendaire est donc légendaire. Il reste secret tant que la légendaire est inconnue (ADR 0015).
• Le serveur (etymo_domaine::pli::rarete_mot) et la PWA (rareteMot) appliquent la même règle.

Elle se voit

• La carte d’un mot au codex, et sa silhouette, portent la forme de sa rareté, comme celle d’un affixe.
• La forme d’un mot n’est jamais Ambre : l’Ambre reste la couleur des plis et des briques qu’ils donnent. Elle prend une teinte de son fond, sans contour : plus foncée sur un fond clair, plus claire sur un fond foncé (le bandeau Encre d’une carte de mot, la fiche en thème sombre). Jamais de blanc.
• La fiche de découverte affiche la forme et son libellé. L’annonce grandit avec la rareté, comme à l’ouverture d’un pli : « Rare ! », « Légendaire ! », et la forme tourne en apparaissant, sans halo.

Elle rapporte de l’encre

• La première découverte d’un mot rapporte des gouttes selon sa rareté : paramètre encre_decouverte de l’équilibrage du fascicule qui publie le mot (ADR 0009).
• Valeurs de départ, à mesurer : commune 2, peu commune 3, rare 5, légendaire 10.
• Le serveur crédite l’encre dans la transaction de la découverte, avec le motif decouverte. Une commande rejouée ne paie pas deux fois. Un mot déjà connu ne rapporte rien.

Options envisagées

Rareté éditée mot par mot

Écartée : une donnée de plus à saisir et à relire, qui peut contredire les briques du mot (un mot « commun » fait d’une brique rare).

Rareté la plus haute de toutes les variantes

Écartée : une variante rare rendrait rare un mot qu’on peut écrire avec des briques communes.

Affichage seul, sans encre

Écartée : la rareté d’un mot ne changerait rien au jeu, et l’effort d’obtenir une brique rare ne serait pas récompensé à la table.

Conséquences

Positives

• Le joueur voit quels mots demandent le plus de patience, et il en est récompensé.
• Aucune donnée nouvelle dans la couche linguistique ; la couche ludique ne gagne qu’un barème.
• La rareté ne dépend toujours pas du niveau de confiance (ADR 0009).

Négatives

• Une nouvelle source d’encre : le rythme des sabliers et des indices (ADR 0038, ADR 0039) est à recalculer.
• Changer la rareté d’un affixe change celle des mots qui l’exigent, y compris ceux déjà découverts.
• Un manifeste antérieur, sans encre_decouverte, ne paie rien à la découverte.

Critères de réévaluation

• Des joueurs qui gardent leurs briques rares pour les mots rares au lieu de composer : baisser le barème.
• Des mots ingrédients rares à obtenir (ADR 0035) : leur donner leur propre rareté dérivée.

• Statut : Accepté
• Portée : MVP, dépôt App (PWA) et dépôt design
• Remplace partiellement : ADR 0001 (préparation d'une fusion et tentative conservée hors connexion), ADR 0007 (« opérations en attente rejouables »), ADR 0024 (la table se prépare hors connexion)

Contexte

Les ADR 0001, 0007 et 0024 promettaient une préparation de la table hors connexion et une file d'opérations rejouables. Aucun code de file n'existe. Le serveur fait foi pour chaque commande, et le client n'a pas les recettes : une file ne ferait que différer un résultat que le joueur ne peut pas voir.

Décision

Hors connexion, le joueur consulte : codex, réserve, fiches, plis prêts, table déjà saisie (affichée, conservée en local). Il ne peut rien commander : ni pose ou déplacement de brique, ni fusion, ni ouverture de pli, ni sablier, ni indice, ni achat. Aucune file, aucun rejeu côté client. Toute mutation exige le réseau.

Le 409 suivi d'une resynchronisation (ADR 0024) reste valable, y compris après la parution d'un fascicule. L'idempotence serveur par clé de commande reste valable. Aucune migration de progression : la resynchronisation suffit.

Conséquences

• Positives : pas de file à tester ni à réconcilier ; aucun résultat local ambigu.
• Négatives : pas de jeu sans réseau.

Critères de réévaluation

Les tests montrent que l'attente du réseau gêne le jeu : rouvrir la question, par un nouvel ADR.

• Statut : Proposé, partiellement remplacé par l’ADR 0045 : l’onglet « Journalières » reçoit les quêtes du jour et la carte de lecteur, et un troisième onglet, « Au long cours », s’ajoute. Le reste du présent ADR reste en vigueur.
• Remplace partiellement : ADR 0038, pour le moment où le serveur accorde un jalon et pour l’endroit où ses récompenses s’affichent ; le format des jalons et le prix des indices restent en vigueur
• Complète : ADR 0007, pour la commande de récupération ; ADR 0034, pour l’adresse de la nouvelle destination

Contexte

L’ADR 0038 accorde un jalon dans la transaction de la découverte qui l’atteint : le pli de jalon et les sabliers arrivent dans la réserve sans geste du joueur. À l’usage, le cadeau passe inaperçu. Le joueur voit un compteur de sabliers bouger ou une brique nouvelle apparaître sans savoir d’où elle vient, et il ignore que des jalons existent tant qu’il n’ouvre pas l’onglet « Objectifs » du codex.

Les jalons n’ont rien à voir avec la collection : ils récompensent une progression. Les ranger dans le codex les cache, et le game-design prévoit d’autres objectifs (défi quotidien, familles, langues) qui auront besoin du même endroit.

Décision

Une destination « Quêtes »

• La PWA gagne une destination Quêtes, après le codex, dans la navigation principale (#/quetes).
• Elle a deux onglets :
  • Journalières (#/quetes/journalieres) : les quêtes journalières, annoncées comme « bientôt disponibles ». Leur contenu fera l’objet d’un ADR ; aucune n’existe dans le MVP.
  • Fascicules (#/quetes/fascicules) : les jalons de chaque fascicule paru, leur progression et leur récompense.
• L’onglet Fascicules se filtre par fascicule avec le même sélecteur que le codex (jaquette, nom, complétude) ; le filtre est dans l’adresse (?fascicule=0).
• Sans onglet dans l’adresse, la page ouvre Fascicules si une récompense attend le joueur, Journalières sinon.
• Les jalons quittent l’onglet « Objectifs » du codex, qui garde les familles et les langues et renvoie aux quêtes.

Un jalon atteint attend d’être récupéré

• Le serveur marque un jalon atteint dans la transaction de la découverte qui l’atteint, ou à la lecture de l’état si le jalon est publié après coup. Il n’accorde rien à ce moment-là.
• Le joueur récupère la récompense par un bouton « Récupérer » dans les quêtes. C’est une commande idempotente et transactionnelle (POST /jalon), avec sa clé et la version_etat connue du client : elle crédite le pli de jalon et les sabliers en une fois.
• Le pli de jalon suit toujours l’ADR 0038 : un exemplaire de chaque brique, de l’encre si la réserve est pleine, sans énergie, hors garantie et hors filet. Il est historisé comme un pli d’origine jalon, à la date de la récupération.
• Une récompense se récupère une seule fois : 403 si le jalon n’est pas atteint, 409 s’il est déjà récupéré.
• Une récompense qui attend n’expire jamais et ne se perd pas : pas de minuterie, pas de rappel pressant.
• Les jalons accordés d’office avant cette décision sont considérés comme récupérés.

Faire savoir que les récompenses existent

• Un compteur Corail signale les récompenses qui attendent : sur la destination Quêtes, sur l’onglet Fascicules et sur la carte du fascicule concerné. Le Corail garde son sens : quelque chose de nouveau attend le joueur.
• La découverte qui atteint un jalon le dit sur la table et propose « Récupérer la récompense ».
• La récompense de chaque jalon, atteint ou non, reste affichée d’avance : jamais un tirage.

Options envisagées

Garder l’octroi automatique et ajouter une annonce

Écartée : une annonce se ferme sans être lue, et le joueur ne relie toujours pas le cadeau à son origine. Le geste de récupérer rend la récompense visible et lisible.

Laisser les jalons dans le codex

Écartée : le codex est la collection, pas une liste d’objectifs. Les quêtes journalières et les autres objectifs à venir auraient encore besoin d’une autre place.

Récompenses qui expirent

Écartée : la boussole refuse la pression et la peur de manquer. Une récompense gagnée reste acquise.

Conséquences

Positives

• Le joueur sait d’où viennent ses briques et ses sabliers, et que les jalons existent.
• Une place est prête pour les quêtes journalières et les autres objectifs.
• La récupération reste une commande du serveur, idempotente, comme les autres (ADR 0007).

Négatives

• Un geste de plus pour obtenir une récompense ; un joueur qui ne va jamais dans les quêtes n’en reçoit aucune, même si le compteur le lui rappelle.
• Une sixième destination dans la navigation : sur mobile, elle passe dans le menu.
• Un onglet « bientôt disponible » tant que les quêtes journalières ne sont pas conçues.
• Les maquettes I-18 montrent encore les jalons dans le codex ; la page Quêtes reste à dessiner dans l’inventaire.

Critères de réévaluation

• Des récompenses atteintes et jamais récupérées chez une part notable des joueurs : rendre l’accès plus direct.
• Des quêtes journalières conçues : un ADR fixe leur contenu, leurs récompenses et leur renouvellement.
• Une navigation mobile trop chargée : regrouper des destinations.

• Statut : Proposé
• Remplace partiellement :
  • ADR 0011, pour la garantie de nouveauté, qui ne vise plus les légendaires, et pour la ligne de chance propre à une légendaire connue ;
  • ADR 0012, pour le filet d’utilité, qui ne choisit jamais une légendaire ;
  • ADR 0015, pour la ligne de chance d’une légendaire trouvée, pour la silhouette d’un mot légendaire une fois sa légendaire trouvée, et pour l’affichage des légendaires trouvées ;
  • ADR 0016, pour la garantie et le filet de chaque fascicule, qui ne portent plus que sur ses briques non légendaires ;
  • ADR 0035, pour le poids des légendaires, remplacé par une chance fixe ;
  • ADR 0040, pour la silhouette et la forme de rareté d’un mot légendaire encore inconnu.
• Complète : ADR 0036 (la ligne des légendaires n’affiche plus jamais 0 %) ; ADR 0038 (un pli de jalon ne contient jamais de légendaire) ; ADR 0004 (le tutoriel et la réserve de départ n’en emploient jamais)

Contexte

Les ADR 0015 et 0036 gardent secrets le nombre et la nature des légendaires d’un fascicule. Trois fuites les trahissent pourtant :

• Le nombre se calcule. Une légendaire pèse 2 et une commune 62 (ADR 0035), et toutes les chances affichées sont exactes (ADR 0036). La ligne des légendaires inconnues vaut donc leur nombre multiplié par la chance d’une commune, divisé par 31 : avec 6,2 % pour une commune et 0,4 % pour les légendaires inconnues, il en reste 31 × 0,4 / 6,2 = 2. Les chances par type trahissent aussi leur type, et la ligne de rareté leur nombre total.
• La garantie de nouveauté les donne. Elle vaut « tant qu’il reste des briques inconnues » (ADR 0011) : une fois toutes les autres briques connues, la dernière légendaire tombe au plus tard au 6ᵉ pli, et le message de garantie dit s’il en reste.
• « Légendaire 0 % » révèle un fascicule sans légendaire, ce que l’ADR 0036 avait accepté.

Les mots qui exigent une légendaire fuient aussi. Leur silhouette apparaît dès que leur légendaire est trouvée (ADR 0015). Au verso d’un affixe, ils entrent dans le compte des mots formés ; une fois trouvés, ils entrent dans la complétude du fascicule, dont le total augmente d’un d’un coup.

Sans la garantie, une légendaire de poids 2 ne serait presque jamais tirée : environ 0,2 % par pli, soit 14 % de chances en un mois pour un joueur assidu (75 plis). Or nous voulons qu’une fois son fascicule complet, le joueur assidu ait encore une vraie chasse à mener, sans jamais savoir combien de légendaires il lui reste.

Décision

Une chance fixe par pli

• Chaque pli a 1,2 % de chances de donner une légendaire, la même dans tous les fascicules, quel que soit leur nombre. Les légendaires d’un fascicule se partagent cette chance à parts égales.
• Les 98,8 % restants se répartissent entre les briques non légendaires selon le poids de leur rareté : commune 62, peu commune 26, rare 10 (ADR 0035).
• La chance est un paramètre d’équilibrage du pli, chance_legendaire_pour_mille (12 pour mille, soit 1,2 % ; ADR 0009).

Ce que montre l’écran des plis

• Les quatre raretés, toujours (ADR 0036) : la ligne « Légendaire » vaut 1,2 % dans tous les fascicules.
• Une seule ligne pour toutes les légendaires du fascicule, connues ou non : le diamant, « Légendaires » et 1,2 %, jamais leur nombre. Une légendaire trouvée ne retrouve pas de ligne propre : sa chance, 1,2 % divisé par leur nombre, le trahirait.
• Les chances par type (préfixes, suffixes) se calculent sans les légendaires : leur somme vaut 98,8 %.
• Chaque brique non légendaire garde sa chance exacte.

Les garanties

• La garantie de nouveauté (6ᵉ pli, ADR 0011, ADR 0016) et le filet d’utilité (5ᵉ pli, ADR 0012) ne choisissent que parmi les briques non légendaires du fascicule. Quand toutes ses briques non légendaires sont connues, la garantie de nouveauté s’arrête.
• Une garantie lointaine propre aux légendaires borne l’attente : dans chaque fascicule, le 100ᵉ pli d’affilée sans légendaire en donne une. Elle peut être déjà connue : c’est alors un doublon, qui ajoute un exemplaire ou de l’encre si la réserve est pleine (ADR 0019, ADR 0020). Son compteur est affiché.
• Seuls les plis ouverts avec l’énergie comptent pour les trois garanties, comme pour la garantie et le filet aujourd’hui (ADR 0038).
• Aucun message ne dit que toutes les briques d’un fascicule sont connues, ni qu’il ne reste aucune légendaire. Par exemple : « Vous connaissez toutes les briques de ce fascicule, hors légendaires : chaque pli remplit votre réserve. »

Au moins une légendaire par fascicule

• Chaque fascicule publie au moins une brique légendaire, employée par au moins une recette. Le validateur le vérifie avant toute publication.
• La ligne des légendaires n’affiche donc jamais 0 %, et ses 1,2 % ne disent rien de leur nombre.

Les mots légendaires

• Un mot est légendaire quand sa recette la moins rare exige une légendaire (ADR 0040).
• Avant d’être trouvé, il n’a ni carte, ni silhouette, ni piste, ni forme de rareté, même quand sa légendaire est déjà trouvée. Il n’apparaît dans aucune liste de mots formés, au verso d’une brique, et n’est visé par aucun indice, aucune quête, aucun filet.
• Il ne compte jamais, trouvé ou non, dans aucune jauge : complétude d’un fascicule, familles, langues, verso d’une brique, maîtrise (ADR 0044), quêtes au long cours (ADR 0045). Un fascicule reste « complet » quand toutes ses cartes non légendaires sont trouvées (ADR 0015).
• Une fois trouvé, il a sa carte, rangée à part avec les briques légendaires trouvées. Il se révise comme les autres, sans entrer dans la jauge de maîtrise.

Plis de jalon, tutoriel et réserve de départ

• Un pli de jalon ne contient jamais de légendaire : sa récompense est affichée d’avance (ADR 0042). Le validateur le vérifie.
• Le tutoriel, les graines (ADR 0030) et le cadeau de bienvenue (ADR 0046) n’emploient jamais de légendaire. Si étymologie ouvre le jeu (game design), la brique étymo- n’est pas légendaire.

Le compte des légendaires trouvées

• Un compteur, le diamant suivi du nombre (« ◆ 2 »), accompagne chaque jauge de complétude : en tête du codex, sur chaque fascicule du codex, sur le choix du fascicule de l’écran des plis et sur le sélecteur de la page Quêtes.
• Il compte les briques et les mots légendaires trouvés. Son nom accessible les détaille : « 2 légendaires trouvées : 1 brique, 1 mot ».
• Jamais de total ni de barre : seulement ce qui a été trouvé.
• Il s’affiche même à 0 : puisque chaque fascicule a au moins une légendaire, « ◆ 0 » ne trahit rien et, à côté de « complet », invite à la chasse.
• Le toucher n’affiche plus, dans le codex, que les légendaires trouvées.

Options envisagées

Garder le poids de 2 et la garantie de nouveauté

Écartée : le nombre de légendaires se calcule à partir des chances affichées, et la dernière tombe au plus tard au 6ᵉ pli.

Garder le poids de 2 sans garantie

Écartée : environ 0,2 % par pli, 14 % de chances en un mois pour un joueur assidu. La légendaire deviendrait presque introuvable.

Arrondir ou masquer les chances des légendaires

Écartée : une chance affichée n’est jamais arrondie de manière trompeuse, et toutes les probabilités du tirage restent affichées (ADR 0036).

Une ligne par légendaire connue

Écartée : sa chance, 1,2 % divisé par le nombre de légendaires, trahirait ce nombre.

Une garantie lointaine qui ne donne qu’une légendaire nouvelle

Écartée : quand elle cesserait de s’appliquer, le joueur saurait qu’il ne lui en reste aucune.

Une chance de 2 %, de 3 % ou de 5 %

Écartées : à 3 %, un joueur assidu a une chance sur deux d’en tirer une en dix jours et neuf sur dix sur un mois ; à 5 %, la chasse se termine trop vite. À 1,2 %, il a environ une chance sur quatre en dix jours et six sur dix sur un mois : la légendaire reste une chasse longue, et la garantie au 100ᵉ pli la borne.

Masquer le compte des légendaires trouvées tant qu’il vaut 0

Écartée : avec au moins une légendaire par fascicule, « 0 » ne révèle rien, et le compteur rend visible la chasse de fin de mois.

Conséquences

Positives

• Le nombre et la nature des légendaires restent secrets, même pour qui fait le calcul.
• Une fois son fascicule complet, le joueur assidu a encore une chasse réelle, sans attente sans fin grâce à la garantie au 100ᵉ pli.
• Les mots légendaires deviennent de vraies surprises : rien ne les annonce, et le joueur les déduit du sens de la brique légendaire.
• Le joueur garde le compte de ses légendaires, à côté de chaque jauge.

Négatives

• La chance d’une légendaire connue n’est plus affichée seule : seule la chance de l’ensemble l’est. La transparence de groupe est à faire valider juridiquement, comme le prévoit déjà l’ADR 0015.
• Chaque fascicule doit publier au moins une légendaire, et ses mots : une charge éditoriale de plus.
• Environ 30 % des joueurs devront attendre la garantie lointaine pour obtenir une légendaire : la probabilité de n’en tirer aucune en 99 plis est de 0,988 puissance 99, soit 30 %.
• 1,2 % des plis vont aux légendaires : le rythme des fascicules est à resimuler (ADR 0022).
• La démonstration et l’App sont à corriger. L’App compte aujourd’hui les mots légendaires au verso des affixes et dans la complétude des fascicules, et n’affiche les légendaires trouvées qu’à partir d’une, briques seulement (dépôt App : web/src/services/codex.ts, web/src/composants/Codex.tsx).

Critères de réévaluation

• Moins de la moitié des joueurs assidus trouvent une légendaire dans le mois de son fascicule : relever la chance.
• La garantie lointaine se déclenche pour plus de 10 % des joueurs : la chance est trop basse.
• Une règle de transparence sur les coffres à butin exige la chance de chaque objet.
• Les tests montrent que « ◆ 0 » à côté de « complet » est ressenti comme une frustration plutôt que comme une invitation.

• Statut : Proposé, format Découper remplacé par l’ADR 0053 : le joueur glisse une lame sur le mot, puis valide. Maîtrise « définitive » remplacée par l’ADR 0065 : une erreur fait perdre la maîtrise, et les cartes maîtrisées restent dans le tirage. Un septième format, Assembler, s’ajoute par l’ADR 0067. Le reste reste en vigueur.
• Complète : ADR 0012 (une activité qui ne consomme rien) ; ADR 0007 (une commande de plus sous autorité serveur) ; ADR 0045 (la quête de mémoire du jour)

Contexte

Entre deux plis, le joueur n’a parfois plus rien à faire : sa réserve ne permet aucune découverte, et l’attente peut durer jusqu’au filet du 5ᵉ pli (ADR 0012). Une fois son fascicule complet, il n’a plus de mot à chercher avant le suivant.

Le pilier Transmission veut que le joueur retienne ce qu’il découvre. L’étude de marché compte les étudiants parmi ses cibles, qui veulent réviser les racines grecques et latines en jouant. Le game design nomme aussi le risque inverse : un jeu « perçu comme un cours ».

Il faut donc une activité qui se joue sans énergie ni exemplaire, sur ce que le joueur a déjà trouvé, courte et ludique.

Décision

Ce que sont les ricochets

• Les ricochets sont de courtes questions sur les cartes déjà trouvées. Ils ne consomment rien : ni exemplaire, ni énergie, ni encre.
• Ils s’ouvrent depuis le codex et depuis la quête du jour qui les demande (ADR 0045). Ils n’ajoutent pas de destination à la navigation.
• Une séance compte 5 questions, environ une minute, en mêlant les formats. Elle choisit d’abord les cartes à revoir, puis les découvertes récentes.
• Le joueur fait autant de séances qu’il le souhaite. Seule une séance par jour compte pour les quêtes.

Six formats

• Réponses et leurres viennent des cartes trouvées et des briques connues du joueur : jamais d’une carte inconnue, qui serait dévoilée, jamais d’un mot inventé. Avec moins de quatre cartes disponibles, une question propose deux ou trois choix.
• Pas de chronomètre. Un toucher sur un choix répond, sans bouton « Valider ». Une brique s’affiche toujours comme une brique, jamais en texte brut, et sans sa glose quand la glose est la réponse. Une mauvaise réponse s’affiche en Gris encre, comme un échec à la table, jamais en rouge.
• Une mauvaise réponse ne coûte rien : la carte revient simplement plus tôt.
• Le codex n’affiche pas de nombre de cartes à revoir : un tas qui grossit se vit comme un devoir. Le bouton « Faire des ricochets » suffit.

La maîtrise

• Chaque carte trouvée a un niveau, de 0 à 3. Une bonne réponse à une carte à revoir la fait monter d’un niveau et éloigne sa prochaine révision : 1 jour, puis 3, puis 7. Une mauvaise réponse la fait descendre d’un niveau, et elle revient le lendemain.
• Au niveau 3, après trois bonnes réponses sur trois jours différents, la carte est maîtrisée, et le reste. Elle revient ensuite tous les 7 jours au plus.
• Une réponse à une carte qui n’est pas à revoir ne change aucun niveau : jouer plus ne fait pas monter plus vite.
• La maîtrise se voit sur la carte, par un signe à dessiner, distinct des formes de rareté, des cercles d’état et des trois traits de la confiance éditoriale (identité).
• Chaque fascicule a sa jauge de maîtrise (« 18 / 24 maîtrisées »). Les mots légendaires n’y comptent pas (ADR 0043).

Autorité serveur

• Niveaux et prochaines révisions sont des données du joueur. Le serveur vérifie chaque réponse, puisque les ricochets font avancer les quêtes (ADR 0045). La commande ricochet est idempotente, comme les autres (ADR 0007).
• Le verdict s’affiche dès la réponse : le client le calcule à partir du catalogue, qui est public. Attendre le serveur ne protégerait donc aucune réponse, et ralentirait chaque question. La commande part en même temps, et le serveur fait foi pour le niveau, la maîtrise et les quêtes. Le récapitulatif de fin de séance, lui, affiche les retours confirmés par le serveur.
• Hors connexion, les ricochets ne se jouent pas, comme toute commande (ADR 0041).

Le nom

« Ricochets » : chaque bonne réponse renvoie la carte plus loin, comme un galet qui rebondit de plus en plus loin. Le nom se décline : « Faites des ricochets », « Cinq ricochets sans faute », « Dans 7 jours, un ricochet juste et la carte géologie sera maîtrisée ».

Options envisagées

D’autres formats

Écartés : la langue d’origine d’un mot, le type d’une transformation, la silhouette d’une carte, la recomposition à la table, l’ordre des formes d’un mot d’une langue à l’autre, et la chronologie des mots, qui demanderait une donnée éditoriale de plus (la date de première attestation).

Récompenser chaque bonne réponse en encre

Écartée : une source d’encre illimitée lèverait la seule borne du rythme des sabliers, l’encre gagnée en ouvrant des plis (ADR 0039). Les ricochets récompensent par les quêtes.

Un chronomètre

Écarté : il presse le joueur et pénalise ceux qui lisent ou répondent plus lentement.

Attendre le serveur avant le verdict

Écarté : le catalogue public donne déjà toutes les réponses au client, l’attente n’empêcherait aucune triche et coûterait un aller-retour réseau par question.

Découper en touchant le mot

Écarté : sur mobile, les lettres sont trop étroites pour une cible de 44 px, et un mot en trois parties a plusieurs coupes justes.

Littéral ou actuel sur un seul sens

Écarté : une question à deux réponses, sur un sens montré seul, se gagne une fois sur deux au hasard, et devient ambiguë quand le sens littéral et la définition actuelle se ressemblent.

D’autres noms

Écartés : « Révision », « Exercices » et « Quiz », trop scolaires ; « Épreuves », vocabulaire de l’examen ; « Gammes », « Petits papiers » et « Mots en tête », moins parlants ; « Atelier », déjà pris par l’atelier des plis ; « Défis », qui se confondrait avec le défi du jour.

Conséquences

Positives

• Le joueur a toujours quelque chose à faire, sans énergie ni exemplaire.
• Ce qu’il découvre s’ancre : le pilier Transmission devient une activité.
• Aucun coût éditorial : tout vient des cartes publiées.
• La maîtrise ajoute une seconde complétude à chaque fascicule, utile une fois ses mots trouvés.

Négatives

• Le risque d’un jeu perçu comme un cours : les séances doivent rester courtes, facultatives et jamais notées.
• De nouvelles données du joueur (niveau, prochaine révision) et une commande de plus à vérifier.
• Un signe de maîtrise à dessiner, sans confusion possible avec les autres signes des cartes.

Critères de réévaluation

• Peu de joueurs font une séance hors des quêtes : les formats ne plaisent pas.
• Les tests montrent que les ricochets sont vécus comme un devoir.
• Les cartes deviennent maîtrisées trop vite ou jamais : revoir les intervalles.

• Statut : Proposé
• Remplace partiellement : ADR 0042, pour le contenu de l’onglet « Journalières », jusqu’ici annoncé « bientôt disponible », et pour le nombre d’onglets de la page Quêtes, qui passe à trois ; le reste de l’ADR 0042, dont la récupération des récompenses, reste en vigueur ; ADR 0039, pour la seule source d’encre : la carte de lecteur et les quêtes au long cours en donnent aussi, en quantité bornée
• Complète : ADR 0038 (d’autres conditions que le nombre de découvertes, pour les seules quêtes au long cours ; les jalons ne changent pas) ; ADR 0044 (les ricochets du jour)

Contexte

L’ADR 0042 a créé la page Quêtes avec un onglet « Journalières » vide, dont le contenu attendait un ADR. Le game design évoque aussi un défi quotidien construit à partir des briques possédées.

Deux moments menacent la fidélité du joueur : le jour où il n’a rien de particulier à faire, et la fin du mois, quand son fascicule est complet. Il lui faut une raison de revenir chaque jour, et des objectifs qui durent au-delà d’un fascicule.

La boussole refuse la pression et la peur de manquer : une récompense gagnée n’expire jamais (ADR 0042), le design système exclut la culpabilisation, et se tromper ne coûte rien.

Décision

Trois quêtes par jour

• Chaque jour, trois quêtes du jour, une de chaque sorte :
  • table : une déduction à la table de fusion ;
  • mémoire : des ricochets (ADR 0044) ;
  • adresse : découper des mots ou relier des paires.
• Elles se renouvellent à minuit GMT, la même heure pour tous. Une quête non faite disparaît au renouvellement, sans pénalité.
• Le serveur les tire à la première visite après minuit, seulement parmi celles que l’état du joueur rend faisables ce jour-là. Si la réserve ne permet aucune découverte, la quête de table cède sa place à une seconde quête de mémoire. Aucune quête ne dépend de l’énergie ni du hasard.
• Chaque quête demande un acte de réflexion : déduire, se souvenir, découper. Jamais un simple geste, comme retourner une carte ou ouvrir un pli.
• Elles portent sur les cartes à revoir et sur les découvertes récentes, jamais sur un mot légendaire (ADR 0043).
• Un échec ne coûte rien : un sans-faute manqué se recommence aussitôt, avec d’autres cartes.
• Le défi du jour du game design devient la quête de table : une recette que la réserve permet, donnée par sa seule piste de sens.

La carte de lecteur

• Quand ses trois quêtes du jour sont faites, le joueur gagne un tampon sur sa carte de lecteur, tamponnée comme une fiche de prêt de bibliothèque. Un tampon par jour au plus.
• Les jours n’ont pas besoin de se suivre : aucune série ne se brise, rien n’expire, la carte ne repart jamais à zéro.
• Au 7ᵉ tampon, une récompense annoncée d’avance, avec ces valeurs de départ, à simuler : 20 gouttes d’encre, 1 sablier et 1 pli de lecteur. Elle attend dans la page Quêtes jusqu’à ce que le joueur la récupère (« Récupérer », ADR 0042), et une nouvelle carte commence.
• Le pli de lecteur : le joueur choisit le fascicule ; le pli tire parmi ses briques peu communes et rares, selon leurs poids, et les légendaires y gardent leur chance de 3 % (ADR 0043). Ses chances sont affichées. Il ne consomme pas d’énergie et ne compte pour aucune garantie, comme un pli de jalon.
• Pas de flamme qui s’éteint : la carte « 4 / 7 » est le seul signe de régularité. Aucune notification ni aucun rappel ne la concernent.

Les quêtes au long cours

• Un troisième onglet de la page Quêtes, « Au long cours » (#/quetes/au-long-cours), réunit des objectifs qui traversent les fascicules. Ils n’expirent jamais et ne repartent jamais à zéro.
• Chaque quête a des paliers ; chaque palier a sa récompense, affichée d’avance, à récupérer comme un jalon.
• Cinq sortes de quêtes, toutes mesurées sur le codex du joueur :

• Récompenses : encre, sabliers et plis de lecteur, de plus en plus généreux avec les paliers. Les paliers se règlent pour qu’un joueur assidu reçoive environ une récompense par semaine.
• Un mot légendaire n’entre dans aucun décompte, et aucune quête ne fixe un nombre de légendaires à trouver, qui trahirait combien il en existe. Seule exception permise : « Trouvez votre première légendaire », puisque chaque fascicule en a au moins une (ADR 0043).
• Les conditions forment une liste fermée : langue, famille, transformation, maîtrise, carte de lecteur. Les quêtes sont déclarées dans le catalogue et contrôlées par le validateur ; le serveur calcule la progression. Il n’y a pas de langage de conditions libre. Les jalons restent définis par le nombre de découvertes (ADR 0038).

Récupérer et faire foi

• Une récompense de tampon ou de palier se récupère par une commande idempotente et transactionnelle, comme un jalon (ADR 0042). Elle n’expire jamais.
• Quêtes du jour, tampons et paliers sont des données du joueur, sous autorité du serveur (ADR 0007). Les définitions viennent du catalogue : quêtes du jour, récompense de la carte de lecteur et quêtes au long cours sont des paramètres d’équilibrage (ADR 0009).

Options envisagées

Des quêtes faites de simples gestes

Écartée : « Retournez une carte » ou « Ouvrez un pli » ne demandent aucune réflexion et deviennent des corvées.

Des quêtes qui dépendent de l’énergie ou du hasard

Écartée : un joueur qui a ouvert ses deux plis à 23 h n’en a plus avant 11 h le lendemain, et un tirage ne se commande pas.

Une série de jours consécutifs, ou flamme

Écartée : une série qui se brise culpabilise, ce que refuse le design système. La carte de lecteur récompense la régularité sans punir l’absence.

Un tampon pour une seule quête, comme dans Pokémon GO

Écartée : les trois quêtes, courtes, font ensemble le tampon du jour.

Une première carte de lecteur à trois cases

Écartée : la première semaine a ses propres récompenses (ADR 0046).

Renouveler les quêtes à minuit, heure locale

Écartée : une seule heure pour tous, minuit GMT, reste simple à calculer et à expliquer.

Un langage de conditions libre

Écartée : il faudrait l’écrire, le valider et l’expliquer. Cinq conditions couvrent les besoins.

Conséquences

Positives

• Une raison de revenir chaque jour, sans pression : rien ne se perd si l’on manque un jour.
• Des objectifs qui durent quand le fascicule du mois est complet.
• Aucun coût éditorial : quêtes et paliers se mesurent sur le contenu publié.

Négatives

• La carte de lecteur ajoute au plus quatre plis par mois, environ 5 % de plus pour un joueur assidu, auxquels s’ajoutent les paliers : le rythme des fascicules est à resimuler (ADR 0022).
• Le serveur doit tirer des quêtes faisables et vérifier leur réalisation.
• Minuit GMT tombe à 1 h ou 2 h du matin en France, et en soirée au Québec.
• La page Quêtes, avec ses trois onglets, et la carte de lecteur restent à dessiner.

Critères de réévaluation

• Une faible part des joueurs actifs termine ses trois quêtes : les quêtes sont trop longues ou trop difficiles.
• Les tests montrent que les quêtes sont vécues comme une corvée.
• Les paliers au long cours récompensent beaucoup plus ou beaucoup moins d’une fois par semaine.

• Statut : Proposé
• Remplace partiellement : ADR 0039, pour la seule source d’encre : le cadeau de bienvenue et les quêtes initiales en donnent aussi, une seule fois
• Complète : ADR 0030 (réserve de départ) ; ADR 0045 (quêtes du jour) ; ADR 0042 (récompenses à récupérer)

Contexte

Les premiers jours décident de la fidélité : dans les jeux de réflexion, environ un joueur sur trois revient le lendemain (étude de marché). Or, après le tutoriel, ses graines (ADR 0030) et ses deux premiers plis, le nouveau joueur attend la prochaine charge, 12 h plus tard.

Nous voulons une première semaine riche, avec plusieurs découvertes par jour, puis un ralentissement qui se fasse de lui-même, sans changer la durée de la recharge ni créer de frustration calculée.

Décision

La recharge ne change pas

Une charge toutes les 12 h, deux au plus, pour tous les joueurs et à tout moment (ADR 0020).

Un cadeau de bienvenue

• Chaque profil reçoit une fois un cadeau de bienvenue, à récupérer dans la page Quêtes (« Récupérer », ADR 0042) dès la fin du tutoriel.
• Valeurs de départ, à simuler :
  • 3 plis de bienvenue au contenu fixé, comme un pli de jalon, dont les briques sont choisies pour ouvrir des recettes, jamais une légendaire (ADR 0043) ;
  • 12 sabliers, soit un pli de plus ;
  • 40 gouttes d’encre, de quoi payer les trois premiers niveaux d’un indice (5 + 10 + 20).
• Les plis de bienvenue ne consomment pas d’énergie et ne comptent pour aucune garantie.
• Le catalogue déclare le cadeau. Ses briques appartiennent à des fascicules parus, et le validateur le vérifie.
• Dans l’interface, il s’appelle « Cadeau de bienvenue ».
• Il ne se présente pas dans la boutique : un cadeau affiché comme un achat à 0 € servirait surtout à habituer au geste d’achat.

Des quêtes initiales

• Pendant la première semaine, des quêtes initiales, faites une seule fois, généreuses puis de moins en moins. Elles suivent les règles des quêtes du jour : un acte de réflexion, jamais un simple geste, et toujours faisables (ADR 0045).
• Elles s’affichent en tête de l’onglet « Journalières » jusqu’à ce qu’elles soient toutes faites, et ne comptent pas pour le tampon du jour.
• Exemples, avec des valeurs de départ à simuler :

• Un pli offert est un pli ordinaire du fascicule que choisit le joueur, chances affichées, sans énergie et hors garanties. Le pli de lecteur est celui de la carte de lecteur (ADR 0045).

Un ralentissement naturel, jamais un levier d’achat

• Les règles sont les mêmes pour tous et affichées dès le début. Seuls le cadeau et les quêtes initiales s’épuisent : le ralentissement est naturel et prévisible.
• La générosité du départ se règle sur la rétention mesurée (ADR 0050), jamais sur des achats. Garde-fou : jamais plus de deux jours sans découverte possible pour un joueur actif (ADR 0012).
• Le ralentissement n’est pas personnalisé selon le comportement du joueur, aucune offre n’apparaît à un moment de frustration (ADR 0018), et aucune frustration n’est dosée pour pousser à l’achat : le game design refuse de « préparer des mécanismes trompeurs sous prétexte d’une monétisation future ».
• Avec plusieurs fascicules parus, les graines de chacun s’ajoutent au cadeau : la générosité du départ se simule avec la taille du catalogue à l’ouverture (ADR 0048).

Options envisagées

Accélérer la recharge la première semaine

Écartée : le compte à rebours garde toujours la même durée. Une recharge plus rapide, puis plus lente, ferait deux règles à expliquer et une perte ressentie au 8ᵉ jour.

Présenter le cadeau comme un achat gratuit dans la boutique

Écartée : il habituerait au geste d’achat, alors que la page Quêtes donne le même cadeau sans ambiguïté.

Doser la frustration pour pousser à l’achat

Écartée, pour trois raisons : les principes du jeu l’excluent (game design, ADR 0018) ; il n’y a rien à acheter pendant la bêta, ni avant l’ouverture de la boutique, et la frustration ne mènerait qu’au départ ; la boutique rapporte environ 0,05 € par joueur actif et par mois (plan financier), quand la rétention fait l’audience et le bouche-à-oreille.

Des quêtes de bienvenue faites de gestes

Écartée : retourner une carte ou suivre un lien n’apprend rien qu’un joueur ne découvre seul. Le tutoriel couvre la table de fusion.

Conséquences

Positives

• Une première semaine riche, sans changer aucune règle du jeu.
• Un ralentissement honnête : rien n’est retiré, le cadeau s’épuise simplement.
• Les quêtes initiales font découvrir les ricochets et la carte de lecteur en les vivant.

Négatives

• Plus de plis la première semaine : le rythme du premier fascicule d’un joueur est à resimuler.
• Le contenu du cadeau se choisit à chaque version du catalogue : ses briques doivent ouvrir des recettes.
• Un joueur qui récupère son cadeau tard en profite moins : la page Quêtes doit le signaler par son compteur Corail (ADR 0042).

Critères de réévaluation

• La rétention au 1ᵉʳ et au 7ᵉ jour ne progresse pas : revoir le contenu du cadeau et des quêtes initiales.
• Plus de 10 % des nouveaux joueurs restent plus de deux jours sans découverte possible pendant leur première semaine.
• Une forte chute d’activité à la fin du cadeau.

• Statut : Proposé, partiellement remplacé par l’ADR 0059 : la règle des tiers ne s’applique pas aux dix fascicules de lancement ; elle reste en vigueur à partir du onzième
• Complète : ADR 0022 (taille d’un fascicule) ; ADR 0009 (équilibrage dans la couche ludique)

Contexte

Rien ne règle aujourd’hui la difficulté d’un fascicule. Il pourrait ne contenir que des mots transparents, que l’on trouve sans réfléchir, ou que des mots dont la forme et le sens ont dérivé, qui découragent un joueur débutant.

Une difficulté croissante d’un fascicule à l’autre a été envisagée, puis écartée : un joueur qui arrive tard reçoit les graines de tous les fascicules parus (ADR 0030) et peut commencer par n’importe lequel. Chaque fascicule doit donc offrir à la fois des entrées faciles et de vrais défis.

Décision

La règle des tiers

• Chaque fascicule compte un tiers de mots faciles, un tiers de mots moyens et un tiers de mots difficiles, à un mot près.
• Les mots croisés comptent dans ces tiers ; les mots légendaires restent à part, hors des compteurs (ADR 0043).

Trois niveaux

• Chaque mot porte un champ difficulte dans la couche ludique, saisi par l’équipe éditoriale avec sa recette et relu avec elle.
• Le validateur avertit quand un fascicule s’écarte des tiers de plus d’un mot.

Un réglage invisible

• La difficulté n’est jamais affichée au joueur.
• Elle sert à l’équilibrage, et peut guider le choix de la quête de table du jour (ADR 0045).
• La rareté d’un mot (ADR 0040) reste une autre mesure : elle dit ce que coûtent ses briques, pas ce que demande sa déduction.

Options envisagées

Une difficulté croissante d’un fascicule à l’autre

Écartée : on garde une difficulté moyenne dans chaque fascicule, puisque le joueur peut commencer par n’importe lequel.

Une difficulté calculée sans jugement éditorial

Écartée : le nombre de transformations se calcule, mais l’écart entre sens littéral et sens actuel demande un jugement.

Afficher la difficulté

Écartée : un signe de plus sur les cartes, et une étiquette « difficile » peut décourager avant même d’essayer.

Conséquences

Positives

• Chaque fascicule offre environ huit à dix entrées faciles, pour un joueur qui arrive comme pour un habitué.
• Les défis restent présents dans chaque fascicule, sans courbe à suivre d’un mois à l’autre.

Négatives

• Une contrainte de plus pour composer un fascicule, en plus de la fermeture et des 20 à 30 mots.
• Un champ de plus à saisir et à relire, sur un jugement qui peut varier d’une personne à l’autre.
• Le skill nouveau-fascicule du dépôt de contenu est à mettre à jour.

Critères de réévaluation

• Les taux de découverte par niveau ne se distinguent pas : la définition des niveaux ne mesure pas la difficulté réelle.
• Les mots difficiles restent introuvables pour la plupart des joueurs, malgré les indices.

• Statut : Proposé, partiellement remplacé par l’ADR 0069 : un nouveau joueur n’a d’abord qu’un fascicule débloqué, et l’estimation de ce qu’il trouve le premier mois, qui supposait tout le catalogue ouvert, ne tient plus. Le reste du présent ADR reste en vigueur.
• Complète : ADR 0028 (la bêta tourne en production) ; ADR 0022 (un fascicule par mois) ; le plan financier (calendrier et budget de lancement)

Contexte

Le plan financier prévoyait une mise en production en janvier 2027, avec le fascicule 1 et le lancement presse le même mois. Un nouveau joueur n’aurait alors trouvé que 20 à 30 mots : un joueur assidu les épuise en moins d’un mois (ADR 0022), au moment même où sa fidélité est la plus fragile.

Il faut à la fois une masse de contenu à l’ouverture officielle, et une épreuve du jeu en conditions réelles avant de dépenser pour faire venir des joueurs.

Décision

Une bêta ouverte

• La bêta est ouverte à tous. Elle tourne en production, déployée par un tag v*.. (ADR 0028), et l’interface la signale par la mention « bêta ». L’environnement hors-prod reste réservé aux essais.
• Les fascicules paraissent pendant la bêta, au rythme habituel.
• Les joueurs de la bêta gardent toute leur progression à l’ouverture officielle.
• La mesure de la rétention (ADR 0050) est en place dès le premier jour de la bêta.

La taille critique avant l’ouverture officielle

• Critère : à l’ouverture, un nouveau joueur assidu ne doit pas pouvoir épuiser le catalogue en un mois.
• Estimation de ce qu’il trouve son premier mois, à confirmer par simulation : 55 à 60 mots. Environ 34 grâce aux plis (75 plis par mois, ADR 0022), une quinzaine grâce aux jalons, au démarrage généreux (ADR 0046) et à la carte de lecteur (ADR 0045), et les découvertes immédiates permises par les graines des fascicules (ADR 0030).

• Minimum : 3 fascicules ; cible : 4, soit environ 100 mots. Avec la règle des tiers (ADR 0047), 3 fascicules offrent déjà environ 25 mots faciles.
• L’ouverture officielle attend aussi que la bêta atteigne ses seuils, fixés avant son ouverture. Valeurs proposées : au moins 80 % de tutoriels terminés, au moins 25 % de joueurs revenus au 7ᵉ jour, et moins de 10 % de joueurs actifs restés plus de deux jours sans découverte possible.

Calendrier

• Janvier 2027 : la bêta ouvre avec les fascicules 1 et 2, tous deux prêts d’après le plan financier.
• Février 2027 : fascicule 3.
• Mars 2027 : fascicule 4 et ouverture officielle, pendant la Semaine de la langue française et de la Francophonie, le temps fort que recommande l’étude de marché.
• Aucun coût éditorial de plus, mais l’avance de production tombe de deux fascicules à un. Le budget de lancement (achat média, presse et créateurs de contenu) passe de janvier à mars.

Options envisagées

Une bêta fermée

Écartée : 50 à 150 testeurs ne disent rien de l’arrivée réelle des joueurs, et la bêta ouverte prépare déjà l’audience de l’ouverture.

Ouvrir officiellement avec deux fascicules

Écartée : un joueur assidu manquerait de mots avant la fin de son premier mois.

Lancer en janvier, comme le prévoyait le plan

Écartée : un seul fascicule à l’arrivée des joueurs de la presse, et aucune mesure avant de dépenser pour eux.

Produire plus vite pour ouvrir plus tôt

Écartée : deux fascicules par mois doublent la charge éditoriale, environ un mot sourcé par jour aujourd’hui (ADR 0014).

Conséquences

Positives

• À l’ouverture, le catalogue tient un joueur assidu plus d’un mois, et chaque fascicule offre ses entrées faciles.
• Le jeu est éprouvé en conditions réelles avant les dépenses de lancement.
• L’ouverture tombe sur le temps fort annuel de la langue française.

Négatives

• Les défauts de la bêta se voient en production, par de vrais joueurs. Les paramètres d’équilibrage peuvent changer en cours de route, puisqu’ils sont versionnés (ADR 0009).
• Avec un seul fascicule d’avance, un mois de retard éditorial ne s’absorbe plus.
• Le profil invité (ADR 0007) peut se perdre si le navigateur efface son stockage : un joueur de la bêta perdrait alors sa progression. Les comptes viendront plus tard.
• Le plan financier change de calendrier : moins de nouveaux joueurs en janvier, davantage en mars.

Critères de réévaluation

• La bêta n’atteint pas ses seuils : reporter l’ouverture officielle plutôt que dépenser pour faire venir des joueurs.
• Les joueurs consomment le catalogue nettement plus vite que l’estimation : viser plus de quatre fascicules à l’ouverture.
• Un retard éditorial menace la parution mensuelle pendant la bêta.

• Statut : Proposé
• Remplace partiellement : ADR 0029, pour ce que l’index dit d’un fascicule à venir : sa date de parution, et rien d’autre ; le calendrier staging/parutions.json reste illisible
• Complète : ADR 0014 (un fascicule ne dévoile pas son contenu)

Contexte

Le fascicule mensuel est le rendez-vous du jeu. Pourtant, le joueur ne sait pas quand paraît le suivant : le calendrier des parutions reste illisible dans staging/ (ADR 0029), et l’index public ne cite que les fascicules parus. Un joueur qui a complété son fascicule ne sait pas s’il doit attendre deux jours ou deux semaines.

Décision

• L’index global publie un champ prochaine_parution : la date et l’heure, en UTC, du prochain fascicule du calendrier. Rien d’autre de ce fascicule : ni numéro, ni nom, ni jaquette, ni nombre de mots.
• La tâche de parution l’écrit avec l’index, à partir du calendrier, à chaque passage. Un changement du calendrier la relance, pour que la date publiée reste juste.
• La PWA affiche cette date sur le choix du fascicule de l’écran des plis et en tête du codex : « Prochain fascicule : 1ᵉʳ novembre ».
• Sans fascicule au calendrier, le champ est absent et rien ne s’affiche.
• Un report change simplement la date affichée.

Options envisagées

Ne rien publier avant la parution

Écartée : le joueur ne sait pas quand revenir, alors que la date ne trahit aucun contenu.

Montrer la jaquette en avant-première

Écartée : la jaquette ne trahit rien par construction (ADR 0016), mais aucun fichier d’un fascicule à venir ne doit se lire avant sa parution (ADR 0029).

Annoncer, à la parution, combien de familles du joueur le fascicule prolonge

Écartée : l’annonce d’une parution s’en tient aux nombres de mots, de préfixes, de suffixes et de langues (ADR 0014).

Conséquences

Positives

• Le joueur sait quand revenir, et l’attente d’un fascicule devient un rendez-vous.
• Aucun contenu à venir n’est lisible : seule une date sort du calendrier.

Négatives

• Une date publique engage : un retard se voit.
• La tâche de parution (dépôt App) et le format de l’index changent ; le client ne doit rien déduire d’autre de ce champ.

Critères de réévaluation

• Des reports fréquents rendent la date peu fiable.
• Des joueurs déduisent quelque chose du contenu à venir à partir de la date.

• Statut : Proposé
• Complète : ADR 0010 (observabilité respectueuse de la vie privée) ; ADR 0048 (les seuils de la bêta)

Contexte

Le plan financier raisonne en cohortes mensuelles : 30 % des joueurs d’un mois encore actifs le mois suivant, 10 % au 8ᵉ mois. La bêta ouverte (ADR 0048) se juge sur des seuils de rétention. Or la télémétrie prévue renouvelle son identifiant pseudonyme tous les 30 jours : une cohorte ne se suit pas au-delà d’un mois, ce que l’ADR 0010 notait déjà (« identifiants limités moins adaptés aux cohortes longues »).

Le joueur, de son côté, ne voit sa progression que dans le codex, fascicule par fascicule. Rien ne lui montre le chemin parcouru d’un mois à l’autre.

Décision

Des cohortes sans donnée nouvelle

• Statut des données : un identifiant d’installation lié à une activité datée est une donnée pseudonymisée, donc personnelle (RGPD, considérant 26). La table joueur et la télémétrie en contiennent déjà ; cet ADR n’ajoute pas de nouvelle sorte de donnée. Seuls les agrégats seuillés à 50 joueurs sont anonymes.
• Rétention mensuelle : la table joueur contient déjà cree_le et derniere_activite. Une tâche mensuelle compte, pour chaque mois d’arrivée, les joueurs actifs pendant le mois qui s’achève, et ne garde que ces nombres.
• Retour au 1ᵉʳ, au 7ᵉ et au 30ᵉ jour : une tâche quotidienne fait le même calcul, jour par jour, pour les profils créés 1, 7 et 30 jours plus tôt.
• Passage d’un mois au suivant : une colonne de plus, mois_activite_precedente, mise à jour quand l’activité d’un joueur change de mois. La tâche mensuelle compte les joueurs actifs du mois dont l’activité précédente date du mois d’avant.
• Télémétrie : chaque événement porte le mois d’arrivée du joueur, comme une propriété énumérée. L’identifiant pseudonyme se renouvelle au début de chaque mois civil plutôt que tous les 30 jours : un joueur a exactement un identifiant par mois.
• Seuil : aucun agrégat de moins de 50 joueurs n’est affiché ni exporté. Les durées de conservation restent documentées (ADR 0010).

Indicateurs suivis, chacun justifié comme le demande l’ADR 0010 :

Les statistiques du joueur

• Un onglet « Cabinet » du codex, fusionné avec les objectifs (familles), montre en tête au joueur ses propres nombres, jamais comparés à ceux des autres :
  • jours de jeu ;
  • mots trouvés ;
  • langues rencontrées ;
  • mot au plus long voyage, celui dont la filiation traverse le plus de langues ;
  • cartes maîtrisées (ADR 0044) ;
  • légendaires trouvées (ADR 0043) ;
  • cartes de lecteur remplies (ADR 0045).
• Une donnée de plus dans joueur : jours_de_jeu, le nombre de jours distincts où le joueur est venu.

Options envisagées

Un identifiant durable pour la télémétrie

Écartée : l’ADR 0010 limite la portée des identifiants, et les tâches d’agrégation donnent les cohortes sans suivre personne.

Garder la rotation de l’identifiant tous les 30 jours

Écartée : à cheval sur deux mois, un même joueur compterait deux fois, et aucune cohorte ne se suivrait au-delà d’un mois.

Montrer au joueur des statistiques collectives

Écartée lors de la revue des pistes de rétention d’octobre 2026 : pas de nombres comme « 12 % des joueurs ont trouvé ce mot ».

Donner des titres au joueur

Écartée lors de la même revue. Des titres tirés du jeu (logophile, philologue) dévoileraient en outre des mots du catalogue.

Une carte des routes des mots dans « Votre cabinet »

Déplacée : elle rejoint une évolution dédiée, avec la vue Filiation du codex (potentiel d’évolution).

Conséquences

Positives

• Les hypothèses du plan financier deviennent mesurables dès la bêta.
• Aucun identifiant durable de plus ; les données du joueur restent pseudonymisées, et les agrégats, seuillés à 50 joueurs, ne gardent rien d’individuel.
• Le joueur voit le chemin parcouru d’un mois à l’autre.

Négatives

• Deux colonnes de plus dans joueur, deux tâches planifiées et une table d’agrégats à purger selon les durées de conservation.
• Les petites cohortes ne s’affichent pas : les premières semaines de la bêta donnent peu de chiffres.
• La télémétrie prévue au jalon J7 de la roadmap de l’App change : renouvellement au mois civil et mois d’arrivée.

Critères de réévaluation

• Une analyse nécessaire à une décision s’avère impossible avec ces agrégats.
• Un agrégat permet de distinguer un petit groupe de joueurs.
• Peu de joueurs ouvrent « Votre cabinet ».

• Statut : Accepté
• Remplace partiellement : ADR 0038, pour la section « Prix des indices » : les cinq niveaux ordonnés disparaissent. La partie sur les jalons reste en vigueur.
• Complète : ADR 0023 : la silhouette d’une carte à trouver devient un indice payant.

Contexte

Les cinq niveaux de l’ADR 0038 (langue, nature des briques, transformation, brique connue, solution) se suivent dans un ordre imposé et portent des métadonnées sèches, identiques pour tous les mots. Le joueur n’a aucun choix, et les premiers niveaux n’apprennent presque rien. Une carte du codex porte pourtant trois informations qui parlent d’elles-mêmes : sa silhouette, son sens littéral et sa définition.

Décision

Un indice porte sur une recette encore à découvrir, comme avant. Les trois indices s’achètent dans l’ordre : silhouette, définition, puis sens littéral. Un indice n’est vendu qu’une fois le précédent obtenu, et chacun ne se paie qu’une fois par recette.

La feuille liste les indices dans cet ordre, du moins cher au plus cher ; seul le suivant à obtenir est achetable. Les boutons de prix sont neutres, avec la goutte de marque : un seul bouton Corail par écran, et un Corail ne porte pas d’icône colorée.

• Les prix sont un paramètre d’équilibrage (ADR 0009). Le prix double d’un indice à l’autre : les trois coûtent 28 gouttes ensemble.
• Aucun niveau « solution » : le joueur trouve le mot lui-même.
• Le sens littéral et la définition ne s’affichent plus gratuitement sur une carte à trouver : la « piste » du codex et la note de la feuille d’indice disparaissent. Ils ne se lisent qu’après l’achat.
• Une recette n’offre que les indices que sa carte porte : une carte sans définition ne vend pas d’indice de définition, une carte sans silhouette commence à la définition.
• Une légendaire cachée (ADR 0015) ne reçoit toujours aucun indice.
• Les indices déjà achetés sous l’ancien barème sont supprimés, leur sens ayant changé, et leur prix est remboursé en encre.

Options envisagées

Garder les cinq niveaux et changer leur contenu

Écartée : les métadonnées des cinq niveaux restent sèches et identiques d’un mot à l’autre.

Masquer le sens sous des gouttes à essuyer, ou révéler la silhouette lettre par lettre

Écartées après prototype : plus lourdes à lire et à équilibrer qu’un achat direct, sans apporter plus d’information.

Garder une solution payante

Écartée : le joueur qui abandonne peut déjà obtenir la découverte autrement, et la solution rendait les autres indices inutiles.

Conséquences

Positives

• Le prix croît à chaque indice : le joueur paie peu pour un premier coup de pouce, cher pour aller au bout.
• Les indices réutilisent des données éditoriales qui existent déjà, sans écriture supplémentaire par carte.

Négatives

• Le joueur ne choisit pas l’indice : pour lire le sens littéral, il paie d’abord les deux autres, 28 gouttes en tout.
• Un joueur bloqué n’a plus de solution à acheter.
• Les trois indices dépendent de la qualité de la fiche : une carte sans sens littéral ou sans définition offre moins d’indices.

Critères de réévaluation

• Des joueurs bloqués qui abandonnent faute de solution : rétablir un dernier recours.
• Un indice jamais acheté : le retirer ou le baisser.
• Une silhouette trop reconnaissable pour son prix : la relever.

• Statut : Proposé
• Remplace partiellement : ADR 0014, pour la phrase « une simple ressemblance de chaînes ne forme pas une combinaison et n’appelle ni recette ni exclusion » : une ressemblance qui trompe vraiment peut désormais être déclarée, avec son explication (le reste de l’ADR 0014, dont les exclusions, reste en vigueur).
• Complète : ADR 0003 (résultats d’une tentative), ADR 0013 (homographes), ADR 0027 (ressources d’un fascicule)

Contexte

Deux briques posées bout à bout s’écrivent parfois comme un mot qui n’en vient pas. Aujourd’hui le joueur reçoit alors un échec neutre (ADR 0003) et ne sait pas si la piste est fausse ou s’il s’y prend mal. Il s’acharne, ou il abandonne : c’est une frustration, et une occasion manquée d’apprendre quelque chose sur le mot.

Deux situations très différentes se cachent derrière ce même échec :

1. La fusion est fausse, définitivement. Les lettres se suivent, mais le mot ne vient pas de ces briques : il a une autre origine, ou ce n’est pas un composé du tout. Aucune autre brique ne la sauve.
2. La fusion est bonne, avec une autre brique. Le joueur a posé la bonne forme au mauvais sens. Le cas type est a- : le préfixe privatif (« sans », amoral) et le préfixe « vers » (amener) sont deux unités, donc deux briques (modèle de données). Dire « fusion invalide » serait faux : la recette existe et reste possible.

La question ouverte « Homographes sur la table » du modèle de données porte sur le second cas ; l’ADR 0014 écartait le premier, faute de réponse de jeu à lui donner.

Contraintes à respecter : se tromper ne coûte rien ; le jeu ne dit jamais « presque » sans pouvoir le justifier ; un fascicule ne dévoile pas son contenu avant que le joueur ne le trouve (ADR 0015, ADR 0049) ; la base de progression ne copie aucun texte du catalogue et ne garde pas les propositions de fusion (ADR 0010).

Décision

Une tentative qui n’est ni une recette, ni une exclusion, ni un « presque » d’ordre reçoit, quand c’est possible, une explication. Il y en a deux sortes, qui n’ont pas la même origine.

1. Mauvais homographe : calculé, rien à saisir

Si remplacer une des deux briques posées par un homographe (même langue, même nature, même forme affichée, autre unité) donne une recette exacte, la réponse est : « Bonne forme, autre brique. »

• Le compilateur du catalogue ajoute à chaque carte de brique la liste homographes (identifiants des autres briques de même langue, nature et forme normalisée). Le serveur et la PWA la lisent, sans recalculer la normalisation.
• Le message nomme la brique posée avec sa glose (« a- « sans » ne convient pas ici ») et dit qu’une autre brique s’écrit de la même façon. Il ne nomme ni la glose ni l’identifiant de la bonne brique : le joueur la cherche dans sa réserve ou dans son codex, où les deux a- se distinguent par leur glose.
• Seul le remplacement d’une brique par un homographe qui donne une recette exacte déclenche ce retour. Un homographe qui n’aboutirait à rien ne produit jamais de fausse lueur.
• La recette reste intacte : elle est indexée par identifiants de briques, jamais par forme. Poser a- « vers » avec la même seconde brique est une découverte normale.
• Le mot déjà découvert n’est pas rappelé (comme pour un « presque »).

2. Trompe-l’œil : une fausse fusion déclarée et expliquée

Un trompe-l’œil est un objet éditorial de la couche ludique (ADR 0009), rattaché à un fascicule, qui déclare : « cette paire ordonnée de briques ressemble à un mot, mais ce mot n’en vient pas ».

Retour de jeu. Un trompe-l’œil prend le pas sur l’échec neutre. Le joueur lit :

• toujours, l’explication_courte (« Les lettres se suivent, mais ce mot n’est pas fait de ces deux briques. L’un de ses morceaux a une autre histoire. ») ;
• l’explication complète (qui nomme le mot) seulement si le mot_id est au codex du joueur, ou s’il est nul. Sinon, le mot reste caché : le trompe-l’œil ne révèle pas l’existence d’un mot encore à trouver. Dès que le mot est découvert, son verso gagne une section « À ne pas confondre » qui liste ses trompe-l’œil avec leur explication complète.

Rien n’est consommé, rien n’est récompensé : on n’engrange rien à se tromper exprès.

Priorité de résolution

resoudre (ADR 0003) applique, dans l’ordre : recette exacte (découverte, connue), exclusion, trompe-l’œil, « presque » d’ordre, mauvais homographe, échec neutre. Un trompe-l’œil et un mauvais homographe ne coexistent jamais sur une même paire : le validateur le refuse (voir ci-dessous), ce qui garde un seul mécanisme par cas.

Les trompe-l’œil ne sont pas des exclusions. Une exclusion (ADR 0014) est une combinaison attestée que l’équipe choisit de ne pas publier (archaïque, offensante). Un trompe-l’œil est une combinaison non attestée qu’on explique.

Données du catalogue (dépôt Content)

• Dossier ludique/trompe-l-oeil/, un fichier JSON par objet, schéma trompe-l-oeil.schema.json, identifiant tpl_[0-9a-z]{8}.
• L’artefact les publie avec les ressources du fascicule (à côté des recettes et des exclusions) ; note_interne et etat_relecture restent privés (CHAMPS_PRIVES). Comme les recettes, ils sont lisibles par tous : le secret tient à l’interface.
• Nouveaux contrôles de valider, un code domaine.regle chacun, un test, une ligne du README :
  • trompe_l_oeil.paire : deux briques publiées au plus tard dans fascicule_id ;
  • trompe_l_oeil.doublon : au plus un par paire ordonnée ;
  • trompe_l_oeil.recette : ni la paire ni son inverse ne sont une recette exacte (variantes comprises), et la paire n’est pas une exclusion ;
  • trompe_l_oeil.homographe_jouable : aucun remplacement d’une brique par un homographe ne donne une recette (ce cas est calculé, voir 1) ;
  • trompe_l_oeil.origine : si mot_id est renseigné, sa composition ou sa chaîne étymologique ne mobilise pas à la fois les deux unités des briques ;
  • trompe_l_oeil.divulgation : l’explication_courte ne contient pas la graphie du mot_id (comparaison normalisée) ;
  • trompe_l_oeil.sources : au moins une source ; en publication, état relu.
• Un rapport non bloquant trompe-l-oeil-candidats liste les paires de briques dont la concaténation (forme normalisée) est la forme d’une unité du catalogue sans recette ni trompe-l’œil, pour aider à repérer les pièges probables. Il ne publie rien.

Contrat et données du joueur (dépôt App)

• IssueFusion::Echec reste { "type": "echec" } et gagne un champ facultatif explication (#[serde(default)]) : { "nature": "homographe", "rang": 1 } ou { "nature": "trompe_l_oeil", "trompe_l_oeil_id": "tpl_…" }. Une PWA qui ne connaît pas ce champ affiche l’échec neutre actuel : le changement est rétrocompatible et suit l’ordre « API d’abord, PWA ensuite ».
• etymo_domaine::fusion::resoudre reçoit les trompe-l’œil et les homographes ; prevoir (web/src/services/jeu.ts) change avec lui, tests miroirs compris. Le serveur fait foi : s’il répond autrement que la prévisualisation, la PWA affiche sa réponse.
• Aucune table de progression nouvelle. Les propositions de fusion ne laissent aucune ligne (modèle de données, § 7) ; la télémétrie compte seulement un résultat de plus par type d’explication (homographe, trompe_l_oeil), sans identifiant de joueur (ADR 0010).
• Aucune énergie, aucun exemplaire, aucune encre n’est touché.

Interface

• Le retour s’affiche sous la table, au même endroit que le « presque » : même gabarit, ton sobre, Encre sur le fond de la carte, jamais de rouge d’erreur. La couleur n’est pas le seul signal : un libellé précède l’explication (« Bonne forme, autre brique », « Fausse piste »).
• Petites briques cliquables dans le message. Les briques citées s’affichent comme des briques en ligne (couleur de leur type), chacune étant un bouton d’au moins 44 px de zone tactile qui ouvre sa carte. Dans « Bonne forme, autre brique », la brique posée et la forme (a-) sont cliquables ; toucher la forme ouvre la réserve filtrée sur celle-ci, où les deux a- se distinguent par leur glose, sans désigner la bonne. Dans « Fausse piste », les deux briques posées sont cliquables.
• Trompe-l’œil : l’explication courte, puis « Pourquoi ? » ouvre l’explication complète si elle est lisible. Un seul bouton Corail par écran : « Pourquoi ? » est neutre.
• Vocabulaire : « trompe-l’œil » et « fausse piste » sont réservés à ce retour ; ni « erreur », ni « invalide », ni « faux ami ».

Options envisagées

Stocker, pour chaque joueur, les fusions invalides qu’il a tentées

Écartée : les propositions de fusion ne laissent aucune ligne dans la base de progression, par principe de vie privée, et l’historique d’un joueur n’apprend rien que le catalogue n’enseigne déjà. Les explications sont publiques, attachées au mot, et se relisent dans son verso. Un « carnet des fausses pistes » par joueur pourra être réévalué (voir ci-dessous).

Étendre les exclusions à toutes les fausses fusions

Écartée : une exclusion décrit un mot attesté qu’on retient, avec deux raisons possibles ; un trompe-l’œil décrit l’inverse, un mot qui n’est pas formé ainsi. Les confondre brouillerait le contrôle de qualité (un fait attesté contre un fait réfuté) et le retour de jeu.

Écrire les explications des mauvais homographes à la main

Écartée : la liste des homographes se déduit du catalogue, et le modèle de données impose déjà que deux homographes se distinguent par leur glose. Un texte saisi pour chaque paire ne dirait rien de plus que « ce n’est pas ce a- », et il faudrait le maintenir à chaque fascicule.

Révéler la bonne brique quand le joueur se trompe d’homographe

Écartée : ce serait donner la solution. On dit seulement « autre brique, même forme », comme le « presque » d’ordre ne dit pas la recette.

Un échec neutre partout, avec une page d’aide générale

Écartée : elle ne répond pas au joueur qui vient d’essayer a- et qui ne comprend pas pourquoi ça ne marche pas.

Conséquences

Positives

• Le joueur sait si sa piste est fausse ou s’il est tout près, au lieu de s’acharner ou d’abandonner.
• Une frustration devient un fait de langue appris : le joueur lit pourquoi para- de parasol n’est pas celui du grec.
• Le cas des homographes (a- et les autres) est traité sans saisie éditoriale, par construction.
• Aucune table, aucune donnée personnelle nouvelle ni dépense nouvelle : le changement tient au catalogue et à resoudre.
• Rétrocompatible : une ancienne PWA affiche un échec neutre.

Négatives

• Un travail éditorial de plus : repérer les paires piégeuses, rédiger deux textes sourcés par trompe-l’œil, les relire.
• Le « presque » d’un homographe dit qu’une autre brique existe, ce qui informe un peu sur le catalogue.
• Un trompe-l’œil dont le mot_id est inconnu du joueur reste vague (« un de ses morceaux a une autre histoire ») : l’explication complète attend la découverte.
• resoudre et prevoir gagnent deux règles à garder en miroir.

Critères de réévaluation

• Plus de 30 % des échecs d’une semaine tombent sur une paire qu’aucun trompe-l’œil ni homographe n’explique : élargir la liste des candidats.
• Un trompe-l’œil dont l’explication courte reste lue sans que le joueur ouvre « Pourquoi ? » : fusionner les deux textes.
• Des joueurs redemandent les explications déjà lues : étudier un carnet des fausses pistes, en pesant la règle « aucune proposition de fusion stockée ».
• Une explication jugée spoiler par les testeurs : ne plus afficher l’explication courte tant que le mot n’est pas trouvé.

• Statut : Proposé, place de la lame remplacée par l’ADR 0068 : à l’arrivée et après chaque coupe, elle se pose au hasard sur une jointure qui n’est pas une coupe attendue. Le reste reste en vigueur.
• Remplace partiellement : ADR 0044, pour le format Découper : quatre découpages proposés, option « Découper en touchant le mot » écartée, et « un toucher répond » appliqué à ce format
• Complète : ADR 0007 (la commande de réponse reste unique et sous autorité serveur)

Contexte

L’ADR 0044 décrit le format Découper comme un choix entre quatre découpages d’un mot, et écarte le découpage « en touchant le mot » : sur mobile, les lettres sont trop étroites pour une cible de 44 px, et un mot en trois parties a plusieurs coupes justes.

Le client livre pourtant une variante : chaque jointure du mot est un bouton invisible, et la dernière coupe envoie la réponse. Au toucher, elle pose trois problèmes :

• la cible fait environ 20 px de large, la moitié des 44 px que le design système exige ;
• l’écartement du mot au survol n’existe pas au doigt : le joueur ne voit rien avant de couper, et le doigt cache la jointure visée ;
• la réponse part à la dernière coupe, sans appel : un doigt qui dérape donne une réponse fausse et définitive.

Découper est le seul format où le joueur produit la réponse au lieu de la reconnaître. Il faut garder ce geste et le rendre fiable au toucher.

Décision

Le geste

Sur un pointeur grossier (écran tactile) :

• Une lame se pose sur le mot dès l’arrivée de la question, en pointillé : la coupe n’existe pas encore. Toute la largeur du mot est une zone de glissement ; la lame se cale sur la jointure la plus proche du doigt, jamais entre deux lettres.
• Une poignée de 44 × 44 px, en forme de brique, Corail, se trouve sous le mot, au bout de la lame : le doigt ne cache aucune lettre.
• Le mot s’écarte à l’endroit de la lame, de 0,2 em de chaque côté. L’écart suit la lame de jointure en jointure.
• Les boutons ‹ et › (chacun 44 px au moins) avancent la lame d’une jointure libre ; au clavier, les flèches ← et → font de même. Chaque glissement a donc une alternative.
• « Couper ici » pose la coupe : l’écart devient fixe, un trait plein en Encre le marque, et la lame repart vers la jointure libre suivante. Deux coupes ne se posent jamais au même endroit.
• « Reprendre » retire la dernière coupe, sans limite et sans pénalité, tant que la réponse n’est pas validée.
• « Valider » prend la place de « Couper ici » quand toutes les coupes sont posées : leur nombre est celui des segments du mot moins un. La consigne ne change pas (« Où ce mot se coupe-t-il ? », « Coupez ce mot en 3 morceaux. »).

La réponse

• Rien n’est envoyé ni jugé avant « Valider ». La commande de réponse est unique : la liste ordonnée des coupes, avec sa clé d’idempotence et la version_etat connue du client ; le serveur fait foi.
• Le verdict garde son déroulé : le mot s’écarte aux coupes, un contour de brique se trace autour de chaque morceau, puis la brique se remplit de la couleur de son type. Une brique garde son trait d’union.
• Une coupe fausse se lit sans nouvelle teinte, comme toute mauvaise réponse des ricochets : morceaux en Sable, contour pointillé en Encre secondaire, secousse de 500 ms, rond barré et texte « Pas cette fois. ». Jamais de rouge. La bonne découpe est donnée au verdict, avec les briques élémentaires.
• Une seule réponse compte par question, quel que soit le nombre de coupes posées puis reprises avant la validation.

Pointeur fin (souris)

• La lame suit le survol ; la poignée et les boutons ‹ › sont masqués.
• Un clic pose la coupe, comme aujourd’hui. Le bouton principal n’apparaît qu’une fois toutes les coupes posées, avec « Valider » : le verdict ne dépend pas de l’appareil.

Ce qui ne change pas

• Les autres formats gardent « un toucher répond, sans bouton Valider » : seul Découper a une étape de validation.
• Les données employées (les segments de la composition préférée), la maîtrise, les quêtes et l’absence de chronomètre ne changent pas.
• Mouvement réduit : l’écart et la lame sautent d’une jointure à l’autre sans transition, et le verdict affiche directement son état final.

Options envisagées

Garder le découpage en touchant directement la jointure

C’est la variante livrée aujourd’hui. Écartée : une cible de 20 px, aucun aperçu au doigt, et une réponse définitive au dernier toucher.

Revenir aux quatre découpages proposés (ADR 0044)

Écartée : le joueur reconnaît un découpage au lieu de le produire, et les leurres, qui déplacent une coupe d’une ou deux lettres, se devinent à l’œil sans connaître les briques. Le geste de découper est ce que le format veut apprendre.

Une loupe au-dessus du doigt

Écartée : elle ajoute un second objet à lire, alors que l’écart du mot montre déjà les deux morceaux à l’endroit visé, et elle demande de gérer sa position près des bords de l’écran.

Valider à la dernière coupe, sans bouton

Écartée : c’est le défaut de la variante livrée. Un bouton « Valider » coûte un toucher de plus, mais supprime les réponses définitives par erreur.

Conséquences

Positives

• La cible de glissement est le mot entier : l’objection de taille de l’ADR 0044 tombe.
• Le joueur voit les deux morceaux avant de couper, et peut se reprendre : se tromper de geste ne coûte rien, comme se tromper de réponse.
• Les formes viennent du design système : la poignée est une brique, la lame en pointillé dit « ce qui manque », le trait plein est un fait.
• Aucun changement côté serveur : la réponse reste la liste des coupes.

Négatives

• Une étape de plus que dans les autres formats, donc une question un peu plus longue.
• Deux modes d’interaction (tactile, souris) à tester et à maintenir.
• La mesure des jointures dépend de la mise en page du mot : les ligatures et les accents demandent des tests.

Critères de réévaluation

• Si la part de réponses fausses du format Découper sur mobile reste supérieure de plus de 15 points à celle des autres formats après un mois d’usage, reprendre la précision du geste (pas de la lame, taille de la poignée).
• Si plus d’une séance sur dix est abandonnée sur une question Découper, étudier un retour à des propositions de découpages pour les mots de plus de dix lettres.
• Si les joueurs reprennent presque toujours la première coupe, la lame se pose mal au départ : revoir sa position initiale.

• Statut : Proposé
• Remplace partiellement : ADR 0022, pour la taille et le rythme des dix premiers fascicules (de 50 à 106 mots, à intervalle hebdomadaire) ; les 20 à 30 mots et le fascicule mensuel restent en vigueur à partir du onzième
• Complète : ADR 0048 (assez de contenu à l’ouverture)

Contexte

L’ADR 0022 fixe de 20 à 30 mots par fascicule et un fascicule par mois. L’ADR 0048 montre qu’un nouveau joueur assidu épuise un catalogue trop mince en moins d’un mois, au moment où sa fidélité est la plus fragile.

Le catalogue actuel compte dix fascicules et 718 mots. Chacun publie de 50 à 106 mots. Leurs dates sont hebdomadaires (du 1ᵉʳ octobre au 12 novembre 2026), et les fascicules 1 à 4 paraissent le même jour. Le validateur signale cet écart (fascicule.taille et fascicule.chronologie, issue Content #12). Ce n’est pas une erreur d’édition : c’est un choix, que cet ADR consigne.

Décision

• Les dix premiers fascicules sont des fascicules de lancement : ils publient plus de 30 mots (de 50 à 106 aujourd’hui) et paraissent à intervalle hebdomadaire, au lieu de 20 à 30 mots par mois. Les quatre premiers paraissent ensemble, à l’ouverture.
• Le but est de donner beaucoup de contenu au lancement de l’application, pour qu’un joueur assidu ne manque pas de mots pendant les premières semaines.
• À partir du onzième fascicule, l’ADR 0022 s’applique de nouveau : de 20 à 30 mots, environ un fascicule tous les 30 jours.
• Les contrôles fascicule.taille et fascicule.chronologie du validateur ne s’appliquent pas aux dix fascicules de lancement. Le plafond de 30 mots et l’ordre strict des dates restent contrôlés pour les suivants.

Options envisagées

Redécouper le catalogue en fascicules de 20 à 30 mots, un par mois

Écartée : il faudrait environ 28 fascicules pour les 718 mots actuels, soit plus de deux ans de parutions. Le lancement ne disposerait que d’un ou deux fascicules, ce que l’ADR 0048 écarte déjà.

Garder la taille actuelle pour tous les fascicules

Écartée : au-delà de 30 mots, un joueur assidu ne complète plus un fascicule avant la parution du suivant (ADR 0022). Le codex devient une dette, et la charge éditoriale d’un fascicule de cent mots n’est pas tenable chaque mois.

Conséquences

Positives

• Un joueur qui arrive trouve un catalogue large, et la rétention des premières semaines ne dépend plus d’un seul fascicule.
• Le catalogue existant est conservé tel quel, sans redécoupage.
• Le retour à 20 à 30 mots par mois garde la charge éditoriale de l’ADR 0022 à long terme.

Négatives

• Un joueur occasionnel ne complétera pas les fascicules de lancement : leurs plis restent ouverts, sans pénalité (ADR 0016).
• Le rythme chute après le dixième fascicule : le contenu suivant doit être prêt, ou la bascule se verra.
• Le validateur du dépôt Content doit distinguer les fascicules de lancement des autres.

Critères de réévaluation

• Les joueurs assidus n’achèvent pas les fascicules de lancement avant la parution du suivant : espacer les dates ou réduire la taille.
• La chute de rythme au onzième fascicule fait décrocher les joueurs : étendre la fenêtre de lancement ou relever le plafond ordinaire.
• Une simulation sur les fascicules de lancement contredit l’estimation de l’ADR 0048.

• Statut : Proposé, origine des transcriptions remplacée par l’ADR 0060 : elles sont lues dans les formes des lexèmes Wikidata, non plus extraites de Wiktextract
• Portée : modèle de données du catalogue et fiche d’une carte
• Complète : ADR 0006 (formes, écritures et translittérations), ADR 0014 (sources), ADR 0025 (médias), ADR 0027 (artefact)

Contexte

Les mots français n’ont ni transcription phonétique ni audio. Seules les formes grecques ont une translittération (ADR 0006). Or la prononciation éclaire des familles qui ne se ressemblent plus à l’écrit : « aquarium » (/akwaʁjɔm/) garde le son latin que « eau » (/o/) a perdu.

Deux voies existent : une transcription (alphabet phonétique international, API), qui est du texte, ou un enregistrement audio. Le second suppose de trouver, d’héberger, de licencier et de relire un fichier par mot ; la première se tire d’une donnée déjà structurée. Le catalogue publié est un artefact statique (ADR 0027), sans service tiers à l’exécution.

Décision

Une prononciation écrite en API, jamais d’audio

• Chaque forme française d’un mot porte une prononciation : une transcription en alphabet phonétique international (API), pour le français standard de France. Une seule prononciation de référence par forme dans le MVP ; pas de variantes régionales.
• Il n’y a aucun audio, ni enregistré, ni synthétisé : ni fichier, ni synthèse vocale du navigateur, ni appel à un service tiers.
• Les formes grecques et latines gardent leur translittération (ADR 0006) et ne reçoivent pas de transcription phonétique dans le MVP.

Elle vit sur la forme

• Le champ prononciation est un attribut de la forme (ADR 0006), au même titre que la translittération. Il ne crée ni brique, ni carte, ni découverte : une prononciation n’est pas collectionnable.
• Il contient le texte API sans les barres obliques (« ɔ » et non « /ɔ/ ») et une référence à sa source (ADR 0014). Les barres sont ajoutées à l’affichage.
• Il est compilé dans la ressource de la carte de l’ADR 0027, donc publié avec le fascicule, pas avant : une prononciation dévoile le mot comme son orthographe.

Sa source : Wiktextract, relue

• Les transcriptions sont extraites des données de Wiktextract (extraction hors ligne du Wiktionnaire, diffusée sur kaikki.org), une fois, à la préparation du fascicule. Aucune API n’est interrogée à l’exécution, ni par l’application ni par le pipeline.
• Cela complète sans contredire l’ADR 0014 : le Wiktionnaire reste une source de repérage pour les étymologies, dont aucun texte n’est repris. Une transcription est une donnée brève, factuelle et sans enjeu éditorial ; elle est importée comme telle, et seulement elle.
• Chaque transcription est relue avant publication, contre un dictionnaire de référence (TLFi ou Académie française) quand il en donne une, et marquée reperage sinon. La licence CC BY-SA 4.0 du catalogue est compatible avec celle du Wiktionnaire (ADR 0017) ; la source est citée dans la liste des sources du fascicule.
• Un mot sans transcription fiable n’en affiche pas : l’absence n’est jamais comblée par une génération automatique à partir de l’orthographe.

Son affichage

• La fiche d’un mot affiche la transcription entre barres obliques, à côté de la forme écrite, en police du design système (couverture API vérifiée dans typographie).
• Le texte est balisé comme du texte API pour les lecteurs d’écran, avec une alternative lisible : l’écriture normale du mot reste toujours à côté. La prononciation n’est jamais le seul moyen de comprendre une carte ni de jouer.
• Le jeu n’en tire aucune règle : ni fusion, ni indice, ni jalon ne dépend d’une prononciation.

Options envisagées

Audio enregistré (Wikimédia Commons ou voix dédiée)

Plus parlant qu’une transcription, mais il faut interroger l’API de Commons ou produire les voix, relire la licence de chaque fichier, héberger des médias supplémentaires (ADR 0025), et ces fichiers manquent pour beaucoup de mots. Écarté : la charge d’intégration et de maintenance dépasse le gain au MVP.

Synthèse vocale du navigateur

Aucun fichier à produire, mais la voix varie selon l’appareil, la prononciation de mots savants est souvent fausse, et rien ne la garantit hors connexion (ADR 0041). Écarté.

Aucune prononciation

C’est l’état actuel. Il laisse sans réponse le besoin des familles que l’écrit sépare. Écarté.

Générer la transcription à partir de l’orthographe

Rapide, mais le français est irrégulier (« oignon », « femme », les noms propres et les mots savants) : l’erreur serait silencieuse dans un jeu qui prétend à la rigueur. Écarté.

Conséquences

Positives

• pas de service tiers ni de fichier supplémentaire : le catalogue reste statique et hors connexion ;
• taille négligeable : quelques octets par mot, soit quelques kilooctets par fascicule ;
• le modèle est prêt à recevoir d’autres langues ou un audio plus tard, sans refonte ;
• aucune dépendance à l’exécution.

Négatives

• l’API est peu lisible pour une partie du public, et mal lu par les lecteurs d’écran : un gain pour certains joueurs, sans effet pour d’autres ;
• un travail de relecture par fascicule (20 à 30 mots, ADR 0022) ;
• une donnée de plus à maintenir dans le schéma et le pipeline (ADR 0005).

Critères de réévaluation

• Des retours de joueurs ou de testeurs montrent que l’API n’est pas comprise : ajouter une aide de lecture, ou reprendre l’audio.
• Un jeu de voix libres couvre la grande majorité du vocabulaire publié, sans API à intégrer : rouvrir l’audio par un nouvel ADR.
• Plus d’une langue d’interface ou de langue jouable est livrée : étendre la prononciation aux autres langues.

• Statut : Proposé, source de la date remplacée par l’ADR 0060 : elle est lue dans la déclaration « first attested from » du lexème Wikidata, non plus dans le TLFi
• Portée : modèle de données du catalogue et fiche d’une carte
• Complète : ADR 0002 (graphe linguistique éditorial), ADR 0013 (schéma des briques), ADR 0014 (sources), ADR 0027 (artefact)

Contexte

Aucun champ ne dit quand un mot apparaît en français, ni quand un emprunt a eu lieu. C’est pourtant l’information la plus parlante d’une carte : « attesté vers 1175 » dit en trois mots que philosophie est un mot du Moyen Âge, et que psychologie ne l’est pas.

Le TLFi donne cette date pour chaque mot, au début de sa rubrique « Étymologie et histoire », avec des précisions variables : une année (« 1557 »), une approximation (« ca 1175 »), une borne (« av. 1350 »), un intervalle (« 1225-50 ») ou un siècle (« xiiiᵉ s. »). La première date n’est pas toujours celle du sens actuel : philosophie est attesté vers 1175 pour un ensemble de disciplines, et ses autres sens viennent plus tard.

Trois endroits pouvaient porter la date : la forme, l’unité ou la relation emprunt / heritage (modèle de données, sections 2 et 3).

Décision

Elle vit sur l’unité, avec son propre fait

• Une unité de nature mot, en français, peut porter une première attestation : la date à laquelle le mot apparaît pour la première fois dans un texte français, quel que soit son sens.
• L’attestation est un fait à part entière (ADR 0002), comme une forme ou un sens : sa confiance, sa relecture et ses sources ne sont pas celles de l’unité.
• Une unité a au plus une première attestation. Les dates d’une graphie ancienne ou d’un sens plus récent ne sont pas des champs : elles se racontent dans l’explication détaillée.
• La date d’un emprunt ou d’un héritage n’est pas stockée sur la relation : c’est la date d’attestation de l’unité cible. La stocker deux fois laisserait les deux diverger.
• Les étymons grecs et latins n’ont pas de date dans le MVP : leurs attestations se donnent par auteur (Platon, Cicéron), pas par année.

Sa précision

• annee est un entier, jamais dans le futur ; annee_fin n’existe que pour un intervalle, et lui est postérieure.
• Une précision plus fine que la source (« début du xiiiᵉ s. » saisi comme « 1201 ») est interdite : on garde la précision de la source, au besoin en arrondissant vers le siècle.

Sa source : une référence, jamais le Wiktionnaire seul

• La date vient d’une source de référence (ADR 0014) : le TLFi, rubrique « Étymologie et histoire », ou un dictionnaire historique de même rang. Sa localisation est l’entrée consultée.
• Le Wiktionnaire peut aider à repérer une date, jamais la justifier : une attestation qui n’a qu’une source de repérage reste un brouillon et n’est pas publiée.
• Quand une étude plus récente antidate le mot, la date retenue reste celle de la source de référence, et l’écart se note dans note_interne.
• Un mot sans date sûre n’en affiche pas : l’absence n’est jamais comblée par une estimation.

Son affichage

• La fiche d’un mot découvert affiche la date à côté de sa langue (« français, attesté vers 1175 »). Elle est compilée dans la ressource de la carte (ADR 0027) et publiée avec son fascicule, pas avant.
• Une carte inconnue n’affiche pas de date : elle reste en silhouette, sans autre piste que la sienne.
• Le jeu n’en tire aucune règle dans le MVP : ni fusion, ni indice, ni jalon, ni quête ne dépend d’une date. Une frise ou un tri chronologique du codex demanderait un nouvel ADR.

Options envisagées

La date sur la forme

Une graphie ancienne aurait sa propre date, ce qui serait plus exact. Écartée : le joueur découvre un mot, pas une graphie, et la plupart des formes du catalogue n’ont qu’une graphie. Le gain ne paie pas un champ de plus par forme.

La date sur la relation emprunt ou heritage

Elle dirait quand le mot a changé de langue. Écartée : beaucoup de mots du catalogue sont formés en français, sans relation entrante, et n’auraient pas de date ; pour les autres, la date de la relation est celle de l’attestation de la cible.

Un champ texte libre (« ca 1175 »)

Rapide à saisir, mais impossible à contrôler, à trier ou à traduire. Écartée.

Aucune date

C’est l’état actuel. Il prive la carte de son repère le plus concret. Écartée.

Conséquences

Positives

• Chaque carte de mot gagne un repère historique sourcé, sans nouvelle brique ni nouvelle règle de jeu.
• La date se relit comme les autres faits, avec sa confiance et sa localisation.
• Le champ est structuré : un tri ou une frise restent possibles plus tard.

Négatives

• Un fait de plus par mot à saisir et à relire.
• Le contrôle de la précision demande une règle de plus dans le validateur du dépôt Content.
• Les dates du TLFi ont l’âge du TLFi : certaines sont antidatées depuis.

Critères de réévaluation

• Les joueurs ne regardent pas la date sur la fiche : la retirer de l’affichage, pas du catalogue.
• Un besoin de dater les étymons ou les sens apparaît (vue Filiation, frise) : étendre l’attestation par un nouvel ADR.
• Une source de référence plus récente que le TLFi devient accessible : changer la source par défaut.

• Statut : Proposé
• Portée : couche ludique du catalogue et codex
• Complète : ADR 0009 (couche ludique), ADR 0015 (codex), ADR 0043 (légendaires secrètes)

Contexte

Aucun regroupement par domaine (médecine, navigation, astronomie) n’existe dans le catalogue. Le modèle de données laisse la porte ouverte : « Un regroupement éditorial nommé (« La terre ») reste possible plus tard, dans la couche ludique. » La piste des fascicules spéciaux thématiques (potentiel d’évolution) en aurait besoin.

Le codex regroupe déjà les cartes de trois façons :

• par fascicule, avec son nom (« Argile », « Lapidaire »), sa jaquette et sa complétude (ADR 0016) ;
• par famille, les mots formés sur une brique trouvée, déduits des recettes sans saisie (codex) ;
• par langue, avec la carte de chaque langue rencontrée.

Un thème serait un quatrième regroupement, saisi à la main, qui traverse les fascicules et les familles.

Décision

Aucun thème dans le MVP

• Le catalogue ne déclare aucun thème nommé, et le codex n’en affiche pas.
• Le nom d’un fascicule reste son seul titre éditorial ; il peut évoquer un domaine (« Lapidaire »), sans en faire une donnée.
• Les familles restent dérivées des recettes. Rien ne se saisit pour elles.

Si un thème vient plus tard

Un nouvel ADR le décidera, avec la piste des fascicules spéciaux. Il respectera ces garde-fous :

• un thème est une donnée de la couche ludique (ADR 0009), jamais un fait linguistique : il référence des mots publiés, jamais l’inverse ;
• il ne regroupe que des mots, pas des briques ni des langues, qui ont déjà leurs familles et leurs cartes ;
• il ne dévoile rien : un thème n’apparaît au codex qu’après la découverte d’un de ses mots, ses mots inconnus restent en silhouette, et un mot légendaire n’y figure ni dans la liste ni dans le compteur (ADR 0043) ;
• il ne crée ni rareté, ni récompense propre, ni pression de temps.

Options envisagées

Un thème par mot, dans la couche ludique, dès maintenant

Il nourrirait une vue « Thèmes » du codex. Écarté pour le MVP : aucune fonction ne le consomme encore, chaque mot demanderait un jugement de plus à saisir et à relire, et le codex compte déjà trois regroupements. Le coût éditorial passe avant l’apport.

Un thème comme fait linguistique

Il vivrait à côté des sens, dans la couche des faits. Écarté : un domaine n’est pas une propriété étymologique attestée par une source de référence, et la couche linguistique ne doit pas dépendre du jeu (ADR 0002, ADR 0009).

Déduire le thème des sens ou des briques

-logie ou neuro- suggèrent un domaine, mais pas assez sûrement : astrologie n’est pas une science, alors qu’astronomie en est une. Écarté : un regroupement faux serait pire que pas de regroupement.

Conséquences

Positives

• Aucun champ de plus à saisir, à relire ni à compiler.
• Le codex garde trois regroupements clairs, dont deux se calculent.
• Les garde-fous sont posés avant que les fascicules spéciaux n’en aient besoin.

Négatives

• Un joueur curieux de la médecine ou de la navigation ne trouve pas de vue qui rassemble ces mots.
• Un futur fascicule spécial thématique demandera d’abord cet ADR complémentaire.

Critères de réévaluation

• Un fascicule spécial thématique est décidé : définir le thème avec lui.
• Les retours de joueurs demandent un regroupement par domaine que les familles ne donnent pas.
• La recherche du codex ne suffit plus à retrouver les mots d’un même domaine.

• Statut : Proposé, « d’après une source de référence » remplacé par l’ADR 0060 : la chaîne passe par une langue d’après Wikidata
• Remplace partiellement : ADR 0013, pour le nombre de langues du MVP (trois) ; l’absence de variété reste en vigueur
• Complète : ADR 0006 (langues et écritures), ADR 0023 (silhouette de chaque langue)

Contexte

L’ADR 0013 fixe trois langues pour le MVP : grec ancien, latin et français. Il prévoit de se réévaluer quand un contenu réel l’exige.

C’est le cas. La relecture des chaînes étymologiques des fascicules 1 à 4 dans le TLFi (issue Content #14) montre des mots qui ne viennent ni du grec ni du latin par la voie directe : biologie et écologie sont empruntés à l’allemand, baromètre, microphone et télépathie à l’anglais, télescope passe sans doute par l’italien. Sans ces langues, la chaîne s’arrête au mauvais endroit, ou elle ment.

Le TLFi distingue aussi des variétés : bas latin, latin médiéval, latin scientifique, ancien français. L’ADR 0013 les a écartées pour ne pas fragmenter le codex en cartes de langue peu remplies.

Décision

Une langue d’emprunt naît d’un mot publié

• Le catalogue peut déclarer d’autres langues que les trois du MVP, quand une chaîne étymologique d’un mot publié passe par elles, d’après une source de référence.
• Aucune langue n’est ajoutée « pour plus tard » : une langue sans unité ne sert à rien et coûte une silhouette.
• Les premières sont l’anglais, l’allemand et l’italien. L’arabe, le persan ou le francique viendront avec le premier mot publié qui les demande, avec leur écriture et leur convention de translittération si elles ne s’écrivent pas en alphabet latin (ADR 0006).

Toujours sans variété

• Le bas latin, le latin médiéval, le latin chrétien et le latin scientifique restent du latin ; l’ancien et le moyen français restent du français, sous forme de graphie ancienne ; l’anglo-américain reste de l’anglais.
• La précision va dans l’explication détaillée ou dans la note_simplification du fait, comme le prévoit l’ADR 0013.

Une langue d’emprunt est une langue comme les autres

• Elle a son nom en toutes lettres, sa lettre emblème, sa langue parente quand elle descend d’une langue du catalogue (l’italien descend du latin), et sa silhouette (ADR 0023) dès qu’un fascicule la cite.
• Elle a sa carte dans le codex. Comme les autres, cette carte regroupe les formes découvertes dans cette langue : elle se remplit avec les étymons des mots trouvés.
• Elle n’est jamais une brique, et un mot anglais ou allemand n’a pas de carte propre : c’est un étymon (ADR 0013).
• La parenté des langues (langue_parente_id) reste une généalogie : un emprunt ne crée jamais de parenté entre deux langues.

Options envisagées

Garder trois langues

Écartée : la chaîne de biologie devrait sauter l’allemand et prétendre que le français a emprunté le mot au grec, ce que la source dément.

Ajouter aussi les variétés du latin et du français

Écartée, pour les raisons de l’ADR 0013 : des cartes de langue presque vides, une frontière discutable entre deux variétés, un coût éditorial sans gain pour le joueur.

Déclarer d’avance une liste de langues

Écartée : une langue sans mot publié n’a rien à montrer, et chacune demande une silhouette et une relecture.

Conséquences

Positives

• Les chaînes suivent la source, y compris les emprunts modernes à l’anglais et à l’allemand.
• Le codex gagne des cartes de langue qui racontent les routes des mots, sans variété à départager.
• Chaque nouvelle langue a un déclencheur clair : un mot publié qui la cite.

Négatives

• Une silhouette et une lettre emblème à dessiner par langue ajoutée.
• Une carte de langue peut rester presque vide si un seul mot passe par elle.
• Le rattachement d’une variété à sa langue simplifie l’histoire : la note doit le dire.

Critères de réévaluation

• Une carte de langue reste vide ou quasi vide pour la plupart des joueurs : regrouper ses mots sous une autre présentation.
• Les variétés reviennent souvent dans les explications et les joueurs les demandent : rouvrir les variétés par un nouvel ADR.
• Une langue non latine arrive (arabe, persan) : vérifier son écriture, sa direction et sa convention avant la saisie.

• Statut : Proposé
• Remplace partiellement : ADR 0047, pour les dix fascicules de lancement ; la règle des tiers, les trois niveaux et le champ difficulte restent en vigueur pour tous les autres
• Complète : ADR 0054 (fascicules de lancement)

Contexte

L’ADR 0047 demande un tiers de mots faciles, moyens et difficiles dans chaque fascicule. Un mot difficile cumule deux écarts : sa recette porte une transformation, et son sens actuel s’est éloigné du sens littéral.

Les dix fascicules de lancement (ADR 0054) comptent 718 mots, dont 9 difficiles (après correction d’épigramme, sans transformation). Ce n’est pas une erreur de classement : ils sont bâtis sur des composés savants transparents (biologie, géographie, thermomètre), dont les briques gardent leur forme. Les fascicules 1 et 2 n’ont que 7 et 2 recettes avec transformation, donc au plus 7 et 2 mots difficiles possibles, pour 17 attendus. La relecture des fascicules 1 à 4 dans le TLFi (issue Content #13) le confirme.

Respecter les tiers demanderait d’ajouter environ deux cents mots difficiles et de retirer autant de mots faciles, chacun avec ses faits sourcés, sa recette, sa silhouette et son explication, à quelques semaines du lancement.

Décision

• Les dix fascicules de lancement ne sont pas tenus à la règle des tiers. Leurs mots gardent leur champ difficulte, saisi et relu selon les trois niveaux de l’ADR 0047 ; un classement faux reste une erreur à corriger.
• Le contrôle fascicule.tiers du validateur ne s’applique pas aux fascicules 1 à 10.
• À partir du onzième fascicule, la règle des tiers s’applique pleinement, à un mot près, légendaires exclues.
• Les mots difficiles ajoutés plus tard à un fascicule de lancement, par exemple par la fermeture, sont les bienvenus : ils ne sont pas obligatoires.

Options envisagées

Ajouter des mots difficiles et retirer des mots faciles

Écartée pour le lancement : environ deux cents mots à créer et autant à déplacer, avec leurs faits, leurs silhouettes et leur relecture. Le calendrier de l’ADR 0054 ne le permet pas, et la qualité éditoriale en souffrirait.

Reclasser des mots pour atteindre les tiers

Écartée : un mot sans transformation ne peut pas être difficile selon l’ADR 0047. Reclasser pour passer le contrôle fausserait l’équilibrage qu’il sert à guider.

Appliquer la règle au catalogue entier plutôt qu’au fascicule

Écartée : elle laisserait chaque fascicule ordinaire libre de déséquilibrer le tout, alors que l’ADR 0047 veut des défis dans chaque fascicule.

Conséquences

Positives

• Les fascicules de lancement restent tels qu’ils ont été relus.
• Un catalogue de départ surtout transparent apprend la mécanique de fusion aux nouveaux joueurs, qui arrivent tous en même temps au lancement.
• La règle garde toute sa force pour les fascicules mensuels.

Négatives

• Un joueur assidu trouve peu de vrais défis pendant les dix premières semaines : les indices, les ricochets et les légendaires doivent porter l’intérêt.
• La quête de table du jour, qui peut s’appuyer sur la difficulté (ADR 0045), aura peu de mots difficiles à proposer au début.

Critères de réévaluation

• Les joueurs assidus jugent les fascicules de lancement trop faciles, ou le taux de découverte y est bien plus haut que dans les suivants : ajouter des mots difficiles aux fascicules de lancement.
• Le onzième fascicule, tenu aux tiers, fait chuter la découverte : revoir la définition des niveaux.

• Statut : Proposé, partiellement remplacé par l’ADR 0061 : l’équipe ne complète plus Wikidata, et Wikidata l’emporte en cas de désaccord ; le reste de la décision reste en vigueur
• Remplace partiellement : ADR 0014, pour les sources (Wiktionnaire en repérage, références savantes qui attestent, rôles reference et reperage) ; le fascicule, la complétude et l'exclusion déclarée restent en vigueur
• Modifie : ADR 0055 (origine des transcriptions), ADR 0056 (origine de la date), ADR 0058 (la chaîne passe par une langue « d'après Wikidata »)
• Complète : ADR 0002 (sources et confiance), ADR 0017 (licences)

Contexte

L'ADR 0014 répartit les sources en deux rôles : des références savantes qui attestent (TLFi, Académie française, Littré, Gaffiot, Ernout-Meillet, Bailly, LSJ, Chantraine) et le Wiktionnaire, qui repère. Ces références ne sont pas libres, souvent payantes ou consultables seulement en ligne. Chaque fait demande une consultation humaine entrée par entrée, que ni un agent ni un script ne peut refaire de façon vérifiable.

Wikidata couvre les langues, et, par ses lexèmes, les lemmes, leur langue, leurs formes, leurs étymologies (dérivation, combinaison de lexèmes) et, parfois, la première attestation d'un mot. Ses données sont CC0 : aucune contrainte de licence ne pèse sur le catalogue. Elles sont interrogeables par SPARQL, donc vérifiables et rejouables. Un serveur MCP les expose aux agents qui rédigent le contenu.

Décision

Une seule source de vérité

• Wikidata est la seule source d'un fait du catalogue : existence et forme d'une unité, langue, étymon, relation, composition, première attestation, transcription.
• Les références savantes (TLFi, Académie française, Littré, Gaffiot, Ernout-Meillet, Bailly, LSJ, Chantraine) et le Wiktionnaire (y compris Wiktextract et kaikki.org) ne sont plus des sources : ni pour attester, ni pour repérer, ni pour vérifier. Aucun import du Wiktionnaire n'est conservé ni comparé.
• Le rôle de source (reference ou reperage) disparaît : il n'y a qu'un rôle. Une source du catalogue désigne une entité Wikidata (item Q… ou lexème L…).
• Chaque lien entre un fait et sa source indique l'identifiant de l'entité consultée (Q… ou L…, éventuellement l'identifiant de l'énoncé) et la date de la consultation, qui tient lieu d'édition.
• Les gloses, définitions, sens littéraux et explications restent rédigés par l'équipe. Aucun libellé Wikidata n'est copié par défaut ; la licence CC0 l'autoriserait, mais les textes du jeu sont éditoriaux.

Niveaux de confiance

• Sans déclaration Wikidata, pas de fait publié. Une absence dans Wikidata ne prouve rien contre un fait, mais elle l'empêche d'être publié. L'équipe peut compléter Wikidata, puis publier le fait.
• Le fait naît brouillon ; seule une relecture humaine le passe à relu (ADR 0002). La relecture rejoue la requête.

Fermeture

La règle de fermeture de l'ADR 0014 devient : pour toute suite ordonnée de briques publiées, si Wikidata porte un lexème formé de ces éléments (propriété « combine les lexèmes » ou « dérivé du lexème »), ce mot est publié avec sa recette, ou écarté par une exclusion déclarée. La recherche des candidats est une requête SPARQL sur les lexèmes, sans import du Wiktionnaire.

Attestation et prononciation

• La première attestation (ADR 0056) est lue dans la déclaration « first attested from » du lexème, avec sa précision. Un lexème sans cette déclaration n'a pas d'attestation affichée.
• Les transcriptions (ADR 0055) sont lues dans les formes du lexème. Une forme sans transcription n'en a pas.

Agent et outillage

Seul l'agent qui génère les nouveaux mots interroge Wikidata, par le serveur MCP wikidata (skill nouveau-mot). Le validateur du dépôt de contenu ne fait aucun appel réseau : il vérifie la forme des sources (identifiant, date), pas leur véracité.

Options envisagées

Garder les références savantes en plus de Wikidata

Écartée : deux sources de vérité se contredisent, et la décision de l'emporter ne se prend pas sans humain. L'équipe veut une seule règle, rejouable.

Garder le Wiktionnaire en repérage

Écartée : un repérage hors Wikidata ouvre une seconde porte d'entrée aux faits, et il faudrait en conserver les imports datés.

Wikidata en repérage, références savantes qui attestent

C'était l'état de l'ADR 0014 en esprit. Écartée : elle laisse le goulot de la consultation humaine et ne se vérifie pas par machine.

Conséquences

Positives

• Une seule règle de preuve, rejouable par requête SPARQL, sans licence ni accès payant.
• Un agent peut établir, citer et revérifier un fait seul.
• Plus d'import du Wiktionnaire à archiver ni à comparer d'un fascicule à l'autre.
• Les corrections de l'équipe profitent à Wikidata.

Négatives

• La couverture de Wikidata borne le catalogue. Les lexèmes latins et surtout grecs anciens sont incomplets ; des mots et des étymons seront impubliables tant que Wikidata ne les porte pas.
• Wikidata est ouvert : une déclaration peut changer ou être vandalisée après publication. Le catalogue publié est un instantané ; la date de consultation et la relecture humaine sont les garde-fous.
• Les faits déjà saisis d'après le TLFi ou le Bailly doivent être recoupés avec Wikidata ou rétrogradés en brouillon.
• L'ADR 0056 perd la précision éditoriale du TLFi ; les dates seront moins nombreuses.

Chantiers découlant

• Schéma source : un seul rôle, localisation = identifiant Wikidata, date de consultation. Règle de publication publication.source_reference adaptée.
• Faits existants et sources src_… du dépôt de contenu à migrer (ADR 0005).

Critères de réévaluation

• Plus du tiers des candidats d'un fascicule ne sont pas publiables faute de lexème Wikidata.
• Une déclaration Wikidata utilisée par un fait publié change ou est contestée plus d'une fois par fascicule.
• Wikidata change de licence ou son serveur MCP n'est plus maintenu.

• Statut : Proposé
• Remplace partiellement : ADR 0060, pour la possibilité de compléter Wikidata avant de publier un fait ; Wikidata seule source, les niveaux de confiance, la fermeture, l’attestation, la prononciation et l’outillage restent en vigueur
• Complète : ADR 0002 (confiance non_retenue)

Contexte

L’ADR 0060 fait de Wikidata la seule source du catalogue, et ajoute : « L’équipe peut compléter Wikidata, puis publier le fait. » Le recoupement des dix fascicules de lancement (issue Content #32) laisse beaucoup de faits que Wikidata ne porte pas : 584 unités sans lexème, 228 relations sans déclaration « dérivé du lexème » (P5191), 707 compositions sans déclaration « combine les lexèmes » (P5238). Compléter Wikidata était la seule voie pour publier ce reste.

Le recoupement relève aussi des désaccords : Wikidata déclare une analyse, le catalogue en saisissait une autre (tri- du latin tres et non du grec τρεῖς, Ökologie de öko- et -logie, etc.). L’ADR 0060 ne dit pas laquelle l’emporte.

Décision

Aucune contribution

• L’équipe ne contribue pas à Wikidata : elle n’y crée ni ne modifie aucune entité, déclaration ni sens, et n’y signale pas d’erreur.
• Un fait que Wikidata ne porte pas reste brouillon, impubliable, tant que Wikidata ne le porte pas de lui-même. Une absence ne prouve rien contre le fait : il n’est pas passé en non_retenue.
• Une erreur probable de Wikidata (un sens sans rapport avec le lexème, par exemple) est notée dans note_interne du fait concerné, qui reste brouillon.

Wikidata fait référence

• Quand Wikidata contredit le catalogue (il déclare une autre analyse du même fait), l’analyse de Wikidata l’emporte. L’analyse du catalogue passe en non_retenue, avec dans note_interne la déclaration Wikidata qui la contredit et la date de consultation.
• Un sens Wikidata plus étroit que la glose (mener : seulement « être en tête d’une course ») n’est pas une contradiction : la liste des sens de Wikidata est incomplète. La glose n’est pas réécrite d’après Wikidata ; sans sens qui la porte, elle reste brouillon.
• Réaligner une composition sur Wikidata quand cela change des briques ou des recettes reste une décision de game design, prise au cas par cas.

Options envisagées

Compléter Wikidata pour publier le reste

L’ADR 0060 le permettait : créer les lexèmes manquants, déclarer P5191, P5238 et la première attestation (P6684), signaler les erreurs. Écartée par décision de l’équipe (issue Content #32) : Wikidata est la référence, et le catalogue n’en est jamais la source.

Garder les deux analyses en confiance discutee

Écartée : selon l’ADR 0060, discutee désigne deux analyses portées par Wikidata. Une analyse du catalogue que Wikidata ne porte pas n’est pas une analyse discutée.

Conséquences

Positives

• Une règle simple pour chaque désaccord : Wikidata l’emporte.
• Aucune entité de Wikidata ne dépend de l’équipe : la source reste indépendante du catalogue.

Négatives

• Le reste du recoupement est impubliable sans échéance : il dépend du rythme de Wikidata, surtout pour le grec ancien et les éléments de composition français (-logie, -phobie…).
• Des analyses justes mais absentes de Wikidata disparaissent du jeu publié.
• Une erreur de Wikidata reste en place, et bloque les faits qui en dépendent.

Critères de réévaluation

• Le critère de l’ADR 0060 est atteint : plus du tiers des candidats d’un fascicule ne sont pas publiables faute de lexème Wikidata.
• Un fascicule ne peut plus réunir assez de mots publiables pour respecter sa taille.

• Statut : Proposé
• Complète : ADR 0011 (le tirage d’un pli reste inchangé) et ADR 0020 (les plis en attente)

Contexte

Quand plusieurs plis attendent le joueur (la capacité d’énergie peut monter à dix), il doit les ouvrir un à un : chaque ouverture dure 1,5 à 2 secondes et finit par un écran à passer. Dix plis, c’est plus de vingt secondes de rituel identique, au moment où le joueur veut surtout retrouver ses briques.

Le rituel d’un pli (charge, écriture, explosion, révélation) est ce que le jeu a de plus marquant. Le raccourcir ou le supprimer pour un lot appauvrirait ce que le joueur aime.

Décision

Un bouton, à partir de deux plis prêts

• Sur l’atelier d’un fascicule, dès que deux plis ou plus sont prêts, un bouton secondaire « Ouvrir les N plis » apparaît à côté de « Ouvrir le pli ». « Ouvrir le pli » reste l’unique action principale, en Corail.
• Le bouton ouvre tous les plis prêts du fascicule choisi, jusqu’à la capacité d’énergie. Il est désactivé hors connexion et pendant une ouverture.
• Chaque pli est un pli ordinaire : même tirage, mêmes garanties comptées pli après pli, même encre. Le serveur reste seul maître de chaque tirage. L’application envoie une commande d’ouverture par pli, l’une après l’autre, chacune avec sa propre clé d’idempotence et la version d’état renvoyée par la précédente.
• Si une commande échoue en cours de route (plus de charge, état périmé, réseau), la série s’arrête. Les plis déjà ouverts s’affichent, une phrase dit pourquoi les autres ne l’ont pas été, et l’état est resynchronisé. L’échec n’est jamais présenté comme un succès.

Un rituel en canon

• Les N plis s’affichent en grille, secoués, dès l’envoi. Chaque pli joue le rituel entier d’un pli seul, avec ses brouillons barrés et sa plume, et les départs sont décalés de 0,11 s.
• La brique prend la place de son pli : nouvelle brique, « +1 · ×3 » ou « pleine », avec sa forme de rareté.
• Une rare ou une légendaire annonce son tirage dès l’écriture : plume et rayons violets, écriture plus longue de 0,6 s, anneau violet à la révélation, accord pour la légendaire. Une annonce « Rare ! » ou « Légendaire ! » conclut le lot, d’après sa meilleure rareté.
• La plume du rituel groupé va un peu plus vite que celle d’un pli seul et saute le brouillon de translittération pour une brique ordinaire ; à six plis ou plus, un pli ordinaire n’écrit qu’un brouillon.
• À dix plis, le rituel dure environ 4 secondes (5 avec une rare et une légendaire).
• Toucher la scène, Échap ou Espace passe l’animation, comme pour un pli seul. Si le système demande de réduire les animations, le résultat s’affiche directement.

Revue de l’animation

Une relecture indépendante de l’animation (11 octobre 2026) a conduit à quelques retouches, sans changer le principe du canon :

• Retenu : une rare ou une légendaire garde un contour violet une fois le lot révélé, et les rayons de fin restent violets, pour que le moment fort ne s’efface pas avec l’anneau. Un pli ordinaire de petite taille (six plis ou plus) n’écrit qu’un brouillon, la plume y étant illisible. L’annonce lue aux lecteurs d’écran commence par la meilleure rareté, chaque brique dit sa rareté, et le flash est coupé quand les animations sont réduites. L’écart entre les deux grands plis est élargi.
• Gardé tel quel : le décalage fixe de 0,11 s entre deux plis, et l’ordre des départs, qui suit celui des tirages. Allonger le décalage avec le nombre de plis ou jouer la rare en dernier ferait monter l’attente, mais allongerait l’ouverture et ferait passer la mise en scène avant l’ordre réel des tirages.
• Non traité : l’équilibrage des rangées (4-4-2, 3-3-3-1) et le coût de rendu de l’écriture lettre à lettre, qui n’a pas été mesuré.

Résultat

• Chaque brique est un bouton « Essayer sur la table ». « Continuer » revient à l’atelier.
• Une seule phrase résume le lot, annoncée une fois aux lecteurs d’écran : « 5 plis ouverts : 2 nouvelles briques, +14 gouttes d’encre. »
• L’encre, les nouveautés, la garantie et l’historique restent figés pendant le rituel et arrivent d’un bloc à la fin, comme pour un pli seul.

Options envisagées

Une route serveur qui ouvre N plis en une transaction

Tout ou rien, une seule clé d’idempotence, un seul aller-retour. Écartée pour l’instant : elle demande un contrat d’API nouveau et ne change rien pour le joueur. À reprendre si les échecs en cours de série se montrent fréquents.

Rafale, éventail, plis retournés, crescendo, bilan groupé

Cinq autres mises en scène ont été comparées en maquette. La rafale et l’éventail raccourcissent le rituel sans le garder entier ; les plis retournés demandent N gestes ; le crescendo révèle les briques dans un ordre différent du tirage ; le bilan groupé ne montre pas les briques atterrir. Le canon garde le rituel de chaque pli, sans ordre inventé.

Conséquences

Positives

• Dix plis s’ouvrent en environ 4 secondes au lieu de plus de 20, sans retirer le rituel.
• Aucun changement de règle de jeu, d’équilibrage ni de contrat d’API.
• Le joueur reconnaît le rituel qu’il connaît.

Négatives

• À dix plis, chaque pli est petit : la plume est décorative, seul le résultat se lit.
• Une série interrompue laisse un lot ouvert en partie.
• Beaucoup d’éléments animés à l’écran : l’animation se limite aux propriétés transform et opacity.
• La durée de 1,5 à 2 secondes du rituel d’ouverture ne vaut plus que pour un pli seul.

Critères de réévaluation

• Plus de 2 % d’ouvertures groupées interrompues en cours de série : passer à une route serveur en une transaction.
• Une ouverture groupée passée dans plus de la moitié des cas : raccourcir encore le canon.
• Un taux de plis ouverts un à un qui baisse sans que les ouvertures groupées augmentent : le bouton n’est pas trouvé.

• Statut : Proposé
• Remplace partiellement : ADR 0044, pour la maîtrise « définitive » (la carte « reste » maîtrisée)
• Complète : ADR 0044 (le choix des cartes d’une séance) ; ADR 0043 (les légendaires restent hors de la jauge)

Contexte

L’ADR 0044 dit qu’une carte maîtrisée « reste » maîtrisée et revient « tous les 7 jours au plus ». Il ne dit pas ce qui arrive quand le joueur se trompe sur elle, ni si elle entre dans le choix des cartes d’une séance. Le modèle de données la rend même définitive (maitrisee_le ne s’efface plus).

Une maîtrise qu’aucune erreur ne peut défaire ne mesure rien : un joueur qui a oublié une carte la garde dans sa jauge. Et une carte maîtrisée qui ne revient jamais n’est plus révisée, ce qui contredit le pilier Transmission.

Décision

Une carte maîtrisée reste dans le tirage

• Une carte maîtrisée est à revoir quand sa prochaine révision est atteinte, au plus 7 jours après la précédente. Elle ne sort jamais définitivement du tirage.
• Une séance de 5 questions choisit ses cartes dans cet ordre : les cartes à revoir non maîtrisées, puis les découvertes récentes, puis les cartes maîtrisées à revoir. Elle compte 2 cartes maîtrisées au plus, pour que les cartes en cours d’apprentissage restent prioritaires. Faute de mieux, une séance se complète avec ce qu’elle trouve : elle ne reste jamais vide.

Une erreur fait descendre d’une marche

• Une mauvaise réponse à une carte à revoir la fait descendre d’un niveau, y compris quand elle était maîtrisée : de maîtrisée (niveau 3, trois bonnes réponses) elle passe au niveau 2. Elle revient le lendemain.
• Elle perd alors sa maîtrise : la jauge du fascicule baisse (« 18 / 24 » devient « 17 / 24 ») et le signe de maîtrise disparaît de la carte. Aucun signe particulier ne la remplace : une carte qui a perdu sa maîtrise est une carte à revoir comme une autre, sans reproche.
• La carte regagne la maîtrise par le chemin habituel : elle remonte au niveau 3, puis trois bonnes réponses sur trois jours différents. Le compte bonnes_niveau_3 repart de 0 ; il n’y a pas de raccourci.
• Les paliers déjà atteints d’une quête au long cours le restent : une récompense atteinte ne se retire pas (ADR 0045).

Inchangé

• Une mauvaise réponse ne coûte rien (ni exemplaire, ni énergie, ni encre) et s’affiche en Gris encre, jamais en rouge.
• Une réponse à une carte qui n’est pas à revoir ne change aucun niveau.
• Les légendaires restent hors de la jauge de maîtrise.
• Le codex n’affiche aucun nombre de cartes à revoir.

Données et serveur

• ricochet.maitrisee_le redevient nullable et réversible : il est vidé quand la carte perd sa maîtrise, rempli quand elle la regagne. Une carte est maîtrisée si et seulement si maitrisee_le est rempli.
• La commande ricochet applique la règle côté serveur, qui fait foi ; le client suit la même règle pour choisir les cartes d’une séance.
• Le récapitulatif de fin de séance annonce une maîtrise perdue sans la dramatiser : « géologie revient demain. »

Options envisagées

Garder la maîtrise définitive

Écartée : la jauge cesserait de refléter ce que le joueur sait, et la carte ne reviendrait plus.

Retomber au niveau 0 ou 1 après une erreur

Écartée : une seule erreur annulerait des semaines de révision, et l’erreur pèserait plus que le reste, contre l’esprit d’un jeu où se tromper ne coûte rien.

Garder les trois bonnes réponses après une perte

Écartée : la carte redeviendrait maîtrisée sur une seule bonne réponse, le jour même d’une erreur : la maîtrise ne prouverait plus rien.

Un signe particulier pour une carte qui a perdu sa maîtrise

Écartée : un signe de plus à dessiner, et un reproche de plus sur la carte. Le signe de maîtrise qui disparaît suffit.

Aucun plafond de cartes maîtrisées par séance

Écartée : un joueur qui a beaucoup de cartes maîtrisées ne verrait plus que ces cartes, au détriment des découvertes récentes.

Conséquences

Positives

• La jauge de maîtrise reste honnête : elle baisse quand le joueur oublie.
• Les cartes maîtrisées continuent d’être révisées, sans prendre la place des cartes en cours d’apprentissage.
• Aucune règle nouvelle à apprendre : le niveau descend d’une marche, comme pour toute carte.

Négatives

• Une jauge qui baisse peut décevoir : le ton du récapitulatif doit rester sans reproche.
• Les cartes maîtrisées doivent être comptées comme un état courant, plus comme un acquis : une migration du champ maitrisee_le des joueurs existants n’est pas nécessaire (les valeurs remplies restent valides).
• Quêtes au long cours sur la maîtrise : leur progression suit l’état courant, leurs paliers atteints restent acquis.

Critères de réévaluation

• Beaucoup de joueurs perdent des maîtrises sans les regagner : revoir la marche (ou le nombre de bonnes réponses à refaire).
• Les séances paraissent répétitives : revoir le plafond de 2 cartes maîtrisées.
• Les tests montrent que la baisse de jauge est vécue comme une punition.

• Statut : Accepté
• Portée : tous les visuels du jeu et de ses supports : silhouettes des cartes, jaquettes, illustrations, icônes, maquettes, captures et communication
• Complète : ADR 0023 (silhouettes des cartes), ADR 0016 (jaquettes)

Contexte

La peur des araignées est l’une des phobies les plus répandues. Une silhouette d’araignée suffit à mettre mal à l’aise une partie des joueurs, alors que le codex se veut un lieu qu’on a plaisir à parcourir, et une carte trouvée reste affichée longtemps.

La question s’est posée avec le fascicule n° 11 : la première silhouette de zoopsie (hallucination où l’on voit des animaux) montrait une araignée au bout de son fil. Rien n’interdisait ce sujet.

Décision

• Aucun visuel ne représente une araignée, ni en entier, ni en partie (pattes, toile, fil d’araignée), ni de façon stylisée. Cela vaut pour les silhouettes des cartes, les jaquettes, les illustrations, les icônes, les maquettes et tout support de communication.
• Un mot dont le sens touche aux araignées (arachnophobie, arachnide) garde sa place dans le catalogue : sa silhouette choisit un autre sujet, par exemple la réaction de la personne ou un objet du contexte.
• La règle s’ajoute aux « Formes à éviter » du skill silhouette du dépôt de contenu, et se vérifie à chaque revue de planche.

Options envisagées

Laisser le choix au cas par cas

Écartée : un dessin d’araignée réussi reste une araignée. La gêne ne dépend pas de la qualité du dessin.

Interdire tous les animaux qui suscitent une phobie courante

Écartée pour l’instant : serpents, insectes ou rongeurs servent des mots du catalogue (nécrophage, zoopsie) et se dessinent sans effet de surprise. L’araignée est le cas le plus fréquent et le plus net.

Conséquences

Positives

• Aucun joueur ne tombe sur une araignée en ouvrant son codex.
• La règle est simple à appliquer et à vérifier en revue.

Négatives

• Quelques mots perdent leur sujet le plus évident et demandent un dessin moins direct.

Critères de réévaluation

• Des retours de joueurs signalent un malaise devant d’autres sujets (serpents, insectes) : étendre la liste.
• Un mot du catalogue ne peut se dessiner lisiblement sans araignée : trancher ce cas dans un nouvel ADR.

• Statut : Proposé, étape « Valider » remplacée par l’ADR 0068 : la seconde brique posée envoie la réponse. Le reste reste en vigueur.
• Complète : ADR 0044 (un format de plus, le septième ; la séance, la maîtrise et l’absence de chronomètre ne changent pas) ; ADR 0053 (même étape de validation) ; ADR 0007 (la commande de réponse reste unique et sous autorité serveur)

Contexte

Les formats des ricochets (ADR 0044) vont du sens vers la brique (Brique d’un sens) ou de la brique vers le sens (Sens d’une brique), et Découper part du mot pour retrouver ses morceaux. Aucun ne demande de construire un mot : le joueur reconnaît toujours une réponse déjà écrite, ou coupe un mot qu’on lui montre.

Or le geste central du jeu est la fusion : assembler des briques pour retrouver un mot. Les ricochets n’en gardent rien. Le format Mot d’un sens littéral s’en approche, mais le sens littéral (« description de la terre ») donne les morceaux presque mot à mot : il se résout par la glose, sans connaître la forme des briques. Le format « littéral ou actuel » a d’ailleurs été abandonné à la livraison de l’App.

Il faut un format où l’énoncé ne trahit pas les morceaux, et où le joueur produit le mot en choisissant ses briques.

Décision

Le format Assembler

• Le joueur voit la définition actuelle d’un mot qu’il a trouvé, jamais son sens littéral : « Science qui décrit la surface de la Terre. » La consigne est « Assemblez le mot. »
• Sous la définition, deux colonnes : à gauche les préfixes, à droite les suffixes. Une colonne propose 4 briques, ou 2 ou 3 quand le joueur n’en connaît pas assez (ADR 0044).
• Le joueur touche une brique de chaque colonne. Entre les deux colonnes, un assemblage à deux emplacements vides (« ? + ? ») montre son choix : chaque brique choisie y prend sa place, et toucher une brique choisie la retire. Choisir une autre brique dans la même colonne remplace la précédente.
• « Valider » s’active quand les deux emplacements sont remplis. Rien n’est jugé ni envoyé avant : comme pour Découper (ADR 0053), un doigt qui dérape sur le second toucher ne donne pas une réponse définitive. C’est la seule autre exception à « un toucher répond ».
• Une brique s’affiche toujours comme une brique, avec son trait d’union (« géo- », « -graphie ») et la couleur de son type, sans sa glose : la glose rendrait la réponse déductible sans connaître le mot.

Quels mots sont tirés

• Un mot est éligible si la composition préférée de sa carte compte exactement deux briques, la première écrite avec un trait d’union à droite (« géo- »), la seconde avec un trait d’union à gauche (« -graphie »). C’est la position qui décide de la colonne, pas le type : une racine écrite « géo- » se range dans les préfixes et garde la couleur de son type.
• Les mots à trois briques ou plus, et les mots à une seule brique, n’ont pas ce format : Découper les couvre.
• Le mot est une carte trouvée et non légendaire, comme pour les autres formats (ADR 0043). Sa définition actuelle est obligatoire pour tout mot découvrable : le format ne demande aucune donnée éditoriale de plus sur la définition.
• Une définition qui contient le mot lui-même, ou l’une de ses briques sous la même forme, n’est pas proposée : le validateur de contenu la signale, et le mot perd ce format tant qu’elle n’est pas reformulée.

Les leurres

• Les leurres viennent des briques que le joueur connaît, jamais d’une brique inconnue, qui serait dévoilée, et jamais d’un mot inventé. Les préfixes en place dans la colonne de gauche, les suffixes dans celle de droite.
• Un leurre n’a pas la même classe de sens que la brique juste : deux affixes de même glose donneraient deux bonnes réponses.
• Aucune des paires possibles entre les deux colonnes, hors la bonne, ne forme un autre mot du catalogue : chaque colonne propose 4 briques, soit 16 paires, et une seule est juste. Un leurre qui compose un mot réel, trouvé ou non, est écarté.
• La bonne brique ne tombe pas toujours au même rang : les deux colonnes sont mélangées à chaque question.

La réponse et le verdict

• La commande ricochet reçoit la paire de briques choisies, dans l’ordre (préfixe, suffixe), avec sa clé d’idempotence et la version_etat du client. Le serveur compare à la composition préférée : la réponse est juste si et seulement si les deux briques sont celles de la composition. Une seule réponse compte par question, quel que soit le nombre de briques posées puis retirées avant la validation.
• Bonne réponse : les deux briques s’emboîtent, le mot s’écrit en entier avec ses morceaux colorés, puis la définition reste affichée sous le mot.
• Mauvaise réponse : comme toute mauvaise réponse des ricochets (ADR 0044), sans rouge : les briques choisies passent en Sable avec un contour pointillé en Encre secondaire, secousse de 500 ms, rond barré et texte « Pas cette fois. ». Les deux bonnes briques s’emboîtent à leur place et le mot s’écrit. Le verdict dit en clair laquelle des deux briques choisies était juste (« Le début était juste. »), par le texte et par un signe, jamais par la couleur seule ; il n’y a pas de demi-point : la question est juste ou fausse.
• Mouvement réduit : l’emboîtement et la secousse sautent, le verdict affiche directement son état final.

Ce qui ne change pas

• Une séance compte toujours 5 questions, sans chronomètre ni note. Assembler entre dans le mélange des formats, jamais deux fois de suite. Une séance en compte un seul : il demande plus de gestes que les autres.
• Niveaux, échéances, maîtrise (ADR 0065), quêtes (ADR 0045) : une réponse à Assembler compte comme n’importe quelle autre réponse à la carte du mot.
• Le format est un candidat de plus dans le tirage : si aucun mot du joueur n’est éligible, ou s’il n’a pas assez de briques connues pour au moins deux choix par colonne, il n’est pas proposé.

Accessibilité

• Chaque colonne est un groupe de boutons (role="radiogroup", flèches pour se déplacer, Entrée ou Espace pour choisir) ; l’assemblage annonce son contenu (« Préfixe : géo-. Suffixe : pas encore choisi. »). Cibles de 44 px au moins.
• Sur mobile, les deux colonnes restent côte à côte : deux colonnes de briques de 44 px de haut tiennent sur 360 px de large, l’assemblage se pose sous elles, au-dessus de « Valider ».

Données et serveur

• Le serveur ne connaît aucun texte du catalogue. Il lui faut, pour chaque mot éligible, les deux identifiants de sa composition préférée (assemblage: [brq_…, brq_…]) et, pour chaque brique, sa position (préfixe ou suffixe) et sa classe de sens, déjà publiés pour les autres formats. Le manifeste ricochets de chaque fascicule les porte ; l’ajout est rétrocompatible (l’API d’abord, la PWA ensuite).
• Le contrat gagne un format assembler et une réponse à deux briques ; aucune table n’est créée : le niveau de la carte du mot suffit.
• L’exclusion des paires qui forment un mot réel se calcule à chaque tirage, sur les assemblages de tous les mots du catalogue publiés dans les manifestes : le serveur ne lit toujours aucun texte. Chaque brique porte sa colonne (position) dans le manifeste.

Options envisagées

Montrer le sens littéral comme énoncé

Écartée : « description de la terre » donne géo- et -graphie par leurs gloses. Le joueur n’aurait pas à connaître les formes des briques, seulement à traduire. La définition actuelle ne dit rien des morceaux ; c’est à lui de les retrouver.

Un toucher sur la seconde brique répond

Écartée : comme l’ADR 0053 pour Découper, la réponse partirait au dernier toucher, sans appel. Avec deux touchers à faire, le risque est double (on se trompe d’abord de colonne, puis de brique). Un bouton « Valider » coûte un toucher de plus mais supprime les réponses définitives par erreur.

Laisser le joueur écrire le mot au clavier

Écartée : le clavier, les accents et les variantes de forme (géographie, geographie) rendent la réponse fragile au toucher, et le joueur n’a pas à produire une orthographe : les briques sont l’objet du jeu.

Une seule colonne de briques mêlées

Écartée : préfixes et suffixes mêlés donneraient trop de combinaisons à parcourir et ôteraient une information que le joueur utilise déjà à la table de fusion, la place de la brique dans le mot.

Proposer aussi les mots de trois briques ou plus

Écartée pour l’instant : une troisième colonne (ou une colonne de racines) rend l’écran lourd sur mobile, et ces mots ont déjà Découper. À reprendre si la part de mots éligibles reste trop faible (voir les critères).

Montrer la glose de chaque brique

Écartée : l’énoncé et les gloses suffiraient à déduire le mot par élimination, sans jamais se souvenir de la forme des briques.

Conséquences

Positives

• Les ricochets retrouvent le geste de la fusion : assembler des briques pour former un mot, mais sans rien consommer.
• Le joueur retient la forme des briques et leur place (« géo- » devant, « -graphie » derrière), ce que ni Sens d’une brique ni Mot d’un sens littéral n’exercent.
• L’énoncé ne trahit rien : la définition actuelle est la donnée la plus fiable du catalogue, et elle existe déjà pour chaque mot découvrable.
• Aucune table de plus ; les données de jugement sont une paire d’identifiants par mot.

Négatives

• Un format de plus à dessiner, à tester sur mobile et à maintenir, avec une étape de validation comme Découper.
• Les mots à trois briques et plus n’y ont pas accès : la part de cartes concernées dépend du catalogue.
• Le validateur de contenu doit vérifier deux choses de plus : la définition ne contient pas le mot, et aucune paire de leurres ne forme un mot du catalogue.
• Quatre briques par colonne exigent du joueur qu’il en connaisse au moins deux de chaque position pour que le format ait un sens : en début de partie, il est rare.

Critères de réévaluation

• Si moins de 40 % des cartes de mots trouvées sont éligibles à Assembler sur le fascicule de lancement, étudier les mots à trois briques (une colonne de racines, ou deux emplacements fixes pour les briques déjà posées).
• Si la part de réponses fausses à Assembler dépasse de plus de 15 points celle des autres formats après un mois d’usage, réduire une colonne à 3 briques.
• Si le joueur retire presque toujours une brique juste après l’avoir posée, revoir la place de l’assemblage et la lisibilité de « Valider ».
• Si des définitions trahissent encore le mot malgré le validateur, ajouter un drapeau éditorial par mot plutôt qu’un contrôle de texte.

• Statut : Proposé
• Remplace partiellement : ADR 0067, pour l’étape « Valider » d’Assembler et l’option « Un toucher sur la seconde brique répond », écartée par cet ADR et retenue ici ; ADR 0053, pour la place de la lame à l’arrivée et après chaque coupe
• Complète : ADR 0044 (« un toucher répond » s’étend à Assembler) ; ADR 0007 (la commande de réponse reste unique et sous autorité serveur)

Contexte

Deux retours de jeu sur les ricochets.

Découper (ADR 0053) : la lame arrive vers 40 % du mot. Les mots à deux briques se coupent souvent près de ce point (géo|graphie, bio|logie) : la lame est déjà sur la bonne jointure, et le joueur valide sans avoir cherché. Le format ne mesure plus rien.

Assembler (ADR 0067) : après deux briques choisies, un toucher de plus sur « Valider ». En usage, ce toucher est vécu comme une formalité : le joueur a déjà choisi, et l’assemblage montre sa réponse dès la première brique posée.

Décision

Découper : la lame arrive sur un leurre

• À l’arrivée de la question, la lame se pose sur une jointure tirée au hasard, uniformément, parmi les jointures libres qui ne sont pas une coupe attendue. Toutes les jointures du mot sont possibles, des bords comme du milieu.
• Après chaque coupe posée, la lame repart de la même façon : une jointure libre tirée au hasard, jamais une coupe attendue.
• Quand aucune jointure libre n’est un leurre (un mot de deux lettres, ou la dernière jointure libre est la seule coupe restante), la lame se pose sur une jointure libre quelconque.
• Le tirage se fait dans le client, sans rien envoyer : la place de la lame n’entre pas dans la réponse.

Assembler : la seconde brique répond

• Il n’y a plus de bouton « Valider ». Dès que les deux emplacements de l’assemblage sont remplis, la réponse part et le verdict s’affiche.
• Tant qu’un seul emplacement est rempli, toucher la brique posée la retire, et choisir une autre brique de la même colonne la remplace.
• Le pied de la séance dit « Touchez un préfixe et un suffixe. » jusqu’à la réponse, comme « Touchez la bonne réponse. » pour les autres formats.
• La commande ne change pas : la paire (préfixe, suffixe), avec sa clé d’idempotence et la version_etat du client ; le serveur fait foi.

Options envisagées

Garder la lame vers 40 % du mot, mais la décaler si elle tombe sur la coupe

Écartée : la lame resterait près du milieu, à une lettre de la bonne jointure. Le joueur apprendrait vite qu’un seul pas suffit.

Tirer la lame sur toutes les jointures, coupe comprise

Écartée : avec un mot de huit à dix lettres, une fois sur huit environ la lame serait déjà en place. C’est le défaut qu’on corrige.

Garder « Valider » pour Assembler

Écartée : l’ADR 0067 craignait un doigt qui dérape sur le second toucher. Les deux colonnes sont distinctes, les cibles font 44 px, et la première brique posée se retire encore : le risque est faible, et le toucher de plus pèse sur chaque question.

Conséquences

Positives

• Découper demande toujours au moins un geste vers la bonne jointure : le format mesure de nouveau la connaissance du mot.
• Assembler passe de trois touchers à deux.

Négatives

• Une seconde brique touchée par erreur donne une réponse définitive, sans appel.
• La place de la lame n’est plus la même d’une séance à l’autre pour un même mot : un test de l’interface doit fixer le hasard.

Critères de réévaluation

• Si la part de réponses fausses à Assembler augmente de plus de 10 points après le retrait de « Valider », sur un mois d’usage, revoir l’espacement des colonnes ou revenir à une étape de validation.
• Si les joueurs signalent une lame « perdue » sur les mots longs (douze lettres et plus), la tirer à deux jointures au moins de la coupe plutôt que n’importe où.

• Statut : Proposé
• Portée : données du joueur, serveur de jeu, PWA ; la publication du catalogue ne change pas
• Remplace partiellement : ADR 0030, pour le moment où les graines sont accordées : au déblocage du fascicule pour ce joueur, et non plus à sa parution ; ADR 0048, pour l’estimation de ce qu’un nouveau joueur trouve le premier mois, qui supposait tout le catalogue ouvert
• Complète : ADR 0038 et ADR 0042 (le deuxième jalon d’un fascicule ouvre le suivant ; la récupération de la récompense reste à part) ; ADR 0016 (un pli ne s’ouvre que pour un fascicule débloqué) ; ADR 0045 et ADR 0046 (quêtes du jour, pli de lecteur et pli offert limités aux fascicules débloqués) ; ADR 0015 (codex d’un fascicule verrouillé) ; ADR 0054 (les quatre premiers fascicules paraissent ensemble, un joueur les ouvre un par un) ; ADR 0049 (la date du prochain fascicule reste affichée)

Contexte

Un fascicule paru est aujourd’hui ouvert à tous, tout de suite : ses graines arrivent à la première synchronisation (ADR 0030), son pli s’ouvre, ses silhouettes remplissent le codex et ses jalons la page Quêtes.

Les fascicules de lancement changent l’échelle (ADR 0054) : les quatre premiers paraissent ensemble, de 50 à 106 mots chacun, puis un par semaine. Un nouveau joueur reçoit d’un coup des centaines de silhouettes, quatre plis à choisir et douze jalons. La charge mentale est trop forte pour un premier contact, et le joueur ne sait pas par où commencer.

Chaque fascicule déclare déjà trois jalons, à environ un quart, la moitié et la totalité de ses mots (ADR 0038). Ils rythment la progression dans un fascicule ; ils peuvent aussi rythmer le passage au suivant.

Décision

La règle

• Un nouveau profil n’a qu’un fascicule débloqué : le fascicule paru de plus petit numéro.
• Atteindre le deuxième jalon d’un fascicule débloqué débloque, pour ce joueur seulement, le fascicule paru suivant, celui de numéro immédiatement supérieur parmi les parus.
• Le déblocage a lieu quand le jalon est atteint, dans la transaction de la découverte qui l’atteint, ou à la lecture de l’état. La récompense du jalon se récupère toujours à part (ADR 0042).
• Si le fascicule suivant n’est pas encore paru, le droit est acquis : il se débloque pour ce joueur dès sa parution, à sa première synchronisation.
• Un fascicule débloqué ne se reverrouille jamais, même si un fascicule de numéro intermédiaire paraît après coup.
• Les profils créés avant cette décision gardent débloqués tous les fascicules dont ils ont déjà reçu les graines.
• La publication ne change pas : l’index, les manifestes, la tâche de parution et la date du prochain fascicule (ADR 0029, ADR 0049) restent les mêmes pour tous. Le déblocage est une donnée du joueur, sous autorité du serveur (ADR 0007), qui ne contient que des identifiants opaques et une date.
• Chaque fascicule déclare donc au moins deux jalons ; le validateur du catalogue l’exige.

Ce qui attend le déblocage

Ne changent pas : le cadeau de bienvenue (ADR 0046), les quêtes au long cours, qui comptent toutes les découvertes, et les ricochets, qui portent déjà sur les seules cartes trouvées.

Un mot croisé reste découvrable

Des briques partagées peuvent former un mot d’un fascicule encore verrouillé. La fusion l’accepte : le mot entre au codex et compte pour les jalons de son fascicule dès le déblocage. Le serveur ne fait jamais passer un vrai mot pour un échec.

Montrer et annoncer

• Un fascicule paru et verrouillé reste visible dans le choix du pli, le codex et les quêtes : jaquette atténuée, cadenas, et sa condition, « Atteignez le 2ᵉ jalon de Nom ». La couleur n’est jamais le seul signal.
• Les fascicules débloqués passent devant les verrouillés, dans le choix du pli comme dans le sélecteur du codex et des quêtes. La liste des jalons de tous les fascicules ne montre que les débloqués ; un fascicule verrouillé ne montre sa condition que filtré.
• Sur le fascicule précédent, le deuxième jalon annonce « Ouvre le fascicule suivant ».
• La découverte qui débloque un fascicule le dit sur la table : « Nouveau fascicule ouvert : Nom », avec un lien vers son pli.
• Une pastille Corail « nouveau » marque la jaquette du fascicule débloqué jusqu’à sa première ouverture : le Corail garde son sens, quelque chose de nouveau attend le joueur.

Premier mois d’un nouveau joueur

L’estimation de l’ADR 0048, 55 à 60 mots le premier mois, supposait tout le catalogue ouvert. Elle ne tient plus : le nouveau joueur tire d’abord dans un seul pli et ouvre le deuxième fascicule à 25 mots sur 50. Le critère de taille critique (ne pas épuiser le catalogue en un mois) est d’autant plus facile à tenir ; seul le garde-fou de l’ADR 0012, jamais plus de deux jours sans découverte possible, reste à surveiller par la mesure de la rétention (ADR 0050).

Options envisagées

Tout ouvrir à la parution

Écartée : c’est la situation actuelle, trop lourde avec quatre fascicules de lancement ouverts ensemble.

Débloquer au dernier jalon

Écartée : finir un fascicule de 50 à 106 mots demande des semaines ; le joueur resterait trop longtemps enfermé, et les mots difficiles d’un fascicule bloqueraient tout le reste.

Débloquer à la récupération de la récompense

Écartée : un joueur qui ne va jamais dans les quêtes resterait bloqué sans comprendre pourquoi. Atteindre le jalon suffit ; la récupération reste un geste de récompense.

Cacher les fascicules verrouillés

Écartée : le joueur ignorerait qu’une suite existe. Une jaquette verrouillée avec sa condition donne un but, sans charge mentale.

Refuser un mot croisé d’un fascicule verrouillé

Écartée : un refus présenté comme un échec mentirait sur un vrai mot, et un refus explicite confirmerait qu’un mot existe sans rien apporter.

Un champ du catalogue pour désigner le jalon qui débloque

Écartée pour l’instant : les onze fascicules ont trois jalons, et le deuxième convient partout. Un champ demanderait schéma, validateur et contrat pour aucun cas réel.

Conséquences

Positives

• Un nouveau joueur commence par un seul fascicule : un pli, une poignée de graines, trois jalons.
• Chaque fascicule ouvert est une récompense et une surprise, annoncées sur la table.
• La publication, l’index et l’infrastructure ne changent pas.
• Les joueurs existants ne perdent rien.

Négatives

• Une table de plus dans les données du joueur, et un calcul de déblocage à chaque synchronisation et à chaque découverte.
• Un joueur assidu peut vouloir explorer un fascicule paru qu’il n’a pas encore ouvert : il doit d’abord avancer dans le précédent.
• Le cadeau de bienvenue peut contenir des briques d’un fascicule verrouillé ; elles n’ouvrent que des mots croisés.
• Les maquettes du choix du pli, du codex et des quêtes ne montrent pas encore l’état verrouillé.

Critères de réévaluation

• Des joueurs actifs restés plus de deux jours sans découverte possible dans leur premier fascicule : abaisser le seuil, ou ouvrir deux fascicules au départ.
• Des joueurs qui abandonnent devant un fascicule verrouillé : rapprocher le jalon qui débloque.
• Un fascicule dont le deuxième jalon ne convient pas : ajouter au catalogue un champ qui désigne le jalon qui débloque.

• Statut : Proposé, durée de conservation des comptes remplacée par l’ADR 0071 : un compte inactif depuis 3 ans est effacé ; le reste de la section « Supprimer, purger » reste en vigueur
• Remplace partiellement : ADR 0007, pour le compte, la récupération et le multi-appareil, qu’il réservait à une décision séparée ; ADR 0024, section « Identité et sécurité », pour le profil invité (un joueur peut désormais avoir plusieurs appareils et un compte)
• Complète : ADR 0010 (aucune adresse dans les journaux ni dans la télémétrie), ADR 0018 (le compte sera le prérequis des achats en euros)

Contexte

Chaque installation de la PWA est un profil invité anonyme (ADR 0007) : un identifiant d’installation et un secret de 256 bits, dont le serveur ne garde que l’empreinte. Si le stockage local disparaît, la progression est perdue. Un joueur ne peut ni changer d’appareil ni en utiliser deux.

Trois besoins arrivent ensemble :

• récupérer sa progression et jouer sur plusieurs appareils ;
• une vue compétitive, possible plus tard, qui demande un nom affichable.

L’ADR 0007 écarte un compte obligatoire au premier lancement : la friction et la collecte de données ne servent pas le jeu. Il demande un ADR dédié avant toute collecte d’identité.

Décision

Le compte est facultatif, l’invité reste le point de départ

• Le premier lancement crée toujours un profil invité, comme aujourd’hui. On joue sans jamais donner d’adresse.
• Le joueur crée un compte en rattachant une adresse électronique à son profil invité : la progression devient celle du compte, sans copie ni perte.
• Le compte ne donne aucun avantage de jeu : ni brique, ni encre, ni pli.

Relancer sans contraindre

L’invité est relancé par une carte « Sauvegardez votre progression », toujours refermable et jamais bloquante :

• à la 3ᵉ découverte ;
• à chaque jalon atteint ;
• sinon, tous les 7 jours de jeu depuis la dernière relance refermée.

Les Réglages gardent en permanence une entrée « Sauvegarder ma progression ». La relance n’est jamais un dialogue ; elle n’interrompt ni une fusion ni le rituel d’un pli.

Connexion sans mot de passe : un lien et un code dans le même e-mail

• Le joueur saisit son adresse. Le serveur envoie un e-mail qui contient un lien et un code à 6 chiffres, valables 15 minutes et à usage unique.
• Le lien sert dans un navigateur. Le code sert dans la PWA installée, en particulier sur iOS : le lien s’y ouvre dans Safari, dont le stockage est séparé de celui de la PWA.
• Le lien mène à la PWA, et seule la PWA confirme. Une visite automatique du lien par une messagerie ne consomme donc jamais le code.
• 5 essais au plus par code ; au-delà, il faut en demander un nouveau. Un nouveau code annule le précédent.
• La réponse à une demande est identique, que l’adresse ait un compte ou non : on ne peut pas savoir qui joue.
• Les demandes sont limitées par adresse réseau, par profil et par adresse électronique (par exemple 3 toutes les 15 minutes).

L’adresse n’est jamais conservée en clair

• Le serveur ne garde qu’une empreinte HMAC-SHA256 de l’adresse normalisée (rognée, minuscules), avec une clé secrète dédiée, distincte de celle des jetons de session.
• L’adresse en clair n’existe que le temps de l’envoi. Elle n’apparaît ni en base, ni dans les journaux, ni dans la télémétrie (ADR 0010), pas plus que le code ou le lien.
• Conséquence assumée : le jeu ne peut écrire à un joueur qu’au moment où il demande à se connecter. Ni lettre d’information, ni annonce par e-mail.
• L’empreinte reste une donnée pseudonyme : la page des données collectées l’explique avant toute diffusion publique.

Un joueur, plusieurs appareils

• Chaque appareil garde son identifiant d’installation et son secret. Un joueur peut en avoir plusieurs.
• Se connecter à un compte rattache l’appareil au joueur du compte.
• Si l’appareil porte une partie invitée avec une progression, le compte l’emporte : un avertissement explicite précède le remplacement, et la partie invitée est effacée, jamais fusionnée. Additionner deux économies (encre, plis, garanties, sabliers) ouvrirait des abus.
• Se déconnecter détache l’appareil, qui repart d’un profil invité neuf.

Le pseudo

• Chaque compte a un pseudo unique : 3 à 24 caractères, lettres minuscules sans accent, chiffres et traits d’union isolés.
• Par défaut, c’est la partie locale de l’adresse, assainie et tronquée à 16 caractères, suivie de - et de 4 chiffres : camille.martin@exemple.fr devient camille-martin-4821.
• Cette partie contient souvent un vrai nom : le pseudo par défaut reste privé tant que le joueur ne l’a ni confirmé ni modifié. Aucun écran ne le montre à un autre joueur avant cela.

Supprimer, purger

• « Supprimer mon compte » efface le joueur et toute sa progression, sur tous ses appareils, après une confirmation explicite.
• Un invité sans compte, inactif depuis 6 mois, est effacé par les purges quotidiennes. La carte de relance le dit. Un compte n’est jamais effacé automatiquement.
• Les demandes de connexion sont effacées au bout d’un jour.

Envoi des e-mails

• L’envoi passe par Scaleway Transactional Email, offre Essential (à l’usage), depuis noreply@etymologique.fr en production et noreply@horsprod.etymologique.fr hors production.
• Le domaine d’envoi est authentifié par SPF, DKIM et DMARC. La zone étant tenue hors de Scaleway, ces enregistrements se posent à la main.
• L’e-mail est en français, sobre, sans image distante ni lien de suivi. Il dit ce qu’il faut faire si l’on n’a rien demandé : rien.

Options envisagées

Compte obligatoire au premier lancement

Écarté, comme dans l’ADR 0007 : un e-mail en retard ou classé en indésirable empêcherait de jouer, et la première session doit mener à une fusion sans détour.

Mot de passe

Écarté : un secret de plus à retenir, à réinitialiser par e-mail de toute façon, et à protéger contre la réutilisation et le bourrage d’identifiants.

Lien magique seul

Écarté : sur iOS, le lien s’ouvre dans Safari et pas dans la PWA installée. La connexion aboutirait dans le mauvais stockage.

Connexion par Google ou Apple

Écartée pour l’instant : un tiers apprendrait qui joue, et il faudrait deux intégrations pour couvrir tout le monde. À reconsidérer si les e-mails n’arrivent pas.

Adresse conservée, chiffrée au repos

Écartée : elle permettrait d’écrire aux joueurs, mais ferait de la base une liste d’adresses à protéger, à exporter et à effacer sur demande. Le jeu n’en a pas besoin.

Fusionner la partie invitée et le compte

Écarté : additionner réserves, encre, sabliers et compteurs de garanties fausserait l’économie autoritaire (ADR 0007).

Pseudo tiré au hasard

Écarté à la demande du produit : un pseudo tiré de l’adresse est plus reconnaissable pour le joueur. Le risque d’exposer un nom est traité en gardant le pseudo privé jusqu’à confirmation.

Conséquences

Positives

• La progression survit à un changement d’appareil, et on peut jouer sur plusieurs appareils.
• Aucune adresse en clair : une fuite de la base ne livre aucun moyen de contacter les joueurs.
• Aucun mot de passe à protéger ni à réinitialiser.
• Une future vue compétitive dispose d’une identité.
• Le premier lancement reste sans friction.

Négatives

• Un nouveau service, l’envoi d’e-mails, avec sa réputation de domaine à entretenir et un coût au-delà de l’offre gratuite.
• Le jeu ne peut pas écrire à ses joueurs en dehors d’une connexion.
• Perdre la clé HMAC rend tous les comptes introuvables : elle se protège comme la clé des jetons, et sa rotation demanderait une double empreinte.
• Un invité inactif 6 mois perd sa partie.
• Plus d’écrans : connexion, relance, compte dans les Réglages.

Critères de réévaluation

• Plus de 5 % des demandes de code sans confirmation dans les 15 minutes : vérifier la délivrabilité, envisager un fournisseur d’identité tiers.
• Moins de 10 % des joueurs actifs depuis 30 jours ont un compte : revoir les moments de relance.
• Ouverture d’une vue compétitive : règles de modération des pseudos (ADR 0075).

• Statut : Proposé
• Portée : données du joueur, purges quotidiennes, textes légaux et Réglages de la PWA
• Remplace partiellement : ADR 0070, section « Supprimer, purger », pour la phrase « Un compte n’est jamais effacé automatiquement »
• Complète : ADR 0010 (« applique des durées de conservation documentées »), ADR 0024 (durées de conservation), ADR 0050 (agrégats d’équilibrage)

Contexte

Le RGPD demande une durée de conservation limitée et justifiée pour chaque donnée (art. 5.1.e). Deux données n’en ont pas :

• les comptes : l’ADR 0070 dit « Un compte n’est jamais effacé automatiquement » ;
• l’historique des plis (ouverture_pli) : jamais purgé.

Le jeu ne garde pas l’adresse (ADR 0070) : il ne peut donc pas prévenir un joueur avant d’effacer son compte. L’avertissement doit passer par le jeu lui-même et par les textes légaux.

Les autres données ont déjà leur durée : commandes 30 jours, quêtes du jour et réponses de ricochets 30 jours, demandes de connexion 1 jour, parties invitées inactives 6 mois, télémétrie brute 90 jours (ADR 0024). Le reste est la progression, qui vit autant que le profil.

Décision

Un compte inactif 3 ans est effacé

• Un compte (le joueur et toute sa progression, sur tous ses appareils) est effacé par les purges quotidiennes quand aucun de ses appareils n’a joué depuis 3 ans.
• Est une activité toute session ouverte avec le serveur par un appareil du joueur : une synchronisation, une commande, une connexion. Elle repousse l’effacement de 3 ans à compter de ce jour.
• Justification : la progression sert à reprendre la partie. Trois ans sans jouer laissent trois ans de fascicules sans aucune visite. Passé ce délai, la reprise est improbable, et une base de joueurs partis n’a plus de finalité. Un invité sans compte garde son délai de 6 mois, plus court, faute d’adresse pour le retrouver.
• Aucun achat en euros n’existe, et il n’y en aura pas.
• Les 3 ans sont à confirmer avec le conseil avant la bêta ouverte (ADR 0048). Le chiffre vit en un seul endroit du code des purges (MOIS_COMPTE_INACTIF).

Le joueur est prévenu sans e-mail

Aucune adresse n’est gardée : l’annonce se fait là où le joueur passe et là où le droit le demande.

• Réglages, entrée « Mon compte » : une ligne « Un compte inactif depuis 3 ans est effacé. »
• Carte de relance de l’invité (ADR 0070) : elle garde « une partie invitée inactive 6 mois est effacée ». On n’y ajoute rien : elle s’adresse à un invité.
• Conditions générales et politique de confidentialité : la durée, le critère d’activité et la manière de s’y soustraire (rouvrir le jeu).
• Au retour : un joueur qui revient avant 3 ans ne perd rien. Après, il repart d’un profil invité neuf ; l’adresse n’étant pas gardée, rien ne le relie à l’ancien compte.

Le texte à montrer :

Conservation de votre compte. Vous n’avez rien à faire pour le garder : il suffit de jouer de temps en temps. Si aucun de vos appareils n’a joué pendant 3 ans, votre compte et votre progression sont effacés. Nous ne vous écrivons pas avant : nous ne gardons pas votre adresse électronique. Vous pouvez aussi effacer votre compte à tout moment, dans les Réglages.

L’historique des plis est agrégé après 12 mois

• Le détail de ouverture_pli (brique tirée, résultat, règle appliquée) sert au diagnostic de l’équilibrage : garanties, filets, taux de doublons (ADR 0008, ADR 0016). Ce besoin porte sur quelques semaines, pas sur des années.
• Les lignes de plus de 12 mois sont agrégées par fascicule, rareté, résultat et règle appliquée, puis effacées. L’agrégat ne contient aucun identifiant de joueur et suit le seuil de 50 joueurs de l’ADR 0050.
• Le joueur n’a pas besoin du détail : la réserve, le codex et compteur_pli tiennent son état. Le détail disparaît aussi avec le joueur, par cascade.

Chaque table de joueur a sa durée

Options envisagées

Conserver les comptes sans limite, avec une justification écrite

Écartée : la progression n’a plus de finalité après des années d’absence, et le jeu ne peut pas demander son accord à un joueur qu’il ne sait pas joindre. L’effacement est le moindre risque.

Une durée plus courte (12 mois)

Écartée : un joueur de collection revient souvent après une longue pause, attiré par un fascicule. 12 mois effaceraient des parties que l’on veut reprendre, sans prévenir.

Garder l’adresse pour prévenir avant l’effacement

Écartée : ce serait contredire l’ADR 0070 et faire de la base une liste d’adresses à protéger, pour un message par joueur et par vie.

Purger l’historique des plis sans l’agréger

Écartée : l’équilibrage a besoin de mesures sur la durée, par exemple l’effet d’un nouveau fascicule sur les doublons. L’agrégat les garde sans identifiant.

Garder le détail des plis aussi longtemps que le compte

Écartée : c’est un historique fin de comportement, sans usage pour le joueur, qui croît à chaque pli.

Conséquences

Positives

• Chaque donnée a une durée écrite et justifiée ; la page des données collectées peut la citer.
• La base ne grossit plus sans fin avec des joueurs partis et leurs plis.
• Aucune adresse n’est ajoutée pour prévenir.
• L’issue d’implémentation de l’App (EtymoLogique/App#68) a toutes ses durées.

Négatives

• Un joueur absent 3 ans perd sa partie, sans avertissement individuel.
• Les purges portent une tâche de plus (agrégation des plis) et un critère d’activité à définir côté serveur.
• Un litige ancien sur un achat futur ne pourra pas s’appuyer sur mouvement au-delà de la vie du compte : à revoir à l’ouverture de la boutique.

Critères de réévaluation

• Avis du conseil sur les 3 ans, ou sur l’agrégation à 12 mois : ajuster les durées.
• Plus de 2 % des comptes effacés qui rouvrent un profil neuf dans les 30 jours : allonger la durée ou prévoir un rappel dans le jeu.
• Ajout d’un historique fin pour le joueur (journal de ses plis) : revoir la durée de ouverture_pli.

• Statut : Proposé
• Portée : télémétrie produit, base légale, information et opposition du joueur
• Précise : ADR 0050 (renouvellement au mois civil : où vit l’identifiant)
• Complète : ADR 0010 (« le produit explique la collecte et offre les contrôles requis »), ADR 0024 (la télémétrie passe par l’API)

Contexte

L’identifiant pseudonyme de la télémétrie se renouvelle chaque mois civil (ADR 0050). Aucun ADR ne dit où il vit, et c’est ce qui fixe le régime juridique (écart L15 de l’audit juridique de l’App, qui complète l’écart E3 de l’audit avant lancement) :

• écrit sur l’appareil : c’est un traceur. Il faut soit l’exemption de la CNIL pour la mesure d’audience (finalité limitée, aucun recoupement, aucun tiers, traceur de 13 mois au plus, données de 25 mois au plus, information et opposition), soit un consentement ;
• calculé côté serveur : le serveur voit déjà chaque fusion, indice et pli, puisqu’il fait foi (ADR 0007). Rien n’est lu ni écrit sur l’appareil pour la mesure : l’article 82 de la loi Informatique et Libertés ne s’appliquerait sans doute pas. Restent le RGPD (intérêt légitime), l’information et un droit d’opposition.

Les documents existants se contredisent sur la durée : l’ADR 0024 et la roadmap de l’App (jalon J7) disent « tous les 30 jours », l’ADR 0050 dit « au mois civil ». Le mois civil l’emporte : l’ADR 0050 en donne la raison (un joueur compté deux fois à cheval sur deux mois).

Ce relevé n’est pas un avis juridique : chaque règle ci-dessous est à confirmer avec le conseil avant la bêta ouverte (ADR 0048).

Décision

Le serveur calcule l’identifiant, l’appareil ne le voit jamais

• L’identifiant pseudonyme d’un événement est une empreinte à clé (HMAC-SHA-256) de l’identifiant d’installation et du mois civil de l’événement, avec une clé secrète du serveur. Deux mois, deux identifiants sans lien lisible entre eux.
• La clé vit dans les secrets du serveur, hors de la base de télémétrie. Aucune table ne fait correspondre un identifiant pseudonyme à un joueur : le serveur le recalcule quand il en a besoin (par exemple pour l’opposition).
• Les événements naissent sur le serveur, qui fait foi : fusion, indice, pli. Les rares événements vus seulement par l’appareil (étapes du tutoriel, erreur technique) arrivent par l’API, dans une session déjà ouverte ; le serveur y ajoute l’identifiant. Rien n’est écrit sur l’appareil pour la mesure : ni identifiant, ni cookie, ni entrée de stockage local, ni file d’événements en attente. Un événement qui ne peut pas partir tout de suite est abandonné.
• Les propriétés restent celles de l’ADR 0010, plus le mois d’arrivée (ADR 0050). Aucune adresse réseau complète n’est gardée.

Base légale : l’intérêt légitime de l’éditeur

• Finalité : mesurer l’équilibrage, la rétention et les erreurs du jeu, pour décider des fascicules, des plis et des quêtes (ADR 0050, tableau des indicateurs). Aucune publicité, aucun profilage, aucun tiers.
• Base : intérêt légitime (RGPD, art. 6, 1, f). Pas de consentement : l’événement ne dit rien que le serveur n’a déjà.
• Garde-fous qui font l’équilibre : pseudonyme à clé renouvelé chaque mois, propriétés énumérées, télémétrie brute 90 jours puis agrégats seuls seuillés à 50 joueurs (ADR 0024, ADR 0050), tables séparées de la progression, accès tracés.
• Le joueur s’oppose sans condition (RGPD, art. 21) : voir ci-dessous.
• Les tâches de rétention de l’ADR 0050 (cree_le, derniere_activite, mois_activite_precedente) ne dépendent pas de la télémétrie : elles lisent la table joueur, dont la conservation est réglée par l’ADR 0071. Elles ne produisent que des nombres seuillés ; l’opposition ne les change pas. À confirmer avec le conseil.

Information du joueur

• Au premier lancement : une ligne sous l’écran d’accueil de la première session, « Le jeu mesure son usage, sans vous identifier. Détails et refus dans les Réglages. », avec un lien vers « Données collectées ».
• Réglages, « Données collectées » : le texte ci-dessous et l’interrupteur d’opposition.
• Politique de confidentialité : la finalité, la base légale, la durée (90 jours puis agrégats), l’absence de tiers et de traceur, le droit d’opposition et celui d’introduire une réclamation auprès de la CNIL.

Le texte à montrer :

Mesure de l’usage. Pour équilibrer le jeu, nous comptons ce qui s’y passe : fusions, indices, plis, erreurs. Chaque mois, un identifiant nouveau, sans lien avec le précédent et sans votre nom, est calculé sur nos serveurs. Rien n’est écrit sur votre appareil pour cela. Les événements sont gardés 90 jours, puis seuls restent des totaux d’au moins 50 joueurs. Personne d’autre que nous ne les reçoit. Vous pouvez refuser à tout moment.

L’interrupteur d’opposition

• Un interrupteur « Mesure de l’usage » dans « Données collectées » (interfaces), actif par défaut, à effet immédiat, avec la sous-ligne « Aide à équilibrer le jeu. Sans nom, sans tiers. ». Même cible tactile et même forme que les autres interrupteurs (design système).
• Il est enregistré côté serveur, dans reglage, pour le profil du joueur : il vaut sur tous ses appareils et ne demande aucun stockage local.
• Désactivé : le serveur n’émet plus aucun événement pour ce joueur, qu’il vienne du serveur ou de l’appareil. Il efface aussi les événements bruts des 90 derniers jours : il recalcule les identifiants pseudonymes de ces mois pour ce joueur, puis supprime les lignes. Les agrégats déjà calculés sont anonymes et restent.
• Réactivé : la mesure reprend, sans rattacher les événements effacés.
• Le jeu fonctionne de la même façon, interrupteur actif ou non : aucune fonction, aucun cadeau ni contenu n’en dépend.
• La suppression d’un compte ou d’un profil invité (ADR 0070, ADR 0071) efface de même les événements bruts restants.

Alignement des documents

• ADR 0024 : « change tous les 30 jours » devient « change chaque mois civil, calculé côté serveur » (correction factuelle).
• Roadmap de l’App, jalon J7 : « renouvelé tous les 30 jours » devient « renouvelé chaque mois civil, calculé côté serveur », avec l’interrupteur d’opposition et le texte d’information.
• Audit avant lancement de l’App, E3 : le texte et le comportement sont ici.
• Game design, section de l’observabilité : le lieu de l’identifiant et l’opposition.

Options envisagées

Un identifiant écrit sur l’appareil, sous l’exemption de mesure d’audience de la CNIL

Écartée : c’est un traceur. L’exemption impose une finalité limitée à la mesure d’audience, des sorties anonymes et une durée de 13 mois au plus ; la télémétrie du jeu (équilibrage, erreurs) dépasse la simple audience. Le serveur n’a pas besoin de l’appareil pour compter.

Un identifiant sur l’appareil, avec consentement

Écartée : un bandeau à l’ouverture pèse sur une première session que le jeu veut douce (ADR 0046), et les joueurs qui refusent trouent la mesure de rétention, qui sert justement de seuil à la bêta.

Réutiliser l’identifiant du joueur comme identifiant de télémétrie

Écartée : l’ADR 0024 le veut distinct, et l’ADR 0050 écarte tout identifiant durable.

Une table de correspondance entre identifiants pseudonymes et joueurs

Écartée : elle rendrait la pseudonymisation réversible pour quiconque lit la base. Le recalcul par la clé suffit à l’opposition.

Une opposition par défaut (mesure désactivée)

Écartée : la mesure n’aurait de sens que pour une minorité, au risque de fausser les cohortes. L’opposition en un geste est le contrôle que l’intérêt légitime demande.

Conséquences

Positives

• Aucun traceur : pas de bandeau, pas de consentement à gérer.
• La télémétrie garde ses cohortes mensuelles et son mois d’arrivée (ADR 0050).
• L’opposition est réelle : elle arrête la collecte et efface le brut.
• Les trois documents (ADR, roadmap, game design) disent la même chose.

Négatives

• Un secret de plus à garder, à sauvegarder et à faire tourner avec soin : le perdre brouille les recalculs pour l’opposition.
• Un joueur qui s’oppose pèse moins dans les mesures : la base est plus petite que le nombre de joueurs.
• Le serveur voit tout, ce qui est inchangé mais doit maintenant être dit au joueur.
• L’avis du conseil peut changer la base légale, le texte ou la durée.

Critères de réévaluation

• Avis du conseil sur l’intérêt légitime, la non-application de l’article 82 ou les textes : ajuster la base, la durée ou le texte.
• Plus de 10 % de joueurs qui s’opposent : revoir l’information ou la finalité.
• Ajout d’un événement vu seulement par l’appareil et en grand nombre : revoir l’absence de file locale.
• Tout tiers, session replay ou traceur de plus : revue dédiée de la vie privée (ADR 0010).

• Statut : Proposé, à faire valider par le conseil et à accepter avant tout affichage d’un pseudo à un autre joueur
• Portée : vue compétitive (après le MVP), CGU, mentions légales, Réglages de la PWA
• Complète : ADR 0070 (section « Le pseudo » et critère « règles de modération des pseudos »), ADR 0010 (aucun contenu libre dans les journaux ni la télémétrie), ADR 0071 (durées de conservation)

Contexte

Dès qu’un pseudo est visible d’un autre joueur, le jeu héberge un contenu fourni par ses utilisateurs. Le règlement sur les services numériques (DSA) s’applique alors, même à une très petite structure (écart L18 de l’audit juridique) :

• points de contact pour les autorités (art. 11) et pour les utilisateurs (art. 12) ;
• conditions d’utilisation qui décrivent la modération, y compris l’examen humain et le traitement des réclamations (art. 14) ;
• mécanisme de signalement (art. 16) ;
• motivation de chaque décision qui restreint un contenu (art. 17).

Le jeu a deux contraintes propres. Le serveur ne garde jamais l’adresse électronique d’un joueur (ADR 0070) : il ne peut donc écrire ni au signalant ni au joueur visé. Et le pseudo par défaut vient de la partie locale de l’adresse, qui contient souvent un vrai nom : il reste privé tant que le joueur ne l’a pas confirmé.

Aujourd’hui, aucun écran ne montre un pseudo à un autre joueur. Cet ADR doit donc être accepté avant la vue compétitive, pas avant. Ce relevé n’est pas un avis juridique : le conseil confirme chaque règle.

Décision

Hypothèse de départ

• Le jeu est un service d’hébergement. Si la vue compétitive diffuse les pseudos au public, il est aussi une plateforme en ligne, mais une microentreprise ou une petite entreprise est exemptée des obligations propres aux plateformes (art. 19 : réclamations, règlement extrajudiciaire, signaleurs de confiance, rapport sur les utilisateurs actifs) et du rapport de transparence (art. 15). Le jeu est établi en France : pas de représentant légal à désigner (art. 13). Le conseil confirme ces trois points.
• Les obligations qui restent s’appliquent telles quelles : points de contact, conditions d’utilisation, signalement, motivation.
• Le jeu applique volontairement une réclamation simple (voir plus bas) : elle ne coûte presque rien et répond à l’article 14.

Quand un pseudo devient visible

• Un pseudo n’est montré à un autre joueur que s’il est confirmé par le joueur, ou modifié par lui (ADR 0070), et qu’il respecte les règles ci-dessous.
• L’écran de confirmation dit où le pseudo sera visible (« Les autres joueurs verront ce pseudo dans… ») et renvoie aux règles. Le joueur peut en choisir un autre à tout moment.
• Le pseudo par défaut n’est jamais montré, quel que soit le moment.

Règles des pseudos

Le format de l’ADR 0070 reste (3 à 24 caractères, minuscules sans accent, chiffres, traits d’union isolés). Il s’y ajoute :

• Aucun propos haineux, injurieux, discriminatoire, sexuel, violent ou qui fait l’apologie d’un crime.
• Aucun nom de personne identifiable autre que le sien, et aucune coordonnée : adresse électronique, numéro de téléphone (pas de suite de 6 chiffres ou plus), nom d’utilisateur d’un autre service.
• Aucune usurpation : pas de nom qui laisse croire que le pseudo est celui d’ÉtymoLogique, de son équipe ou d’un modérateur. Les noms réservés (par exemple etymologique, admin, support, moderateur) sont refusés.
• Aucune publicité ni appel à acheter, à rejoindre ou à visiter.

Le jeu tient pour non retenue toute orthographe qui contourne ces règles (chiffres à la place de lettres, traits d’union entre les lettres).

Le filtre à la saisie

• Une liste de termes interdits, normalisée (minuscules, chiffres lus comme des lettres, traits d’union retirés), est versionnée comme un paramètre (ADR 0009). Elle sert à refuser un pseudo au moment du choix ; elle ne retire jamais un pseudo déjà confirmé.
• Le refus dit la règle enfreinte, sans donner la liste : « Ce pseudo n’est pas disponible : il enfreint la règle sur les noms de personnes. Choisissez-en un autre. »
• Le filtre est une aide : il ne remplace pas le signalement, car une liste ne comprend ni le contexte ni les langues.

Le signalement

• Toute vue qui montre le pseudo d’un autre joueur porte une entrée « Signaler ce pseudo », atteignable en un geste, à 44 px au moins.
• Le formulaire demande : le motif (une règle ci-dessus, « contenu illicite » ou « autre »), une explication facultative de 500 caractères au plus, et rappelle que le pseudo signalé est joint au signalement. Il n’est pas nécessaire de se connecter : un invité peut signaler.
• Le jeu ne demande ni nom ni adresse au signalant. L’article 16 demande de faciliter ces éléments pour qu’un signalement vaille connaissance effective ; le signalant est ici identifié par son profil, et le conseil confirme que cela suffit. Un signalement envoyé par e-mail au point de contact est traité de la même façon.
• Le jeu accuse réception à l’écran dès l’envoi, puis notifie la décision au signalant à sa prochaine ouverture (carte refermable), puisqu’aucune adresse n’est gardée.
• Un profil ne peut signaler un même pseudo qu’une fois, et les signalements sont limités par profil et par adresse réseau (par exemple 10 par jour), contre les signalements abusifs.
• Un signalement ne masque rien tout seul : sinon, signaler servirait à faire taire un adversaire.

L’examen et la décision

• Un humain examine chaque signalement : sous 48 heures quand le motif est « contenu illicite », sous 7 jours sinon. Aucune décision n’est prise par un moyen automatique seul.
• Trois décisions possibles : ne rien faire ; masquer le pseudo (les autres joueurs voient « Joueur masqué » et un numéro neutre) ; pour un contenu manifestement illicite, masquer sans attendre la fin de l’examen.
• Le joueur dont le pseudo est masqué garde son compte et tout son jeu : la sanction ne touche que l’affichage public. Il choisit un autre pseudo, soumis aux mêmes règles. Un joueur dont trois pseudos ont été masqués voit son affichage public suspendu 30 jours ; jamais le jeu, la progression ni les achats.
• Un contenu qui laisse soupçonner une infraction pénale grave menaçant la vie ou la sécurité d’une personne est transmis aux autorités compétentes (art. 18). Le point de contact en tient la trace.

La motivation des décisions

Toute décision qui masque un pseudo ou suspend l’affichage public est motivée (art. 17), en français clair, par une carte à la prochaine ouverture du joueur, puis conservée dans les Réglages. Faute d’adresse, l’e-mail n’est pas un canal. La motivation dit :

• ce qui est décidé et depuis quand, et la durée d’une suspension ;
• les faits et la règle des CGU enfreinte ;
• si la décision est née d’un signalement (sans nommer le signalant) ou d’un contrôle du jeu ;
• que la décision a été prise par un humain, ou à l’aide du filtre à la saisie ;
• les recours : la réclamation par le point de contact, un règlement amiable, ou les juridictions.

La réclamation

• Un joueur peut contester une décision depuis la carte ou les Réglages (« Contester cette décision »), pendant 6 mois. Le message part au point de contact, avec la décision jointe.
• Une autre personne que l’auteur de la décision, ou le porteur du projet lui-même à défaut, la réexamine sous 14 jours, et répond dans les Réglages. Le résultat peut lever la décision.

Les points de contact

• Un seul point de contact électronique, contact@etymologique.fr, sert aux autorités (art. 11) et aux joueurs (art. 12). Il est tenu par un humain, jamais par un robot de réponse seul, et répond en français et en anglais.
• Il figure dans les mentions légales, dans les CGU, dans l’entrée « Nous contacter » des Réglages et sur la page de la vue compétitive. Les langues acceptées y sont indiquées.
• Accusé de réception sous 3 jours ouvrés. Les demandes des autorités sont traitées en priorité.
• La boîte contact@etymologique.fr est créée avant l’ouverture ; son contenu est conservé 12 mois au plus.

Les conditions d’utilisation

Les CGU (EtymoLogique/App#66) reprennent, en français, sous une rubrique « Pseudos et modération » :

Votre pseudo peut être vu des autres joueurs une fois que vous l’avez confirmé. Il ne doit contenir ni propos haineux, injurieux, discriminatoire, sexuel ou violent, ni nom d’une autre personne, ni coordonnées, ni usurpation d’ÉtymoLogique ou de son équipe, ni publicité. Vous pouvez signaler le pseudo d’un autre joueur depuis tout écran qui l’affiche. Une personne examine chaque signalement, sous 48 heures s’il s’agit d’un contenu illicite et sous 7 jours sinon. Un pseudo qui enfreint les règles est masqué ; trois pseudos masqués suspendent votre affichage public 30 jours. Votre compte, votre progression et vos achats ne sont jamais touchés. Nous vous expliquons chaque décision, à votre prochaine ouverture du jeu, et vous pouvez la contester pendant 6 mois depuis les Réglages ou en écrivant à contact@etymologique.fr. Les filtres automatiques refusent un pseudo au moment du choix ; ils ne masquent jamais un pseudo déjà confirmé.

Les données du signalement

• Un signalement, une décision et une réclamation sont des données personnelles : ils figurent sur la page des données collectées, avec leur finalité (la modération) et leur durée.
• On les garde 12 mois après la décision, la durée d’un recours utile, puis on les efface. Une suspension en cours prolonge la conservation jusqu’à sa fin.
• Ils vivent en base, jamais dans les journaux ni dans la télémétrie (ADR 0010) : un pseudo est un contenu libre.
• Le signalant n’est jamais nommé au joueur visé, sauf si la décision l’exige.

Options envisagées

Masquer dès le premier signalement

Écarté : un joueur pourrait faire disparaître le pseudo d’un rival avec quelques signalements. Seul le contenu manifestement illicite est masqué avant l’examen.

Refuser la modération humaine, tout filtrer par liste

Écarté : une liste ne comprend ni le contexte, ni les langues, ni les contournements, et une décision seulement automatique est plus difficile à motiver et à contester.

Pseudos tirés au hasard

Écarté, comme dans l’ADR 0070, à la demande du produit. Les règles ci-dessus traitent le risque.

Demander nom et adresse au signalant

Écarté : cela ferait entrer dans la base des adresses que l’ADR 0070 refuse de garder. L’article 16 demande de faciliter ces éléments, non de les exiger ; à confirmer par le conseil.

Notifier par e-mail

Écarté : le serveur ne conserve aucune adresse. La carte à la prochaine ouverture sert de canal. Un joueur qui n’ouvre plus le jeu n’est pas informé : c’est la limite assumée.

Bannir du jeu

Écarté : le jeu ne contient aucun échange libre, donc aucun danger qui justifierait de retirer à un joueur sa progression ou ses achats. La sanction se limite à l’affichage public.

Ne pas afficher de pseudo

Reporté, non écarté : sans vue compétitive, aucune obligation ne naît. Si les règles pèsent plus que la vue ne rapporte, il suffit de ne pas l’ouvrir.

Conséquences

Positives

• Les règles, le signalement, la motivation et les contacts sont écrits avant tout affichage public.
• Une sanction proportionnée : le joueur perd un affichage, jamais son jeu.
• Aucune adresse conservée pour la modération.
• Les CGU disposent d’un texte prêt à reprendre.

Négatives

• Un travail humain récurrent (48 heures, 7 jours) pour un porteur de projet seul : à revoir si les signalements montent.
• Un joueur qui n’ouvre plus le jeu ne reçoit pas la motivation avant d’y revenir.
• Une boîte de contact à tenir, en français et en anglais.
• Plusieurs écrans de plus pour la vue compétitive : signalement, carte de décision, contestation, « Nous contacter ».

Critères de réévaluation

• Plus de 20 signalements par semaine, ou un délai d’examen dépassé deux fois de suite : outiller la modération ou réduire l’exposition des pseudos.
• Le jeu cesse d’être une microentreprise ou une petite entreprise (12 mois de suite) : reprendre les obligations des plateformes, dont le rapport de transparence et le règlement extrajudiciaire.
• Le conseil refuse l’identification du signalant par son profil, la motivation par carte ou la suspension de 30 jours : revoir la section concernée.
• Ouverture de messages, de commentaires ou de tout autre contenu libre entre joueurs : nouvel ADR, car le risque change de nature.

• Statut : Proposé
• Portée : PWA (Réglages, navigation, modale), API (un webhook), page des données personnelles
• Remplace : l’idée d’une boutique en euros (abandonnée le 15 octobre 2026, ADR 0073 supprimé, ADR 0076 et 0077 jamais acceptés)
• Complète : ADR 0008 et ADR 0011 (aucun paiement dans le jeu), ADR 0070 (aucune adresse conservée en clair, empreinte HMAC), ADR 0010 (aucune adresse dans les journaux), ADR 0024 (aucun script tiers dans la PWA)

Contexte

La boutique de gouttes en euros demandait un prestataire de paiement, la TVA, le droit de rétractation, un reçu sur support durable et un compte obligatoire. Le projet y renonce. Il garde un moyen de financer le jeu : des dons libres sur Ko-fi, page d’un particulier.

Ko-fi n’est pas le marchand de référence : il ne collecte ni TVA ni impôt, et le don arrive directement sur le PayPal ou le Stripe de l’éditeur. Tant que rien n’est vendu, le jeu ne porte aucune des obligations de la vente à distance. Le statut fiscal de l’éditeur (don occasionnel ou activité habituelle) reste à faire confirmer par le SIP ou un comptable ; il ne change pas ce qui est construit ici.

Décision

Un don ne donne rien dans le jeu

• Aucune goutte, aucun sablier, aucune brique, aucun pli, aucune chance ni rareté ne s’obtient en donnant. Un abonné joue exactement comme les autres.
• Le seul effet d’un abonnement est de ne plus voir la modale de rappel. Le jeu ne le présente jamais comme une contrepartie.
• Seuls les dons libres et les abonnements de la page Ko-fi sont utilisés. Ni boutique Ko-fi, ni commande, ni « membership » à avantages : ils engageraient la TVA.

Où le soutien se présente

• Réglages : une carte « Soutenir ÉtymoLogique » tout en haut, avec le lien. Pour un abonné, le même emplacement remercie. Un bouton « Masquer pendant 30 jours » la cache, ici comme dans la Boutique ; elle revient d’elle-même après 30 jours réels (horodatage local, comme le reste du souvenir de la modale).
• Boutique : la même carte sous les échanges, même si rien ne s’y achète : le don n’est pas une offre de la boutique, il le dit (« ne change rien à votre partie »).
• Navigation : un lien « Soutenir » discret dans le rail des écrans larges. Sur mobile, la barre garde ses quatre onglets.
• Modale de rappel : jamais au début. Première apparition après 15 minutes de jeu sur l'appareil (onglet visible, joueur présent), puis au plus tous les 7 jours. Elle attend que la table soit calme (ni rituel de pli, ni fusion, ni fiche, ni relance « Sauvegardez votre progression »), que le joueur soit en ligne et qu'il soit resté une minute sans toucher l'écran ; une fois ouverte, elle reste jusqu'à sa fermeture. « Plus tard » comme « Offrir un café » la ferment. Le temps de jeu et les dates sont un souvenir local (IndexedDB), jamais envoyés au serveur.
• Le lien est un simple <a href> vers Ko-fi, ouvert hors de la PWA : aucun script ni cadre tiers, la CSP ne change pas.

Reconnaître un abonné

• Ko-fi appelle POST /soutien/kofi à chaque paiement (webhook, data=<JSON> en formulaire). L’API compare le verification_token au secret ETYMO_KOFI_TOKEN à temps constant ; sans lui, le point d’entrée répond 503.
• Seuls les paiements d’abonnement (is_subscription_payment) comptent. Un don ponctuel ne retire pas la modale.
• Chaque webhook valide envoie aussi un e-mail à contact@etymologique.fr (ETYMO_KOFI_NOTIFICATION) : type d’événement et montant, sans adresse, nom ni message du donateur. Un échec d’envoi ne fait pas échouer le webhook, pour que Ko-fi ne le rejoue pas.
• L’adresse de l’événement est normalisée comme pour la connexion, puis réduite à son empreinte HMAC (la clé de l’ADR 0070). La table soutien ne garde que cette empreinte et la date du dernier paiement : ni nom, ni montant, ni message.
• Un abonnement est actif 45 jours après son dernier paiement. La ligne est supprimée avec le compte, et les lignes de plus de 90 jours sont purgées à chaque webhook.
• GET /etat renvoie compte.soutien (vrai ou faux). Un invité sans compte n’est jamais reconnu : il voit la modale.
• Limite connue : la détection ne marche que si l’adresse de l’abonnement Ko-fi est celle du compte.

Données personnelles

• La page des données personnelles et les CGU le disent : le lien quitte le jeu, Ko-fi et PayPal ou Stripe sont responsables de leur traitement, le jeu ne leur envoie rien, et il ne reçoit l’adresse d’un abonné que le temps de calculer son empreinte.
• Le corps du webhook n’est jamais journalisé. Le contrat accepte les champs inconnus de ce seul point d’entrée (Ko-fi en ajoute), au contraire du reste de l’API.

Options envisagées

• Rien : seulement un lien dans les Réglages. Plus simple, mais aucun rappel : peu de dons.
• Modale sans reconnaître les abonnés. Sans donnée de plus, mais un abonné serait relancé. Écartée.
• Bouton « J’ai déjà soutenu » local. Sans serveur ni donnée, mais déclaratif. Possible plus tard en complément pour qui s’abonne avec une autre adresse.
• Contrepartie dans le jeu (gouttes, cosmétique). Recrée une vente : TVA, rétractation, monnaie de jeu. Écartée.

Conséquences

• (+) Aucune vente : « gratuit, sans publicité, aucun avantage payant » reste vrai.
• (+) Un seul point d’entrée serveur, une table de deux colonnes, un secret.
• (−) Le secret du webhook se saisit à la main dans Ko-fi puis dans Secret Manager : il n’est pas généré par l’infrastructure.
• (−) Un abonné dont l’adresse Ko-fi diffère de celle du compte voit encore la modale.
• (−) Une empreinte d’adresse reste une donnée pseudonyme : la page des données personnelles l’explique.

Critères de réévaluation

• Plus d’un tiers des abonnés relancés malgré leur abonnement : ajouter « J’ai déjà soutenu ».
• Dons récurrents réguliers : faire confirmer le statut (micro-entreprise, TVA) avant d’aller plus loin.
• Toute proposition de contrepartie dans le jeu : nouvel ADR, avec la TVA et la monnaie de jeu.