Communications multiplateformes

Horizon doit pouvoir informer une personne, solliciter un responsable ou publier une annonce sur Twitch, Discord et le Poste de commande sans transformer chaque destination en communication indépendante. Une montée de niveau peut ainsi apparaître sur plusieurs interfaces tout en restant la manifestation d'un même fait, avec une formulation adaptée à chaque espace et un résultat de remise suivi séparément.

Cette continuité ne signifie ni qu'un texte identique doit être copié partout ni que toute information doit être diffusée sur chaque plateforme. Le Noyau détermine la finalité, les destinataires, les données divulgables et les destinations autorisées. Chaque interface reçoit seulement la manifestation qui correspond à son contexte, à ses contraintes et aux préférences applicables.

Le présent chapitre définit l'unité fonctionnelle d'une communication Horizon, ses catégories, la sélection des destinataires, l'adaptation par interface, les préférences de notification, la prévention des doublons et le traitement des remises partielles ou tardives. Les catalogues détaillés de notifications, les permissions et les paramètres techniques seront définis dans leurs référentiels spécialisés.

Fonctionnement cible — Principes validés

Une communication Horizon possède un sens commun et peut produire plusieurs manifestations adaptées à Twitch, Discord et au Poste de commande. Ces manifestations conservent la même origine et la même finalité, mais leur langue, leur longueur, leur forme et leur niveau de détail peuvent varier.

Le Poste de commande constitue le centre de référence des notifications personnelles. Discord est le canal privé complémentaire privilégié. Twitch reste un canal contextuel, notamment pendant une conversation ou un direct, et ses messages sont toujours limités à 500 caractères par Horizon.

Le Noyau choisit les destinataires et autorise chaque destination. Le LLM peut être sollicité plusieurs fois pour préparer les variantes, mais il ne décide ni de la diffusion, ni des données divulguées, ni du résultat d'une remise.

Synthèse normative

• Une communication Horizon doit conserver une origine, une finalité, des destinataires, une importance, une sensibilité et un état communs.
• Chaque destination doit disposer d'une manifestation distincte rattachée à cette communication.
• Une adaptation ne doit modifier ni le fait annoncé, ni l'état réel, ni l'action demandée, ni les restrictions applicables.
• Les communications personnelles, communautaires, opérationnelles et conversationnelles doivent rester distinguées.
• Le Noyau doit déterminer les destinataires, les destinations, les données divulgables et les confirmations requises.
• Le LLM ne doit choisir librement ni un destinataire ni un canal.
• Le Poste de commande doit constituer le centre de référence des notifications personnelles.
• Une notification personnelle ordinaire doit être conservée dans le Poste de commande et peut être remise sur un canal privé autorisé.
• Une notification personnelle urgente doit pouvoir être remise dans le Poste de commande et sur le canal privé immédiatement disponible le plus adapté.
• Discord doit constituer le canal privé complémentaire privilégié.
• Un canal privé Twitch doit rester contextuel et exceptionnel.
• Horizon ne doit prévoir ni courriel, ni SMS, ni notification mobile native dans le périmètre actuel.
• Une réponse doit revenir par défaut sur l'interface d'origine lorsque celle-ci reste appropriée.
• Un canal public devenu inadapté doit pouvoir orienter la personne vers une réponse privée sans en révéler le contenu.
• Les préférences doivent pouvoir être définies par catégorie de communication et par canal.
• Les périodes de tranquillité doivent être configurables pour différer les communications non urgentes.
• Certaines communications obligatoires doivent rester accessibles dans le Poste de commande même lorsque leur copie externe est désactivée.
• La langue d'une communication doit être déterminée par le destinataire, l'échange, l'espace ou l'auteur selon le contexte applicable.
• Une manifestation Twitch ne doit jamais dépasser 500 caractères, plafond permanent propre à Horizon.
• Un message Twitch peut être bref ou développé selon la situation dans la limite de ce plafond.
• Discord et le Web doivent pouvoir recevoir des formulations plus développées et structurées.
• Une fonction doit pouvoir solliciter plusieurs fois le LLM afin de produire des variantes adaptées à chaque plateforme.
• Chaque variante générée doit être vérifiée séparément par le Noyau avant sa diffusion.
• Une communication essentielle prévue doit disposer d'une formulation déterministe lorsque le LLM est indisponible.
• Une annonce ordinaire définie par une règle validée doit pouvoir être diffusée automatiquement.
• Une annonce exceptionnelle, sensible ou à grande échelle doit être créée ou confirmée par un Administrateur habilité ou le Capitaine.
• Une donnée privée ne doit pas devenir publique parce qu'une annonce est automatique.
• Une annonce Discord doit utiliser le nom visible sur Discord ; le tag ne doit être ajouté que lorsque la visibilité du compte et la finalité le permettent.
• Le tag Discord ne doit être utilisé que lorsque la visibilité du compte Discord et la finalité de la communication le permettent.
• Une communication publique doit pouvoir être redirigée vers un canal privé sans élargir son contenu.
• Une communication privée ne doit jamais devenir publique sans autorisation explicite.
• Un doublon doit être reconnu à partir de l'origine, de la finalité, du destinataire et de l'occurrence fonctionnelle, et non du seul texte.
• Une lecture enregistrée dans le Poste de commande doit actualiser l'état fonctionnel commun de la notification.
• Une remise ou un tag Discord ne doit pas constituer une preuve de lecture.
• Une lecture obligatoire doit pouvoir être confirmée par une réaction Discord prévue ou par un bouton du Poste de commande.
• Une confirmation de lecture ne doit valoir ni acceptation d'un règlement, ni autorisation d'action, ni reconnaissance d'une faute.
• Plusieurs notifications ordinaires proches doivent pouvoir être regroupées sans fusionner des décisions sensibles distinctes.
• Un rappel doit rester rattaché à la communication initiale.
• Chaque destination doit conserver son propre résultat de remise.
• Le résultat global doit employer les issues du chapitre 8 et distinguer notamment la réussite complète, la réussite partielle, le refus global, l'échec global, la non-applicabilité, l'annulation, l'expiration et l'incertitude.
• Un résultat inconnu ne doit pas provoquer le renvoi immédiat et aveugle d'une même communication.
• Une communication doit pouvoir porter une durée de pertinence ou une condition d'expiration.
• Une confirmation doit pouvoir être accomplie depuis une autre interface autorisée et clôturer les manifestations liées.
• Une communication adressée par un responsable doit pouvoir viser une liste de personnes ou un groupe autorisé.
• Le responsable doit choisir entre une remise privée individuelle et une publication dans un espace commun.
• Une personne appartenant à plusieurs groupes ciblés ne doit recevoir qu'une occurrence de la même communication.
• Les responsabilités des destinataires doivent être vérifiées au moment de chaque remise.
• Le renvoi d'une communication destinée à un groupe doit réévaluer les appartenances et permissions actuelles.
• Une confirmation de lecture collective doit être enregistrée séparément pour chaque personne.
• Une communication modifiée après sa diffusion doit produire un erratum et, si sa lecture est obligatoire, une nouvelle demande de confirmation.
• Une communication expirée ne doit plus attendre de validation, de confirmation ou d'action.

