Cycle de traitement d'un événement

Le Noyau Horizon reçoit des informations provenant de plusieurs interfaces, services et fonctions internes. Une même information peut nécessiter une simple mise à jour, déclencher plusieurs conséquences, attendre une confirmation humaine ou être refusée sans produire d'action. Le Noyau doit donc appliquer un cycle commun permettant de comprendre l'origine de l'événement, de vérifier son contexte et d'établir ce qui a réellement été exécuté.

Le présent chapitre décrit ce parcours fonctionnel depuis la réception ou la production d'un événement jusqu'à la consolidation de ses résultats. Il complète les responsabilités définies au chapitre 7, sans définir encore la structure détaillée de l'état global Horizon ni les catégories précises d'événements, qui relèvent du chapitre 9.

Il ne fixe pas davantage le format technique des messages, le choix d'une file de traitement, les transactions, les protocoles de communication ou les délais d'expiration exacts. Ces éléments seront définis dans les parties consacrées à l'architecture technique, aux intégrations externes et à la robustesse.

Fonctionnement cible — Principes validés

Tout événement susceptible d'influencer une donnée, une règle, une permission, une décision, une action ou l'état connu d'Horizon doit être rattaché à un traitement contrôlé par le Noyau.

Un événement ne provoque jamais directement une action. Le Noyau en vérifie l'origine, le contexte, la pertinence, les permissions et les risques, puis produit uniquement les conséquences nécessaires et autorisées. Une conséquence n'est considérée comme réussie que lorsque son résultat est suffisamment établi.

Chaque traitement et chacune de ses conséquences doivent rester identifiables afin d'empêcher les doubles exécutions, de distinguer les réussites des échecs et d'expliquer les décisions prises.

Synthèse normative

• Tout événement fonctionnel est rattaché à un traitement identifiable contrôlé par le Noyau.
• Une interaction possède un événement d'origine ; les décisions, résultats, échéances et changements d'état peuvent produire des événements dérivés reliés causalement.
• Une conséquence devenue inutile, interdite, abandonnée ou non applicable n'est pas exécutée.
• L'état du traitement global reste distinct de l'état et du résultat de chacune de ses conséquences.
• Une instruction transmise ne constitue pas la preuve de son exécution, et un résultat incertain ne doit être présenté ni comme une réussite ni comme un échec certain.
• Une reprise automatique n'est autorisée que lorsque l'absence d'exécution est établie ou que la répétition ne peut produire aucun effet indésirable supplémentaire.

Événement, traitement et conséquence

Le cycle repose sur trois notions complémentaires :

• Un événement décrit une occurrence contextualisée, par exemple un fait observé, une demande, une décision, un résultat, une transition d'état, une échéance, une anomalie ou une correction.
• Un traitement désigne le parcours contrôlé par le Noyau pour interpréter cet événement et déterminer la réponse appropriée.
• Une conséquence représente un effet particulier que le traitement envisage, autorise, refuse ou tente d'obtenir.

Un événement ne doit donc pas être confondu avec l'action qu'il peut provoquer. L'arrivée d'un raid Twitch constitue un événement, l'enregistrement de ce raid, le lancement d'un protocole, l'envoi d'un message ou la modification d'une scène OBS constituent des conséquences distinctes. Chacune peut posséder ses propres conditions, dépendances, permissions et résultats.

De la même manière, une demande ne garantit pas qu'une conséquence sera produite. Elle peut être invalide, sans objet, non autorisée, devenue inutile ou impossible à exécuter. Le rôle du Noyau consiste précisément à transformer une information reçue en décision maîtrisée, et non à traduire automatiquement chaque demande en action.

Le chapitre 9 définira les catégories d'événements et leurs relations avec l'état global. Le présent chapitre utilise le terme dans un sens fonctionnel suffisamment large pour décrire leur parcours commun.

Origines possibles d'un événement

Un événement peut provenir de différentes origines sans changer les principes généraux de son traitement. Il peut notamment être :

• Reçu de Twitch, Discord, OBS ou d'un autre service relié par l'intermédiaire d'une extension Horizon.
• Produit à partir d'une action réalisée dans le Poste de commande Web.
• Issu d'une demande de P.O.U.B.E.L.L.E. transmise au Noyau.
• Créé par une règle, une tâche planifiée ou une fonction de supervision du Noyau.
• Produit par le résultat, l'échec ou l'expiration d'un traitement précédent.
• Déclenché par une confirmation, un refus, une annulation ou une intervention humaine.
• Établi à partir d'une différence détectée entre plusieurs représentations d'un même état.

L'origine doit toujours rester identifiable. Un événement produit par une fonction interne n'est pas dépourvu d'origine : il est rattaché à la fonction, à la règle, à la tâche planifiée ou au traitement qui l'a produit. De même, une demande de P.O.U.B.E.L.L.E. conserve P.O.U.B.E.L.L.E. comme entité demandeuse, même si le Noyau reste l'autorité qui décide des conséquences.

