Principes fondamentaux de conception

Les chapitres précédents ont présenté la raison d'être du Projet Horizon, l'organisation générale de la Plateforme et les résultats qu'elle doit permettre d'atteindre. Le présent chapitre définit les principes qui devront guider les décisions prises au cours de sa conception, de son développement et de son évolution.

Ces principes ne décrivent pas encore les structures de données, les mécanismes d'authentification, le cycle technique des événements ni les procédures de sécurité dans leur détail. Ils établissent les règles communes auxquelles ces futures solutions devront se conformer. Une implémentation pourra évoluer ; les garanties fonctionnelles définies ici devront rester valables tant qu'une nouvelle décision ne les aura pas explicitement remplacées.

Principes fondateurs : Fonctionnement cible validé

Horizon repose sur une référence commune pour les données et les identités, des événements contextualisés, des accès limités, une protection intégrée dès la conception, une exécution contrôlée par le Noyau et une séparation claire entre le service LLM, le modèle employé et les systèmes concernés.

Toute conséquence importante doit être autorisée, traçable et, lorsqu'elle est critique, confirmée par une personne habilitée. Les fonctions déterministes essentielles doivent rester disponibles autant que possible lorsque le modèle LLM ne l'est pas.

Une référence commune pour les données et les identités

Lorsqu'une information doit être partagée entre plusieurs composantes d'Horizon, elle doit disposer d'une référence commune. Twitch, Discord et le Poste de commande Web ne doivent pas maintenir chacun une version indépendante de l'identité, de la progression, des grades, des permissions ou des paramètres d'une même personne.

Cette règle n'interdit pas toute copie technique. Une extension peut conserver temporairement une information pour assurer son fonctionnement, améliorer les performances ou permettre une reprise après interruption. Cette copie ne doit toutefois pas devenir une autorité concurrente : elle doit rester rattachée à la donnée de référence et pouvoir être actualisée ou invalidée selon les règles du Noyau.

Une identité Horizon derrière plusieurs comptes externes

Une personne connue d'Horizon est représentée par une identité Horizon centrale, indépendamment de son statut communautaire actuel. Ses comptes Twitch et Discord constituent des comptes externes pouvant être reliés à cette identité ; ils ne forment pas deux personnes indépendantes et ne possèdent pas les données communes créées par Horizon.

L'accès à la Plateforme Horizon s'effectue au moyen d'une connexion Twitch ou Discord. Cette connexion permet au service concerné d'attester que l'utilisateur contrôle le compte présenté, puis à Horizon de retrouver ou d'établir le rattachement correspondant. Horizon n'a donc pas besoin de créer un mot de passe communautaire distinct pour permettre l'accès au Poste de commande.

L'authentification par un service externe ne transfère pas à ce service la propriété de l'identité Horizon. Twitch reste l'autorité pour le compte Twitch et ses informations natives. Discord conserve la même responsabilité pour le compte Discord. Horizon demeure l'autorité pour l'identité centrale, les relations entre les comptes liés et les données propres à la Plateforme.

Une liaison entre deux comptes doit être vérifiée. La ressemblance de deux pseudonymes, l'utilisation d'un même nom d'affichage ou une supposition de P.O.U.B.E.L.L.E. ne doivent jamais suffire à réunir automatiquement deux identités. Une personne authentifiée par Twitch ou Discord peut relier un autre compte au moyen d'une procédure contrôlée prouvant qu'elle en possède également l'accès.

Une autorité et une priorité définies donnée par donnée

Il n'existe pas de priorité générale plaçant systématiquement Horizon, Twitch ou Discord au-dessus des autres services. L'autorité dépend de la nature de l'information :

• Twitch fait autorité pour le suivi de la chaîne, un abonnement, un raid ou une autre information native de Twitch.
• Discord fait autorité pour l'appartenance à un serveur, un rôle natif ou une autre information propre à Discord.
• Horizon fait autorité pour l'identité Horizon, la progression commune, les niveaux, les grades, les paramètres et les autres données créées par la Plateforme.

