Extension Twitch

Twitch constitue l'interface publique et immédiate d'Horizon pendant les directs de La Tanière. Les messages du chat, les commandes, les événements de la chaîne et les interventions de P.O.U.B.E.L.L.E. doivent pouvoir y circuler sans transférer à Twitch ou à son extension les règles fonctionnelles de la Plateforme.

L'Extension Twitch assure cette liaison. Elle observe les informations rendues disponibles par Twitch, les transmet au Noyau sous une forme exploitable, reçoit les instructions autorisées et retourne le résultat réel des opérations demandées. Elle ne décide ni de la progression, ni du déroulement d'un protocole, ni d'une sanction, ni de l'utilisation d'une donnée personnelle.

Le présent chapitre définit son rôle fonctionnel, les comptes qu'elle mobilise, les principales catégories d'événements reçus, les interactions du chat, les actions sortantes et les comportements attendus en cas d'indisponibilité. Les mécanismes techniques de connexion, les contrats d'API et les règles métier des systèmes communautaires seront définis dans leurs chapitres spécialisés.

Fonctionnement cible — Principes validés

La V1 d'Horizon dessert une chaîne Twitch principale configurable. Elle se connecte directement à Twitch et utilise le compte officiel de P.O.U.B.E.L.L.E. pour ses interventions. Le compte du Capitaine conserve l'autorité sur la chaîne et accorde les autorisations nécessaires.

Streamer.bot constitue une solution actuelle appelée à disparaître au profit d'Horizon. Il ne fait pas partie de l'architecture cible de l'Extension Twitch.

L'Extension Twitch traduit les échanges entre Twitch et le Noyau sans prendre de décision métier. Toute conséquence externe est autorisée par le Noyau, exécutée par l'extension compétente, puis consolidée à partir du résultat réellement obtenu.

Synthèse normative

• La V1 doit fonctionner pour une chaîne Twitch principale configurable.
• Le modèle fonctionnel ne doit pas empêcher la création future de copies autonomes d'Horizon ni une évolution ultérieure vers plusieurs chaînes.
• L'accueil mutualisé de plusieurs streamers ne constitue pas un objectif de la V1.
• Le compte Twitch du Capitaine doit rester distinct du compte officiel utilisé par P.O.U.B.E.L.L.E.
• Le compte du Capitaine doit conserver l'autorité sur la chaîne et les autorisations qui en dépendent.
• P.O.U.B.E.L.L.E. doit utiliser son propre compte Twitch pour ses interventions publiques.
• Horizon doit se connecter directement à Twitch dans son fonctionnement cible.
• Streamer.bot ne doit pas constituer une dépendance permanente de l'architecture cible.
• L'Extension Twitch doit recevoir, vérifier techniquement et normaliser les événements Twitch qu'elle prend en charge.
• Chaque événement normalisé doit conserver son origine, sa date disponible, son contexte et les identifiants nécessaires à son traitement.
• L'Extension Twitch ne doit attribuer aucune signification métier autonome à un événement reçu.
• Tous les messages publics admissibles doivent pouvoir être transmis au Noyau, y compris lorsqu'ils ne s'adressent pas directement à P.O.U.B.E.L.L.E.
• Le contenu intégral du chat ne doit pas être conservé systématiquement du seul fait de sa réception.
• Une mention explicite de P.O.U.B.E.L.L.E. doit normalement déclencher le traitement d'une réponse.
• Hors mention, commande, échange déjà engagé ou événement prévu, le Noyau doit déterminer si une intervention de P.O.U.B.E.L.L.E. est pertinente.
• Une commande doit être reconnue et transmise sans donner à l'extension l'autorité sur sa validité fonctionnelle ou ses conséquences.
• Les rôles, statuts, événements et résultats natifs doivent conserver Twitch comme source d'autorité.
• Une participation Twitch et un temps de présence doivent rester deux observations distinctes.
• Une présence silencieuse non observable ne doit produire ni durée ni absence supposée.
• Une action Twitch sortante doit provenir d'une instruction limitée et autorisée par le Noyau.
• L'envoi d'une instruction ne doit jamais être assimilé à la réussite de l'action demandée.
• Une action OBS provoquée par un événement Twitch doit constituer une conséquence distincte exécutée par l'extension compétente.
• L'Extension Twitch ne doit jamais piloter directement OBS.
• Une action manuelle réalisée directement sur Twitch doit être répercutée dans Horizon lorsqu'elle est observable.
• Une notification privée destinée à une personne responsable ne doit pas dépendre obligatoirement de Twitch.
• Une déconnexion doit rendre la période concernée non observable sans inventer les événements manqués.
• Une action tardive ne doit être rejouée automatiquement que si elle reste utile, autorisée et explicitement répétable.
• Le catalogue d'événements, de commandes et d'actions présenté dans ce chapitre doit rester extensible.