La confiance accordée à une origine ne dispense jamais des autres contrôles. Un événement produit par une composante interne peut être obsolète, répété ou incompatible avec l'état actuel. Une personne authentifiée peut demander une action située hors de son périmètre et un service externe reconnu peut transmettre une information invalide ou incomplète.

Vue générale du cycle

Le cycle fonctionnel comprend les étapes générales suivantes. Certaines peuvent être très rapides, regroupées ou sans objet pour un traitement particulier, mais aucune décision importante ne doit échapper aux contrôles qu'elles représentent.

Étape	Finalité générale	Résultat attendu
1. Réception ou production	Recevoir l'événement externe ou créer un événement produit par une fonction interne.	Une information est prise en charge par le Noyau.
2. Identification du traitement	Attribuer une référence unique et rattacher l'événement à son origine.	Le traitement peut être suivi sans être confondu avec un autre.
3. Validation	Vérifier la provenance, l'intégrité, la structure et le caractère exploitable de l'information.	L'événement est accepté, refusé ou isolé pour vérification.
4. Détection des répétitions	Rechercher si l'événement ou ses effets ont déjà été traités.	Une répétition ne produit pas involontairement les mêmes conséquences.
5. Construction du contexte	Identifier les acteurs, l'identité Horizon, l'état utile et les relations avec d'autres traitements.	Le Noyau dispose du contexte nécessaire et autorisé.
6. Contrôles	Appliquer les règles, permissions, classifications et niveaux de risque.	Les possibilités autorisées et interdites sont établies.
7. Planification des conséquences	Déterminer les effets nécessaires, leurs dépendances et leurs conditions.	Un plan limité aux conséquences pertinentes est produit.
8. Confirmation éventuelle	Suspendre les opérations qui nécessitent une décision humaine explicite.	Le traitement est confirmé, refusé, annulé ou expiré.
9. Exécution	Réaliser les conséquences internes et transmettre les instructions externes autorisées.	Chaque conséquence reçoit un état d'exécution individuel.
10. Consolidation	Interpréter les résultats, erreurs, refus et absences de réponse.	Le résultat réellement établi est distingué de l'intention initiale.
11. Mise à jour et propagation	Mettre à jour l'état d'Horizon et produire les suites encore pertinentes.	Les informations et interfaces concernées reflètent le résultat établi.
12. Finalisation et traçabilité	Clore ou suspendre le traitement en conservant les traces nécessaires.	Le parcours et ses résultats peuvent être expliqués et supervisés.

Ce cycle ne constitue pas nécessairement une chaîne strictement linéaire. Un contrôle peut conduire à rechercher une information supplémentaire, une confirmation peut provoquer une nouvelle vérification, et un résultat externe peut produire un nouvel événement. Ces reprises doivent conserver le lien avec le traitement d'origine au lieu de créer des opérations impossibles à rattacher entre elles.

Schéma du cycle fonctionnel

Le schéma suivant présente le parcours principal d'un événement et ses branches de décision. Il distingue notamment le refus, l'attente d'une confirmation, l'exécution de plusieurs conséquences et la consolidation de résultats pouvant être complets, partiels ou incertains.

Il représente un cycle fonctionnel et non une architecture logicielle. Les blocs ne préjugent donc ni du nombre de services techniques ni de la manière dont les informations seront transportées entre eux.

FIG. 06 Figure fonctionnelle — Cycle d'un événement Horizon, décisions du Noyau et suivi individuel des conséquences jusqu'à l'établissement de leurs résultats.

Création et identification du traitement

Dès qu'un événement fonctionnel est accepté pour examen, le Noyau doit créer ou retrouver un traitement identifiable. Cette identification permet de suivre toutes les étapes, de rattacher plusieurs conséquences à une même origine et de distinguer une reprise légitime d'une répétition accidentelle.

Sans imposer encore de format technique, le traitement doit pouvoir conserver au minimum :

• Un identifiant propre au traitement.
• La référence de l'événement d'origine lorsqu'elle existe.
• La source technique et l'acteur demandeur éventuel.
• Le moment auquel l'événement a été produit, observé et reçu, lorsque ces informations sont disponibles.
• Le contexte fonctionnel initial.
• Le traitement parent ou les traitements liés.
• Les conséquences produites et leur propre identification.
• L'état courant du traitement.
• Les décisions, confirmations, résultats et erreurs importants.

Un nouvel événement peut être lié à un traitement existant sans être confondu avec lui. Le résultat retourné par Discord après une demande d'attribution de rôle constitue, par exemple, une nouvelle information, mais il doit rester rattaché à la conséquence et au traitement qui ont provoqué cette demande.

La structure exacte des identifiants, des références et des relations sera définie lors de la conception du modèle des événements et de l'architecture technique.

Réception, validation et normalisation

La réception ne suffit pas à rendre un événement exploitable. Le Noyau doit d'abord vérifier les éléments nécessaires à son interprétation et à sa sécurité.

Selon l'origine et la nature de l'information, cette validation peut notamment porter sur :

