Fusion d'identités

Le principe d'unicité défini au chapitre 10 prévoit qu'une même personne ne doit disposer que d'une seule Identité Horizon active. Malgré cette règle, plusieurs identités peuvent être créées avant qu'Horizon dispose des preuves permettant de reconnaître qu'elles appartiennent à la même personne. Cette situation peut notamment apparaître lorsqu'une personne interagit séparément sur Twitch et Discord avant de relier ses comptes.

Le chapitre 11 définit les moyens de vérifier le contrôle des comptes externes et d'établir qu'ils sont utilisés par la même personne. Lorsque chacun de ces comptes possède déjà sa propre Identité Horizon, une simple liaison ne suffit plus : les deux identités, leurs états et leurs données doivent être réunis au moyen d'une fusion contrôlée.

Le présent chapitre définit les conditions, les confirmations, les états et les garanties de cette fusion. Il établit également le devenir de l'identité absorbée, le traitement des événements reçus pendant l'opération et les règles applicables lorsqu'une donnée ne peut pas être consolidée automatiquement.

Il ne détermine pas encore la stratégie détaillée de chaque donnée. Le chapitre 13 recensera les données concernées et le chapitre 14 définira leurs sources faisant autorité, leurs priorités et leurs règles de cohérence.

Fonctionnement cible — Principes validés

Une fusion peut être proposée automatiquement par Horizon lorsqu'une liaison révèle l'existence de deux identités, ou être demandée depuis le Poste de commande, par une commande Twitch ou Discord, ou depuis l'administration Horizon. Elle n'est jamais exécutée automatiquement.

La preuve de contrôle des comptes et la confirmation de la fusion constituent deux décisions distinctes. Avant toute exécution, la personne doit pouvoir comprendre quelles identités sont concernées, quelles règles seront appliquées et quelles données nécessitent encore un choix ou une intervention.

L'Identité Horizon la plus ancienne est conservée. L'autre identité est absorbée, puis conservée pendant trente jours sous la forme d'un instantané limité aux données nécessaires à la correction et à la reconstruction. Cet instantané est ensuite supprimé. Une trace technique minimale demeure afin de préserver la cohérence des anciennes références sans conserver une seconde identité exploitable.

Synthèse normative

• Une fusion doit concerner plusieurs Identités Horizon dont les comptes ont été suffisamment vérifiés comme appartenant à une même personne.
• Horizon peut détecter et proposer une fusion, mais ne doit jamais l'exécuter automatiquement.
• Une ressemblance entre des pseudonymes, des avatars, des comportements ou des données de profil ne constitue jamais une preuve suffisante.
• La confirmation d'une liaison ne doit pas valoir confirmation de la fusion correspondante.
• L'Identité Horizon la plus ancienne doit être conservée comme référence centrale.
• Chaque donnée doit suivre la stratégie de fusion définie dans son référentiel fonctionnel.
• Une donnée dépourvue de règle applicable ne doit jamais être sélectionnée, additionnée ou supprimée silencieusement.
• Une restriction, une exclusion, un départ volontaire, un blocage de réentrée ou un blocage de sécurité ne doit pas être effacé par la fusion.
• Une permission ou une responsabilité ne doit être conservée que si son attribution demeure valide.
• Une fusion ne doit pas produire plusieurs comptes actifs pour une même plateforme.
• Les événements reçus pendant l'exécution doivent être conservés puis rattachés à l'identité finale lorsque leur application reste valide.
• L'identité absorbée doit être conservée pendant trente jours sous une forme minimisée, privée de secrets, de jetons et de données transitoires inutiles.
• Une fusion échouée doit aboutir soit à un retour arrière complet, soit à un état explicite de conflit ou d'intervention nécessaire.
• Une trace technique minimale doit permettre de résoudre les anciennes références après cette suppression.
• Une fusion achevée ne doit pas pouvoir être annulée directement par l'utilisateur.
• P.O.U.B.E.L.L.E. ne doit jamais être fusionnée avec une identité humaine.

Rôle de la fusion

Une fusion d'identités est l'opération contrôlée par laquelle Horizon transforme plusieurs représentations d'une même personne en une seule Identité Horizon active. Elle ne consiste ni à juxtaposer deux profils ni à déplacer arbitrairement un compte externe.

La fusion poursuit plusieurs finalités :

• Restaurer le principe d'une seule identité active par personne.
• Rattacher les comptes vérifiés à une référence centrale commune.
• Consolider les données selon leurs règles propres.
• Préserver les restrictions, responsabilités et informations nécessaires à la continuité du fonctionnement.
• Empêcher la perte ou le double comptage d'une donnée.
• Conserver une explication vérifiable de l'opération.

La fusion ne signifie pas que toutes les valeurs des deux identités sont additionnées. Selon la donnée, Horizon peut conserver une valeur, sélectionner une source prioritaire, réunir plusieurs éléments distincts, demander un choix, maintenir une restriction, refuser un transfert ou constater un conflit.

