Catalogue des données Horizon

Les trois chapitres de la Partie III ont défini la manière dont Horizon représente une personne, relie ses comptes Twitch et Discord, et réunit plusieurs identités lorsqu'elles appartiennent à la même personne. Ces mécanismes reposent sur des informations dont la signification doit rester commune à l'ensemble de la Plateforme.

Le présent chapitre établit le catalogue fonctionnel des données Horizon. Il identifie les principales familles de données nécessaires au Noyau, aux interfaces, aux systèmes communautaires et à P.O.U.B.E.L.L.E. Il précise leur rôle général, leur rattachement fonctionnel et les distinctions qui doivent rester visibles avant toute conception technique.

Ce catalogue demeure volontairement synthétique. Il ne constitue ni un schéma de base de données ni la liste définitive de chaque champ technique. La future Annexe F — Catalogue des données accueillera le référentiel exhaustif et sera enrichie au fil des chapitres spécialisés. Le chapitre 14 définit ensuite le rattachement, les autorités fonctionnelles, les règles de sélection, la synchronisation et la résolution des conflits.

Fonctionnement cible — Principes validés

Horizon ne conserve que les données nécessaires à ses fonctions et à leur continuité. Une donnée doit posséder une finalité identifiable, être rattachée au bon sujet et rester distincte de ses éventuelles copies, observations, intentions ou représentations historiques.

L'état actuel est conservé directement. Les événements expliquent les évolutions utiles, mais Horizon ne dépend pas d'un rejeu intégral du passé pour connaître la situation présente.

Les données principales sont décrites dans ce chapitre. Les formules, seuils, catalogues métier, formats techniques, classifications détaillées et durées de conservation restent définis par leurs chapitres et annexes maîtres.

Synthèse normative

• Une donnée Horizon doit répondre à une finalité fonctionnelle identifiable.
• Une donnée doit être rattachée au sujet, au compte, au traitement, au système ou au service qu'elle décrit réellement.
• Un pseudonyme externe ne doit jamais remplacer l'identifiant permanent fourni par sa plateforme.
• L'identifiant interne permanent, l'identifiant public Horizon unique et le nom d'affichage public doivent rester distingués.
• Une session du Poste de commande ne doit pas être modélisée comme un troisième compte externe.
• Les valeurs actuelles nécessaires au fonctionnement doivent être conservées directement.
• Une information externe doit conserver sa provenance et son moment d'observation.
• Une valeur calculée doit rester distinguée des données utilisées pour la produire.
• Une donnée doit être décrite selon des axes indépendants de production, de rôle fonctionnel et de cycle de vie.
• Les instants d'occurrence, de réception et d'observation doivent rester distingués lorsqu'ils sont disponibles.
• Une donnée temporaire doit disparaître lorsque sa finalité ou sa validité est terminée, sauf résultat minimal encore nécessaire.
• Une donnée privée ne doit pas devenir publique uniquement parce qu'elle est utilisée par plusieurs composantes d'Horizon.
• La visibilité de deux données liées doit pouvoir rester différente.
• Les valeurs numériques de confiance relationnelle et de proximité utilisées par P.O.U.B.E.L.L.E. doivent rester cachées.
• Toute modification de la confiance relationnelle ou de la proximité doit produire une trace minimale explicative.
• Les paramètres relationnels ne doivent jamais décider seuls d'une permission, d'une sanction ou d'une action critique.
• Le contenu brut des conversations ne doit pas être conservé indéfiniment par défaut.
• Les données transmises ou produites autour d'un traitement LLM doivent rester limitées au contexte utile, à l'action et au résultat nécessaires.
• Les données d'activité Twitch, Discord et Web doivent rester distinguées selon leur nature.
• Une correction doit conserver les valeurs avant et après ainsi que son origine, sans réécriture silencieuse.
• Le chapitre 13 doit rester lisible. Le détail exhaustif relève de l'Annexe F et des chapitres spécialisés.

Rôle du catalogue fonctionnel

Le catalogue fonctionnel répond à la question « Quelles informations Horizon doit-il connaître pour remplir ses fonctions ? ». Il fournit un vocabulaire commun avant que ces informations soient réparties entre des bases de données, des caches, des files de traitement, des journaux ou des services externes.

Il poursuit plusieurs objectifs :

• Donner une signification commune aux données utilisées par plusieurs systèmes.
• Éviter qu'une même notion reçoive plusieurs définitions incompatibles.
• Identifier le sujet auquel une donnée se rattache réellement.
• Préparer les décisions d'autorité, de priorité et de cohérence du chapitre 14.
• Préparer la classification, les permissions et les règles de conservation.
• Fournir une base fonctionnelle au futur modèle de données technique.
• Orienter l'alimentation progressive de l'Annexe F.

Le catalogue ne décide pas à lui seul qui peut lire, modifier ou divulguer une donnée. Ces capacités seront définies par le modèle de permissions, la classification des données et les règles de vie privée et de conservation.

Définition fonctionnelle d'une donnée Horizon

