Périmètre général

Les chapitres précédents ont présenté la finalité du Projet Horizon, son organisation générale, ses objectifs, ses principes de conception et les acteurs amenés à interagir avec la Plateforme. Le présent chapitre complète ce cadre en délimitant les responsabilités qui appartiennent à Horizon et celles qui restent exercées par les plateformes, logiciels et services auxquels il est relié.

Cette délimitation ne décrit pas encore le fonctionnement détaillé des extensions, les données échangées, les permissions nécessaires ni les mécanismes techniques d'intégration. Elle établit les frontières générales qui permettront aux chapitres spécialisés de préciser ces éléments sans attribuer à Horizon une autorité qu'il ne possède pas.

Frontière générale — Fonctionnement cible validé

Horizon contrôle ses règles, son état global, son orchestration, ses composants techniques et les données pour lesquelles il constitue la source fonctionnelle faisant autorité. Il peut observer des événements produits par des services externes et leur transmettre des actions autorisées, mais ces services conservent l'autorité sur leurs comptes, leurs données natives, leurs contraintes et l'exécution réelle de leurs fonctions.

Une intégration permet à Horizon de coordonner un service : elle ne transforme pas ce service en composante interne de la Plateforme.

Comprendre la frontière de responsabilité

Le périmètre d'Horizon ne se limite pas à distinguer ce qui est hébergé localement de ce qui fonctionne à distance. Un composant peut appartenir à la Plateforme tout en étant déployé sur un service distant. Inversement, un logiciel exécuté sur le même ordinateur que certaines composantes d'Horizon peut rester un système extérieur possédant son propre état et ses propres responsabilités.

Pour chaque donnée, événement ou action, quatre questions permettent d'identifier la frontière applicable :

• Quel système produit ou détient l'information d'origine.
• Quel système constitue la source faisant autorité.
• Quel traitement Horizon peut réaliser à partir de cette information.
• Quel système exécute la conséquence demandée et demeure l'autorité sur son état réel.

Horizon peut conserver une représentation locale d'une information externe lorsqu'elle est nécessaire à son fonctionnement, à son historique ou à la continuité de ses services. Cette représentation ne devient pas automatiquement la nouvelle autorité. Un rôle Twitch, une appartenance à un serveur Discord ou l'état réel d'une scène OBS doivent rester rattachés au service qui les définit, même lorsqu'ils sont consultés ou utilisés depuis le Poste de commande.

La répartition précise de l'autorité, de la priorité et des règles de synchronisation sera définie donnée par donnée au chapitre 14.

Ce qui appartient à Horizon

Horizon contrôle les composants et les fonctions qui assurent la continuité commune entre les interfaces de La Tanière. Ce périmètre comprend notamment :

• Le Noyau Horizon, son orchestrateur et les mécanismes de contrôle des traitements.
• Le modèle commun des événements, des demandes, des conséquences et de leur contexte.
• L'identité Horizon et les relations établies avec les comptes externes vérifiés.
• Les données natives de la Plateforme, notamment la progression, les niveaux, les grades, les paramètres et les états fonctionnels qu'elle calcule.
• Les règles métier, les permissions internes et les validations appliquées avant l'exécution d'une action.
• La base de données, les historiques, les journaux techniques et la mémoire mise à la disposition de P.O.U.B.E.L.L.E.
• Le service LLM Horizon, qui assemble le contexte sélectionné et autorisé par le Noyau, sollicite le modèle local et vérifie la conformité technique et formelle du résultat.
• Les extensions qui traduisent les échanges avec Twitch, Discord, OBS et les autres services reliés.
• Le Poste de commande Web et les espaces qu'il fournit aux membres, aux responsables et au Capitaine.
• Les modules fonctionnels de La Tanière progressivement repris par la Plateforme.

Le fait qu'une extension appartienne à Horizon ne signifie pas que la plateforme qu'elle relie lui appartient également. L'extension Twitch est un composant d'Horizon, Twitch reste un service externe. De la même manière, le Poste de commande appartient à la Plateforme, mais il n'est pas une autorité indépendante sur les données qu'il affiche. Il consulte et modifie celles-ci par l'intermédiaire du Noyau.