Elle ne rend pas non plus publiques les relations entre les plateformes. La connaissance par Horizon du lien entre un compte Twitch et un compte Discord reste soumise aux règles de confidentialité définies pour l'identité et ses liaisons.

Détection et proposition de fusion

La détection désigne le constat que plusieurs Identités Horizon pourraient appartenir à une même personne. Elle peut provenir d'une demande explicite ou apparaître au cours d'une autre opération.

Cette situation peut résulter d'interactions séparées sur Twitch et Discord avant la liaison des comptes. Horizon doit accepter temporairement ce doublon plutôt que de réunir deux personnes sur la base d'une supposition.

Une proposition de fusion peut être produite :

• Lorsqu'une liaison vérifiée découvre qu'un compte est déjà associé à une autre identité.
• Lorsqu'une personne authentifiée demande à réunir ses comptes depuis sa page personnelle.
• Lorsqu'une vérification croisée par commandes établit le contrôle des deux comptes.
• Lorsqu'une personne signale un doublon à l'assistance ou à l'administration.
• Lorsqu'un contrôle fonctionnel détecte une relation contradictoire entre des comptes et des identités.
• Lorsqu'une personne habilitée ouvre un examen administratif documenté.

Une détection automatique ne constitue qu'un signal. Elle peut préparer la procédure, présenter les identités concernées ou demander des vérifications supplémentaires, mais elle ne prouve pas à elle seule qu'elles appartiennent à la même personne.

Horizon ne doit notamment pas produire une fusion sur la seule base :

• D'un pseudonyme identique ou similaire.
• D'un ancien pseudonyme réutilisé par une autre personne.
• D'un avatar commun.
• D'une adresse ou d'un attribut technique isolé.
• D'une déclaration non authentifiée.
• D'une déduction produite par le LLM.
• D'une conclusion de P.O.U.B.E.L.L.E.
• D'une proximité supposée entre des comportements ou des centres d'intérêt.

La détection ouvre donc un traitement identifiable. Elle ne modifie encore aucune liaison, aucune donnée et aucun statut.

Personnes et identités admissibles

La procédure dépend de l'état de revendication des identités concernées.

Situation	Condition générale	Conséquence
Une identité revendiquée et une identité non revendiquée	Le contrôle du compte associé à l'identité non revendiquée doit être établi.	Une fusion peut être proposée puis confirmée.
Deux identités revendiquées	Le contrôle récent des comptes permettant d'accéder aux deux identités doit être établi.	Une fusion peut être proposée puis confirmée.
Deux identités non revendiquées	Au moins l'une des identités doit d'abord être revendiquée par une personne vérifiée.	La fusion directe par une personne reste indisponible.
Une identité revendiquée par une autre personne	Les preuves sont contradictoires ou insuffisantes.	La fusion est bloquée et la situation passe en conflit.
Une identité exclue ou restreinte	La propriété peut être vérifiée, mais la restriction doit être conservée et présentée.	La fusion peut nécessiter un examen renforcé sans lever la restriction.
Une identité spéciale ou appartenant à P.O.U.B.E.L.L.E.	Les règles humaines ordinaires ne sont pas applicables.	La fusion humaine est interdite.

Une identité non revendiquée peut déjà contenir une progression, des événements, un statut ou des paramètres déterminés par les interactions observées. Son absence de revendication n'autorise ni son écrasement ni son absorption silencieuse.

Vérification du contrôle des comptes

La fusion utilise les preuves obtenues dans le cadre du chapitre 11. Horizon doit disposer d'éléments suffisants pour établir que la personne contrôle les comptes externes associés aux identités qu'elle souhaite réunir.

Les preuves admissibles, leur portée et les garanties de confidentialité sont celles définies au chapitre 11. Le présent chapitre les réutilise pour la fusion sans créer une seconde procédure de preuve concurrente.

La vérification répond uniquement à la question suivante : la personne contrôle-t-elle les comptes concernés ? Elle ne décide ni de la consolidation des données ni de l'acceptation de la fusion.

Confirmation distincte et explicite

La confirmation de la fusion intervient après la vérification des comptes. Elle constitue une décision séparée de la liaison, car elle autorise la consolidation de deux états fonctionnels et de leurs données.

Elle peut être donnée depuis le Poste de commande ou au moyen d'une commande sécurisée rattachée à la demande. Le Poste de commande constitue le parcours le plus simple pour consulter les détails, mais la voie par commandes conserve les mêmes exigences de preuve, de confidentialité et d'information définies au chapitre 11. Une commande publique ne présente jamais les identités concernées ni les détails de la fusion.

Avant de demander cette confirmation, Horizon doit présenter au minimum :

• Les Identités Horizon concernées sous une forme compréhensible.
• Les comptes Twitch et Discord vérifiés.
• L'identité la plus ancienne qui sera conservée.
• Le fait que l'autre identité sera absorbée.
• Les principales catégories de données concernées.
• Les règles déjà déterminées pour ces données.
• Les valeurs ou paramètres qui nécessitent un choix.
• Les restrictions, responsabilités ou conflits identifiés.
• La période d'archivage de trente jours.
• Le caractère non annulable de la fusion par la procédure utilisateur ordinaire.