Finalité et périmètre du chapitre

Le chapitre répond à la question suivante :

Comment Horizon peut-il produire une communication cohérente sur plusieurs interfaces, l'adapter à chaque contexte et suivre sa remise sans multiplier les messages, les divulgations ou les décisions ?

Il poursuit plusieurs objectifs :

• Définir une unité commune de communication.
• Distinguer les familles dont les règles de diffusion diffèrent.
• Sélectionner les destinataires et les destinations selon le contexte réel.
• Respecter les préférences sans masquer les communications obligatoires.
• Adapter la langue, la longueur et la présentation à chaque interface.
• Encadrer l'utilisation du LLM et prévoir un fonctionnement déterministe.
• Préserver la confidentialité lors d'un changement de canal.
• Éviter les doublons, regroupements trompeurs et rappels devenus inutiles.
• Suivre séparément chaque remise et consolider le résultat global.
• Organiser les lectures obligatoires et les confirmations accessibles depuis plusieurs interfaces.

Le chapitre ne définit pas le contenu exhaustif des annonces, les valeurs de délai et d'expiration, les limites de tentatives, les permissions détaillées de chaque rôle ou les protocoles techniques de remise. Il fournit le modèle fonctionnel auquel ces décisions devront se rattacher.

Communication commune et manifestations

Une communication Horizon représente l'information ou la demande que la Plateforme doit transmettre. Elle constitue une conséquence possible du cycle de traitement et n'est pas limitée à un texte. Elle doit pouvoir conserver :

• Une référence stable.
• L'événement, la décision ou le traitement qui l'a produite.
• Sa Finalité.
• Son Auteur ou sa fonction productrice.
• Les destinataires visés.
• Son Importance et son éventuelle urgence.
• Sa Sensibilité et les limites de divulgation.
• Les actions ou confirmations associées.
• Sa Date de création et sa durée de pertinence.
• Les manifestations prévues et leur résultat.

Chaque version destinée à Twitch, Discord ou au Poste de commande constitue une manifestation de cette communication. Une manifestation peut employer un texte, une notification structurée, un bouton, une réaction demandée ou une autre forme permise par l'interface.

Les manifestations restent liées à la même communication même lorsque leurs formulations diffèrent. Cette relation permet de comprendre qu'un message Discord et une carte du Poste de commande annoncent le même succès, de consolider leur lecture et d'empêcher une remise répétée de produire un nouveau fait.