• L'identité du service ou de la composante qui transmet l'événement.
• L'authenticité de la transmission lorsque celle-ci peut être vérifiée.
• La présence des informations indispensables.
• La validité des valeurs, références et formats attendus.
• La cohérence entre l'auteur déclaré, le compte utilisé et le contexte observé.
• L'ancienneté de l'événement et sa pertinence pour l'état actuel.
• L'absence d'instruction ou de donnée située hors du périmètre autorisé de la source.

La normalisation permet ensuite de représenter l'information dans un cadre compréhensible par le Noyau sans effacer sa provenance. Un rôle Discord et un statut Twitch peuvent tous deux contribuer à déterminer une capacité, mais l'événement normalisé doit conserver le service qui fait autorité pour l'information native.

Un événement invalide ne doit pas être corrigé silencieusement pour produire malgré tout l'action attendue. Il peut être refusé, ignoré lorsqu'il est manifestement sans effet, isolé pour vérification ou transformé en signalement. Les événements invalides présentant un enjeu de sécurité ou une répétition anormale doivent rester traçables selon des modalités adaptées à leur sensibilité.

Détection des répétitions

Un même événement peut être transmis plusieurs fois en raison d'une reprise, d'une reconnexion, d'un délai de réponse ou du comportement normal d'un service externe. Le Noyau doit donc rechercher si l'information a déjà été prise en charge et, surtout, si les conséquences correspondantes ont déjà été exécutées.

La détection peut s'appuyer sur une référence fournie par la source, sur l'identification du traitement, sur les caractéristiques de l'événement ou sur d'autres éléments permettant d'établir qu'il s'agit de la même occurrence. Les mécanismes techniques exacts dépendront des intégrations concernées.

La réception répétée d'un événement peut être ajoutée aux traces ou actualiser certaines informations de suivi. Elle ne doit pas créer automatiquement un nouveau gain d'expérience, un second remboursement, une nouvelle attribution de rôle ou un nouvel envoi de la même annonce.

Deux événements proches ne doivent toutefois pas être fusionnés uniquement parce qu'ils se ressemblent. La détection des répétitions doit préserver les occurrences réellement distinctes et signaler les situations pour lesquelles la certitude demeure insuffisante.

Construction du contexte

Le contexte réunit uniquement les informations nécessaires pour comprendre l'événement et décider de ses conséquences. Il peut notamment comprendre :

• L'acteur, le compte externe ou la fonction interne à l'origine du traitement.
• L'identité Horizon éventuellement reconnue.
• Le statut, les responsabilités et les permissions pertinentes.
• L'interface et l'environnement concernés.
• L'état actuel de la cible.
• Les événements ou traitements liés.
• Les règles applicables.
• Les informations nécessaires à l'évaluation du risque.
• Les capacités actuellement disponibles ou indisponibles.

La construction du contexte doit respecter la minimisation des données et le moindre privilège. Le fait qu'une information soit techniquement accessible au Noyau ne signifie pas qu'elle doit être utilisée pour tous les traitements, transmise à une extension ou intégrée au contexte d'un modèle LLM.

Le Service LLM Horizon peut être sollicité lorsqu'une compréhension linguistique ou une formulation est nécessaire. Le Noyau identifie alors le cas fonctionnel, autorise la finalité et le périmètre, puis sélectionne les sources, les données et les restrictions applicables. Le Service LLM assemble ces éléments dans le modèle de prompt actif, dialogue avec le modèle et vérifie la conformité technique et formelle du résultat avant de le restituer au Noyau. Le résultat obtenu reste une contribution au traitement et non une décision faisant autorité. Ces mécanismes seront détaillés au chapitre 20.

Identification des acteurs et vérification des permissions

Le Noyau doit déterminer qui demande l'action, pour quel périmètre et au titre de quelle capacité. La vérification ne peut pas se limiter à l'affichage proposé par l'interface ou à une permission qui était valide lors d'un traitement précédent.

Elle doit notamment prendre en compte :

• L'identité effectivement rattachée à la session, au compte ou à la composante technique.
• L'origine et la validité actuelle de chaque responsabilité utilisée.
• Le contexte Twitch, Discord, Web ou Horizon dans lequel la capacité s'applique.
• La cible de l'opération.
• La nature précise de la lecture, de l'utilisation, de la modification ou de la divulgation demandée.
• Les restrictions propres au service qui exécutera éventuellement l'action.

Un acteur non reconnu peut encore être à l'origine d'un événement public ou d'un traitement ne nécessitant pas d'identification personnelle. Cette absence d'identité ne doit cependant pas lui permettre d'accéder à une fonction protégée. Le comportement applicable dépend de la finalité du traitement et non de la seule capacité technique à recevoir l'événement.

P.O.U.B.E.L.L.E. utilise ses capacités propres et finalisées. Elle ne reçoit pas le rôle humain d'un Super administrateur, ne transforme pas une demande en autorisation et ne confirme pas une action critique. Les permissions détaillées seront définies au chapitre 32.

Classification des données et du risque

Avant de produire ou d'autoriser une conséquence, le Noyau doit évaluer la sensibilité des informations concernées et le niveau de risque de l'opération envisagée.

Cette évaluation détermine notamment :