La personne doit pouvoir consulter ces informations sans que l'interface divulgue inutilement des données sensibles. Une valeur protégée peut être décrite par sa catégorie, son origine ou son effet sans être intégralement affichée lorsque les permissions ne l'autorisent pas.

La confirmation est rattachée à l'état présenté. Elle doit devenir invalide si, avant l'exécution, un compte est remplacé, une restriction importante apparaît, une autre fusion est terminée ou une modification rend la proposition obsolète.

Un refus, une annulation ou une expiration laisse les identités séparées. Les preuves obtenues peuvent rester utilisables selon leur durée de validité, mais elles n'autorisent aucun transfert de données en l'absence d'une nouvelle décision applicable.

Identité conservée

L'Identité Horizon la plus ancienne est conservée comme référence centrale. L'ancienneté est déterminée à partir de la création effective de l'identité dans Horizon et non à partir de l'ancienneté d'un compte Twitch, d'un compte Discord, d'un pseudonyme ou d'une revendication.

Cette règle apporte un résultat déterministe et évite de créer une notion de compte principal. Elle ne signifie pas que les données les plus anciennes deviennent systématiquement prioritaires.

L'identité conservée reçoit, selon les règles applicables :

• Les liaisons externes vérifiées et compatibles.
• Les données consolidées.
• Les états et paramètres retenus.
• Les références nécessaires aux historiques.
• Les restrictions et responsabilités encore valides.
• Les événements mis en attente pendant l'opération.

L'identité conservée peut être initialement non revendiquée, moins avancée ou associée à une seule plateforme. Ces différences ne modifient pas la règle d'ancienneté. Son état final est recalculé à partir des informations consolidées.

L'identifiant interne conservé reste distinct des identifiants Twitch et Discord. Il ne devient ni visible par défaut ni porteur d'une priorité générale entre les plateformes.

Stratégies de consolidation des données

Le chapitre 12 définit le cadre d'application des stratégies sans attribuer lui-même une stratégie définitive à chaque donnée. Le catalogue du chapitre 13 et les règles du chapitre 14 constituent les référentiels maîtres.

Chaque donnée susceptible d'être rencontrée pendant une fusion doit indiquer une stratégie applicable parmi les catégories suivantes ou une règle fonctionnelle équivalente.

Stratégie	Principe	Exemple indicatif
Valeur la plus élevée	Horizon conserve la valeur valide la plus haute.	Niveau ou valeur de progression lorsque le système concerné définit cette règle.
Plateforme ou source prioritaire	Horizon conserve la valeur provenant de l'autorité définie pour cette donnée.	Information native dont Twitch, Discord ou Horizon reste l'autorité.
Réunion sans doublon	Horizon conserve les éléments distincts provenant des deux identités.	Ensemble de distinctions ou références uniques lorsque leur cumul est permis.
Choix de la personne	Horizon demande quelle valeur doit devenir la valeur active.	Nom d'affichage ou préférence personnelle concurrente.
Restriction la plus forte	Horizon conserve l'état le plus protecteur ou le plus contraignant.	Exclusion, blocage ou paramètre de confidentialité.
Absence de transfert	La donnée reste exclue de la consolidation.	Élément non applicable à l'identité finale ou interdit de transfert.
Conflit	Aucune règle ne permet d'établir une valeur suffisamment fiable.	Donnée contradictoire nécessitant un examen ou une décision.

La notion de donnée « cumulable » ne signifie donc pas nécessairement une addition. Une progression peut suivre la valeur la plus élevée, une source prioritaire ou une règle spécialisée du système fonctionnel concerné. La fusion applique la règle déclarée ; elle n'en invente pas une à partir du type apparent de la valeur.

Application des règles de données

Avant l'exécution, Horizon prépare un état prévisionnel de la fusion. Pour chaque donnée concernée, il détermine :

1. La donnée ou la famille fonctionnelle applicable.
2. Les valeurs présentes sur les deux identités.
3. L'origine, l'état de connaissance et la fraîcheur nécessaires à la décision.
4. La stratégie définie par le référentiel maître.
5. Le résultat attendu de cette stratégie.
6. L'existence éventuelle d'un choix, d'un conflit ou d'un blocage.

La règle appliquée est celle en vigueur au moment de l'exécution. Une modification ultérieure des stratégies ne doit pas recalculer automatiquement une fusion terminée. Une évolution peut produire une migration, une correction ou une nouvelle transition d'état lorsqu'un chapitre spécialisé l'autorise, mais elle ne réécrit pas silencieusement l'opération passée.

Le compte rendu de fusion doit permettre d'identifier la stratégie appliquée sans nécessairement reproduire toutes les valeurs sensibles. Il doit également distinguer une valeur conservée, une valeur écartée, une donnée transférée, une donnée supprimée et une donnée demeurée en conflit.