Une communication reste également distincte de l'événement qui la justifie. Un gain de niveau peut produire une annonce publique, une notification personnelle et une actualisation Web. Ces conséquences ont la même cause sans se confondre avec le gain lui-même.

Quatre familles de communications

Horizon reconnaît quatre familles générales, en cohérence avec les catégories d'actions et outils.

Famille	Finalité	Exemples
Communication personnelle	Informer une personne d'un fait, d'un résultat ou d'une action qui la concerne.	Succès, changement de compte, réponse à une demande ou avertissement personnel.
Communication communautaire	Informer un groupe ou un espace public selon une règle commune.	Montée de niveau publiable, nouveau grade, événement de La Tanière ou annonce générale.
Communication opérationnelle	Demander une intervention, une confirmation ou l'examen d'une situation.	Erreur importante, conflit, diagnostic, signalement ou action critique.
Communication conversationnelle	Permettre à P.O.U.B.E.L.L.E. ou à une fonction autorisée de répondre dans un échange.	Réponse Twitch, conversation Discord privée ou échange depuis le Poste de commande.

Une communication peut relever de plusieurs dimensions sans perdre sa finalité principale. Une anomalie peut, par exemple, produire une communication opérationnelle pour un Super administrateur et une communication personnelle séparée pour la personne affectée. Chacune doit recevoir uniquement les informations nécessaires à son destinataire.

Sélection des destinataires et des destinations

Le Noyau détermine les destinataires et les destinations en tenant compte :

• De la famille et de la finalité de la communication.
• De la personne, du groupe ou de l'espace concerné.
• Des responsabilités et permissions actuelles.
• De la sensibilité des informations.
• Des préférences de notification.
• De la présence connue et des canaux disponibles.
• De l'Urgence, de la durée de pertinence et du besoin de confirmation.
• De l'État des remises déjà tentées.

Le LLM peut proposer une formulation, mais il ne choisit pas librement la personne à contacter ni le canal sur lequel la joindre. Cette séparation applique les règles du chapitre 21.

Stratégie générale par famille

Une notification personnelle ordinaire est enregistrée dans le Poste de commande. Elle peut également être remise sur le canal privé choisi par la personne lorsque sa catégorie et sa sensibilité le permettent.

Une notification personnelle urgente est enregistrée dans le Poste de commande et peut être envoyée sur le canal privé immédiatement disponible le plus adapté. Discord constitue le canal complémentaire privilégié. Une capacité privée Twitch reste exceptionnelle et dépend du contexte réel.

Une annonce communautaire est publiée uniquement dans les espaces explicitement prévus par sa règle ou par la décision qui l'autorise. Sa présence sur une plateforme ne rend pas automatique sa diffusion sur les autres.

Une communication opérationnelle est toujours consultable dans l'espace Web du responsable habilité. Un canal privé complémentaire peut être utilisé lorsqu'une intervention rapide est nécessaire.

Interface d'origine et redirection

Lorsqu'une communication répond à une conversation ou à une demande, elle revient par défaut sur l'interface d'origine. Cette continuité respecte les contextes propres à Twitch, Discord et au Poste de commande.

Le canal d'origine peut néanmoins devenir inadapté en raison de la confidentialité, de la longueur, d'une confirmation structurée ou d'une indisponibilité. Horizon peut alors :

• Fournir une réponse privée sur Discord.
• Ouvrir ou signaler une notification dans le Poste de commande.
• Indiquer publiquement qu'une suite privée est disponible, sans révéler son contenu.
• Employer une autre destination déjà autorisée par la personne et compatible avec la communication.

Le changement de canal ne doit jamais devenir un moyen d'élargir la divulgation. Une information privée ne peut pas être publiée parce que son canal initial est indisponible.

Le périmètre actuel ne prévoit ni courriel, ni SMS, ni notification mobile native. Une communication sans destination externe disponible reste conservée dans le Poste de commande lorsqu'elle doit encore être remise ou consultée.

Préférences de notification

Une personne peut définir ses préférences de notification selon la catégorie de communication et le canal. Elle peut, par exemple, recevoir ses succès sur Discord tout en limitant les informations administratives au Poste de commande.

Des regroupements de paramètres peuvent être proposés pour conserver une configuration compréhensible. Ils ne doivent pas masquer la portée des catégories importantes ni activer implicitement un canal sensible.

Les préférences influencent les manifestations supplémentaires ; elles ne suppriment pas les communications qui doivent rester accessibles dans le centre Web. Les catégories obligatoirement conservées comprennent initialement :

• Les changements de sécurité ou d'accès.
• Les opérations sur l'identité et les comptes liés.
• Les mises à jour du règlement nécessitant une acceptation.
• Les confirmations demandées.
• Les résultats d'actions sensibles.
• Les sanctions ou décisions devant être communiquées.
• Les réponses aux demandes d'accès, de correction ou d'effacement.