Lorsqu'une même donnée peut être obtenue ou modifiée depuis plusieurs sources, sa règle de résolution doit être définie individuellement. Cette règle peut désigner une source prioritaire, imposer une validation, comparer la date des valeurs ou refuser toute mise à jour tant que le conflit n'est pas résolu. Elle ne doit pas être déduite d'une préférence globale pour une plateforme.

Des événements identifiables, contextualisés et reliés

Une interaction reçue par Horizon possède un événement d'origine identifiable. Les décisions, résultats, échéances et changements d'état qu'elle produit peuvent devenir de nouveaux événements dérivés, chacun doté de sa propre référence et relié au même traitement ou à la même chaîne causale.

Une activité reconnue sur Twitch peut ainsi modifier une progression commune, actualiser le Poste de commande, conduire à une demande d'adaptation d'un rôle Discord et provoquer une intervention de P.O.U.B.E.L.L.E. Ces occurrences ne doivent ni être confondues avec l'interaction initiale ni devenir une succession d'événements indépendants dépourvus de lien.

Le Noyau doit pouvoir rattacher chaque conséquence à l'événement qui l'a provoquée, puis relier les événements dérivés au traitement et à leur cause. Ce rattachement permet de comprendre le parcours, d'identifier une exécution partielle, de prévenir les boucles et d'éviter qu'une même conséquence soit reproduite involontairement.

Un événement ne produit pas nécessairement une action visible. Il peut mettre à jour une donnée, être conservé dans un historique, être refusé par une règle ou rester sans conséquence. À l'inverse, un événement valide peut produire plusieurs actions coordonnées lorsque son contexte et les règles applicables le justifient.

Des conséquences adaptées aux comptes liés

Les conséquences possibles dépendent notamment des comptes rattachés à l'identité Horizon du membre. Une action destinée à Discord ne peut être appliquée à un membre qui ne possède aucun compte Discord lié ; une action Twitch obéit à la même règle pour Twitch.

L'absence d'une liaison ne doit pas remettre en cause le traitement général de l'événement. Les conséquences applicables peuvent être exécutées, tandis que celles qui nécessitent un compte absent sont ignorées, différées ou signalées selon leur importance. Les permissions du membre, l'état du service concerné et les règles propres à l'action restent également vérifiés avant toute exécution.

Cette logique permet à deux membres de participer au même système sans avoir relié exactement les mêmes services. L'identité Horizon constitue leur référence commune, tandis que leurs comptes liés déterminent les interfaces sur lesquelles certaines conséquences peuvent se manifester.

Un contexte conservé pendant tout le traitement

Un événement doit conserver les informations nécessaires à son interprétation : son origine, son auteur, sa date, l'interface et l'espace concernés, sa visibilité, sa cible éventuelle ainsi que les événements auxquels il est lié. Les conséquences produites doivent rester rattachées à ce contexte plutôt que d'être traitées comme des actions isolées.

Le contexte détermine notamment la forme d'une réponse, les données pouvant être utilisées et les interfaces vers lesquelles une information peut être transmise. Une demande formulée dans un échange privé ne peut pas devenir publique du seul fait qu'elle a traversé le Noyau ; une information reçue pendant un direct ne doit pas non plus être réutilisée ultérieurement sans conserver son origine et ses conditions d'utilisation.

Une séparation claire des différentes formes d'information

Horizon doit distinguer l'état actuel, l'historique, la journalisation et la mémoire mise à la disposition de P.O.U.B.E.L.L.E. Ces notions peuvent s'appuyer sur la même base de données, mais elles ne répondent ni au même besoin ni aux mêmes règles d'accès, de conservation ou d'utilisation.

L'état actuel et l'historique