Absence de règle applicable

Une donnée dépourvue de stratégie ne doit jamais être sélectionnée arbitrairement.

Horizon applique alors les principes suivants :

• Une donnée sensible ou structurelle bloque la fusion lorsqu'aucun résultat sûr ne peut être établi.
• Une donnée personnelle simple demande un choix explicite à la personne lorsque ce choix est autorisé.
• Une donnée facultative peut rester temporairement en conflit lorsque sa présence n'empêche pas la cohérence de l'identité finale.
• Une absence de règle doit apparaître dans la proposition et dans le compte rendu.
• Une règle manquante susceptible d'affecter d'autres personnes, des permissions ou une restriction doit conduire à une intervention.

Une fusion partielle n'est acceptable que lorsque les données laissées en conflit peuvent rester isolées sans compromettre l'identité, les liaisons, la sécurité ou les traitements futurs. Dans le cas contraire, l'ensemble de l'opération demeure en attente.

Progression, historiques et éléments uniques

La progression ne reçoit pas une règle générale d'addition dans le présent chapitre. Chaque système fonctionnel détermine la stratégie adaptée à ses données.

Le système de progression pourra notamment distinguer :

• Une valeur courante pour laquelle la valeur la plus élevée doit être conservée.
• Des événements de progression distincts pouvant être réunis sans double comptage.
• Des récompenses ou distinctions uniques conservées une seule fois.
• Des éléments dépendant d'une plateforme prioritaire.
• Des corrections, retraits ou valeurs invalides qui ne doivent pas réapparaître après la fusion.

Les historiques des deux identités ne sont pas confondus avec l'état actuel. Ils peuvent être réunis chronologiquement tout en conservant l'identité d'origine, la plateforme, la causalité et les corrections associées. Leur conservation détaillée relève du chapitre 15.

Un événement observé sur les deux identités ne doit pas produire deux conséquences si le Noyau peut établir qu'il s'agit de la même origine fonctionnelle. Lorsque cette équivalence reste incertaine, la stratégie du système concerné doit déterminer si l'élément est conservé, ignoré ou placé en conflit.

Statuts, rôles, permissions et restrictions

Les dimensions d'identité définies au chapitre 10 restent distinctes pendant la fusion. Elles ne peuvent pas être combinées par une simple règle de valeur maximale.

Horizon applique notamment les principes suivants :

• Le statut communautaire final est recalculé à partir de la situation consolidée après application de l'ordre de priorité défini au chapitre 10.
• Une exclusion reste prioritaire jusqu'à sa levée par une personne habilitée.
• Un départ volontaire et son blocage de réentrée restent actifs jusqu'à un retour explicite autorisé.
• La revendication conservée par l'une des identités ne doit pas neutraliser une sortie ou une restriction prioritaire.
• Un bannissement ou une restriction ne peut pas être contourné au moyen d'une autre identité.
• Une permission administrative ou de modération n'est conservée que si son attribution reste valide.
• Une responsabilité ne doit pas être étendue à un nouveau périmètre uniquement parce que deux identités sont fusionnées.
• La distinction de Membre honorifique est conservée lorsqu'elle reste valide selon ses propres règles.
• Une demande de débannissement ou une procédure de récupération en cours doit rester rattachée à l'identité finale.

Lorsqu'une identité est exclue et l'autre ne l'est pas, la fusion ne rétablit pas automatiquement l'accès communautaire. L'identité finale conserve la restriction et la personne reste orientée vers la procédure de demande de débannissement prévue au chapitre 10.

De même, une identité issue d'un départ volontaire ne redevient pas Membre d'équipage parce que l'autre identité possède une présence externe ou une revendication valide. Le blocage de réentrée est consolidé avant le calcul du statut final et ne peut être levé que par la procédure de retour autorisée.

Comptes concurrents d'une même plateforme

Une Identité Horizon ne peut posséder qu'un seul compte Twitch et un seul compte Discord actifs. Une fusion qui réunirait deux comptes du même service ne peut donc pas être exécutée directement.

La personne doit d'abord choisir le compte à conserver pour la plateforme concernée. Le second compte est ensuite traité selon les règles de déliaison, de remplacement ou de récupération du chapitre 11.

Ce choix doit vérifier :

• Le contrôle des deux comptes lorsque cela est nécessaire.
• Les restrictions externes ou internes applicables.
• La continuité du dernier moyen d'accès à l'identité.
• Le devenir des autorisations externes.
• Les données dont la plateforme reste l'autorité.
• Les conséquences d'une liaison devenue indisponible.

La fusion reste en attente tant que ce conflit de cardinalité n'est pas résolu. Horizon ne choisit pas automatiquement le compte le plus ancien, le plus actif ou celui dont le pseudonyme ressemble au nom d'affichage Horizon.

Conflits et blocages

Tous les conflits n'ont pas le même effet. Certains empêchent la fusion entière ; d'autres peuvent être résolus par un choix ou conservés temporairement dans l'état global Horizon.