La personne peut désactiver une copie externe lorsque la règle le permet, mais elle ne peut pas faire disparaître du Poste de commande une information que la Plateforme doit lui rendre accessible.

Périodes de tranquillité

Des périodes de tranquillité configurables permettent de différer les notifications non urgentes. La communication reste créée à sa date réelle et sa remise ultérieure ne doit pas la présenter comme un nouvel événement.

Une catégorie explicitement urgente peut dépasser cette période lorsque le retard créerait un risque, ferait expirer une décision ou empêcherait une intervention nécessaire. Les horaires, catégories et exceptions seront définis ultérieurement comme valeurs configurables.

Langue de la communication

La langue est déterminée selon l'origine et la forme de la communication :

1. Une annonce rédigée par un membre du personnel conserve la langue dans laquelle elle a été rédigée.
2. Un message produit par le Noyau dans un salon ou un espace global emploie la langue définie pour l'annonce.
3. Un message privé produit par le Noyau suit la langue de la conversation.
4. Une conversation avec P.O.U.B.E.L.L.E. suit la langue de l'échange en cours, sauf demande contraire.
5. Une communication adressée individuellement à plusieurs personnes peut produire des variantes lorsque la règle qui l'autorise le prévoit.

L'adaptation linguistique ne doit pas altérer les faits, les conséquences ou la force de la formulation. Une obligation ne devient pas une suggestion et un résultat incertain ne devient pas une réussite lors de la traduction.

Adaptation à chaque interface

Les manifestations peuvent adapter leur longueur, leur ton, leur structure et leur niveau de détail selon les capacités définies pour l'Extension Twitch, l'Extension Discord et le Poste de commande Web.

Twitch

Une communication Twitch tient compte du rythme du direct et du caractère souvent public du chat. Elle peut être brève pour une notification immédiate, mais un message plus développé reste possible dans une conversation ou pour certaines annonces.

Horizon applique dans tous les cas un plafond permanent de 500 caractères par message Twitch. Ce plafond constitue une exigence fonctionnelle propre à Horizon, indépendamment d'une éventuelle évolution de la capacité technique de Twitch.

Lorsqu'une communication ne peut pas être correctement formulée dans cette limite, Horizon peut la répartir en plusieurs messages uniquement si le contexte autorise une séquence lisible et non intrusive. Dans les autres cas, il fournit une indication courte et redirige vers Discord ou le Poste de commande.

Discord

Discord permet des messages plus développés, des annonces dans des salons configurés, des échanges privés et des interactions structurées. La manifestation doit respecter le contexte de l'espace, les règles communautaires et la visibilité du compte Discord du destinataire.

Poste de commande

Le Poste de commande fournit la manifestation la plus structurée. Il peut présenter l'état réel, les détails autorisés, les autres remises, une échéance et les actions ou confirmations disponibles. Il constitue le centre de référence des notifications personnelles sans devenir l'autorité sur le fait annoncé.

Éléments invariants

Une adaptation ne peut pas modifier :

• Le fait annoncé.
• La personne, le groupe ou la situation concernés.
• L'état réel du traitement.
• Les conséquences et restrictions applicables.
• L'action demandée.
• L'échéance.
• Le niveau de confidentialité.
• L'origine et la relation avec le traitement.

La longueur, le ton, le vocabulaire, la mise en forme et les détails secondaires peuvent varier tant que ces invariants restent compréhensibles et exacts.

Utilisation du LLM

Une fonction peut solliciter plusieurs fois le LLM pour produire une formulation adaptée à chaque plateforme, chaque langue ou certains destinataires. Une version Twitch n'est donc pas obligatoirement une réduction mécanique du message Discord, et la version Web peut fournir une présentation plus structurée. Chaque sollicitation reste soumise au rôle limité du LLM et aux règles de construction du contexte.

Chaque sollicitation reçoit uniquement le contexte nécessaire à sa manifestation. Le Noyau vérifie séparément :

• La destination et le destinataire.
• Les données utilisées et divulguées.
• Le respect des invariants.
• La langue et la longueur.
• La compatibilité avec l'espace public ou privé.
• Les instructions, liens et actions proposés.

Une variante refusée ne rend pas les autres variantes invalides lorsqu'elles sont indépendantes et autorisées. Leur résultat commun reste alors partiel jusqu'à la décision applicable.

Fonctionnement sans LLM

Les communications essentielles prévues doivent disposer d'une formulation déterministe. Une montée de niveau, un succès, une confirmation requise, une erreur ou un résultat important ne doivent pas disparaître parce que le LLM est indisponible.

Le modèle déterministe conserve les mêmes faits, destinations et protections. Il peut être moins personnalisé, mais doit rester compréhensible et adapté aux limites de l'interface.