Finalité et périmètre du chapitre

Le chapitre répond à la question suivante :

Comment Horizon peut-il recevoir les interactions et événements de Twitch, puis y produire des actions contrôlées, sans confier à l'Extension Twitch les décisions du Noyau ou des systèmes fonctionnels de La Tanière ?

Il poursuit plusieurs objectifs :

• Définir la place de Twitch parmi les interfaces d'Horizon.
• Délimiter les responsabilités respectives de Twitch, de l'Extension Twitch et du Noyau.
• Organiser la reconnaissance des comptes et des viewers.
• Encadrer la réception du chat, des commandes et des événements de la chaîne.
• Définir la manifestation de P.O.U.B.E.L.L.E. pendant les directs.
• Transmettre les observations nécessaires à la présence, aux statistiques, à la mémoire et aux systèmes communautaires.
• Encadrer les actions sortantes et la consolidation de leurs résultats.
• Préparer le remplacement fonctionnel de Streamer.bot.
• Garantir un comportement cohérent lors des déconnexions et reprises.

Le chapitre ne définit pas les formules de progression, les scénarios du Protocole de Raid, les règles du soundboard, la politique de modération ou les mécanismes techniques de connexion à Twitch. Il décrit les capacités d'interface dont ces systèmes pourront disposer.

Position fonctionnelle de Twitch

Twitch est l'espace privilégié des interactions publiques et immédiates pendant les directs. Il fournit notamment le chat, les événements de la chaîne, des statuts propres au service, des récompenses de points de chaîne et des fonctions permettant au Capitaine, à l'équipage et à P.O.U.B.E.L.L.E. d'interagir dans le rythme du stream.

Twitch reste l'autorité sur ce qui lui est propre : existence d'un compte, identifiant natif, pseudonyme actuel, statut de follower, abonnement, rôle de modération, utilisation d'une récompense ou résultat d'une opération Twitch. Horizon peut conserver une observation ou un état synchronisé, mais ne doit pas prétendre remplacer la valeur native lorsque Twitch demeure la source compétente.

L'interface Twitch ne constitue toutefois pas l'autorité sur l'Identité Horizon, la progression commune, la mémoire de P.O.U.B.E.L.L.E., les permissions internes ou les protocoles de La Tanière. Ces domaines restent gouvernés par le Noyau et leurs règles spécialisées.

Responsabilités respectives

Trois niveaux doivent rester distingués.

Composante	Responsabilité principale	Limite
Twitch	Produit les événements et exécute les opérations propres à son service.	Ne décide pas des règles internes d'Horizon.
Extension Twitch	Reçoit, traduit et transmet les événements ; exécute les instructions Twitch autorisées ; retourne les résultats.	Ne décide ni de la signification métier ni des conséquences à produire.
Noyau Horizon	Vérifie, déduplique, contextualise, autorise, refuse ou planifie les conséquences.	Ne présente pas une instruction comme réussie sans résultat suffisant du service externe.

L'extension ne doit pas transformer directement un événement Twitch en action métier. La réception d'un raid, par exemple, peut conduire le Noyau à enregistrer l'événement, solliciter P.O.U.B.E.L.L.E., lancer un protocole ou demander un effet audiovisuel. Ces conséquences restent indépendantes et peuvent produire des résultats différents.

Cette séparation applique le cycle de traitement défini au chapitre 8. Elle permet également de remplacer ou faire évoluer la connexion Twitch sans déplacer les règles centrales vers l'adaptateur technique.

Périmètre de la V1 et évolutivité

La V1 dessert une seule chaîne principale : celle du Capitaine. Cette limite correspond au besoin réel de La Tanière et ne doit pas introduire prématurément la complexité d'une plateforme mutualisée pour plusieurs streamers.

La chaîne doit néanmoins être configurable. Les éléments propres à son exploitation ne doivent pas être dispersés sous forme de constantes impossibles à remplacer. Cette précaution doit permettre, si Horizon fonctionne et suscite un intérêt suffisant :

• De Produire une copie autonome configurée pour une autre chaîne.
• D'Offrir ou commercialiser une version indépendante sans partager les données de La Tanière.
• D'Étudier ultérieurement une gestion multichaîne ou un service mutualisé.