• Les informations pouvant être consultées pour prendre la décision.
• Les éléments pouvant être transmis à une extension, à P.O.U.B.E.L.L.E. ou au service LLM.
• Les traces pouvant être conservées et les personnes pouvant les consulter.
• La nécessité d'une confirmation humaine.
• L'autorité requise pour modifier la donnée.
• Le comportement à adopter en cas d'échec ou d'incertitude.

La classification ne doit pas être déduite uniquement de l'action demandée. Une opération apparemment simple peut devenir sensible en raison de sa cible, de son contexte, des informations qu'elle révèle ou de ses conséquences cumulées.

Les classes de données et les critères détaillés seront établis au chapitre 33. Le présent cycle impose seulement que cette évaluation intervienne avant toute utilisation ou transmission qui en dépend.

Construction du plan de traitement

Après les contrôles nécessaires, l'orchestrateur peut construire un plan décrivant les conséquences envisagées. Ce plan doit être limité à ce qui est utile pour atteindre le résultat autorisé.

Pour chaque conséquence, le Noyau doit pouvoir déterminer :

• Son objectif et son rattachement à l'événement d'origine.
• La règle ou la décision qui la justifie.
• Sa cible et l'autorité qui détient l'état concerné.
• Les données strictement nécessaires à son exécution.
• Les permissions et confirmations requises.
• Ses préconditions.
• Ses dépendances envers d'autres conséquences.
• La manière dont son résultat pourra être établi.
• Le comportement prévu en cas de refus, d'échec ou d'incertitude.

Une conséquence autorisée n'est pas nécessairement utile. Si son objectif est déjà atteint, si sa cible n'existe plus, si une autre conséquence la rend sans objet ou si son exécution ne produit plus d'effet pertinent, elle doit être écartée ou marquée comme non applicable. Horizon ne doit pas multiplier les opérations au seul motif qu'elles figuraient dans le plan initial.

Le plan n'accorde aucune autorité supplémentaire aux extensions. Il décrit ce que le Noyau pourra leur demander dans un contexte précis. Chaque instruction transmise doit rester limitée à la conséquence correspondante.

Plusieurs conséquences et ordre d'exécution

Un événement unique peut produire plusieurs conséquences indépendantes ou liées. Le Noyau doit conserver leur origine commune tout en suivant chacune séparément.

Les conséquences indépendantes peuvent être exécutées séparément ou simultanément lorsque cela ne crée ni incohérence ni risque supplémentaire. Les conséquences dépendantes doivent respecter l'ordre imposé par leurs préconditions.

Le Noyau doit notamment éviter :

• D'annoncer comme acquis un résultat qui n'a pas encore été établi.
• De déclencher une conséquence devenue inutile après l'échec d'une étape préalable.
• D'exécuter plusieurs fois une conséquence commune à plusieurs branches.
• De transmettre à une extension des instructions dépassant la partie du plan qui la concerne.
• De considérer la réussite d'une conséquence comme preuve de la réussite des autres.

Le plan peut être réévalué pendant le traitement. Une conséquence initialement prévue peut devenir non applicable, tandis qu'un échec peut produire une notification ou une demande d'intervention qui n'était pas nécessaire dans le parcours nominal. Toute modification importante du plan doit rester explicable et rattachée au même traitement.

Suspension et confirmation humaine

Lorsqu'une conséquence nécessite une confirmation humaine, le Noyau doit suspendre son exécution avant qu'elle ne produise l'effet critique. Les autres conséquences véritablement indépendantes peuvent continuer uniquement si leur exécution ne réduit pas la liberté de décision de la personne et ne révèle pas prématurément une information sensible.

La demande de confirmation doit présenter de manière compréhensible :

• L'action envisagée.
• Sa cible.
• Sa portée et ses principales conséquences.
• L'origine de la demande.
• Les informations importantes permettant de prendre la décision.
• La durée pendant laquelle la confirmation reste valable.

Une confirmation doit être liée au traitement, à la conséquence, à la personne habilitée et au contexte présenté. Elle ne peut pas être réutilisée pour une autre opération ou considérée comme une autorisation permanente.

Au moment de la confirmation, le Noyau doit vérifier de nouveau l'identité, les permissions, l'état de la cible, les préconditions et la pertinence de l'action. Si le contexte a changé de manière significative, la confirmation précédente doit expirer ou être refusée, puis une nouvelle décision adaptée peut être demandée.

L'absence de réponse pendant la durée prévue entraîne l'expiration de la demande. P.O.U.B.E.L.L.E., le service LLM et le modèle sollicité peuvent préparer ou expliquer une action, mais ils ne peuvent pas fournir la confirmation humaine qui l'autorise. Les niveaux de risque et les mécanismes détaillés seront définis au chapitre 34.

Décisions possibles avant l'exécution

Les contrôles, confirmations et évolutions du contexte peuvent conduire aux décisions ou conclusions générales suivantes :