Annonces automatiques et exceptionnelles

Une règle validée peut produire automatiquement des annonces ordinaires, notamment pour :

• Une montée de niveau.
• Un nouveau grade.
• Un badge ou un succès.
• Un événement communautaire prévu.
• Une étape déterministe d'un système de La Tanière.

L'automatisation ne supprime aucun contrôle. Le Noyau vérifie que l'événement est établi, que l'annonce reste pertinente, que les destinations sont configurées et que les informations peuvent y être divulguées. Les règles produisant les niveaux, grades et succès seront précisées dans le système de progression.

Une annonce exceptionnelle, sensible ou à grande échelle est créée ou confirmée par un Administrateur habilité, un Super administrateur ou le Capitaine selon son périmètre. La confirmation porte sur le contenu ou l'intention, les destinataires, les destinations et la portée de la diffusion.

Visibilité des annonces Discord

La visibilité de l'événement annoncé et celle du compte Discord sont deux décisions distinctes conformément au catalogue des données et à leurs règles d'autorité et de visibilité.

Lorsqu'un niveau, un grade, un badge ou un succès peut être publié, une annonce Discord peut être produite. Elle emploie le nom visible de la personne sur Discord. Si le compte Discord est public et que la finalité le justifie, la manifestation peut également employer son tag Discord.

Si le compte Discord est privé, l'annonce n'ajoute pas de tag ni de lien vers le compte. L'emploi du nom visible sur Discord reste propre à cette plateforme et ne doit pas être remplacé par le nom d'affichage Horizon ni servir à révéler une liaison avec un autre compte.

Si l'événement lui-même est privé, aucune annonce publique nominative n'est produite. La personne peut néanmoins recevoir une notification privée selon ses préférences, et retrouver l'information dans le Poste de commande.

L'absence de tag ne suffit donc pas à rendre une annonce admissible. Le contenu annoncé doit lui-même pouvoir être publié.

Communications privées et publiques

Une communication autorisée pour un espace public peut être redirigée vers un canal privé si son contenu n'est pas élargi. Une version privée peut également contenir davantage de détails uniquement lorsqu'une autorisation distincte permet de les divulguer au destinataire.

Une communication privée ne doit jamais devenir publique sans décision explicite. L'échec d'un message privé, l'absence de la personne ou l'urgence ne permettent pas de révéler publiquement son contenu. La permission de lire une donnée reste distincte de celle de la divulguer, selon le modèle de permissions et sa future classification.

Une indication publique peut seulement signaler qu'une information privée attend la personne, lorsque cette indication ne révèle pas elle-même un fait protégé.

Communications de P.O.U.B.E.L.L.E.

P.O.U.B.E.L.L.E. reste la même entité sur Twitch, Discord et le Poste de commande. Ses différentes manifestations ne constituent pas plusieurs interventions relationnelles indépendantes lorsqu'elles portent la même communication.

Une annonce publiée sur trois interfaces est donc conservée comme une intervention commune dotée de trois remises. Elle ne doit pas augmenter artificiellement le nombre d'interactions, créer un souvenir ni modifier plusieurs fois la relation avec une personne. Les annonces, embeds et autres messages de diffusion ne rejoignent pas la mémoire conversationnelle de P.O.U.B.E.L.L.E.

À l'inverse, les messages d'une conversation entre P.O.U.B.E.L.L.E. et un membre peuvent contribuer à sa mémoire autorisée, qu'ils soient échangés dans le chat Twitch ou dans un salon Discord configuré à cette fin. Cette possibilité reste soumise aux règles du chapitre 16 et ne transforme pas les autres messages du canal en mémoire personnelle.

La forme peut néanmoins évoluer : immédiate et contextuelle sur Twitch, communautaire ou privée sur Discord, personnelle ou structurée dans le Poste de commande. P.O.U.B.E.L.L.E. ne choisit ni d'étendre la diffusion ni de révéler une donnée supplémentaire pour rendre une variante plus naturelle.

Sélection manuelle des destinataires

Un Modérateur, un Administrateur Twitch ou Discord, un Super administrateur ou le Capitaine peut, selon les responsabilités définies au chapitre 5 et ses permissions, adresser une communication à :

• Une liste de personnes sélectionnées par leur nom.
• Les visiteurs.
• Les Membres d'équipage.
• Les Modérateurs Twitch.
• Les Modérateurs Discord.
• Les Administrateurs habilités.
• Les Super administrateurs.
• L'équipage complet.

L'auteur choisit également le mode de diffusion :

• Remise privée individuelle : chaque destinataire reçoit une manifestation personnelle sans connaître les autres destinataires.
• Publication commune : un message est publié dans un espace autorisé destiné au groupe.

