Structurer les questions, réponses et scores d’un jeu

Séparer identité, contenu et état

Une question reçoit un identifiant stable qui ne change pas quand une faute est corrigée. Le contenu regroupe consigne, réponses, explication, source et langue. L’état de publication indique brouillon, relu, publié ou retiré. Le score et les réponses d’une session vivent ailleurs afin qu’une mise à jour éditoriale ne réécrive pas l’historique des joueurs.

• question_id stable et non signifiant.
• version du contenu et date de révision.
• session_id distinct du participant.
• statut de publication indépendant du texte.

Modèle minimal d’une question

Le modèle utile contient la consigne, le type de réponse, la réponse canonique, les équivalents acceptés, l’explication, la difficulté, les thèmes, la source et les besoins d’accessibilité. Un champ facultatif n’est ajouté que si son usage est défini. La durée n’est pas enfouie dans la consigne : elle appartient à la manche ou au format.

• Prompt et langue.
• Type : choix unique, multiple, libre, ordre ou estimation.
• Réponse canonique et validation.
• Source, date et relecteur.
• Alternative textuelle pour média lorsque pertinente.

JSON pour l’échange structuré

Le RFC 8259 définit JSON comme un format d’échange de données. Il convient aux objets imbriqués, listes de choix et métadonnées, à condition de publier un schéma et une version. N’encodez pas une date ou un nombre dans une phrase lorsque le consommateur doit les comparer. Refusez les champs inconnus si le contrat est fermé ou conservez-les explicitement si l’extension est prévue.

• schemaVersion obligatoire.
• UTF-8 et dates ISO 8601 explicites.
• Types numériques pour scores et durées.
• Validation avant import et message d’erreur localisable.

CSV pour l’édition tabulaire

Le CSV est pratique pour relire et corriger un lot dans un tableur, mais les séparateurs, guillemets, retours à la ligne et encodages doivent être définis. Le RFC 4180 décrit un format courant sans couvrir tous les dialectes réels. Publiez un exemple, l’ordre des colonnes, l’encodage et la règle des cellules multiples.

• En-tête obligatoire et noms de colonnes stables.
• UTF-8 déclaré.
• Guillemets et retours à la ligne testés.
• Aucune formule ou contenu actif importé aveuglément.
• Rapport de lignes rejetées sans perte du fichier source.

Versionner sans casser les anciennes parties

Une correction éditoriale crée une nouvelle version de la question. Une session conserve la version effectivement jouée afin d’expliquer un score. Une rupture de schéma reçoit un nouveau numéro majeur et un chemin de migration ; l’import ancien reste refusé proprement ou converti de façon testée. L’ajout d’un thème ne doit pas changer l’identité de la question.

• Version du schéma et version du contenu distinctes.
• Journal court du motif de correction.
• Migration idempotente et réexécutable.
• Rollback vers le dernier catalogue validé.

Calculer et expliquer le score

Le barème transforme une action en points. Stockez la règle ou son identifiant avec la session : bonne réponse, vitesse, pénalité, bonus et égalité. Le résultat doit pouvoir être recalculé à partir d’événements validés sans dépendre de l’ordre d’affichage. Une correction ajoute un événement d’ajustement plutôt que de modifier silencieusement le total.

• Événement, acteur, manche et horodatage borné.
• Points avant et après ajustement.
• Motif d’arbitrage.
• Règle d’égalité versionnée.

Préserver accessibilité et traduction

Le contenu textuel, les libellés d’interface et les alternatives de média sont séparés. Une traduction possède son propre statut de relecture et ne devient pas indexable parce que la version française l’est. Les réponses acceptées sont localisées ; un identifiant technique ne remplace jamais un libellé visible.

• Langue déclarée par contenu.
• Traduction relue, pas seulement présente.
• Alternative de média et consigne synchronisées.
• Ordre de lecture et libellés conservés à l’export.

Minimiser les données de session

Le catalogue de questions n’a pas besoin de connaître les joueurs. La session peut utiliser un pseudonyme et un identifiant éphémère. Les réponses individuelles et journaux suivent une durée adaptée au jeu et au diagnostic annoncé. Les exports éditoriaux ne doivent jamais embarquer par erreur les participants ou leurs historiques.

• Catalogues publics séparés des sessions.
• Aucune donnée personnelle dans les identifiants ou URLs.
• Exports filtrés par finalité.
• Suppression testée et conservation documentée.

Pipeline d’import sûr

Un import passe par validation du schéma, contrôle des identifiants, détection des doublons, vérification des sources, quarantaine des lignes invalides et revue humaine. La publication est atomique : tout le catalogue validé devient courant ensemble, avec un manifeste et une empreinte. Une information externe modifiée déclenche une file de revue, pas une republication automatique non contrôlée.

• Dry-run avant écriture.
• Rapport borné des erreurs.
• Déduplication par identifiant et version.
• Manifeste signé ou empreinte vérifiable.
• Activation et rollback atomiques.

Sources

Source primaire : catalogue public TABUZZZ, règles et états de disponibilité affichés dans le produit. Les critères de choix sont des repères éditoriaux et ne constituent ni un classement commercial ni une garantie de résultat.

• IETF / RFC Editor — RFC 8259 — The JavaScript Object Notation (JSON) Data Interchange Format
• IETF / RFC Editor — RFC 4180 — Common Format and MIME Type for CSV Files
• CNIL — Minimiser les données collectées
• W3C Web Accessibility Initiative — Web Content Accessibility Guidelines (WCAG) 2.2

Révision éditoriale : 9 septembre 2026. Éditeur responsable : DOHM. Toute correction factuelle peut être signalée depuis la page de contact.