Ces possibilités ne constituent ni un engagement commercial ni une exigence de la V1. Leur réalisation, leur mode de distribution, leur isolation et leur hébergement relèveront du chapitre chapitre 66 et des décisions techniques futures.

Comptes Twitch et autorité sur la chaîne

Deux identités techniques remplissent des fonctions différentes.

Compte du Capitaine

Le compte du Capitaine représente le diffuseur et conserve l'autorité native sur la chaîne. Il permet d'accorder les autorisations nécessaires à l'observation ou à l'exécution des fonctions propres au canal.

Cette autorité ne signifie pas que toutes les interventions doivent être publiées sous son identité. Elle établit qui contrôle la chaîne et qui peut autoriser Horizon à y accéder.

Compte officiel de P.O.U.B.E.L.L.E.

P.O.U.B.E.L.L.E. possède un compte Twitch distinct, déjà employé dans le système actuel. Horizon utilise ce compte pour manifester sa présence, publier ses messages et réaliser les opérations qui lui sont explicitement accessibles.

Ce compte constitue une présence officielle rattachée à l'Identité Horizon spéciale de P.O.U.B.E.L.L.E.. Il ne devient ni un compte humain ordinaire ni une source autonome de permissions. Les capacités utilisables restent définies par Horizon et limitées par les autorisations réellement accordées sur Twitch.

Les secrets, jetons, renouvellements d'autorisation et méthodes d'authentification seront précisés au chapitre 45.

Connexion directe et remplacement de Streamer.bot

Dans l'état actuel, Streamer.bot assure plusieurs fonctions liées à Twitch, à P.O.U.B.E.L.L.E. et aux automatismes du direct. Il constitue une solution existante utile, mais ses limites font partie des raisons ayant conduit à la création d'Horizon.

Dans le fonctionnement cible, l'Extension Twitch se connecte directement à Twitch. Streamer.bot ne constitue ni l'autorité, ni l'intermédiaire permanent, ni une dépendance nécessaire au fonctionnement normal d'Horizon.

Son retrait devra suivre une migration contrôlée afin d'éviter les événements traités deux fois, les commandes concurrentes ou la perte d'une fonction encore utilisée. L'inventaire de l'existant et les étapes de coexistence, de bascule et de retrait relèveront des chapitres 57 et 58.

Identification des viewers

Chaque interaction Twitch doit être rattachée en priorité à l'identifiant natif stable fourni par la plateforme, lorsqu'il est disponible. Le pseudonyme et le nom d'affichage restent utiles à l'interaction, mais ne doivent pas servir seuls de clé durable lorsqu'un identifiant plus fiable existe.

L'extension transmet au Noyau les informations nécessaires pour :

• Retrouver le compte Twitch déjà connu.
• Créer l'identité requise lorsqu'un événement éligible le justifie.
• Rattacher l'interaction à l'Identité Horizon correspondante.
• Employer le pseudonyme Twitch approprié dans l'échange public.
• Conserver l'origine Twitch de l'observation.

La réception d'un message, d'une récompense ou d'un événement pertinent peut contribuer à la création d'une identité selon les règles du chapitre 10. Cette création ne prouve pas que l'identité est revendiquée, que d'autres comptes appartiennent à la même personne ou que la personne dispose d'un rôle particulier.

Lorsqu'une liaison avec Discord ou le Poste de commande existe, elle ne doit pas être révélée dans le chat Twitch du seul fait qu'Horizon la connaît. P.O.U.B.E.L.L.E. utilise normalement le pseudonyme de la plateforme source et respecte les règles de divulgation entre interfaces.

Réception et normalisation des événements

L'Extension Twitch reçoit uniquement les catégories d'événements qu'Horizon a configurées et qu'elle est autorisée à observer. Pour chaque événement, elle doit transmettre les informations nécessaires sans en effacer la provenance.

Un événement normalisé peut notamment comporter :

• Une catégorie et un type précis.
• L'identifiant natif de l'événement, lorsqu'il existe.
• Le compte, la chaîne ou la personne concernés.
• La date fournie par Twitch et la date de réception par Horizon.
• Le contexte du direct.
• Les paramètres propres à l'événement.
• Les références permettant la déduplication et le suivi.
• Le niveau de complétude ou d'incertitude connu.