Décision	Signification fonctionnelle
Autoriser	La conséquence est pertinente, permise et prête à être exécutée selon le plan établi.
Suspendre	Une information, une confirmation ou une condition encore attendue empêche temporairement l'exécution.
Refuser	Une règle, une permission, un risque ou une contrainte interdit l'exécution.
Abandonner	Le traitement n'a plus de raison valable de poursuivre la conséquence.
Annuler	Une personne habilitée ou un système autorisé interrompt explicitement la conséquence avant son résultat final.
Déclarer expirée	La durée de validité de la conséquence ou de la confirmation nécessaire est dépassée.
Déclarer non applicable	La conséquence est sans objet dans le contexte réellement établi.

Un refus, un abandon, une annulation, une expiration et une absence d'exécution ne sont pas équivalents. Le refus exprime une interdiction ou un contrôle négatif. L'abandon constate que la poursuite n'est plus justifiée. L'annulation résulte d'une décision explicite. L'expiration résulte de la fin d'une durée de validité. Le caractère non applicable indique que les conditions fonctionnelles de la conséquence ne sont pas réunies. Cette distinction facilite l'explication du traitement et évite de présenter toute absence d'action comme une erreur.

Exécution des conséquences internes

Une conséquence interne est réalisée dans le périmètre d'autorité d'Horizon. Elle peut, par exemple, calculer une valeur déterministe, mettre à jour une donnée native de la Plateforme, créer une demande de notification ou préparer un nouvel événement.

Son exécution doit respecter les mêmes règles que les actions externes : permissions, classification, préconditions, pertinence, prévention des répétitions et traçabilité. Le fait qu'une fonction appartienne au Noyau ne l'autorise pas à modifier librement toute donnée accessible.

Les calculs et valeurs faisant autorité doivent reposer sur des règles déterministes ou sur une décision humaine autorisée. Une proposition du modèle LLM ne devient pas une valeur officielle simplement parce qu'elle a été produite au cours du traitement.

Lorsqu'une conséquence interne modifie plusieurs informations liées, le Noyau doit éviter de présenter un état intermédiaire comme un résultat final cohérent. Les mécanismes techniques permettant de garantir cette cohérence seront définis avec le modèle de données et l'architecture cible.

Transmission aux extensions et exécution externe

Lorsqu'une conséquence concerne Twitch, Discord, OBS ou un autre service, le Noyau transmet une instruction limitée à l'extension compétente. Cette instruction doit contenir uniquement les informations nécessaires à l'opération autorisée et conserver la référence permettant de rattacher le résultat au traitement.

L'extension :

• Traduit l'instruction dans le langage ou le protocole du service.
• Utilise uniquement les capacités techniques qui lui ont été accordées.
• Transmet la demande au service concerné.
• Collecte le résultat disponible.
• Retourne au Noyau un état exploitable sans décider seule de la signification fonctionnelle finale.

Le service externe conserve l'autorité sur l'exécution native. Le Noyau peut demander un changement de scène à OBS, l'attribution d'un rôle à Discord ou l'envoi d'un message à Twitch, mais il ne doit pas déclarer cette action réussie sur la seule base de l'instruction transmise.

Une extension ne doit pas élargir une demande, choisir une autre cible ou réutiliser les données reçues pour une finalité différente. Si l'opération demandée n'est pas possible avec les capacités disponibles, elle retourne un refus ou un échec au Noyau au lieu de rechercher un contournement.

Consolidation des résultats

Chaque conséquence doit posséder un état distinct. Le Noyau consolide ensuite ces états afin de déterminer le résultat général du traitement sans masquer les différences entre les branches.

État d'une conséquence	Interprétation générale
Prévue	La conséquence appartient au plan, mais n'a pas encore été autorisée ou exécutée.
En attente	Une condition, une confirmation, une ressource ou une dépendance est attendue.
En cours	L'exécution a commencé, mais aucun résultat final n'est encore établi.
Réussie	Le résultat attendu est suffisamment confirmé.
Refusée	Le Noyau, une personne habilitée ou le service cible a explicitement refusé l'opération.
Échouée	Le résultat attendu n'a pas été obtenu, y compris lorsque l'opération a été exécutée mais a produit un résultat invalide, incomplet ou inutilisable.
Abandonnée	Le Noyau a établi que la poursuite de la conséquence n'avait plus de raison valable.
Non applicable	L'opération n'était plus utile ou ses conditions n'étaient pas réunies.
Annulée	Une personne habilitée ou un système autorisé a interrompu explicitement l'opération.
Expirée	La durée de validité de l'opération, de son contexte ou de la confirmation nécessaire est dépassée.
Incertaine	Le Noyau ne peut pas établir avec une confiance suffisante si l'opération a été exécutée.

L'état Échouée décrit l'absence du résultat attendu. Il ne suffit pas, à lui seul, à établir si l'opération n'a jamais commencé, a été interrompue, a été exécutée partiellement ou a produit un résultat invalide. Ce qui est connu de l'exécution réelle doit donc être conservé séparément lorsque cette distinction influence une reprise, une correction ou une explication.

État du traitement global

Le traitement possède son propre cycle d'état. Cet état est dérivé de sa progression générale et ne remplace jamais les états individuels de ses conséquences.