Une donnée Horizon est une information qu'Horizon doit connaître, produire, conserver temporairement ou référencer afin de comprendre une situation, appliquer une règle, conduire un traitement, personnaliser une interaction ou expliquer un résultat.

Une donnée n'est pas nécessairement détenue exclusivement par Horizon. Elle peut être :

• Établie directement par Horizon.
• Observée auprès d'un service externe.
• Calculée à partir d'autres valeurs.
• Fournie par une personne.
• Produite pendant un traitement.
• Conservée comme référence historique ou trace minimale.

La présence d'une donnée dans Horizon ne lui confère donc pas automatiquement l'autorité sur cette information. Cette distinction sera définie donnée par donnée au chapitre 14.

Axes de classification des données

Chaque donnée est décrite selon plusieurs axes indépendants : son mode de production, son rôle fonctionnel et son cycle de vie. Ces axes sont cumulables et ne constituent pas des catégories concurrentes.

Axe	Valeurs fonctionnelles indicatives	Question traitée
Mode de production	Interne, déclarée, observée externe, calculée ou dérivée.	Comment la valeur est-elle obtenue ?
Rôle fonctionnel	Identité, compte, liaison, profil, relation, événement, procédure, état ou paramètre.	À quoi la donnée se rattache-t-elle et que représente-t-elle ?
Cycle de vie	Actuelle, temporaire, historique, archivée, conservée comme trace minimale ou anonymisée.	Comment la donnée évolue-t-elle et sous quelle forme reste-t-elle conservée ?

Une information observée depuis un service externe peut ainsi être une donnée de relation, rester actuelle pendant une période déterminée, puis être conservée sous forme historique ou comme trace minimale. De même, un état opérationnel peut être calculé et temporaire sans perdre son rôle d'état.

Le terme famille reste un regroupement documentaire utilisé pour faciliter la lecture. Il ne remplace aucun des trois axes et ne doit pas devenir une propriété technique unique dans le futur catalogue détaillé.

Rattachement des données

Une donnée doit être rattachée à l'objet fonctionnel qu'elle décrit. Ce rattachement évite notamment de confondre une personne, son Identité Horizon, ses comptes externes et ses différentes interactions.

Sujet fonctionnel	Données typiques
Identité Horizon	État d'existence, revendication, statut communautaire, profil, progression et relation avec P.O.U.B.E.L.L.E.
Compte externe	Identifiant de plateforme, pseudonyme, appartenance, rôles natifs et autorisation externe.
Liaison	Relation vérifiée entre une identité et un compte, état, date et visibilité.
Procédure	Preuves, confirmations, choix, conflit, expiration et résultat.
Événement	Origine, fonction, contexte, causalité, traitement et conséquences.
Système fonctionnel	Paramètres, état actuel, participants, résultat et données métier.
Service externe	Disponibilité observée, état communiqué et résultat d'exécution.
Plateforme Horizon	Configuration, santé, alertes, traitements et corrections.

Une donnée peut être consultée depuis plusieurs interfaces tout en restant rattachée à un seul sujet. Le niveau d'une personne, par exemple, appartient à son Identité Horizon même lorsqu'il est affiché sur Twitch, Discord et le Poste de commande.

Données de l'Identité Horizon

L'Identité Horizon constitue le point de rattachement central des données communes à une même personne. Sa définition, ses états et son cycle sont établis au chapitre 10.

Les principales données d'identité comprennent :

• L'Identifiant Horizon permanent.
• L'Identifiant public Horizon unique.
• Le Type d'identité, humaine ou spéciale.
• L'État d'existence, actif, archivé ou anonymisé.
• L'État de revendication, non revendiqué ou revendiqué.
• La Date de création.
• L'Événement ou l'interaction ayant justifié la création.
• La Méthode et la date de revendication.
• Le Nom d'affichage Horizon.
• La Date de dernière modification du profil.
• Le Statut communautaire actuel.
• Les Références nécessaires après une fusion.

L'identifiant interne ne doit jamais être réattribué. Il ne dépend ni d'un pseudonyme Twitch ou Discord ni de l'existence actuelle d'une liaison externe.

P.O.U.B.E.L.L.E. constitue une exception explicitement configurée. Elle possède une identité spéciale destinée à relier ses présences officielles et à porter ses permissions propres. Cette identité ne suit pas le cycle communautaire des personnes humaines.

Les autres bots et comptes automatisés ne possèdent pas d'Identité Horizon. Horizon peut connaître les références techniques nécessaires à leur filtrage ou à leur fonctionnement sans les représenter comme des membres de l'équipage.

Comptes externes

Un compte externe représente un compte détenu par un service distinct d'Horizon. Le catalogue fonctionnel reconnaît actuellement Twitch et Discord comme plateformes principales d'identification.