Les groupes sont résolus selon les appartenances et responsabilités actuelles au moment de la remise. Une personne appartenant à plusieurs groupes ciblés ne reçoit qu'une occurrence de la même communication. Lors d'un renvoi, le groupe et les permissions sont de nouveau évalués : seules les personnes alors admissibles reçoivent cette nouvelle remise.

La sélection d'un groupe ne donne pas à l'auteur une permission générale sur ses membres. Le Noyau vérifie que l'auteur peut contacter ce groupe, utiliser les données incluses et choisir les destinations demandées.

Déduplication

Deux manifestations sont considérées comme appartenant à la même communication lorsqu'elles partagent la même origine fonctionnelle, la même finalité, le même destinataire et la même occurrence, même si leur texte diffère. Cette corrélation applique les règles de prévention des doubles conséquences des chapitres 8 et 14.

Horizon doit notamment prévenir :

• La création de plusieurs notifications à partir de la réception répétée d'un même événement.
• La remise multiple provoquée par l'appartenance d'une personne à plusieurs groupes ciblés.
• La réémission d'une annonce après un résultat incertain non vérifié.
• La création d'une nouvelle interaction relationnelle pour chaque variante de P.O.U.B.E.L.L.E.
• La répétition d'une conséquence commune à plusieurs branches d'un même traitement.

La déduplication ne doit pas supprimer deux communications réellement distinctes. Deux confirmations portant sur des actions différentes restent séparées même si elles utilisent un texte voisin.

Regroupement et rappels

Plusieurs notifications ordinaires proches peuvent être regroupées lorsqu'elles concernent la même situation, le même destinataire et une finalité compatible. Le regroupement doit conserver le nombre d'éléments, leur période et les actions encore nécessaires.

Ne doivent pas être fusionnés d'une manière qui masquerait leur portée :

• Deux Confirmations distinctes.
• Deux Sanctions ou décisions sensibles.
• Deux Erreurs indépendantes exigeant des traitements différents.
• Des communications dont les échéances ou destinataires diffèrent.

Un rappel reste rattaché à la communication initiale. Il possède sa propre tentative de remise, mais ne crée ni nouvelle décision ni nouvel événement métier. Les rappels cessent lorsque l'action est accomplie, refusée, annulée ou expirée.

Remise, lecture et acquittement

La remise, la lecture et l'action sont trois états distincts.

État	Signification
Remise établie	La destination a accepté ou présenté la manifestation selon un résultat suffisant.
Lecture connue	La personne a ouvert ou acquitté la notification par un moyen observable prévu.
Lecture à confirmer	La communication exige une action explicite confirmant sa prise de connaissance.
Action accomplie	La demande ou décision associée a été exécutée ou traitée séparément.

Un message accepté par Discord ou accompagné d'un tag ne prouve pas sa lecture. Une notification ouverte dans le Poste de commande peut actualiser son état fonctionnel commun, même si Discord ne permet pas de modifier rétroactivement l'apparence du message déjà publié.

Lecture obligatoire

Lorsqu'une lecture doit être confirmée, la manifestation propose :

• Une réaction Discord déterminée et attribuable au destinataire.
• Un bouton de confirmation dans le Poste de commande.

La confirmation vaut uniquement pour la personne qui utilise la réaction ou le bouton après vérification de son identité. Pour une communication adressée à un groupe, chaque destinataire conserve donc son propre état de lecture. La première confirmation d'une personne clôt seulement ses manifestations liées ; elle signifie uniquement que cette personne déclare avoir reçu et pris connaissance de la communication.

Cette confirmation ne vaut ni acceptation d'un règlement, ni autorisation d'une action, ni reconnaissance d'une faute, ni renonciation à un droit. Les actions nécessitant une confirmation suivent le parcours distinct du chapitre 34.

En l'absence de réaction ou d'appui sur le bouton, la communication reste dans l'état lecture à confirmer. L'absence de réponse ne constitue ni un refus ni une acceptation. Des rappels peuvent être produits selon une politique configurable, et une absence prolongée peut être signalée au responsable prévu sans déclencher automatiquement une sanction.

Lorsqu'une règle particulière conditionne un accès, comme l'acceptation du règlement Horizon, cette règle applique sa propre restriction indépendamment de la confirmation de lecture.

Si le contenu d'une communication déjà diffusée est modifié, Horizon publie un erratum rattaché à la communication initiale. Lorsque la lecture est obligatoire, cet erratum ouvre une nouvelle demande de confirmation pour chaque destinataire concerné ; l'acquittement de l'ancienne version ne vaut pas lecture de la version corrigée.

Résultats par destination

Chaque manifestation conserve son résultat propre, conformément à la séparation des conséquences et de leurs résultats définie au chapitre 8. Une communication peut ainsi être remise dans le Poste de commande, échouer sur Discord et ne pas être prévue sur Twitch.