État du traitement	Signification fonctionnelle
Actif	Le traitement est en cours d'analyse, de contrôle, de planification ou d'exécution.
En attente	Une information, une confirmation, une ressource ou une échéance empêche temporairement sa poursuite.
Partiellement terminé	Certaines conséquences ont atteint un état terminal, tandis que d'autres restent actives ou en attente.
Terminé	Toutes les conséquences pertinentes ont atteint un état terminal et le résultat global peut être établi.
Abandonné	Le Noyau a établi que le traitement n'avait plus de raison valable de se poursuivre.
Expiré	La durée de validité du traitement ou de son contexte est dépassée avant sa conclusion normale.
Intervention nécessaire	Le traitement ne peut pas être conclu ou poursuivi de manière sûre sans intervention d'une personne disposant de la capacité requise.

Lorsqu'un traitement est terminé, son résultat global peut être une réussite complète, une réussite partielle, un refus global, un échec global, une situation non applicable, une annulation, une expiration ou une situation incertaine. L'état En attente n'est pas un résultat final. Le résultat global fournit une synthèse ; il ne doit pas masquer les résultats individuels dont dépend sa compréhension.

Une absence de réponse ne doit pas être assimilée automatiquement à un échec, car le service peut avoir exécuté l'action sans retourner la confirmation attendue. Elle ne doit pas davantage être assimilée à une réussite. Lorsque l'état réel ne peut pas être vérifié, la conséquence doit rester incertaine jusqu'à l'obtention d'un élément suffisant ou à une intervention adaptée.

Échecs partiels et interventions administratives

Lorsqu'un traitement produit plusieurs conséquences, la réussite de certaines d'entre elles doit être conservée même si une autre échoue. Horizon ne doit pas appliquer un retour arrière général susceptible de supprimer ou de contredire des effets déjà établis.

Une action compensatoire peut être prévue lorsqu'elle possède un sens fonctionnel clair et qu'elle est explicitement autorisée. Elle constitue alors une nouvelle conséquence identifiable, soumise à ses propres contrôles. Elle ne doit pas être confondue avec l'effacement silencieux d'un résultat antérieur.

Lorsqu'un échec, une incertitude ou une incohérence nécessite une intervention, le Noyau doit produire une demande d'intervention dont la gravité, la finalité et les données déterminent les personnes autorisées à la consulter. Les Super administrateurs Horizon et le Capitaine disposent du périmètre général attendu pour les interventions sur la Plateforme, sans que l'étiquette d'un rôle remplace la vérification de la capacité précise.

Cette notification doit fournir, selon les permissions et la sensibilité applicables :

• L'identification du traitement et de l'événement d'origine.
• La conséquence concernée.
• Le résultat attendu.
• Le résultat, l'erreur ou l'incertitude observés.
• Les conséquences déjà réussies.
• L'incidence possible sur l'état d'Horizon ou d'un service externe.
• Les vérifications déjà effectuées.
• L'intervention ou la correction éventuellement nécessaire.

La notification ne doit pas exposer davantage d'informations que ne l'exige la résolution du problème. Elle constitue elle-même une conséquence traçable ; son éventuel échec d'envoi est enregistré comme une anomalie distincte et ne doit pas masquer l'anomalie initiale.

Reprise et prévention des doubles exécutions

Le Noyau peut reprendre automatiquement une conséquence uniquement lorsqu'il peut établir que la première tentative n'a pas été exécutée ou que la répétition ne produira aucun effet supplémentaire indésirable.

Avant une reprise, il doit notamment vérifier :

• L'état connu de la tentative précédente.
• La possibilité de demander au service cible son état réel.
• Le caractère répétable ou non de l'opération.
• L'existence d'une référence permettant au service ou à l'extension de reconnaître la même demande.
• L'évolution des permissions, du contexte et des préconditions.
• La persistance de l'utilité de la conséquence.

Un traitement ancien ne doit pas reprendre une action devenue inutile uniquement parce que la ressource est de nouveau disponible. La pertinence doit être réévaluée au moment de la reprise.

Lorsque l'exécution précédente demeure incertaine et que la répétition pourrait produire un doublon, le Noyau suspend la reprise automatique. Il peut rechercher une preuve supplémentaire, demander une vérification ou notifier les responsables habilités. Il ne doit pas choisir arbitrairement entre considérer l'action comme réussie et la répéter.

Les politiques de temporisation, le nombre de tentatives et les stratégies propres à chaque intégration seront définis aux chapitres 45 et 47.

Mise à jour de l'état

Le Noyau met à jour l'état d'Horizon à partir des résultats suffisamment établis. Une intention, une instruction envoyée ou une réponse générée par un modèle ne constitue pas, à elle seule, la preuve qu'un changement a eu lieu.

Pour une donnée native d'Horizon, la modification peut être établie lorsque le traitement interne autorisé est effectivement terminé. Pour une donnée ou une action relevant d'un service externe, le Noyau doit utiliser les éléments retournés par l'extension, une lecture de vérification ou un autre mécanisme prévu pour déterminer l'état réellement appliqué.