Donnée	Rôle fonctionnel
Plateforme	Identifier le service auquel appartient le compte.
Identifiant externe permanent	Reconnaître le compte indépendamment de ses changements de pseudonyme.
Pseudonyme actuel	Afficher le nom actuellement utilisé sur la plateforme.
Pseudonyme précédent	Conserver au maximum le nom immédiatement antérieur pour faciliter la continuité de lecture.
Nom d'affichage externe	Représenter le nom communiqué par la plateforme lorsqu'il diffère du pseudonyme.
Première observation	Situer le moment où Horizon a rencontré le compte pour la première fois.
Dernière observation	Situer la fraîcheur de la représentation connue.
État natif du compte	Représenter l'existence ou le statut communiqué par la plateforme lorsqu'elle expose cette information.
Observabilité ou accessibilité	Indiquer, à une date déterminée, si Horizon peut actuellement consulter ou recevoir les informations nécessaires.
Utilisabilité locale	Indiquer si Horizon peut effectivement utiliser le compte pour une fonction donnée selon l'autorisation, les permissions et l'état technique.
Autorisation externe	Représenter séparément l'autorisation native, son état observé, les moyens techniques locaux et le droit fonctionnel d'usage.
Responsabilités externes	Représenter les rôles natifs pertinents observés sur la plateforme.
Restrictions externes	Représenter les exclusions, sanctions ou limitations nécessaires aux fonctions d'Horizon.

Horizon ne conserve pas un historique complet des pseudonymes. Lorsqu'un nouveau pseudonyme est observé, le pseudonyme actuel peut devenir le pseudonyme précédent et l'ancienne valeur précédente peut être supprimée. Cette donnée ne sert jamais de preuve d'identité.

L'état natif, l'observabilité et l'utilisabilité locale ne sont pas interchangeables. Un compte peut encore exister chez son fournisseur tout en étant momentanément inobservable par Horizon ; il peut également être observable sans être utilisable pour une action faute d'autorisation ou de permission suffisante.

Le Poste de commande ne crée aucun compte externe supplémentaire. Il ouvre une session Horizon après authentification par Twitch ou Discord.

Liaisons et procédures d'identité

Une liaison est une donnée de relation entre une Identité Horizon et un compte externe. Elle reste distincte du compte, de l'identité et de l'autorisation OAuth. Son cycle est défini au chapitre 11.

Les données principales d'une liaison comprennent :

• L'Identité Horizon concernée.
• Le Compte externe concerné.
• L'État de la liaison.
• La Date de création.
• La Méthode et la date de vérification.
• La Date de dernière vérification utile.
• La Visibilité publique ou privée du compte lié.
• L'Éventuelle demande de retrait.
• La Date et le motif de retrait.
• La Référence d'un compte remplacé lorsque cette information reste nécessaire.

Les états fonctionnels reconnus sont : En attente de vérification, Active, Indisponible, En conflit, En attente de retrait et Retirée.

Une identité ne peut posséder qu'une seule liaison Twitch active et une seule liaison Discord active. La relation entre les deux comptes est privée par défaut, même lorsque certaines informations de profil sont rendues publiques.

Les procédures de revendication, liaison, déliaison, remplacement et fusion utilisent également des données temporaires ou de décision :

• L'Identifiant de la procédure.
• Le Type de procédure.
• L'Origine et l'auteur de la demande.
• Les Identités et comptes concernés.
• Les Preuves de contrôle obtenues.
• La Date d'expiration des preuves.
• La Présentation privée soumise à la personne.
• Les Confirmations reçues.
• Les Choix effectués.
• Les Conflits détectés.
• La Décision et le résultat final.
• Le Compte rendu adressé à la personne.
• L'Événement Horizon associé.

Pour une fusion, le catalogue reconnaît en complément l'identité conservée, l'identité absorbée, les stratégies appliquées, la date effective, la fin du délai d'archivage de trente jours et la trace minimale définie au chapitre 12.

Profil, préférences et visibilité

Le profil rassemble les informations de présentation et les choix personnels rattachés à l'Identité Horizon. Il ne remplace ni les comptes externes ni leurs pseudonymes.

Donnée de profil	Comportement général
Identifiant public Horizon	Identifiant unique et nativement public permettant de distinguer les homonymes sans exposer l'identifiant interne permanent.
Nom d'affichage Horizon	Nom modifiable et nativement public ; il reprend initialement le pseudonyme du compte d'origine, puis la personne est invitée à le choisir après revendication.
Description	Présentation personnelle facultative, privée par défaut et publiable.
Pronoms	Information facultative, privée par défaut et publiable.
Langue	Préférence privée utilisée d'abord par le Poste de commande, puis potentiellement par les autres interfaces.
Préférence de visibilité du compte Twitch	Choix indépendant, privé par défaut.
Préférence de visibilité du compte Discord	Choix indépendant, privé par défaut.
Préférences de notification	Canaux et catégories de notifications acceptées.
Préférence de visibilité du grade	Choix permettant de demander la publication ou le masquage du grade.
Préférence de visibilité de l'XP	Choix permettant de demander la publication ou le masquage de l'XP.
Préférences de visibilité des statistiques	Choix défini statistique par statistique, complété par un réglage global permettant de tout masquer.
Préférence de visibilité des succès	Choix par succès, complété par un réglage global permettant de tous les masquer.