L'extension réalise les vérifications techniques relevant de son périmètre : authenticité disponible de la transmission, présence des champs indispensables, validité des formats et compatibilité avec les capacités actives. Le Noyau reste responsable de l'admissibilité fonctionnelle, du rattachement à l'état global et des conséquences éventuelles.

Catalogue fonctionnel initial

Le catalogue suivant est volontairement non définitif.

Famille	Événements ou informations concernés	Utilisation possible par le Noyau
Chat	Message public, réponse, mention, suppression ou événement comparable disponible.	Interaction, commande, statistique, contexte temporaire ou souvenir candidat.
Direct	Mise en ligne, fin du direct et changement d'état observable.	Ouverture ou clôture d'un contexte de stream.
Communauté	Follow, abonnement, réabonnement, abonnement offert et cheer.	Mise à jour d'état, annonce ou système communautaire.
Raids	Raid reçu ou raid effectué.	Historique, annonce, Protocole de Raid ou conséquence prévue.
Points de chaîne	Utilisation, accomplissement, annulation ou remboursement d'une récompense.	Soundboard, interaction ou autre module autorisé.
Fonctions d'animation	Sondage, prédiction et train de la hype.	Suivi d'état, annonce, interaction ou automatisation prévue.
Rôles et statuts	Diffuseur, Modérateur, VIP, follower, abonné ou autre statut observable.	Synchronisation d'une donnée native et évaluation des permissions applicables.
Modération	Suppression, exclusion temporaire, bannissement, levée de sanction ou autre action disponible.	Synchronisation, historique, notification ou traitement de modération.
Résultats techniques	Acceptation, refus, erreur, expiration ou résultat d'une action demandée.	Consolidation de l'état réel de la conséquence.

L'ajout ultérieur d'un type d'événement ne doit pas lui accorder automatiquement une conséquence. Il doit être décrit, relié à une finalité et intégré au cycle de traitement avant d'être utilisé.

Chat public

Tous les messages publics admissibles doivent pouvoir être transmis au Noyau. Cette couverture est nécessaire même lorsqu'un message ne vise pas directement P.O.U.B.E.L.L.E., car une interaction peut contribuer à plusieurs fonctions distinctes :

• Reconnaissance d'une participation.
• Comptage d'un message admissible.
• Traitement d'une commande.
• Compréhension temporaire du contexte du direct.
• Détection d'un souvenir candidat.
• Détection prudente d'une situation nécessitant une vérification humaine.
• Déclenchement d'un système explicitement prévu.

La réception générale du chat n'autorise pas sa conservation intégrale et illimitée. Le message peut être utilisé pendant la durée nécessaire à son traitement, alimenter une mesure ou produire un souvenir distinct lorsqu'il satisfait les règles correspondantes, puis disparaître. L'historique, les statistiques et la mémoire de P.O.U.B.E.L.L.E. conservent leurs propres critères.

Les messages échangés dans une conversation entre P.O.U.B.E.L.L.E. et un membre peuvent ainsi contribuer à sa mémoire autorisée. Les annonces, messages de diffusion et autres sorties qui ne constituent pas une conversation avec ce membre n'y contribuent pas.

Les messages techniques, les répétitions manifestes et les contenus produits par des comptes automatisés identifiés peuvent être écartés des usages pour lesquels ils ne sont pas admissibles. Un filtrage statistique ou mémoriel ne doit toutefois pas supprimer un événement nécessaire à la sécurité, à la modération ou à l'explication d'une action.

Lorsqu'une suppression de message est signalée, Horizon doit retirer le contenu des contextes temporaires encore contrôlables lorsqu'il peut identifier l'élément concerné. Les éventuelles mesures, traces ou conséquences déjà produites suivent leurs propres règles de correction et de conservation.

Commandes Twitch

Une commande Twitch est une demande structurée exprimée depuis le chat selon une syntaxe reconnue. L'extension peut détecter sa forme, isoler les paramètres utiles et transmettre la demande au Noyau. Elle ne décide pas seule :

• Si la commande existe dans ce contexte.
• Si son auteur possède les permissions nécessaires.
• Si les paramètres sont admissibles.
• Si une confirmation est requise.
• Si la conséquence reste pertinente.
• Si la réponse doit être publique ou privée.

Le chapitre peut reconnaître des commandes élémentaires liées, par exemple, à la consultation d'une information personnelle, à la progression, à l'interaction avec P.O.U.B.E.L.L.E. ou à une fonction du direct. Il ne fixe ni préfixe définitif, ni syntaxe exhaustive, ni catalogue complet.