Situation	Traitement général
Contrôle insuffisant d'un compte	La fusion reste en attente de vérification ou est refusée.
Identité revendiquée par une autre personne	La fusion est bloquée et une intervention est nécessaire.
Plusieurs comptes d'une même plateforme	La fusion est suspendue jusqu'au choix et au traitement du compte excédentaire.
Restriction ou exclusion non présentée	La proposition devient obsolète et doit être reconstruite avant confirmation.
Donnée structurelle sans stratégie	La fusion est bloquée jusqu'à la définition ou l'application d'une règle valide.
Donnée personnelle concurrente	Un choix est demandé lorsque la personne possède l'autorisation nécessaire.
Donnée facultative isolable	La donnée peut rester en conflit sans empêcher les autres consolidations.
Suppression ou récupération en cours	L'opération est suspendue jusqu'à la résolution de la procédure prioritaire.
Identité spéciale protégée	La fusion ordinaire est refusée.

Une fusion ne doit pas transformer une incertitude en certitude. Lorsque le Noyau ne peut pas déterminer si les conditions sont réellement réunies, l'état attendu est « en conflit » ou « intervention nécessaire », et non « fusionnée ».

Exécution de la fusion

La fusion constitue un traitement coordonné par le Noyau. Sans imposer encore une transaction technique particulière, son cycle fonctionnel comprend les étapes suivantes :

1. Horizon identifie les identités et les comptes concernés.
2. Horizon vérifie les preuves de contrôle encore valides.
3. Horizon détermine l'identité la plus ancienne.
4. Horizon charge les stratégies applicables aux données concernées.
5. Horizon construit et présente l'état final prévisionnel.
6. La personne effectue les choix nécessaires et confirme la fusion.
7. Horizon vérifie que la proposition n'est pas devenue obsolète.
8. Horizon verrouille les modifications sensibles sur les deux identités.
9. Horizon consolide les données et transfère les liaisons actives compatibles vers l'identité conservée.
10. Horizon recalcule les statuts, restrictions, responsabilités et permissions applicables.
11. Horizon crée pour trente jours un instantané minimisé de l'identité absorbée, dont les anciennes liaisons ne sont plus que des références historiques.
12. Horizon rattache les événements en attente à l'identité conservée lorsque leur application reste valide.
13. Horizon met à jour l'état global et produit les événements de résultat nécessaires.
14. Horizon génère le compte rendu et la notification finale.

La réussite doit être établie comme un ensemble cohérent. Si une étape essentielle échoue, Horizon ne doit pas présenter la fusion comme achevée alors que les comptes ou les données restent répartis de manière contradictoire.

Lorsqu'un échec survient pendant l'exécution, Horizon tente d'annuler les modifications déjà appliquées à partir de l'état prévisionnel et des valeurs conservées pour la reprise. Trois sorties doivent rester distinguées :

• La fusion devient Échouée lorsque le retour arrière est complet et qu'aucun transfert, aucune liaison active concurrente et aucun état partiel ne subsiste.
• La fusion devient En conflit lorsqu'une incompatibilité cohérente empêche la consolidation et exige un nouvel arbitrage avant toute nouvelle tentative.
• La fusion passe en Intervention nécessaire lorsque l'état est partiel ou incertain et qu'un retour automatique sûr ne peut plus être garanti.

Aucun de ces états ne peut être présenté comme Fusionnée. Un traitement générique du chapitre 8 peut être terminé alors que la fusion métier demeure En conflit ou exige une intervention ; les deux niveaux d'état restent distincts.

Événements reçus pendant l'opération

Une fusion ne suspend pas les interactions sur Twitch, Discord ou le Poste de commande. Des messages, récompenses, changements de rôles ou autres événements peuvent être reçus pendant son exécution.

Horizon applique alors les principes suivants :

• Les événements continuent d'être reçus et identifiés.
• Les conséquences dépendant des identités en cours de fusion sont placées en attente lorsque leur application immédiate créerait une incohérence.
• Les événements conservent leur origine, leur horodatage et leur lien causal.
• Après la fusion, les conséquences encore valides sont appliquées à l'identité conservée.
• Une conséquence déjà produite n'est pas exécutée une seconde fois.
• Un changement incompatible provoque l'interruption ou la reconstruction de la proposition.

Le verrouillage doit être limité aux modifications nécessaires à la cohérence. Une interaction sans conséquence sensible peut continuer son traitement ordinaire lorsqu'elle ne dépend pas du résultat de la fusion.

États fonctionnels d'une fusion

Une fusion dispose de son propre cycle, distinct des états de l'identité et des liaisons.