Les notifications personnelles utilisent en priorité le Poste de commande et Discord. Un canal privé Twitch peut être utilisé exceptionnellement lorsqu'il est disponible, adapté à la situation et autorisé. Un message public Twitch ne doit jamais divulguer une information privée.

Le nom d'affichage et l'identifiant public Horizon sont publics pour tous. La publication d'une autre donnée ne publie pas automatiquement les autres informations du profil. Une personne peut, par exemple, publier son grade et son compte Twitch tout en conservant son XP, ses statistiques et son compte Discord privés.

Une préférence de visibilité exprime le choix de présentation de la personne dans les limites autorisées. Elle n'accorde aucun droit de lecture, d'utilisation, de modification ou de divulgation. Horizon détermine séparément la limite maximale autorisée et la visibilité effective selon le modèle de permissions et la classification des données.

Chaque statistique possède une visibilité maximale définie par sa nature et sa sensibilité. Certaines mesures fines, notamment les habitudes temporelles, les heures de présence, les délais d'arrivée ou les variables internes du profil, peuvent être limitées à un usage privé même lorsque la personne demande une publication plus large.

Statut communautaire, responsabilités et distinctions

Le statut communautaire décrit la relation actuelle d'une personne avec l'équipage. Il demeure distinct de l'existence de l'identité, de sa revendication et de ses comptes liés.

Les données principales comprennent :

• Le Statut actuel, Visiteur, Membre d'équipage ou Exclu de l'équipage.
• La Date d'entrée dans le statut.
• Le Motif et l'événement de transition.
• Les Conditions d'appartenance actuellement remplies.
• La Date d'un départ volontaire éventuel.
• La Décision d'exclusion, son origine et ses restrictions.
• La Demande de débannissement et son état.
• La Date et la décision d'un éventuel retour.

Les conditions observables d'appartenance peuvent notamment inclure l'état de follower Twitch accompagné d'une interaction, la présence sur le serveur Discord accompagnée d'au moins un message, ou l'existence d'un compte lié et revendiqué.

Les responsabilités et distinctions sont conservées séparément :

• Les Responsabilités Twitch.
• Les Responsabilités Discord.
• Les Responsabilités propres à Horizon.
• Le Périmètre de chaque responsabilité.
• La Date et l'origine de l'attribution.
• Les Permissions et restrictions actuellement applicables.
• La Distinction de Membre honorifique.
• La Date d'attribution et l'éventuelle échéance de retrait différé de sept jours.

Le catalogue ne contient pas encore la matrice complète des permissions. Celle-ci relèvera du chapitre 32 et de l'Annexe H.

Progression, succès et activité

Les données de progression sont rattachées à l'Identité Horizon afin de réunir l'activité reconnue sur les différentes interfaces.

Les données principales comprennent :

• Le Total d'XP actuel.
• Le Niveau actuel.
• Le Grade actuel.
• La Progression calculée vers le niveau suivant.
• La Date de dernière évolution.
• Les Succès obtenus.
• La Date d'obtention d'un succès.
• L'Éventuelle progression d'un succès non terminé.
• Les Références nécessaires à l'historique des gains, niveaux, grades et corrections.

Le chapitre 13 ne fixe ni la formule de l'XP, ni les seuils de niveaux, ni la liste complète des grades, ni les conditions détaillées de promotion. Ces règles relèvent du chapitre 26.

Présence et activité par interface

Les activités Twitch, Discord et Web ne possèdent pas la même nature et ne doivent pas être additionnées dans un score unique sans règle métier explicite.

Interface	Mesure principale	Agrégations retenues
Twitch	Temps de présence reconnu uniquement à partir de signaux individuels qu'Horizon peut réellement observer ou établir.	Semaine, mois, année et total.
Discord	Nombre de messages admissibles créés par la personne, hors commandes adressées aux bots et messages automatisés.	Semaine, mois, année et total.
Poste de commande	Temps d'activité authentifiée reconnue, hors périodes de session inactive.	Semaine, mois, année et total.

Les périodes sont calendaires et suivent le fuseau fonctionnel Europe/Paris, changements d'heure compris. La semaine s'étend du lundi au dimanche, le mois correspond au mois civil et l'année à l'année civile. Les instants échangés restent représentés sous une forme non ambiguë afin de permettre leur comparaison et leur conversion sans perte de contexte.

La présence Twitch ne doit pas être présentée comme continue lorsque la source ne permet pas de l'établir. Horizon distingue une participation prouvée par un événement, une présence technique observée au moyen d'un signal documenté et une période non observable. Il comptabilise uniquement les périodes reconnues ; les périodes non observables restent inconnues et ne sont transformées ni en présence ni en absence.

Un message Discord admissible est compté une seule fois lors de sa création. Une modification du message ne produit pas une nouvelle occurrence. Une suppression ne crée aucun message supplémentaire ; une éventuelle correction d'agrégat suit les règles du chapitre consacré aux statistiques, notamment lorsque le message est invalidé pour automatisation, spam ou modération.