Les commandes effectivement retenues seront documentées avec les systèmes et outils correspondants. Leur présence dans le chat ne doit jamais permettre de contourner les règles générales des actions et outils.

Présence de P.O.U.B.E.L.L.E. sur Twitch

P.O.U.B.E.L.L.E. est la même entité sur Twitch, Discord et le Poste de commande. Sur Twitch, son expression s'adapte au caractère public, immédiat et rythmé du direct sans créer une personnalité ou une mémoire séparée.

Une intervention peut notamment provenir :

• D'une mention explicite de P.O.U.B.E.L.L.E.
• D'une réponse qui lui est adressée.
• D'une commande prévue.
• D'une conversation à laquelle elle participe déjà.
• D'un événement Twitch pour lequel une réaction est configurée.
• D'une sollicitation du Noyau liée au fonctionnement du direct.
• D'une initiative autorisée relevant de ses capacités de commandant en second.

Une mention explicite doit normalement déclencher le traitement d'une réponse afin de fournir aux membres un moyen simple de l'activer. La réponse reste soumise à la disponibilité des composants nécessaires et aux protections indispensables ; un échec technique ne doit pas être déguisé en absence volontaire.

En dehors de ces sollicitations directes, le Noyau détermine la pertinence de l'intervention. P.O.U.B.E.L.L.E. ne doit pas répondre à chaque message observé ni monopoliser le chat. Les limites de fréquence doivent préserver la fluidité du direct sans empêcher une conversation légitime engagée avec elle.

La personnalisation peut mobiliser les informations autorisées de l'Identité Horizon, la mémoire pertinente et les paramètres relationnels selon le contexte LLM. Une information connue grâce à une autre interface ne devient pas pour autant publiable sur Twitch.

Participation et présence Twitch

L'Extension Twitch fournit des observations ; elle ne calcule pas seule les statistiques ou l'XP.

Une participation peut être reconnue dès qu'une identité apparaît dans un événement admissible. Un message, une commande, une récompense ou un autre événement pertinent peut ainsi prouver un passage sans établir toute la durée de présence de la personne.

Le temps de présence doit reposer sur des périodes réellement observables au moyen de signaux individuels documentés. Il reste indépendant du nombre de messages, de la fréquence d'attribution de l'XP et de la simple durée globale du direct.

L'extension doit permettre au Noyau de distinguer :

• Une présence ou une participation effectivement observée.
• Une absence établie dans un contexte où la personne était individuellement observable.
• Une période partiellement observable.
• Une période non observable, qui reste inconnue.

Une personne silencieuse ne doit pas être déclarée absente lorsque Twitch ne fournit aucun signal individuel suffisant. Les définitions, agrégations et précautions statistiques restent celles du chapitre 17. L'utilisation éventuelle de ces mesures pour la progression relève du chapitre 26.

Rôles et statuts natifs

L'extension doit transmettre les rôles et statuts Twitch réellement observables, notamment ceux de diffuseur, Modérateur, VIP, follower, abonné ou personne sanctionnée. Chaque information conserve Twitch comme source d'autorité et doit pouvoir être actualisée lorsque le service signale un changement ou qu'une vérification est réalisée.

Un statut Twitch ne doit pas être confondu avec une responsabilité générale dans Horizon. Être Modérateur de la chaîne peut ouvrir des capacités dans le périmètre Twitch, mais n'accorde pas automatiquement des droits Discord, Web ou de Super administrateur. De même, un statut communautaire Horizon ne modifie pas de lui-même les rôles natifs de Twitch.

Les correspondances de permissions seront établies dans la Partie IX. Le présent chapitre exige seulement que l'extension fournisse les observations fiables nécessaires à leur évaluation.

Actions Twitch sortantes

Une action Twitch sortante est une conséquence autorisée par le Noyau et confiée à l'Extension Twitch. Elle peut notamment concerner :

Catégorie	Exemples fonctionnels
Communication	Envoyer un message, publier une réponse ou annoncer un résultat.
Interaction	Répondre à une commande ou manifester une réaction prévue.
Chaîne	Initier une opération native autorisée, notamment un raid effectué.
Points de chaîne	Accomplir, annuler ou rembourser une récompense lorsque Twitch le permet.
Animation	Créer ou mettre à jour un sondage, une prédiction ou une fonction comparable autorisée.
Modération	Exécuter une opération limitée après vérification des permissions et confirmations applicables.