L'état actuel représente ce qui est considéré comme vrai au moment du traitement : niveau d'un membre, grade en vigueur, comptes liés, permissions actives ou état d'un événement en cours. Il peut évoluer lorsqu'une action ou un nouvel événement modifie la situation connue d'Horizon.

L'historique conserve les changements et événements passés qui doivent rester consultables. Le niveau actuel d'un membre et l'événement au cours duquel il l'a atteint sont donc deux informations différentes. Modifier l'état actuel ne doit pas réécrire silencieusement le passé, et l'existence d'un historique ne signifie pas que chaque ancienne valeur demeure active.

Cette distinction permet de reconstruire un parcours, d'expliquer une modification et de produire des statistiques sans traiter toutes les informations passées comme si elles décrivaient encore la situation présente.

La journalisation et la mémoire mise à la disposition de P.O.U.B.E.L.L.E.

La journalisation d'Horizon conserve les traces nécessaires au diagnostic, à la sécurité, à l'audit et à la compréhension du fonctionnement de la Plateforme. Elle peut enregistrer des informations techniques, des refus, des erreurs, des tentatives d'action et des détails qui n'ont aucune utilité conversationnelle.

La mémoire mise à la disposition de P.O.U.B.E.L.L.E. sélectionne les informations susceptibles de contribuer à la continuité de ses interactions avec l'équipage. Elle obéit à ses propres règles de création, de révision, d'oubli, d'accès et de divulgation.

Une trace technique ne doit jamais devenir automatiquement un souvenir. Inversement, la mémoire ne doit pas servir de journal d'audit ni constituer la seule preuve d'une action effectuée. Une même situation peut alimenter ces deux fonctions, mais au moyen de traitements et de finalités explicitement distincts.

Une centralisation assortie d'un contrôle des accès

La centralisation permet à Horizon de maintenir des informations cohérentes ; elle ne crée aucun droit universel d'accès. Le fait qu'une donnée existe dans la Plateforme ne signifie pas que tous les membres, toutes les extensions, tous les administrateurs ou P.O.U.B.E.L.L.E. peuvent la consulter ou l'utiliser librement.

Chaque accès doit dépendre de l'identité du demandeur, de son rôle, de la fonction employée, du contexte de la demande et de la sensibilité de la donnée. Une extension ne doit recevoir que les informations nécessaires à l'action qu'elle exécute. Le modèle LLM ne doit recevoir que le contexte utile au traitement pour lequel il est sollicité.

Lire, utiliser, modifier et divulguer

La permission de lire une donnée ne vaut pas permission de la modifier, de l'utiliser pour n'importe quelle finalité ni de la transmettre à un tiers. La lecture et la divulgation constituent notamment deux autorisations distinctes.

P.O.U.B.E.L.L.E. peut, par exemple, recevoir une préférence privée afin d'adapter une réponse sans être autorisée à révéler cette préférence dans le chat Twitch, sur Discord ou auprès d'un autre membre. De la même manière, le Noyau peut consulter une information pour vérifier une permission sans devoir la transmettre à l'extension chargée d'exécuter l'action.

La sélection du contexte envoyé au modèle doit également respecter cette séparation. Le fait que le Noyau puisse lire une donnée ne suffit pas à autoriser sa transmission au modèle. L'utilité, la sensibilité, la finalité et les permissions applicables doivent être vérifiées pour chaque traitement.

Une protection des données et une sécurité intégrées dès la conception

La protection des personnes, des données et des systèmes ne doit pas être ajoutée après la définition des fonctionnalités. Chaque nouvelle collecte, mémoire, statistique, intégration ou capacité d'action doit être conçue en tenant compte de sa finalité, de sa nécessité, de sa sensibilité et des risques qu'elle crée.

Horizon doit notamment appliquer les principes suivants dès la conception :