Les manifestations emploient le vocabulaire des conséquences du chapitre 8 :

• Prévue, lorsqu'elle appartient au plan sans être encore autorisée ou exécutée.
• En attente, lorsqu'une condition, une ressource ou une dépendance est attendue.
• En cours, lorsque la remise a commencé sans résultat final établi.
• Réussie, lorsque la remise est suffisamment établie.
• Refusée, lorsque le Noyau, une personne habilitée ou la destination a explicitement refusé la remise.
• Échouée, lorsque la remise attendue n'a pas été obtenue.
• Abandonnée, lorsque sa poursuite n'a plus de raison valable.
• Non applicable, lorsqu'elle n'est plus utile ou que ses conditions ne sont pas réunies.
• Annulée, lorsqu'une autorité habilitée l'a explicitement interrompue.
• Expirée, lorsque sa durée de validité est dépassée.
• Incertaine, lorsque le résultat réel de la remise ne peut pas être suffisamment établi.

Une destination non demandée n'est pas une manifestation échouée : aucune conséquence de remise n'y a été planifiée. La preuve technique de remise, de lecture ou d'acquittement reste conservée séparément de cet état général lorsqu'elle est nécessaire.

Le résultat global est consolidé à partir des destinations nécessaires :

Résultat global	Signification
Réussite complète	Toutes les remises requises sont suffisamment établies.
Réussite partielle	Au moins une remise requise a réussi et une autre a atteint un résultat terminal différent ou reste incertaine.
Refus global	Les remises requises ont été explicitement refusées sans réussite suffisante.
Échec global	Aucune destination requise n'a permis d'obtenir le résultat nécessaire et l'échec est établi.
Situation non applicable	Aucune remise requise ne demeure applicable à la situation.
Annulation	La communication a été explicitement annulée avant l'obtention du résultat attendu.
Expiration	La communication a dépassé sa durée de validité avant sa conclusion normale.
Situation incertaine	L'incertitude restante empêche de conclure suffisamment.

Une destination facultative non utilisée n'empêche pas la réussite. À l'inverse, la réussite d'une copie secondaire ne suffit pas si la destination nécessaire à une confirmation ou à une obligation n'a pas reçu la communication.

Échecs, reprises et destinations de repli

Un échec établi peut conduire à une nouvelle tentative bornée lorsque la communication reste pertinente et que l'indisponibilité paraît temporaire. Les nombres de tentatives et les délais seront définis avec la gestion des erreurs.

Après ces tentatives, le Noyau peut employer un canal privé de repli lorsque l'importance le justifie, que la personne l'autorise et que la confidentialité est préservée. Le Poste de commande conserve dans tous les cas l'état de référence des notifications personnelles.

Lorsque le résultat d'un envoi est inconnu, Horizon ne doit pas renvoyer immédiatement le même message. Il tente d'abord d'établir le résultat ou emploie les moyens de corrélation et de déduplication disponibles. Une destination différente peut être utilisée uniquement si elle ne produit pas une répétition trompeuse ou une divulgation supplémentaire.

Chaque erreur reste rattachée à sa destination. Cette séparation permet de déterminer si l'échec provient de Twitch, de Discord, du Poste de commande, de la formulation ou d'une règle Horizon.

Pertinence et expiration

Une communication peut posséder une durée de pertinence, une échéance ou une condition d'expiration. Les valeurs seront déterminées ultérieurement selon sa catégorie.

Lorsqu'une communication expire avant sa remise :

• Elle n'est pas diffusée tardivement comme si elle était encore actuelle.
• Son état indique qu'elle a expiré avant remise.
• Son historique peut rester consultable selon sa finalité et sa conservation.
• Les rappels et confirmations associés cessent.
• Elle n'attend plus aucune validation, confirmation ou action.
• Une nouvelle situation doit produire une nouvelle communication plutôt que réactiver silencieusement l'ancienne.

Une notification remise après une période de tranquillité conserve la date de l'événement d'origine et ne doit être envoyée que si elle reste pertinente.

Confirmation depuis une autre interface

Une demande présentée sur Discord peut être confirmée depuis le Poste de commande, et une demande Web peut être accomplie depuis une autre interface autorisée lorsque celle-ci fournit les garanties nécessaires. Cette continuité ne remplace pas les contrôles du cycle de traitement ni ceux des actions critiques.

Le Noyau vérifie alors :

• L'Identité de la personne.
• Ses Permissions actuelles.
• La référence de la communication et de l'action.
• La concordance du contexte présenté.
• La validité temporelle de la demande.
• L'absence d'une décision déjà enregistrée.

La première décision valide clôt les autres manifestations de la même demande. Une réaction ou un bouton tardif ne doit pas produire une seconde exécution.

Représentation fonctionnelle

La figure suivante présente la création d'une communication commune, son adaptation pour chaque interface et la consolidation des résultats de remise.