Chaque instruction doit préciser la cible, l'opération, les paramètres nécessaires et la référence du traitement. L'extension ne doit pas élargir la demande, changer de cible ou choisir une opération voisine lorsqu'elle ne peut pas exécuter celle qui a été autorisée.

Après la tentative, elle retourne un résultat exploitable. Une action peut notamment être réussie, refusée, échouée, expirée, non applicable ou incertaine. Le Noyau consolide cet état et détermine la communication éventuelle. Un message de P.O.U.B.E.L.L.E. ne doit jamais annoncer une réussite fondée uniquement sur l'envoi de l'instruction.

Raids et événements d'animation

L'extension observe les raids reçus et effectués, ainsi que les informations natives disponibles sur leur origine, leur destination et leur résultat. Elle transmet ces éléments au Noyau sans lancer elle-même le Protocole de Raid.

Lorsqu'un raid est reçu, le Noyau peut produire plusieurs conséquences indépendantes : enregistrer l'événement, préparer une annonce, solliciter P.O.U.B.E.L.L.E., déclencher le protocole prévu ou demander un effet audiovisuel. Leur définition relève du chapitre 27.

Les sondages, prédictions et trains de la hype suivent la même séparation. L'extension observe ou exécute les opérations Twitch prévues, tandis que le Noyau détermine la finalité, le contexte et les conséquences internes. Leur présence dans le catalogue initial n'impose pas que toutes leurs utilisations soient développées dès la première version opérationnelle.

Récompenses et points de chaîne

Une utilisation de récompense constitue un événement Twitch distinct de l'action qu'elle demande. L'extension transmet au Noyau l'identité disponible, la récompense concernée, les paramètres utiles, l'état natif et les références nécessaires.

Le Noyau détermine ensuite si la demande est valide, si la personne satisfait les conditions, si une substitution ou un véto s'applique et quelles conséquences doivent être produites. Lorsque Twitch le permet et que la règle le prévoit, l'extension peut recevoir l'instruction d'accomplir, d'annuler ou de rembourser la récompense.

Les règles propres aux sons, variantes de P.O.U.B.E.L.L.E., substitutions, vétos et remboursements relèvent du chapitre 28.

Modération Twitch

L'Extension Twitch remplit deux fonctions de modération distinctes : observer les actions natives disponibles et exécuter les instructions autorisées par le Noyau.

Une suppression, une exclusion temporaire, un bannissement ou une levée de sanction réalisé directement sur Twitch par le Capitaine ou un Modérateur doit être répercuté dans Horizon lorsqu'il est observable. L'événement conserve son auteur, son origine, sa cible et son résultat dans la limite des informations fournies par Twitch.

Une analyse du chat, de P.O.U.B.E.L.L.E. ou du LLM ne constitue jamais une sanction. Lorsqu'un message semble problématique sans qu'une règle déterministe suffise, le Noyau peut demander la confirmation d'un Modérateur présent. L'action ne peut être exécutée qu'après la décision humaine requise et la vérification des permissions actuelles.

La politique communautaire, les motifs, les durées, les recours et la coordination avec Discord seront définis au chapitre 29. Les actions critiques et confirmations relèveront également de la Partie IX.

Notifications et interventions privées

Certaines situations peuvent nécessiter une information ou une décision sans interrompre publiquement le direct. L'Extension Twitch peut fournir une capacité privée lorsqu'elle existe et qu'elle est appropriée, mais Horizon ne doit pas dépendre obligatoirement d'un message privé Twitch.

Le Noyau détermine le destinataire et le canal selon :

• La nature de la demande.
• Le périmètre de responsabilité.
• La présence connue de la personne.
• Les canaux privés réellement disponibles.
• La sensibilité des informations à transmettre.
• L'urgence et le besoin de confirmation.

Une demande adressée à un Modérateur présent peut donc être remise par Twitch, Discord ou le Poste de commande selon les règles applicables. L'adaptation, le choix de destination et la prévention des notifications redondantes relèvent du chapitre 25.

Relation avec OBS

Un événement Twitch peut justifier un effet sur OBS, mais les deux systèmes ne doivent jamais être reliés directement par l'Extension Twitch.

Le cycle attendu est le suivant :

1. Twitch produit un événement.
2. L'Extension Twitch le transmet au Noyau.
3. Le Noyau vérifie l'événement et détermine les conséquences autorisées.
4. Si un effet OBS est pertinent, le Noyau transmet une instruction limitée à l'extension compétente.
5. Cette extension exécute l'opération sur OBS.
6. Le résultat réel est retourné au Noyau puis consolidé séparément des autres conséquences.