• Ne collecter et ne conserver que les informations nécessaires à une finalité définie.
• Limiter chaque acteur, composant et service aux données et capacités indispensables à sa fonction.
• Protéger les données et les secrets pendant leur stockage, leur transmission et leur utilisation.
• Valider les informations et événements reçus avant de les intégrer à un traitement.
• Prévoir la correction, la suppression, la révocation et la traçabilité lorsque la nature de la donnée ou de l'accès l'exige.
• Distinguer la documentation publiable des informations internes dont la divulgation fragiliserait la sécurité ou la vie privée.

Ces garanties n'imposent pas encore une solution technique particulière. La classification des données, les durées de conservation, le modèle de menaces, la gestion des secrets et les mesures précises de protection seront définis dans les chapitres spécialisés. Toute décision future devra néanmoins respecter ce principe de sécurité et de protection des données dès la conception.

Une exécution contrôlée par le Noyau

Le service LLM Horizon peut solliciter un modèle afin de contribuer à la compréhension d'une demande, à la formulation d'une réponse ou à la préparation d'une intention structurée. Ni ce service ni le modèle employé ne doivent contrôler directement Twitch, Discord, le Poste de commande Web, la base de données ou un système du vaisseau.

Le Noyau Horizon reste l'autorité d'exécution. Son orchestrateur coordonne les fonctions internes chargées de construire le contexte, d'appliquer les règles, de vérifier les permissions et de déterminer les actions autorisées, puis organise la transmission aux extensions d'instructions limitées à ce qu'elles doivent exécuter. Une proposition produite par un modèle ou une demande de P.O.U.B.E.L.L.E. ne devient pas une action tant que le Noyau ne l'a pas autorisée.

Les calculs et valeurs qui font autorité doivent reposer sur des règles déterministes. La progression, les niveaux, les permissions, les remboursements et les modifications automatiques de données ne peuvent pas dépendre d'une formulation libre du modèle. Une sanction doit résulter d'une règle déterministe ou d'une décision humaine autorisée ; elle ne peut jamais être décidée exclusivement par le LLM. Celui-ci peut contribuer à expliquer un résultat ou à préparer un message, mais il ne fixe pas la valeur officielle ni la règle appliquée.

Une extension ne dispose pas davantage d'une autorité autonome. Elle traduit les événements reçus, exécute les actions validées dans son environnement et retourne leur résultat au Noyau. Elle ne doit pas contourner les permissions ni élargir la portée de l'instruction qui lui a été transmise.

Une confirmation humaine pour les actions critiques

Une action critique doit nécessiter la confirmation explicite d'une personne authentifiée et habilitée. Avant cette confirmation, Horizon doit présenter de manière compréhensible la nature de l'action, sa cible, sa portée et ses principales conséquences.

P.O.U.B.E.L.L.E. ou le service LLM peuvent proposer ou préparer une action critique, mais ils ne peuvent pas fournir eux-mêmes la confirmation qui en autorise l'exécution. Cette confirmation humaine ne dispense pas le Noyau de ses autres contrôles : l'action doit encore être refusée si les permissions, l'état du système ou les règles applicables ne permettent plus de l'exécuter.

Les catégories d'actions critiques, les niveaux de risque et les mécanismes précis de confirmation seront définis dans les chapitres consacrés à la sécurité. Le principe commun demeure qu'une opération susceptible de produire une conséquence importante, difficilement réversible ou sensible ne doit jamais résulter d'une simple interprétation conversationnelle.

Une plateforme traçable et résiliente

Toute action importante doit pouvoir être expliquée après son exécution. Horizon doit conserver une trace permettant d'identifier l'événement d'origine, l'acteur ou le service demandeur, les règles et permissions appliquées, la confirmation éventuellement obtenue, les conséquences demandées ainsi que leur résultat.