Les situations en attente ou incertaines doivent rester distinguées de l'état confirmé. Horizon peut conserver qu'une modification a été demandée sans présenter cette modification comme accomplie.

Une mise à jour peut produire de nouveaux événements, par exemple lorsqu'un changement de niveau entraîne une réévaluation du grade. Ces événements restent liés au traitement précédent, mais suivent leur propre cycle afin que leurs règles et leurs résultats demeurent identifiables.

Chaque événement dérivé doit conserver un lien de causalité avec l'événement ou le résultat qui l'a produit et un lien de corrélation avec le traitement fonctionnel commun. Avant de planifier une nouvelle conséquence, le Noyau vérifie que l'événement dérivé ne reproduit pas une chaîne déjà traitée. Une synchronisation ne doit notamment pas relancer indéfiniment la même synchronisation lorsqu'un service externe retourne l'observation attendue.

La structure de l'état global Horizon et les relations entre événements sont développées au chapitre 9. Les conventions techniques des identifiants de causalité, de corrélation et de prévention des boucles seront précisées dans les chapitres techniques et l'Annexe R. Le rattachement, l'autorité, la priorité et la cohérence des données sont définis donnée par donnée au chapitre 14.

Propagation des résultats

La propagation consiste à rendre un résultat disponible ou à produire une conséquence sur les interfaces concernées. Elle ne doit pas être automatique pour toutes les connexions d'une personne.

Le Noyau doit tenir compte :

• De la finalité du traitement.
• Des comptes et interfaces effectivement reliés.
• Du contexte dans lequel l'événement s'est produit.
• Des préférences et permissions applicables.
• De la sensibilité de l'information.
• De l'utilité réelle de la propagation.
• De l'état confirmé, partiel ou incertain du résultat.

Une information peut être enregistrée dans l'état d'Horizon sans devoir être annoncée sur Twitch ou Discord. Inversement, un message peut être transmis sans donner à son destinataire l'accès à l'ensemble des données ayant permis de le produire.

Une conséquence de propagation devenue inutile ne doit pas être exécutée. Le Noyau doit également éviter d'annoncer une réussite complète lorsqu'une partie importante du traitement a échoué ou demeure incertaine.

Traçabilité du traitement

La traçabilité doit permettre de reconstituer les décisions importantes sans transformer les journaux en copie illimitée de toutes les données manipulées.

Selon la nature du traitement, les traces doivent permettre d'identifier :

• L'événement et son origine.
• Les acteurs et identités fonctionnellement impliqués.
• Les contrôles réalisés.
• Les règles et permissions ayant déterminé la décision.
• Les données faisant autorité qui ont été utilisées.
• Le plan de conséquences et ses évolutions.
• Les confirmations demandées, accordées, refusées ou expirées.
• Les instructions transmises.
• Les résultats, reprises, erreurs et incertitudes.
• Les modifications d'état établies.
• Les notifications ou interventions administratives produites.

Les traces doivent respecter la classification des données, la minimisation, les durées de conservation et les permissions de consultation. Une donnée sensible ne doit pas être reproduite intégralement dans un journal si une référence, une catégorie ou une information expurgée suffit à expliquer le traitement.

La trace d'exécution ne remplace ni l'historique fonctionnel ni la mémoire de P.O.U.B.E.L.L.E. Ces finalités seront distinguées aux chapitres 15, 16 et 48.

Service LLM et mode dégradé

Le Service LLM Horizon n'est pas une étape obligatoire du cycle. Il peut contribuer à comprendre une formulation, assembler le contexte sélectionné et autorisé par le Noyau, préparer une intention structurée ou rédiger une réponse. Les contrôles, calculs, décisions et valeurs faisant autorité restent déterministes ou humains selon les règles applicables.

Si le modèle LLM local défini selon les principes du chapitre 19 devient indisponible, le Noyau doit poursuivre les traitements qui n'en dépendent pas. Il peut employer une réponse préparée, différer une formulation, signaler l'indisponibilité ou renoncer à une conséquence devenue impossible. Il ne doit pas inventer le résultat du modèle ni assouplir les permissions pour maintenir artificiellement une fonction.

L'indisponibilité d'un service externe suit le même principe général. Le Noyau peut suspendre, différer ou refuser les conséquences concernées tout en poursuivant les branches indépendantes. Il ne doit jamais présenter comme exécutée une action dont le résultat n'est pas suffisamment établi.

Exemple fonctionnel simplifié

L'exemple suivant illustre le cycle sans définir le fonctionnement détaillé du Protocole de Raid.