FIG. 20 Communications multiplateformes — Création d'une communication commune, adaptation par interface et suivi des résultats de remise.

Garanties fonctionnelles

Les communications multiplateformes doivent garantir les principes suivants :

• Une communication commune peut posséder plusieurs manifestations sans devenir plusieurs faits.
• Chaque manifestation reste adaptée et contrôlée pour sa destination.
• Le Noyau conserve l'autorité sur les destinataires, les données et la diffusion.
• Le LLM formule sans décider ni exécuter directement.
• Les communications essentielles restent possibles sans LLM.
• Le Poste de commande conserve le centre de référence des notifications personnelles.
• Les préférences et périodes de tranquillité sont respectées sans supprimer les informations obligatoires.
• La limite permanente de 500 caractères est respectée pour chaque message Twitch.
• La langue et le format peuvent varier sans altérer le sens ou le statut du message.
• La visibilité d'un événement et celle du compte Discord restent distinctes ; le nom employé sur Discord reste le nom visible sur Discord.
• Un changement de canal n'élargit jamais automatiquement la divulgation.
• Les annonces automatiques restent limitées aux règles et données publiables.
• Les annonces exceptionnelles conservent une décision humaine adaptée.
• Les groupes sont résolus selon les responsabilités actuelles et leurs chevauchements sont dédupliqués.
• Les remises privées ne révèlent pas la liste des autres destinataires.
• Les regroupements ne masquent ni décision sensible ni confirmation distincte.
• La remise, la lecture, l'acquittement et l'action restent séparés.
• Une confirmation de lecture ne remplace aucune autre décision et ne vaut que pour la personne qui l'effectue.
• Chaque destination conserve son résultat réel.
• Un échec partiel reste visible et localisable.
• Une incertitude ne provoque ni réussite inventée ni répétition aveugle.
• Une communication expirée n'est pas diffusée comme si elle était encore actuelle.
• Une décision prise sur une interface clôt les manifestations liées sans produire de nouvelle exécution.

Limites du présent chapitre

Le présent chapitre ne définit pas :

• Le catalogue exhaustif des communications et notifications.
• Les valeurs finales des périodes de tranquillité, délais, rappels et expirations.
• Le nombre de tentatives et les stratégies techniques de reprise propres à chaque service.
• Les formats d'API, identifiants techniques et protocoles de corrélation.
• La matrice complète des permissions de communication et de divulgation.
• La classification détaillée de chaque contenu.
• Les règles métier produisant les niveaux, grades, succès, sanctions ou autres annonces.
• Les modèles de texte définitifs.
• La conception détaillée du centre de notifications Web.
• Les fonctions futures de courriel, SMS ou notification mobile native.
• Les règles de conservation détaillées des communications et preuves de lecture.

Les événements et conséquences suivent les chapitres 8 et 9. Les données et leur autorité relèvent des chapitres 13 et 14.

Les communications de P.O.U.B.E.L.L.E. restent soumises aux chapitres 18 à 21. Les possibilités propres aux interfaces sont définies aux chapitres 22, 23 et 24. Les permissions, la sensibilité et la vie privée seront précisées dans la Partie IX, puis les erreurs et la reprise dans la Partie XII.

Synthèse

Une communication Horizon constitue une unité commune pouvant produire plusieurs manifestations adaptées à Twitch, Discord et au Poste de commande. Le fait, la finalité, les destinataires, la confidentialité et l'état réel restent invariants, tandis que la langue, la longueur et la présentation peuvent évoluer selon le canal.

Le Poste de commande demeure le centre de référence des notifications personnelles. Discord constitue le canal privé complémentaire privilégié, tandis que Twitch reste contextuel et respecte un plafond Horizon permanent de 500 caractères par message. Le périmètre actuel n'intègre ni courriel, ni SMS, ni notification mobile native.

Le LLM peut être sollicité plusieurs fois afin de préparer les variantes, mais le Noyau contrôle chacune d'elles. Les annonces essentielles disposent d'une formulation déterministe lorsque le modèle est indisponible. Les annonces ordinaires prévues peuvent être automatiques ; les communications exceptionnelles ou sensibles sont créées ou confirmées par une personne habilitée.

La visibilité de l'événement reste distincte de celle du compte Discord. Une annonce publiable emploie sur Discord le nom visible sur Discord et n'ajoute un tag que lorsque la visibilité du compte et la finalité le permettent, tandis qu'un événement privé ne produit aucune annonce publique nominative.

Enfin, Horizon déduplique les destinataires et les occurrences, regroupe seulement les notifications compatibles, rattache les rappels à leur communication initiale et distingue la remise de la lecture ou de l'action. Chaque destination conserve son résultat, permettant d'identifier précisément les réussites, échecs et incertitudes sans transformer une réussite partielle en succès général.