Le Poste de commande ne doit pas davantage constituer une dépendance obligatoire pour toutes les fonctions de la Plateforme. Une indisponibilité de son interface ne doit pas, à elle seule, empêcher les extensions Twitch ou Discord de traiter les événements autorisés, ni remettre en cause l'existence des identités et des comptes déjà liés.

Les responsabilités fonctionnelles du Noyau seront détaillées au chapitre 7. Les composants logiciels qui réaliseront ce périmètre seront ensuite définis au chapitre 41.

P.O.U.B.E.L.L.E. ne fait pas partie de la Plateforme

P.O.U.B.E.L.L.E. reste une entité indépendante utilisant Horizon comme infrastructure technique. Sa personnalité, son identité et son canon ne résultent ni du Noyau, ni du service LLM, ni du modèle employé, ni de l'assemblage des données et des outils disponibles.

Horizon peut conserver les références nécessaires à la cohérence de ses interventions, lui construire un contexte et mettre à sa disposition une mémoire ou des outils autorisés. Il ne devient pas pour autant propriétaire de son identité. Cette séparation permet notamment de faire évoluer les composants techniques, le modèle LLM local ou les interfaces sans redéfinir P.O.U.B.E.L.L.E.

Sa relation avec la Plateforme sera précisée au chapitre 18.

FIG. 04 Figure fonctionnelle — Frontières de responsabilité : le service LLM appartient à Horizon, tandis que le modèle local ou le fournisseur sollicité reste une ressource technique distincte.

Ce qui reste géré par Twitch

Twitch demeure l'autorité sur les fonctions et informations natives de la chaîne. Il gère notamment les comptes Twitch, leur authentification, les identifiants attribués par la plateforme, le suivi de la chaîne, les abonnements, les statuts VIP ou de modération, les récompenses de points de chaîne, les messages du chat et les événements propres aux directs.

Horizon peut recevoir ces événements, vérifier leur origine, les rattacher à une identité commune et produire les conséquences prévues par ses propres règles. Il peut également demander à Twitch d'envoyer un message, de réaliser une opération de modération, de gérer certaines récompenses ou d'exécuter une autre action autorisée par l'interface disponible.

Ces capacités restent soumises aux permissions accordées au compte utilisé, aux possibilités de l'API, aux règles de Twitch et à la disponibilité du service. Horizon ne peut ni créer un droit que Twitch n'accorde pas, ni se substituer à Twitch pour déterminer l'état réellement appliqué sur la chaîne. Les mécanismes de vérification des résultats relèveront des chapitres consacrés aux intégrations et à la gestion des erreurs.

Horizon peut calculer des informations fonctionnelles à partir de l'activité Twitch, comme une progression ou un historique propre à La Tanière. Il constitue alors la source faisant autorité pour les valeurs qu'il calcule, tandis que les événements Twitch utilisés conservent leur origine externe. Cette autorité fonctionnelle ne vaut ni propriété de la personne concernée ni droit illimité sur ses données. La frontière dépend donc de la nature de l'information, de sa finalité et de l'autorité qui la définit, et non du seul endroit où elle est stockée.

Les interactions fonctionnelles avec Twitch seront détaillées au chapitre 22. Leur mise en œuvre technique relèvera du chapitre 45.

Ce qui reste géré par Discord

Discord demeure l'autorité sur les comptes Discord, les identifiants qu'il attribue, l'appartenance au serveur de La Tanière, ses salons, ses messages, ses rôles natifs, ses permissions et les opérations de modération ou d'administration réalisées sur le serveur.

L'extension Discord permet à Horizon de recevoir les événements utiles, de reconnaître les membres, de traduire certains rôles en responsabilités exploitables et d'exécuter les actions autorisées. Horizon peut, par exemple, demander l'attribution d'un rôle reflétant une progression, publier une annonce, transmettre un message de P.O.U.B.E.L.L.E. ou coordonner une conséquence commencée sur une autre interface.

La représentation d'un rôle Discord dans Horizon ne remplace pas le rôle détenu sur le serveur. Si Discord indique qu'une personne ne possède plus ce rôle ou n'appartient plus au serveur, Horizon doit réévaluer les capacités qui en dépendaient. Il peut conserver l'historique du changement ou les données Horizon légitimement associées à la personne, mais il ne doit pas continuer à lui attribuer une responsabilité externe devenue invalide.