1. Twitch signale un raid à l'extension Horizon compétente.
2. Le Noyau crée un traitement, valide l'origine et recherche une éventuelle répétition.
3. Il identifie la chaîne, le raid, les informations disponibles et l'état actuel d'un éventuel protocole.
4. Les règles déterminent les conséquences pertinentes, par exemple enregistrer le raid, préparer une intervention de P.O.U.B.E.L.L.E. et demander une modification audiovisuelle.
5. Une conséquence devenue inutile, comme le lancement d'un second protocole incompatible avec celui déjà actif, est écartée ou remplacée par le comportement prévu.
6. Les conséquences indépendantes autorisées sont transmises aux extensions concernées.
7. Le message Twitch réussit, mais OBS ne confirme pas le changement demandé.
8. Le Noyau conserve la réussite du message, marque la conséquence OBS comme incertaine ou échouée selon les informations disponibles et ne déclare pas le traitement entièrement réussi.
9. Si une intervention est nécessaire, une demande est ajoutée au suivi administratif et une notification adaptée à sa gravité est produite avec le contexte utile.
10. L'état, les résultats et les traces sont mis à jour sans répéter les conséquences déjà établies.

Cet exemple montre qu'un événement commun peut produire plusieurs branches sans perdre son contexte, et qu'un échec local ne doit ni effacer les réussites ni être dissimulé par un résultat général imprécis.

Limites du cycle

Le cycle commun ne doit pas :

• Transformer chaque événement en action.
• Exécuter une conséquence devenue inutile ou non applicable.
• Confondre authentification de la source, permission de l'acteur et autorisation de l'action.
• Accorder au service LLM, au modèle, à P.O.U.B.E.L.L.E. ou à une extension une autorité autonome.
• Considérer l'envoi d'une instruction comme la preuve de sa réussite.
• Masquer les résultats individuels derrière un statut général.
• Annuler automatiquement des conséquences déjà réussies en raison d'un échec indépendant.
• Répéter une action lorsque son état précédent demeure incertain et que le doublon présente un risque.
• Propager un résultat à toutes les interfaces sans vérifier sa finalité, sa sensibilité et son utilité.
• Conserver dans les traces davantage d'informations que ne l'exigent l'explication, la sécurité et l'exploitation.
• Imposer prématurément une architecture technique particulière.

Ces limites garantissent que le cycle reste un cadre de décision et de traçabilité commun, sans devenir une justification pour automatiser indistinctement chaque possibilité offerte par les services reliés.

Synthèse du cycle

Domaine	Principe de traitement	Garantie recherchée
Origine	Tout événement conserve sa source, son acteur éventuel et son contexte initial.	Une information ne devient pas anonyme lorsqu'elle entre dans Horizon.
Identification	Chaque traitement et chaque conséquence possèdent une référence propre.	Les branches, reprises et résultats restent rattachés à leur origine.
Validation	La provenance, la structure, l'intégrité et la pertinence sont vérifiées avant décision.	Une information reçue ne devient pas automatiquement fiable ou exploitable.
Répétitions	Le Noyau recherche les événements et conséquences déjà traités.	Une reprise ou une retransmission ne produit pas involontairement un doublon.
Contexte	Seules les informations nécessaires et autorisées sont mobilisées.	Centraliser les données ne crée ni accès général ni transmission systématique.
Permissions et risque	L'acteur, le périmètre, la sensibilité et les préconditions sont vérifiés.	Une interface ou une origine reconnue ne suffit pas à autoriser l'action.
Pertinence	Une conséquence devenue inutile, sans objet ou non applicable n'est pas exécutée.	Horizon évite les actions superflues et les effets tardifs incohérents.
Confirmation	Une opération critique est suspendue, présentée puis vérifiée de nouveau lors de la confirmation.	La décision humaine reste explicite, contextualisée, limitée et actuelle.
Exécution	Les traitements internes restent contrôlés et les actions externes passent par les extensions.	Aucun composant ne contourne l'autorité du Noyau.
Résultats	Chaque conséquence distingue réussite, refus, échec, abandon, annulation, expiration, non-applicabilité et incertitude.	L'état reflète ce qui est établi plutôt que ce qui était seulement prévu.
Traitement global	Le traitement distingue ses états actif, en attente, partiellement terminé, terminé, abandonné, expiré ou nécessitant une intervention.	La synthèse générale ne masque ni la progression ni les résultats individuels.
Échec partiel	Les réussites sont conservées et les interventions nécessaires sont routées selon la capacité et la gravité.	Un échec local ne détruit pas les résultats valides et ne reste pas invisible.
Reprise	Une répétition automatique exige l'absence certaine d'exécution ou une opération sans effet supplémentaire.	Les doubles remboursements, attributions, annonces ou modifications sont évités.
Propagation	Les résultats sont transmis selon les connexions, permissions, finalités et besoins réels.	Un événement multiplateforme ne provoque pas une diffusion universelle.
Traçabilité	Les contrôles, décisions, confirmations, conséquences et résultats importants sont conservés avec mesure.	Le traitement peut être expliqué sans créer une copie excessive des données.
Résilience	Les branches indépendantes et déterministes continuent lorsque cela reste sûr.	Une panne locale ne provoque ni effondrement général ni résultat inventé.

Le cycle de traitement constitue ainsi le parcours commun par lequel le Noyau transforme un événement en décisions et en conséquences maîtrisées. Le chapitre suivant précisera les informations sur lesquelles ce cycle s'appuie en définissant l'état global d'Horizon, les catégories d'événements et les relations qui permettent de conserver une représentation cohérente de la Plateforme.