La réussite d'un message Twitch ne prouve pas celle d'un effet OBS, et inversement. Un échec audiovisuel ne doit pas effacer l'événement Twitch reçu ni masquer les autres résultats du traitement.

Vue fonctionnelle de l'intégration Twitch

La figure suivante présentera la circulation des événements et des instructions entre Twitch, l'Extension Twitch et le Noyau. Elle distinguera également l'intervention de P.O.U.B.E.L.L.E., l'exécution séparée des effets OBS et le retrait de Streamer.bot dans l'architecture cible.

FIG. 18 Extension Twitch — Réception des événements, décision du Noyau et exécution séparée des actions Twitch et OBS.

Limites de fréquence, répétitions et événements tardifs

L'Extension Twitch doit respecter les limites imposées par Twitch et celles définies par Horizon. Une limitation peut s'appliquer à une catégorie d'action, à une personne, à un canal ou à une période, mais elle doit rester adaptée à la finalité concernée.

Une conversation légitime avec P.O.U.B.E.L.L.E. ne doit pas être interrompue par un plafond arbitraire identique à celui d'une annonce automatique. À l'inverse, une notification répétitive, un événement susceptible d'être reçu plusieurs fois ou une opération sensible doit disposer de protections adaptées.

Le Noyau et l'extension doivent pouvoir reconnaître, selon les informations disponibles :

• Un même événement reçu plusieurs fois.
• Une instruction déjà exécutée ou encore en cours.
• Un résultat tardif rattaché à une ancienne demande.
• Une action devenue inutile avant son exécution.
• Une nouvelle intention explicitement répétée par une personne autorisée.

Un événement tardif peut encore mettre à jour un historique ou corriger un état sans déclencher une annonce ou une conséquence devenue incohérente avec le direct en cours.

Déconnexion, indisponibilité et reprise

L'Extension Twitch doit rendre son état de disponibilité exploitable par le Noyau. Une rupture de connexion, une autorisation expirée, un refus du service ou une capacité devenue indisponible ne doit pas être dissimulé derrière un fonctionnement apparemment normal.

Lorsqu'une indisponibilité est détectée, Horizon doit autant que possible :

1. Identifier la capacité ou le flux concerné.
2. Signaler l'état aux personnes habilitées selon sa gravité.
3. Tenter une reconnexion contrôlée lorsqu'elle est appropriée.
4. Préserver les traitements encore vérifiables.
5. Marquer les périodes ou résultats devenus inconnus, partiels ou incertains.
6. Réévaluer l'utilité et les permissions avant toute reprise d'action.

Horizon ne doit pas reconstruire artificiellement les messages, événements ou présences qu'il n'a pas pu observer. Une période de déconnexion générale devient non observable pour les statistiques concernées.

Les actions sortantes en attente doivent être examinées selon leur nature :

• Une consultation ou une synchronisation répétable peut être reprise si elle reste utile.
• Une annonce devenue trop tardive doit expirer ou être abandonnée.
• Une action dont le résultat est incertain ne doit pas être répétée sans vérification lorsqu'elle pourrait produire un doublon.
• Une opération devenue non autorisée ou sans objet doit être refusée ou déclarée non applicable.

Les stratégies techniques de reconnexion, de file d'attente, de surveillance et de reprise seront précisées dans les chapitres consacrés aux intégrations externes et à la gestion des erreurs.

Données, mémoire et minimisation

L'accès au flux Twitch doit rester proportionné aux fonctions réellement utilisées. Une donnée reçue ne doit être conservée, transmise au LLM ou réutilisée pour une autre finalité que si les règles correspondantes l'autorisent.

Il convient notamment de distinguer :

• Le message temporairement nécessaire à l'interaction en cours.
• La mesure statistique issue d'une activité admissible.
• L'événement historique qui mérite une conservation propre.
• Le souvenir candidat soumis au cycle de la mémoire.
• La trace nécessaire à l'explication d'une action.
• L'état natif Twitch synchronisé pour le fonctionnement actuel.

Ces éléments peuvent provenir d'une même interaction sans former une copie durable unique du message original. Le Noyau doit sélectionner les données nécessaires à chaque finalité et appliquer les règles de visibilité correspondantes.

Garanties fonctionnelles

L'Extension Twitch doit garantir les principes suivants :