Horizon n'a pas vocation à reproduire l'ensemble de Discord ni à se substituer au serveur communautaire. Il utilise les fonctions nécessaires à la continuité de La Tanière et laisse à Discord la gestion de son infrastructure, de ses contraintes et des possibilités natives qui ne nécessitent aucune coordination avec la Plateforme.

Les interactions fonctionnelles avec Discord seront détaillées au chapitre 23, puis leur intégration technique au chapitre 45.

Ce qui reste géré par OBS et Streamer.bot

OBS et Streamer.bot occupent deux positions différentes dans le périmètre cible. OBS reste un système audiovisuel externe qu'Horizon pourra piloter. Streamer.bot constitue au contraire une solution actuellement utilisée dont les responsabilités doivent être reprises par Horizon avant la stabilisation de la V1.

OBS reste un système externe pilotable

OBS conserve la responsabilité de la composition et du rendu audiovisuel du direct. Il gère effectivement les scènes, les sources, les transitions, les filtres et les autres éléments qu'il met à la disposition du direct. Horizon n'a pas vocation à remplacer son moteur de production ou de diffusion.

La Plateforme doit toutefois pouvoir dialoguer directement avec OBS lorsque les interfaces disponibles le permettent. Elle peut consulter certains états, demander un changement de scène, activer une source, déclencher une transition ou exécuter une autre opération audiovisuelle autorisée. Ces fonctions pourront être proposées depuis une interface adaptée du Poste de commande, notamment afin d'organiser séparément les éléments employés par le Protocole de Raid ou par d'autres systèmes du direct.

Horizon contrôle la logique qui détermine qu'une conséquence audiovisuelle doit être demandée, son contexte, ses conditions et sa traçabilité. OBS reste l'autorité sur l'état réellement appliqué à la production. Les modalités de confirmation, de reprise et de traitement des erreurs seront définies dans les chapitres consacrés aux intégrations et à la robustesse.

Retrait de Streamer.bot après migration des fonctions retenues

Streamer.bot appartient à l'état actuel de La Tanière et constitue une solution transitoire pendant le développement et la migration vers Horizon. Il peut continuer à assurer certaines automatisations tant que leurs équivalents Horizon ne sont pas suffisamment développés et validés.

Le principe validé est que la V1 stabilisée ne doit plus dépendre de Streamer.bot pour les fonctions explicitement retenues dans son périmètre. Cette orientation est notamment motivée par la nécessité de construire dans Horizon un système de progression commun, difficile à maintenir de manière durable dans Streamer.bot.

Chaque règle, état, scénario ou automatisation retenu pour la V1 devra être repris, testé et validé dans Horizon avant le retrait de la dépendance correspondante. Cette exigence ne promet pas une parité exhaustive avec toutes les fonctions historiquement présentes dans Streamer.bot : leur inventaire, leur sélection et leur ordre de migration restent à établir.

L'inventaire de l'existant et la procédure de migration seront traités aux chapitres 57 et 58. La composition exacte de la V1 sera arrêtée au chapitre 63.

Services vocaux et multimédias

Les moteurs de synthèse vocale, les outils de modification de voix, les lecteurs audio, les ressources vidéo et les autres services multimédias restent des moyens spécialisés reliés à Horizon. Selon les choix techniques futurs, ils pourront être exécutés localement ou fournis à distance sans modifier leur position fonctionnelle générale.

Horizon contrôle la logique qui détermine si une production vocale ou multimédia doit être demandée, le contenu autorisé, les paramètres applicables, le moment du déclenchement et les conséquences à enregistrer. Le service spécialisé conserve la responsabilité de générer, transformer ou lire le média selon les capacités qu'il propose.

Une sortie produite par un service externe ne doit pas pouvoir agir librement sur la Plateforme. Elle reste rattachée à la demande d'origine, aux permissions vérifiées et au traitement qui l'a sollicitée. De la même manière, l'indisponibilité d'un service vocal ne doit pas interrompre les fonctions déterministes d'Horizon qui peuvent continuer sans lui.

Le détail des besoins audiovisuels propres au Protocole de Raid et au soundboard sera présenté aux chapitres 27 et 28. Les connexions à OBS, aux services TTS et aux outils vocaux relèveront du chapitre 45.