État	Signification	Conséquence générale
Proposée	Horizon a identifié plusieurs identités susceptibles d'appartenir à la même personne.	Aucune donnée n'est modifiée.
En attente de vérification	Le contrôle d'au moins un compte reste à établir ou à renouveler.	La fusion ne peut pas être confirmée.
En attente de choix	Une donnée ou un compte concurrent nécessite une décision autorisée.	La proposition reste préparatoire.
En attente de confirmation	Les contrôles et choix requis permettent de présenter la décision finale.	Horizon attend le consentement distinct de la personne.
En cours	Les derniers contrôles sont réussis et l'exécution a commencé.	Les modifications sensibles sont temporairement verrouillées.
Fusionnée	Une identité active unique a été établie et l'identité absorbée est archivée.	Les traitements utilisent l'identité conservée.
Échouée	Une erreur a interrompu l'exécution et toutes les modifications ont été annulées proprement.	Les identités restent séparées et aucun état partiel ne subsiste.
En conflit	Une incompatibilité empêche la consolidation et exige un nouvel arbitrage.	La fusion est suspendue dans un état cohérent avant une éventuelle reprise.
Intervention nécessaire	L'état est partiel ou incertain et ne peut pas être établi ou restauré automatiquement avec une confiance suffisante.	Les opérations sensibles restent bloquées jusqu'à une décision habilitée.
Refusée	La personne ou Horizon refuse la proposition dans les conditions prévues.	Les identités restent séparées.
Annulée	Une demande autorisée met explicitement fin au traitement avant son exécution.	Aucun transfert n'est réalisé.
Expirée	La durée de validité de la proposition ou des preuves est dépassée.	Une nouvelle vérification ou proposition est nécessaire.
Correction nécessaire	Une fusion achevée présente une erreur avérée ou une incohérence importante.	Une procédure administrative exceptionnelle est ouverte.

La répétition d'une demande déjà fusionnée doit retrouver l'identité conservée et confirmer l'état actuel sans reproduire les transferts, notifications ou consolidations.

Refus, annulation et expiration

Tant que l'exécution n'a pas commencé, la personne peut refuser ou annuler la proposition selon l'état de la procédure. Horizon peut également refuser une demande lorsque les preuves, les permissions ou les règles fonctionnelles ne permettent pas de l'exécuter.

Une proposition peut expirer lorsque :

• Une preuve de contrôle dépasse sa durée de validité.
• Une commande temporaire n'est pas confirmée dans le délai prévu.
• Un compte ou une liaison change avant l'exécution.
• Une restriction ou un conflit rend la proposition obsolète.
• La personne ne termine pas les choix nécessaires.

L'expiration ne supprime pas les identités et ne déplace aucune donnée. Une nouvelle demande peut être ouverte ultérieurement avec des preuves et un état prévisionnel actualisés.

Une fusion refusée ne doit pas empêcher l'utilisation séparée des identités lorsque cette utilisation reste légitime. Elle ne doit toutefois pas permettre à une personne de contourner une restriction, une décision de modération ou une règle d'unicité devenue certaine.

Archivage minimisé de trente jours

Après la réussite, l'identité absorbée est conservée pendant trente jours sous la forme d'un instantané limité aux données nécessaires à la correction, à la reconstruction et à l'explication de la fusion. Cette période constitue une fenêtre de contrôle et non un délai pendant lequel deux identités restent actives.

L'instantané exclut les secrets, les jetons OAuth, les données transitoires et les informations dont aucune finalité active ne justifie la conservation. Son accès est limité aux fonctions de contrôle et aux personnes habilitées. Sa suppression à l'échéance est automatique, sauf lorsqu'une correction légitime et documentée a été ouverte avant la fin du délai.

Durant l'archivage :

• L'identité conservée est la seule identité utilisée pour les interactions ordinaires.
• Les comptes externes compatibles sont déjà rattachés à l'identité conservée.
• L'identité absorbée ne conserve aucune liaison active ; elle référence seulement l'ancienne relation lorsque cette information est nécessaire à la correction.
• L'identité absorbée ne reçoit plus de progression ni de nouveaux événements fonctionnels.
• Ses données restent accessibles uniquement aux fonctions autorisées de contrôle et de correction.
• La personne peut signaler une erreur depuis le compte rendu de fusion.
• Une personne habilitée peut examiner la provenance des données et les décisions appliquées.

Le délai est calculé à partir de l'achèvement effectif de la fusion. Une correction ouverte avant son expiration peut suspendre la suppression tant que l'examen reste légitime et documenté. Les durées détaillées et les exceptions de conservation relèvent du chapitre 35.

Suppression de l'identité absorbée

À l'issue des trente jours, Horizon supprime les données propres à l'identité absorbée qui ne sont plus nécessaires à l'identité conservée, à une obligation applicable ou à une procédure encore ouverte.

La suppression concerne notamment :

• Le profil autonome de l'identité absorbée.
• Son état opérationnel devenu sans objet.
• Les copies de données déjà consolidées.
• Les paramètres qui n'ont pas été retenus.
• Les relations temporaires utilisées pour la procédure.

Les anciens pseudonymes Twitch ou Discord ne sont pas réservés par Horizon. Un pseudonyme reste un attribut modifiable du compte externe et ne constitue pas sa référence stable. Horizon reconnaît les comptes au moyen des identifiants fournis par les plateformes.