• Twitch reste l'autorité sur ses comptes, événements, statuts et résultats natifs.
• L'Extension traduit les échanges sans devenir une autorité fonctionnelle.
• Le Noyau contrôle chaque conséquence produite à partir d'un événement Twitch.
• Le compte du Capitaine et celui de P.O.U.B.E.L.L.E. conservent des fonctions distinctes.
• La V1 reste centrée sur une chaîne configurable sans imposer une architecture mutualisée.
• Streamer.bot ne constitue pas une dépendance de l'architecture cible.
• Un événement conserve son origine et les références nécessaires à son traitement.
• Un même événement ne doit pas produire plusieurs fois la même conséquence sans intention explicite.
• Tous les messages admissibles peuvent être traités sans devenir un historique intégral permanent.
• Une mention explicite permet normalement de solliciter P.O.U.B.E.L.L.E.
• Les interventions non sollicitées restent soumises à une décision de pertinence du Noyau.
• Une commande ne contourne ni les permissions ni les confirmations.
• Les statuts Twitch ne deviennent pas automatiquement des responsabilités générales Horizon.
• La participation et le temps de présence restent distincts.
• Une période non observable reste inconnue.
• Les systèmes de progression, de raid, de points de chaîne et de modération conservent leurs propres règles.
• Une action externe est exécutée par l'extension compétente après autorisation du Noyau.
• L'Extension Twitch ne pilote jamais directement OBS.
• Chaque résultat est consolidé selon ce que le service externe permet réellement d'établir.
• Une déconnexion ne provoque ni événement inventé ni répétition aveugle d'une action.

Limites du présent chapitre

Le présent chapitre ne définit pas :

• La technologie ou la bibliothèque utilisée pour se connecter à Twitch.
• Les protocoles, webhooks, événements techniques ou formats d'API.
• Les secrets, jetons et procédures détaillées de renouvellement d'autorisation.
• Le préfixe définitif et le catalogue exhaustif des commandes Twitch.
• La liste finale de tous les événements et actions Twitch pris en charge.
• Les valeurs chiffrées des limites de fréquence.
• La méthode technique définitive de mesure de la présence.
• Les formules d'XP, niveaux, grades ou promotions.
• Les états et scénarios détaillés du Protocole de Raid.
• Les règles du soundboard et des récompenses de chaîne.
• La politique de modération, les sanctions, leurs durées et leurs recours.
• La matrice complète des permissions et actions critiques.
• Les interfaces de configuration et de consultation du Poste de commande.
• Les règles de diffusion et d'adaptation entre plusieurs plateformes.
• Le plan détaillé de migration et de retrait de Streamer.bot.
• Les modalités commerciales ou techniques d'une éventuelle distribution d'Horizon à d'autres streamers.

Les interfaces Discord, Web et les communications entre plateformes seront précisées dans les chapitres 23 à 25. Les systèmes fonctionnels de La Tanière relèvent des chapitres 26 à 30, les permissions de la Partie IX, l'architecture logicielle de la Partie XI et la migration de la Partie XV.

Synthèse

L'Extension Twitch constitue l'adaptateur fonctionnel entre Twitch et le Noyau Horizon. Elle reçoit les messages, commandes, événements de chaîne, rôles, récompenses et résultats natifs, puis les transmet sans décider seule de leur signification ou de leurs conséquences. Dans l'autre sens, elle exécute uniquement les instructions Twitch autorisées et retourne leur résultat réel.

La V1 dessert une chaîne principale configurable. Le compte du Capitaine conserve l'autorité sur cette chaîne, tandis que P.O.U.B.E.L.L.E. utilise son propre compte pour intervenir dans le chat. Horizon doit se connecter directement à Twitch et remplacer progressivement Streamer.bot, sans intégrer ce dernier comme dépendance durable.

Tous les messages publics admissibles peuvent contribuer au traitement, aux statistiques, au contexte ou à la sélection d'un souvenir, mais ils ne forment pas automatiquement un historique permanent. Une mention explicite permet normalement d'activer P.O.U.B.E.L.L.E. ; ses autres interventions restent déterminées par le Noyau selon la situation.

Les événements Twitch alimentent les systèmes de progression, de raid, de points de chaîne et de modération sans en contenir les règles. Une conséquence OBS reste séparée : le Noyau l'autorise et la transmet à l'extension compétente, tandis que l'Extension Twitch ne communique jamais directement avec OBS.

Enfin, toute indisponibilité doit rester visible. Horizon distingue les événements confirmés, les résultats incertains et les périodes non observables, puis ne reprend que les opérations encore utiles, autorisées et suffisamment sûres pour éviter les doublons.