La traçabilité doit également couvrir les refus, les erreurs et les exécutions partielles. Lorsqu'une conséquence réussit sur une interface mais échoue sur une autre, le système doit pouvoir distinguer ces résultats et déterminer ce qui a réellement été effectué. Cette exigence ne signifie pas que toutes les traces doivent être conservées indéfiniment : leur contenu, leur sensibilité et leur durée de conservation seront définis selon leur finalité.

Un fonctionnement essentiel indépendant du modèle LLM

Le service LLM Horizon constitue une ressource utile de la Plateforme, mais ses capacités génératives ne sont pas une condition générale de fonctionnement. L'indisponibilité du modèle local retenu selon les principes du chapitre 19 ne doit pas empêcher, autant que possible :

• L'authentification par Twitch ou Discord et l'accès aux fonctions autorisées.
• La reconnaissance des identités et des comptes liés.
• La progression, les niveaux, les grades et les rôles.
• L'application des permissions et des règles déterministes.
• Les commandes, automatisations et traitements d'événements qui ne nécessitent pas de compréhension générative.
• Les mécanismes de modération fondés sur des règles établies.
• La consultation et l'administration des données accessibles depuis le Poste de commande.

P.O.U.B.E.L.L.E. peut continuer à utiliser ses messages préparés, ses scénarios déterministes et les interventions qui ne nécessitent pas le modèle. Ses capacités de compréhension ou de formulation générative peuvent en revanche devenir temporairement indisponibles ou adopter un mode dégradé clairement identifiable.

Horizon ne doit pas remplacer une réponse absente du modèle par une décision inventée ni contourner ses mécanismes de contrôle pour maintenir artificiellement une fonction. Le mode dégradé doit privilégier un comportement prévisible, explicable et sûr.

Synthèse des principes

Domaine	Principe directeur	Conséquence pour Horizon
Identité Horizon et comptes liés	Une référence commune, reliée à des comptes externes vérifiés.	Les interfaces n'entretiennent pas de versions indépendantes d'une même personne ou d'une même donnée.
Autorité des données	L'autorité et l'éventuelle priorité sont définies donnée par donnée.	Aucun service ne bénéficie d'une priorité générale sur les autres.
Événements	Une interaction possède un événement d'origine ; ses décisions, résultats et changements d'état peuvent devenir des événements dérivés reliés causalement.	Chaque conséquence et chaque événement dérivé restent rattachés au traitement concerné sans provoquer de répétition involontaire.
État, historique, logs et mémoire	L'état actuel, l'historique, les logs et la mémoire remplissent des fonctions distinctes.	Leur accès, leur utilisation et leur conservation peuvent obéir à des règles différentes.
Permissions et classification	Centraliser une information ne crée aucun accès universel.	Lire, utiliser, modifier et divulguer constituent des capacités séparées.
Protection des données et sécurité dès la conception	Toute collecte, transmission ou capacité d'action est conçue selon sa finalité, sa nécessité, sa sensibilité et ses risques.	Horizon applique la minimisation, le moindre privilège et les protections nécessaires avant la mise en service d'une fonctionnalité.
Noyau et LLM	Le Noyau demeure l'autorité et aucun modèle n'agit directement.	Toute action est vérifiée avant d'être transmise à une extension.
Sécurité	Une action critique exige une confirmation humaine explicite.	Une proposition conversationnelle ne peut pas, à elle seule, provoquer une opération sensible.
Traçabilité	Toute action importante doit pouvoir être expliquée.	Les demandes, contrôles, confirmations, résultats et erreurs sont rattachés au traitement concerné.
Résilience	Les fonctions déterministes essentielles ne dépendent pas d'un modèle LLM.	Horizon continue de fournir ses services fondamentaux en mode dégradé.

Ces principes forment le cadre commun des futures décisions fonctionnelles et techniques. Les chapitres spécialisés pourront préciser leur mise en œuvre sans en modifier la finalité. Le chapitre suivant identifiera les acteurs amenés à interagir avec Horizon, avant que le périmètre général ne répartisse les responsabilités entre la Plateforme et les services externes.