L'activité du Poste de commande exige une session authentifiée, une page effectivement visible et un signal d'activité valide. Elle cesse d'être comptabilisée après le seuil d'inactivité prévu ou lorsque la session ne permet plus d'établir l'activité. Le seuil exact, le traitement des coupures et les mécanismes techniques de mesure seront définis dans les chapitres spécialisés.

Le catalogue reconnaît également :

• La Première interaction globale connue.
• La Dernière interaction globale connue.
• La Première et la dernière interaction Twitch.
• La Première et la dernière interaction Discord.
• La Première et la dernière interaction sur le Poste de commande.
• Le Délai entre l'heure officielle de début d'un direct et la première présence reconnue.
• Les Moyennes de délai d'arrivée sur la semaine, le mois, l'année et le total.

Un direct pendant lequel la personne n'est jamais observée est exclu du calcul de la moyenne d'arrivée. Il ne peut être comptabilisé comme une absence que si Horizon disposait, pour cette personne et ce direct, d'une couverture individuelle suffisante permettant d'établir cette absence. Les modalités précises de reconnaissance d'une présence, de correction des mesures, de calcul des agrégats et d'utilisation de ces informations seront définies par les chapitres consacrés à la progression, aux statistiques et aux interfaces.

Relation avec P.O.U.B.E.L.L.E.

Chaque Identité Horizon humaine peut porter deux paramètres décrivant sa relation actuelle avec P.O.U.B.E.L.L.E. Ces valeurs sont communes à Twitch, Discord et au Poste de commande.

Paramètre relationnel	Plage	Valeur initiale	Interprétation
Confiance relationnelle	−100 à +100	0	Une valeur positive exprime la confiance ; une valeur négative exprime la méfiance.
Proximité relationnelle	−100 à +100	0	Une valeur positive exprime une relation proche ; une valeur négative exprime une relation distante.

Ces paramètres peuvent augmenter ou diminuer au fil du temps ou en conséquence d'actions prédéfinies. Une sanction Twitch ou Discord peut, par exemple, réduire la confiance. Une longue absence peut réduire la proximité.

P.O.U.B.E.L.L.E. peut demander une modification dans un cadre strict et limité. Un Super administrateur peut également modifier les valeurs dans les conditions autorisées. Dans tous les cas, la modification passe par le Noyau et ses contrôles : le LLM ne dispose d'aucun accès direct à la donnée.

Horizon conserve directement la valeur actuelle de chaque paramètre, sans maintenir un historique relationnel détaillé. Toute modification produit néanmoins une trace minimale reliée à sa cause. Cette trace conserve l'ancienne valeur, la nouvelle valeur, la règle ou décision appliquée, l'événement associé, la date ainsi que l'acteur ou le traitement responsable.

La confiance relationnelle et la proximité peuvent contribuer au contexte autorisé d'une interaction, mais elles ne peuvent jamais, à elles seules, attribuer ou retirer une permission, déclencher une sanction ou produire une action critique. Lorsqu'un usage de ces indicateurs affecte une personne, il doit rester explicable, corrigeable et soumis au contrôle humain prévu.

Les valeurs numériques restent cachées. Une indication qualitative dérivée peut être présentée lorsque cette fonction sera définie, sans révéler nécessairement la valeur exacte.

La confiance relationnelle ne doit pas être confondue avec la confiance d'une information définie au chapitre 9. La première décrit la relation de P.O.U.B.E.L.L.E. avec une identité, la seconde qualifie le degré de certitude d'une donnée ou d'un résultat.

État global et événements

L'état global Horizon rassemble les données actuelles nécessaires à la compréhension et à la conduite des traitements. Il peut contenir des données internes, des observations externes, des valeurs calculées, des états temporaires et des conflits connus.

Une donnée de l'état global peut notamment conserver :

• Sa Valeur actuelle.
• Sa Provenance.
• Son Moment d'observation.
• Sa Disponibilité, connue ou inconnue.
• Sa Fraîcheur, actuelle ou obsolète.
• Sa Confiance, confirmée ou incertaine.
• Sa Cohérence, cohérente ou en conflit.
• Sa Transition, stable, en attente ou en cours de vérification.

Un événement Horizon peut notamment conserver :

• Son Identifiant fonctionnel.
• Son Origine.
• Sa Fonction.
• Son Auteur ou acteur connu.
• L'Identité, le système ou le service concerné.
• La Date de l'occurrence et la date de réception lorsqu'elles diffèrent.
• Le Contexte nécessaire au traitement.
• L'Événement causal éventuel.
• Le Traitement associé.
• Les Conséquences demandées.
• Les Résultats obtenus.
• Les Nouveaux événements produits.
• Les Anomalies, corrections ou conflits rencontrés.

Le format technique et le catalogue exhaustif des événements relèvent de l'Annexe G et des futurs contrats d'intégration.

Corrections, confirmations et notifications