Service LLM Horizon et modèle utilisé

Le service LLM Horizon appartient à la Plateforme et reste contrôlé par le Noyau. Il assemble la demande adressée au modèle à partir du modèle de prompt, des sources, des données et des restrictions sélectionnés par le Noyau, sollicite le moteur retenu et vérifie la conformité technique et formelle du résultat. Il ne constitue ni P.O.U.B.E.L.L.E., ni sa mémoire, ni une autorité décisionnelle concurrente du Noyau.

Le modèle LLM reste distinct de ce service interne. Le fonctionnement cible actuellement validé repose sur un modèle open source téléchargé et exécuté localement ; son choix exact n'est pas encore arrêté et relève du chapitre 19. Il fournit une capacité technique de traitement du langage selon ses possibilités, ses limites et sa disponibilité, sans acquérir d'accès général à Horizon.

Horizon reste responsable de la finalité du traitement, de la sélection du contexte, des permissions appliquées, de l'interprétation du résultat et de l'autorisation de toute conséquence. Un changement de modèle ne transfère donc aucune responsabilité du Noyau et ne modifie pas la place fonctionnelle du service LLM Horizon.

Les fonctions essentielles fondées sur des règles déterministes doivent continuer à fonctionner autant que possible sans capacité générative. Le modèle peut contribuer à la compréhension ou à la formulation : il ne calcule pas les valeurs faisant autorité et n'exécute jamais directement une opération sur Twitch, Discord, OBS, la base de données ou un autre système.

Son rôle fonctionnel sera détaillé au chapitre 19, la sélection de ses informations au chapitre 20 et les outils accessibles à P.O.U.B.E.L.L.E. au chapitre 21.

Autres services tiers

Horizon pourra être relié à d'autres services techniques lorsqu'ils apportent une capacité utile à La Tanière. Il peut s'agir, par exemple, d'un service de notification, d'une source d'information, d'un outil de stockage spécialisé, d'un système du vaisseau ou d'une future plateforme communautaire.

L'ajout d'une intégration ne doit pas créer une connexion incontrôlée avec le Noyau ou la base de données. Chaque service doit être relié par une extension ou un mécanisme équivalent dont le périmètre limite les événements acceptés, les données accessibles et les actions autorisées.

Aucun service tiers ne bénéficie d'un accès général aux données, aux outils ou aux autres interfaces du seul fait qu'il est connecté à Horizon. Les permissions, confirmations, protocoles, retours d'exécution et comportements en cas d'indisponibilité seront définis dans les chapitres consacrés aux intégrations externes et à la gestion des erreurs.

Fonctionnalités hors du périmètre d'Horizon

Certaines responsabilités restent extérieures au Projet Horizon par nature. Sauf décision future explicite modifiant son périmètre, Horizon n'a pas vocation à :

• Remplacer l'infrastructure générale, les comptes ou l'ensemble des fonctions de Twitch et Discord.
• Assurer lui-même la capture, le rendu, l'encodage ou la diffusion vidéo réalisés par OBS et les services de streaming.
• Développer un moteur généraliste de synthèse vocale, de modification de voix, de génération multimédia ou de modèle de langage lorsque des solutions spécialisées peuvent être intégrées.
• Reproduire les outils complets de création, de montage ou d'administration déjà fournis par les logiciels externes.
• Contourner les permissions, les limitations ou les règles imposées par un service relié.
• Garantir la disponibilité d'une plateforme ou d'un fournisseur extérieur.
• Déléguer à P.O.U.B.E.L.L.E., au service LLM ou au modèle employé une autorité humaine, une décision critique ou un contrôle direct des systèmes.

Cette exclusion n'empêche pas Horizon de piloter certaines fonctions de ces services, d'en conserver le contexte ou de proposer une interface mieux adaptée aux besoins de La Tanière. Elle signifie que la Plateforme coordonne leur utilisation sans reprendre la responsabilité générale du système concerné.

Frontière entre la V1 et les évolutions futures

Le périmètre général du Projet Horizon est plus large que celui de sa première version. Une fonctionnalité peut donc appartenir à la vision d'Horizon tout en étant volontairement reportée. Elle est alors hors du périmètre de la V1, mais non hors du périmètre du Projet Horizon.