Une personne qui récupère ultérieurement un ancien pseudonyme abandonné par quelqu'un d'autre possède un identifiant externe distinct. Elle peut donc être reconnue comme une autre personne sans que le pseudonyme historique provoque une fusion automatique.

Trace technique minimale

La suppression de l'identité absorbée ne doit pas rendre les anciens événements incohérents. Horizon conserve donc une trace technique minimale, qui ne constitue plus une Identité Horizon exploitable.

Cette trace contient uniquement les références nécessaires pour établir :

• L'ancien identifiant Horizon.
• L'identifiant Horizon conservé.
• La date effective de la fusion.
• La référence de l'événement de fusion.

Elle ne conserve ni profil autonome, ni pseudonyme réservé, ni statut communautaire actif, ni liaison externe concurrente. Une éventuelle référence historique à un compte ne constitue pas une liaison active et ne permet aucune authentification. Les détails complémentaires relèvent du compte rendu, de l'historique autorisé et des durées de conservation définies dans les chapitres spécialisés.

L'ancien identifiant Horizon ne peut jamais être réattribué. Lorsqu'un traitement légitime rencontre une ancienne référence, il peut retrouver l'identité conservée au moyen de cette trace sans recréer l'identité supprimée.

Correction administrative exceptionnelle

Une fusion achevée ne peut pas être annulée directement depuis la page personnelle. Après l'exécution, de nouveaux événements peuvent déjà avoir modifié l'identité finale et rendre une séparation automatique dangereuse.

Une correction administrative exceptionnelle peut toutefois être ouverte :

• Lorsqu'une erreur de personne est démontrée.
• Lorsqu'une fraude ou une usurpation est établie.
• Lorsqu'un compte a été rattaché à la mauvaise identité.
• Lorsqu'une défaillance a appliqué une stratégie incorrecte.
• Lorsqu'une incohérence importante apparaît pendant la période d'archivage.

La correction n'est autorisée que si la provenance des données permet de reconstruire un résultat fiable. Elle peut conduire à une séparation, à une nouvelle fusion, à une correction ciblée ou au maintien de l'identité finale avec une rectification documentée.

Une personne habilitée doit pouvoir consulter les preuves, les choix, les stratégies appliquées et les événements postérieurs. Si une séparation fiable est impossible, Horizon ne doit pas inventer une répartition. La situation reste en conflit et fait l'objet d'une décision adaptée à son niveau de sensibilité.

Toute correction produit de nouveaux événements. Elle ne réécrit ni ne supprime silencieusement l'événement de fusion initial.

Cas particulier de P.O.U.B.E.L.L.E.

L'Identité Horizon spéciale de P.O.U.B.E.L.L.E. ne suit pas le cycle communautaire des personnes humaines. Par conséquent :

• Elle ne peut pas être proposée dans une fusion humaine.
• Elle ne peut pas absorber une identité humaine.
• Elle ne peut pas être absorbée par une identité humaine.
• Ses comptes et paramètres spéciaux ne peuvent pas être déplacés par les commandes ordinaires.
• Une détection la concernant doit être refusée ou transmise à une procédure technique dédiée.

P.O.U.B.E.L.L.E. peut expliquer la procédure ou transmettre une demande au Noyau, mais ne peut ni confirmer la fusion ni arbitrer les données.

Confidentialité de la procédure

Une proposition de fusion révèle qu'Horizon connaît ou suspecte une relation entre plusieurs comptes. Cette information est privée par défaut.

Horizon doit notamment garantir que :

• Une proposition n'est présentée qu'à la personne authentifiée et aux fonctions administratives autorisées.
• Une commande publique ne divulgue pas inutilement le pseudonyme de l'autre plateforme.
• Un code temporaire ne révèle pas les données de l'identité recherchée.
• Le compte rendu respecte la classification des informations qu'il décrit.
• La publication antérieure d'un compte ne rend pas automatiquement toute la fusion publique.
• P.O.U.B.E.L.L.E. continue d'utiliser le pseudonyme propre au contexte de l'interaction.

La consolidation des paramètres de visibilité applique la valeur la plus protectrice jusqu'à un choix explicite de la personne. Une fusion ne constitue jamais un consentement général à la divulgation multiplateforme.

Notification et compte rendu

Après une fusion réussie, Horizon envoie une seule notification fonctionnelle à la personne. Cette notification donne accès à un compte rendu depuis le Poste de commande.

Le compte rendu présente notamment :

• Les comptes désormais liés.
• L'identité conservée et les principales catégories de données traitées.
• Les stratégies appliquées.
• Les choix effectués par la personne.
• Les données écartées ou demeurées en conflit.
• Les restrictions et permissions réévaluées.
• La date de la fusion et la fin de la période d'archivage de trente jours.
• Le moyen de signaler une erreur.

Les valeurs sensibles ne sont affichées que lorsque les permissions l'autorisent. Une notification administrative supplémentaire n'est produite qu'en cas d'anomalie ou d'intervention nécessaire.