Les corrections et décisions produisent leurs propres données fonctionnelles afin d'empêcher toute modification silencieuse.

Une correction peut notamment conserver :

• La Donnée concernée.
• La Valeur avant correction.
• La Valeur après correction.
• L'Origine de l'anomalie.
• La Règle ayant autorisé la correction.
• Le Caractère automatique ou manuel.
• L'Auteur d'une intervention humaine.
• La Date et le résultat de la correction.
• L'Intervention manuelle restant nécessaire.

Une confirmation peut notamment conserver la décision présentée, la personne habilitée, le contexte, le résultat et la date d'expiration.

Une notification peut notamment conserver le destinataire, le canal, la catégorie, le contenu fonctionnel minimal, l'état de remise et le traitement auquel elle se rattache. Pour les corrections, une notification consolidée peut indiquer le nombre de corrections réalisées et le nombre d'actions restant à effectuer manuellement.

Données temporaires

Certaines données n'existent que pour permettre une procédure, une interaction ou une vérification limitée dans le temps.

Elles peuvent notamment comprendre :

• Les Codes temporaires de revendication ou de liaison.
• Les Preuves de contrôle dont la validité est limitée.
• Les Confirmations en attente.
• Les Propositions de liaison ou de fusion.
• Les Choix préparatoires.
• Les États intermédiaires d'une action critique.
• Le Contexte conversationnel récent nécessaire à une interaction.
• Les Données reçues pendant un traitement mais non encore appliquées.

À l'expiration, les contenus temporaires doivent être supprimés automatiquement. Horizon peut conserver uniquement le résultat fonctionnel nécessaire, par exemple qu'une demande a expiré, été refusée, annulée ou terminée.

La suppression d'une donnée temporaire ne doit pas effacer une valeur actuelle légitime ni rendre incompréhensible une opération déjà exécutée.

Données liées au LLM et aux outils

Le recours à un modèle LLM ne justifie pas la conservation systématique de toutes les entrées et sorties produites pendant une interaction. Horizon doit limiter les données fonctionnelles retenues à ce qui reste nécessaire.

Trois catégories principales sont reconnues :

• Le Contexte utile sélectionné pour le traitement.
• L'Action éventuellement proposée ou demandée.
• Le Résultat fonctionnel obtenu.

Le prompt complet, la réponse brute du modèle et l'intégralité des conversations ne sont pas conservés systématiquement. Un message Twitch ou Discord peut être utilisé temporairement pour comprendre et traiter une interaction, puis disparaître lorsque cette finalité est terminée. Un souvenir sélectionné pour P.O.U.B.E.L.L.E. constitue une donnée distincte, régie par le chapitre 16.

Une action proposée par le LLM ou par P.O.U.B.E.L.L.E. reste une proposition jusqu'à son contrôle par Horizon. Les permissions, confirmations et résultats de l'outil demeurent des données distinctes.

Données des interfaces et systèmes fonctionnels

Le catalogue reconnaît les principales familles nécessaires aux interfaces et systèmes futurs sans en reproduire les référentiels détaillés.

Domaine	Données fonctionnelles principales	Référence future
Twitch	Interactions, follows, raids, récompenses, rôles, sanctions, présence et résultats d'actions.	Chapitre 22
Discord	Appartenance, messages admissibles, rôles, sanctions, notifications et résultats d'actions.	Chapitre 23
Poste de commande	Sessions, activité réelle, préférences, consultations et demandes autorisées.	Chapitre 24
Communications multiplateformes	Message d'origine, adaptations, destinations, remise et prévention des doublons.	Chapitre 25
Progression	Gains, corrections, niveaux, grades, promotions, succès et historique.	Chapitre 26
Protocole de Raid	Raid reçu, état du protocole, scénario, sélection, étapes, résultat et clôture.	Chapitre 27
Soundboard	Récompense, son demandé, variante, substitution, véto, remboursement et exécution.	Chapitre 28
Modération	Personne concernée, plateforme, action, motif, durée, décision, confirmation et recours.	Chapitre 29
Autres modules	Missions, défis, récompenses, succès, participants, états et résultats.	Chapitre 30

Les événements, commandes, protocoles, récompenses et paramètres détaillés sont réservés à leurs chapitres et annexes maîtres.

Données administratives et opérationnelles

Horizon doit également connaître certaines informations sur son propre fonctionnement. Le chapitre en recense les familles sans définir leur structure technique.

Elles comprennent notamment :

• Les Paramètres généraux de la Plateforme.
• Les Paramètres propres aux modules.
• Les Fonctions activées ou désactivées.
• La Configuration fonctionnelle des extensions.
• La Disponibilité observée des services.
• Les Traitements, tâches et protocoles actifs.
• Les Erreurs, incidents et anomalies connus.
• Les Alertes et notifications administratives.
• Les Corrections automatiques ou manuelles.
• Les Sessions et autorisations externes.
• Les Demandes d'accès, d'export, de correction ou de suppression.
• Les Entrées du registre de restriction conservées séparément des Identités Horizon supprimées.
• Les Références nécessaires aux sauvegardes et restaurations.
• Les Mesures de santé, de charge et de performance.