À l'inverse, une responsabilité exclue du Projet Horizon ne doit pas être présentée comme une simple fonctionnalité future. Cette distinction évite de transformer chaque possibilité technique en engagement et permet de préserver une trajectoire de développement réaliste.

Le présent chapitre ne fixe pas la liste détaillée des fonctions qui composeront la V1. Cette liste dépendra des décisions prises dans les parties fonctionnelles et techniques, de l'apprentissage réalisé et des dépendances découvertes au cours de la conception. Elle sera établie au chapitre 63.

Deux orientations générales sont néanmoins déjà établies :

• La V1 doit constituer un ensemble commun suffisamment cohérent pour ne pas reproduire la fragmentation des systèmes actuels.
• La V1 stabilisée ne doit plus dépendre de Streamer.bot pour les fonctions explicitement retenues dans son périmètre, après leur migration et leur validation dans Horizon.

Les fonctions volontairement reportées seront recensées au chapitre 65. Les principes permettant d'ajouter ultérieurement de nouvelles interfaces, plateformes et capacités seront définis au chapitre 66.

Synthèse du périmètre général

Domaine	Autorité principale	Rôle général d'Horizon	Limite établie
Plateforme et Noyau Horizon	Horizon	Maintient l'identité commune, les données dont il est la source fonctionnelle, les règles, l'état global Horizon, l'orchestration, le service LLM, les extensions et le Poste de commande.	Les composants internes contrôlent les traitements Horizon, mais n'acquièrent pas l'autorité des services reliés.
P.O.U.B.E.L.L.E.	P.O.U.B.E.L.L.E. reste une entité indépendante.	Lui fournit un contexte autorisé, une mémoire conversationnelle sélectionnée et des outils contrôlés.	La Plateforme ne constitue ni son identité, ni sa personnalité, ni son intelligence.
Twitch	Twitch pour ses comptes, rôles, événements et fonctions natives.	Observe les événements utiles, calcule ses données propres et demande des actions autorisées.	Twitch conserve ses contraintes et l'autorité sur l'exécution réelle.
Discord	Discord pour ses comptes, rôles, serveur, messages et fonctions natives.	Relie les membres, coordonne les données utiles et demande des actions autorisées.	Horizon ne remplace ni le serveur communautaire ni les permissions natives.
OBS	OBS pour la composition et l'état audiovisuel réellement appliqué.	Peut le piloter directement et proposer des contrôles adaptés depuis le Poste de commande.	Horizon coordonne certaines opérations sans remplacer le moteur de production ou de diffusion.
Streamer.bot	Solution actuelle et transitoire.	Reprend progressivement les fonctions sélectionnées après l'inventaire de l'existant.	La V1 stabilisée ne doit plus en dépendre pour les fonctions explicitement retenues dans son périmètre.
Services vocaux et multimédias	Chaque outil pour la génération, la transformation ou la lecture qu'il réalise.	Sélectionne, autorise, paramètre et orchestre leur utilisation.	Horizon ne devient pas un moteur multimédia généraliste.
Service LLM et modèle utilisé	Horizon pour le service interne ; moteur local distinct pour l'exécution du modèle.	Le Noyau sélectionne le contexte ; le service LLM l'assemble, sollicite le modèle et vérifie son résultat.	Le modèle ne décide pas, n'exécute pas directement et ne constitue pas P.O.U.B.E.L.L.E.
Autres services tiers	Chaque service pour ses données, contraintes et opérations natives.	Les relie au moyen d'intégrations limitées et contrôlées.	Une connexion ne crée aucun accès général à Horizon.
V1 et développements futurs	Horizon définit son propre calendrier fonctionnel.	Construit d'abord un socle cohérent, puis ajoute progressivement les capacités retenues.	La composition exacte de la V1 et les fonctionnalités reportées sont définies dans les parties de planification et d'évolution.

Ce périmètre achève la présentation des fondations générales du Projet Horizon. La partie suivante décrira le fonctionnement interne du Noyau, en commençant par ses responsabilités, ses limites et ses relations avec les données, les interfaces, P.O.U.B.E.L.L.E. et les services externes.