Événements et traçabilité

La fusion produit des événements Horizon identifiables. Ceux-ci permettent d'expliquer les modifications de l'état global sans faire de l'historique l'unique source de reconstruction de l'identité actuelle.

Les événements fonctionnels peuvent notamment représenter :

• Une fusion proposée.
• Une vérification demandée ou réussie.
• Un choix fourni par la personne.
• Une fusion confirmée, refusée, annulée ou expirée.
• Une fusion commencée, achevée ou échouée.
• Une fusion placée en conflit ou nécessitant une intervention.
• Une donnée placée en conflit.
• Une identité absorbée puis archivée.
• Une suppression exécutée après trente jours.
• Une correction administrative ouverte ou terminée.
• Une notification envoyée.

Chaque événement conserve son origine, son contexte et son lien causal. La trace minimale conservée après la suppression permet uniquement de résoudre l'ancienne référence et d'identifier l'événement expliquant sa disparition.

Vue fonctionnelle du cycle de fusion

La figure suivante présentera le passage de deux Identités Horizon vérifiées vers une identité unique. Elle distinguera la détection, l'application des stratégies de données, les choix ou conflits, la confirmation, l'identité finale, l'archivage pendant trente jours et la trace minimale conservée après suppression. Le schéma restera fonctionnel et ne représentera pas les mécanismes techniques d'exécution.

FIG. 10 Cycle fonctionnel — Vérification, consolidation et fusion contrôlée de deux Identités Horizon appartenant à une même personne.

Garanties fonctionnelles

Le fonctionnement de la fusion doit garantir les principes suivants :

• Une fusion ne doit jamais être exécutée à partir d'une simple ressemblance.
• Une fusion ne doit jamais être déclenchée automatiquement sans confirmation distincte.
• La personne doit contrôler les comptes nécessaires à l'opération.
• L'identité la plus ancienne doit rester la référence centrale.
• Une donnée doit suivre une stratégie déclarée et vérifiable.
• Une donnée sans règle applicable ne doit jamais recevoir une valeur arbitraire.
• Une restriction ne doit pas être effacée par la présence d'une identité moins restrictive.
• Une fusion ne doit pas permettre plusieurs comptes actifs pour une même plateforme.
• Un événement reçu pendant l'opération ne doit être ni perdu ni appliqué deux fois.
• L'identité absorbée ne doit plus recevoir d'activité après la fusion.
• La suppression après trente jours ne doit pas rendre les anciennes références incohérentes.
• Une correction doit produire de nouveaux événements sans réécriture silencieuse du passé.
• La relation entre Twitch et Discord doit rester privée par défaut.

Limites du présent chapitre

Le présent chapitre fixe la procédure fonctionnelle de fusion. Les domaines suivants relèvent de leurs chapitres ou référentiels maîtres :

• La nature, les états et les statuts de l'Identité Horizon relèvent du chapitre 10.
• La liaison, la vérification, la déliaison et le remplacement des comptes relèvent du chapitre 11.
• Le catalogue fonctionnel des données susceptibles d'être consolidées relève du chapitre 13.
• Les sources faisant autorité, les priorités et les règles de cohérence relèvent du chapitre 14.
• La conservation détaillée des événements et évolutions relève du chapitre 15.
• Les règles propres à la progression et à ses valeurs relèvent du chapitre 26.
• Les restrictions et décisions de modération relèvent du chapitre 29.
• L'authentification, les sessions et les autorisations externes relèvent du chapitre 31.
• Les permissions humaines et administratives relèvent du chapitre 32.
• La classification et la visibilité des données relèvent du chapitre 33.
• Les confirmations renforcées et opérations sensibles relèvent du chapitre 34.
• Les durées détaillées de conservation, l'accès, l'export et la suppression relèvent du chapitre 35.
• Le modèle complet des identités, comptes et relations relève de l'Annexe E.
• Le catalogue exhaustif des données relève de l'Annexe F.
• Les entités, contraintes, transactions et migrations relèvent du chapitre 43.

Synthèse de la Partie III

La fusion restaure une Identité Horizon active unique après la vérification des comptes et une confirmation distincte de la liaison. L'identité la plus ancienne est conservée ; les comptes compatibles lui sont rattachés et chaque donnée suit la stratégie définie par son référentiel maître.

Les exclusions, les départs volontaires et les blocages de réentrée restent applicables. Les permissions sont réévaluées et les conflits empêchent tout résultat silencieux. L'identité absorbée est conservée pendant trente jours dans un instantané minimisé, puis ses données propres sont supprimées. Une trace minimale préserve seulement la cohérence des anciennes références.

Avec les chapitres 10, 11 et 12, la Partie III établit la représentation centrale d'une personne, la liaison vérifiée de ses comptes et la résolution contrôlée des doublons. La Partie IV peut désormais définir les données portées par Horizon ainsi que les autorités et règles garantissant leur cohérence.