Les journaux, traces d'audit, métriques, sauvegardes et mécanismes d'exploitation seront détaillés dans les parties consacrées à la sécurité, à l'architecture technique et à la robustesse.

Une entrée du registre de restriction ne constitue pas une Identité Horizon. Elle conserve uniquement les identifiants ou empreintes nécessaires, la portée, le motif, la durée ou le critère de réexamen et les accès autorisés. Elle ne peut pas servir à reconstituer un profil personnel supprimé.

Métadonnées communes

La valeur seule ne suffit pas toujours à interpréter correctement une donnée. Selon sa nature et son usage, une donnée peut nécessiter plusieurs métadonnées fonctionnelles.

Métadonnée	Question traitée
Nom fonctionnel	Quelle notion commune la donnée représente-t-elle ?
Sujet	À quelle identité, relation, procédure, système ou service se rattache-t-elle ?
Finalité	Pourquoi Horizon connaît-il cette information ?
Source	D'où provient la valeur connue ?
Autorité fonctionnelle	Quel acteur, service ou règle établit la valeur canonique ?
Date d'occurrence	Quand le fait s'est-il produit dans son système d'origine ?
Date de réception	Quand Horizon a-t-il reçu l'événement ou l'observation ?
Date d'observation	Quand Horizon a-t-il établi sa représentation locale ?
Dernière vérification	Quand la valeur a-t-elle été confirmée ou rafraîchie pour la dernière fois ?
Moment de modification	Quand la valeur actuelle a-t-elle changé ?
Version ou révision source	Quel ordre ou quelle version la source a-t-elle communiqué ?
Identifiant externe	Quelle référence stable permet de corréler ou de dédupliquer le fait reçu ?
Disponibilité	Une valeur exploitable est-elle connue ?
Fraîcheur	La valeur est-elle encore suffisamment actuelle ?
Confiance de l'information	La valeur est-elle confirmée ou incertaine ?
Cohérence	La valeur est-elle compatible avec les autres informations disponibles ?
Transition	La valeur est-elle stable ou une modification reste-t-elle en attente ?
Préférence de visibilité	Quelle présentation la personne demande-t-elle dans les limites autorisées ?
Visibilité effective	Quelle présentation Horizon peut-il réellement appliquer selon les permissions et la classification ?
Sensibilité	Quel niveau de protection général doit être envisagé ?
Conservation	La donnée est-elle actuelle, temporaire, historique ou soumise à une échéance ?

Toutes les données n'ont pas besoin de matérialiser chacune de ces métadonnées. Leur représentation dépend du risque, de l'usage et de la capacité de la source à les fournir. Le futur catalogue détaillé devra indiquer, donnée par donnée, les métadonnées disponibles et la stratégie applicable lorsqu'elles manquent.

Les sources faisant autorité, les priorités, les stratégies de synchronisation et la résolution des conflits seront définies au chapitre 14. La classification détaillée et les durées de conservation relèvent respectivement des chapitres 33 et 35.

État actuel, historique, mémoire et journalisation

Le catalogue doit préserver les finalités distinctes établies au chapitre 9.

Ensemble	Finalité
État actuel	Connaître directement la situation présente d'Horizon.
Historique Horizon	Expliquer les évolutions fonctionnelles conservées dans le temps.
Mémoire de P.O.U.B.E.L.L.E.	Fournir un contexte conversationnel sélectionné, autorisé et révisable.
Journalisation	Diagnostiquer le fonctionnement technique et les incidents.
Trace d'audit	Établir qui a effectué ou autorisé une opération sensible.
Statistiques	Produire des mesures et tendances à partir de données adaptées.

Une même occurrence peut alimenter plusieurs ensembles, mais chaque conservation doit répondre à sa propre finalité. Un message Discord peut, par exemple, contribuer à un compteur d'activité, fournir temporairement un contexte conversationnel et produire un événement fonctionnel sans être conservé intégralement dans chacun de ces ensembles.

Les règles détaillées relèvent des chapitres 15 à 17 et des chapitres de robustesse et d'exploitation.

Relation avec l'Annexe F

Le présent chapitre fournit une carte lisible des données. La future Annexe F constituera le référentiel exhaustif et évolutif après la stabilisation des chapitres spécialisés.

Pour chaque donnée détaillée, l'annexe pourra notamment préciser :

• Le Nom fonctionnel canonique.
• La Définition.
• La Famille documentaire et le sujet concerné.
• Le Mode de production.
• Le Rôle fonctionnel.
• Le Cycle de vie.
• La Cardinalité fonctionnelle.
• Les Sources possibles et l'autorité fonctionnelle.
• Les Métadonnées d'occurrence, de réception, d'observation, de vérification, de version et d'identification disponibles.
• Les Conditions de modification.
• La Visibilité et la sensibilité.
• La Durée ou la condition de conservation.
• La Stratégie de fusion.
• Les Systèmes qui la consultent, la produisent ou la modifient.
• Les Événements capables de la faire évoluer.

L'annexe sera alimentée progressivement. Un chapitre spécialisé reste la source de vérité de ses règles métier, tandis que l'Annexe F permet de retrouver la définition détaillée des données correspondantes sans alourdir le parcours principal.

Vue fonctionnelle du catalogue

La figure suivante présente plusieurs ancrages fonctionnels : la personne et son Identité Horizon, les services ou systèmes, ainsi que les événements ou procédures. Les données humaines restent visuellement prédominantes, tandis que les paramètres système et les états opérationnels demeurent rattachés à leur véritable sujet. Elle montre également que les familles détaillées alimenteront la future Annexe F sans transformer le chapitre en schéma technique.

FIG. 11 Cartographie fonctionnelle — Principales familles de données Horizon et leurs sujets de rattachement.

Garanties fonctionnelles

Le catalogue fonctionnel doit garantir les principes suivants :

• Une donnée doit posséder une définition commune avant sa traduction technique.
• Une donnée doit rester rattachée à son véritable sujet fonctionnel.
• L'Identité Horizon doit rester la référence centrale des données communes à une personne.
• Un compte externe doit être reconnu par son identifiant de plateforme et non par son pseudonyme.
• Une liaison doit rester distincte du compte, de l'identité et de l'autorisation externe.
• Une donnée privée doit rester privée tant qu'une publication explicite n'a pas été demandée.
• Une publication doit pouvoir être retirée sans modifier la valeur fonctionnelle sous-jacente.
• Les activités Twitch, Discord et Web doivent rester distinguées.
• Les valeurs de confiance relationnelle et de proximité doivent rester cachées et encadrées.
• Toute évolution d'un indicateur relationnel doit conserver une trace minimale explicative.
• Une préférence de visibilité ne doit jamais être confondue avec une permission ou une visibilité effective.
• Une Statistique publiable doit posséder son propre réglage et respecter une visibilité maximale définie par Horizon.
• Une Période Twitch non observable ne doit devenir ni une présence ni une absence supposée.
• Les métadonnées temporelles disponibles doivent rester suffisamment précises pour ordonner, vérifier et dédupliquer les informations.
• Le LLM ne doit disposer d'aucune autorité directe sur les données Horizon.
• Une donnée temporaire ne doit pas survivre sans finalité active.
• Une correction doit conserver son origine et ses valeurs avant et après.
• L'état actuel, l'historique, la mémoire, les journaux et les traces d'audit ne doivent pas être confondus.
• Une nouvelle donnée métier doit enrichir la future Annexe F sans rendre ce chapitre illisible.

Limites du présent chapitre

Le présent chapitre définit les familles et données structurantes d'Horizon. Les domaines suivants relèvent de leurs chapitres ou référentiels maîtres :

• L'État global et les événements relèvent du chapitre 9.
• L'Identité Horizon, ses états et ses statuts relèvent du chapitre 10.
• Les liaisons et autorisations externes relèvent du chapitre 11.
• La consolidation des identités relève du chapitre 12.
• Les sources faisant autorité, priorités et conflits relèvent du chapitre 14.
• L'Historique Horizon, la mémoire et les statistiques relèvent des chapitres 15 à 17.
• La relation avec P.O.U.B.E.L.L.E., le LLM, le contexte et les outils relèvent des chapitres 18 à 21.
• Les règles des interfaces relèvent des chapitres 22 à 25.
• Les systèmes communautaires et leurs catalogues métier relèvent des chapitres 26 à 30.
• L'Authentification, les permissions, la classification, les actions critiques et la conservation relèvent des chapitres 31 à 35.
• La Traduction technique du modèle relève du chapitre 43.
• Le Modèle complet d'identité relève de l'Annexe E.
• Le Catalogue exhaustif des données relèvera de la future Annexe F.
• Le Catalogue des événements relève de l'Annexe G.
• Les Matrices de permissions et de sensibilité relèvent des Annexes H et J.
• Le Schéma technique de la base de données relève de l'Annexe P.

Synthèse

Le catalogue fonctionnel organise les principales données dont Horizon a besoin sans les transformer prématurément en tables, colonnes ou contrats techniques. L'Identité Horizon demeure la référence centrale des données communes à une personne ; les comptes externes, liaisons, profils, statuts, responsabilités, progressions et relations avec P.O.U.B.E.L.L.E. conservent leurs propres significations.

Les modes de production, rôles fonctionnels et cycles de vie restent décrits par des axes indépendants. Les activités Twitch, Discord et Web ne sont pas mélangées sans règle métier et suivent un cadre temporel commun. Les périodes non observables restent inconnues. Les données privées restent privées par défaut, chaque statistique respecte une visibilité maximale et les traitements LLM conservent uniquement les informations nécessaires.

Le chapitre 14 peut désormais définir, pour chaque famille, qui produit la valeur, quelle source fait autorité, comment Horizon synchronise les observations et quelles règles s'appliquent lorsqu'une divergence ou un conflit apparaît.