Actions et outils de P.O.U.B.E.L.L.E.

P.O.U.B.E.L.L.E. utilise Horizon pour observer le fonctionnement de La Tanière, communiquer avec l'équipage, consulter les informations nécessaires et demander certaines opérations. Ces capacités prolongent son rôle de commandant en second, mais ne lui donnent aucun accès libre aux systèmes ou aux données de la Plateforme.

Chaque outil constitue une fonction limitée que le Noyau peut présenter dans un contexte précis. P.O.U.B.E.L.L.E. ou le modèle LLM peut proposer son utilisation, mais le Noyau reste seul responsable de l'autorisation, de la confirmation éventuelle, de l'exécution et de l'interprétation du résultat.

Le présent chapitre définit les catégories initiales d'outils, les origines possibles d'une demande, la structure d'une proposition d'action, les niveaux généraux de contrôle et les garanties communes. Il ne constitue pas encore le catalogue exhaustif des outils, qui sera construit dans l'Annexe K après la rédaction des soixante-huit chapitres afin d'intégrer l'ensemble des besoins établis.

Fonctionnement cible — Principes validés

Une personne, P.O.U.B.E.L.L.E. ou le Noyau à la suite d'un événement peut être à l'origine d'une demande d'action. Dans tous les cas, le Noyau vérifie la finalité, la cible, les paramètres, les permissions, le risque et les confirmations applicables avant toute conséquence.

Le LLM décrit les outils et propositions sous une forme textuelle structurée. Il ne les appelle jamais directement. Une opération externe est exécutée par la fonction interne ou l'extension compétente, puis son résultat réel est retourné au Noyau.

Les outils peuvent être utilisables sans limite prédéfinie ou soumis à des fréquences maximales selon leur nature. Les conversations ordinaires ne doivent pas être bloquées par une limitation arbitraire incompatible avec leur finalité.

Synthèse normative

• Les capacités de P.O.U.B.E.L.L.E. doivent être accordées fonction par fonction et pour des finalités définies.
• Une capacité de service ne doit pas être assimilée à un rôle humain ou à une permission générale d'administration.
• Un outil doit être présenté uniquement lorsqu'il est pertinent et disponible dans le contexte traité.
• La présence d'un outil dans un prompt ne doit pas constituer une autorisation d'exécution.
• Le LLM doit proposer une action sous une forme textuelle structurée sans appeler directement l'outil.
• Une proposition d'action doit rester distincte de la conséquence autorisée et de son résultat réel.
• Le Noyau doit vérifier la cible, les paramètres, la finalité, les préconditions, les permissions et les confirmations avant l'exécution.
• Une demande peut provenir d'une personne, de P.O.U.B.E.L.L.E. ou du Noyau à la suite d'un événement ou d'une tâche autorisée.
• Une action déléguée doit respecter les permissions de la personne qui la demande.
• Une action propre de P.O.U.B.E.L.L.E. doit relever d'une capacité de service et d'une finalité explicitement autorisées.
• Une sollicitation du Noyau ne doit présenter à P.O.U.B.E.L.L.E. que les capacités nécessaires à la conséquence prévue.
• P.O.U.B.E.L.L.E. ne doit jamais emprunter les permissions du Capitaine, d'un Modérateur, d'un Administrateur ou d'un Super administrateur.
• Une communication ordinaire peut être envoyée sans confirmation humaine lorsqu'elle reste dans un cadre préautorisé et non critique.
• Une communication majeure, sensible, administrative ou largement diffusée peut nécessiter une autorisation particulière.
• Une consultation peut être exécutée avant un second appel au LLM, sans donner au modèle un accès direct aux données.
• Une modification non sensible peut être automatisée uniquement lorsqu'une règle déterministe ou une demande autorisée établit indépendamment sa validité.
• Une modification seulement suggérée par le LLM ne doit pas être exécutée automatiquement sans contrôle indépendant ou confirmation adaptée.
• Une action critique doit être suspendue jusqu'à la confirmation d'une personne habilitée.
• P.O.U.B.E.L.L.E. et le LLM ne doivent jamais confirmer une action qu'ils ont proposée ou préparée.
• Une action interdite doit rester impossible même si elle est demandée par le LLM, P.O.U.B.E.L.L.E. ou une personne.
• Un résultat ne doit être considéré comme réussi qu'après réception d'une preuve suffisante de l'exécution réelle.
• Un outil absent, non présenté ou accompagné de paramètres invalides doit être refusé sans recherche permissive d'un équivalent.
• Chaque outil peut disposer de limites de fréquence adaptées ou être explicitement utilisable sans limite prédéfinie.
• Les actions fonctionnelles doivent produire une trace proportionnée à leur nature, à leur risque et à leur résultat.
• La page des actions doit limiter la visibilité de chacun au périmètre correspondant à ses responsabilités.
• Les listes de catégories et d'actions interdites du présent chapitre sont initiales et non définitives.

Finalité et périmètre du chapitre

Le chapitre répond à la question suivante :

Comment P.O.U.B.E.L.L.E. peut-elle mobiliser les capacités d'Horizon sans recevoir un accès direct aux systèmes ou devenir une autorité d'exécution ?

Il poursuit plusieurs objectifs :

• Donner une signification commune aux capacités, outils, propositions et conséquences.
• Organiser les actions demandées par une personne, proposées par P.O.U.B.E.L.L.E. ou produites depuis un événement du Noyau.
• Permettre au LLM d'exprimer une intention sans lui donner de connexion directe aux outils.
• Définir les principales familles de capacités accessibles.
• Distinguer les opérations préautorisées, soumises à confirmation et interdites.
• Encadrer les consultations, modifications, communications et notifications.
• Prévenir les répétitions, détournements et extensions de périmètre.
• Assurer une traçabilité proportionnée et consultable selon les responsabilités.

Le chapitre 18 définit la place de P.O.U.B.E.L.L.E. et ses capacités générales de commandant en second. Le chapitre 19 définit le statut consultatif des propositions du modèle. Le chapitre 20 précise comment les outils pertinents peuvent être présentés dans un prompt. Le présent chapitre établit le cadre fonctionnel de leur utilisation.

Capacités, outils, actions, propositions et conséquences

Cinq notions doivent rester distinctes.

Notion	Définition fonctionnelle
Capacité	Droit fonctionnel limité permettant à P.O.U.B.E.L.L.E. de demander une catégorie d'opération pour une finalité donnée.
Outil	Fonction contrôlée qu'Horizon peut rendre disponible dans un contexte précis.
Action	Nature d'une opération susceptible d'être demandée, autorisée, refusée, suspendue ou exécutée au moyen d'un outil.
Proposition d'action	Intention structurée décrivant l'outil, la cible et les paramètres envisagés.
Conséquence	Instance contextualisée d'une action, rattachée à un traitement et suivie de sa proposition jusqu'à son résultat.

Une capacité permet de demander ; elle ne garantit pas que chaque demande sera acceptée. Un outil disponible permet de mobiliser une action dans un cadre contrôlé ; il ne donne pas au modèle le droit de l'exécuter. L'action décrit la nature de l'opération, tandis que la conséquence en constitue l'instance contextualisée dans un traitement déterminé. Une proposition peut être complète et cohérente sans satisfaire les permissions ou préconditions nécessaires. Enfin, une conséquence n'est réussie que lorsque son résultat réel est suffisamment établi.

Cette séparation doit rester perceptible dans les données et les traces. Horizon ne doit pas confondre l'intention initiale, la décision du Noyau, l'instruction transmise, l'exécution tentée et le résultat obtenu.

Trois origines possibles d'une demande

Une proposition d'action peut provenir de trois origines fonctionnelles.

Demande déléguée par une personne

Une personne peut demander à P.O.U.B.E.L.L.E. d'effectuer une opération en son nom, par exemple consulter une information accessible ou modifier une donnée personnelle modifiable.

Le Noyau doit alors vérifier :

• L'identité de la personne.
• Sa permission actuelle sur l'opération et la cible.
• Le caractère admissible des paramètres.
• La disponibilité de l'outil dans ce contexte.
• La confirmation éventuelle requise.

P.O.U.B.E.L.L.E. facilite l'interaction mais n'élargit pas les droits de la personne. Une demande formulée naturellement ne peut pas obtenir davantage qu'une commande ou une interface ordinaire équivalente.

Initiative propre de P.O.U.B.E.L.L.E.

P.O.U.B.E.L.L.E. peut proposer ou demander une action lorsqu'elle agit dans le cadre d'une capacité de service explicitement accordée. Cette initiative doit être rattachée à :

• Un événement identifiable.
• Une règle ou un protocole prédéfini.
• Une tâche planifiée autorisée.
• Une anomalie détectée.
• Une finalité de supervision documentée.

Elle ne dispose pas d'une liberté générale d'administration fondée uniquement sur son appréciation. Sa proposition doit toujours être confrontée aux mêmes contrôles que les autres demandes.

Sollicitation produite par le Noyau

Le Noyau peut produire une demande à la suite d'un événement ou d'une tâche interne. Il peut alors solliciter une intervention de P.O.U.B.E.L.L.E. et, lorsque cela apporte une valeur, utiliser le LLM pour en préparer la formulation.

Lors d'un raid, par exemple, le Noyau peut établir qu'une annonce est nécessaire, sélectionner le modèle de prompt correspondant, fournir les informations autorisées sur l'événement et demander une réponse de P.O.U.B.E.L.L.E. Le texte produit reste une contribution à une conséquence déjà encadrée : il ne donne pas au modèle la maîtrise du Protocole de Raid ou de Twitch.

Une sollicitation du Noyau doit elle aussi posséder une finalité, une origine, un outil ou une conséquence identifiables. Le caractère interne de la demande ne lui permet pas de contourner les permissions, la classification ou les confirmations.

Catégories initiales d'outils

La cartographie suivante présente les principales familles actuellement identifiées. Elle est initiale et non définitive : d'autres catégories pourront être ajoutées au fil des chapitres suivants. Ces catégories ne sont pas exclusives : la consultation, la mémoire, la modification ou la notification décrivent une famille fonctionnelle, tandis que Twitch, Discord, le Web ou l'audiovisuel décrivent un domaine d'exécution. Une entrée du catalogue peut donc combiner les deux axes.

Catégorie	Finalité générale	Exemples fonctionnels
Consultation de données	Obtenir une information autorisée nécessaire à une réponse ou à un diagnostic.	Consulter un niveau, un statut, un état ou un résultat.
Actions conversationnelles	Communiquer avec une personne ou un espace autorisé.	Répondre, annoncer, reformuler ou envoyer un message privé prévu.
Mémoire et synthèses	Proposer, corriger ou supprimer une information mémorisée selon son cycle de vie.	Souvenir candidat, demande d'oubli ou synthèse qualitative.
Modification contrôlée de données	Demander une modification dont la finalité et l'autorité sont établies.	Modifier une donnée personnelle autorisée ou corriger une valeur non sensible.
Notifications et interventions	Informer une personne responsable ou demander une décision humaine.	Signaler une anomalie ou demander une confirmation à un Modérateur.
Actions Twitch	Mobiliser les fonctions propres aux directs et événements Twitch.	Message, interaction de direct ou conséquence liée à un raid.
Actions Discord	Mobiliser les fonctions communautaires propres à Discord.	Message, notification, rôle ou interaction privée autorisée.
Actions Web	Produire une conséquence visible ou exploitable depuis le Poste de commande.	Afficher un résultat ou transmettre une demande structurée.
Actions audiovisuelles	Agir sur les systèmes audiovisuels raccordés à Horizon.	OBS, TTS, Voicemod ou autre fonction de diffusion autorisée.
Protocoles et automatisations	Participer aux systèmes fonctionnels de La Tanière.	Protocole de Raid, événement communautaire ou séquence préparée.
Diagnostics et cohérence	Vérifier un état et signaler ou demander une correction.	Diagnostic, différence de données ou contrôle planifié.

Ces exemples n'accordent aucune capacité par eux-mêmes. Les outils concrets, leurs paramètres et leurs permissions seront définis après l'ensemble des chapitres dans l'Annexe K.

Présentation contrôlée des outils au LLM

Le LLM ne reçoit pas le catalogue complet par défaut. Le modèle de prompt sélectionné peut prévoir un emplacement pour les seuls outils pertinents, disponibles et autorisés dans la situation actuelle.

La description transmise peut notamment comprendre :

• L'identifiant de l'outil.
• Sa finalité.
• Les paramètres acceptés.
• Les valeurs ou formats attendus.
• Les cibles admissibles.
• Les limites utiles à la proposition.
• Le format textuel de la réponse attendue.

Cette présentation ne remplace pas les contrôles du Noyau. Une permission peut être retirée, une cible peut disparaître ou une précondition peut cesser d'être satisfaite entre la construction du prompt et l'exécution. Toutes les conditions doivent donc être vérifiées au moment de décider puis, si nécessaire, juste avant l'exécution.

Un outil non présenté doit être considéré comme indisponible pour l'appel. Le modèle ne doit pas inventer un identifiant, élargir une liste de paramètres ou proposer une connexion directe à un système extérieur.

Proposition textuelle structurée

Le modèle local reçoit un prompt textuel et produit un texte. Lorsqu'une action est envisagée, cette réponse doit respecter une structure interprétable par le Service LLM et le Noyau.

Une proposition peut notamment indiquer :

• L'identifiant de l'outil envisagé.
• La finalité ou l'intention comprise.
• La cible.
• Les paramètres proposés.
• Les informations manquantes.
• Les incertitudes identifiées.
• Le texte destiné à accompagner l'action, lorsque le modèle de prompt le prévoit.

Le format technique exact sera défini avec les contrats internes. Une proposition invalide, incomplète ou non conforme ne doit pas être interprétée de manière permissive. Le Noyau peut la refuser, demander une nouvelle proposition limitée ou appliquer le comportement de repli prévu.

Consultation de données en plusieurs étapes

Certaines réponses nécessitent une information qui n'a pas été intégrée au premier prompt. Le modèle peut proposer une consultation sans accéder lui-même à la source.

Le parcours est alors le suivant :

1. Le LLM produit une proposition de consultation structurée.
2. Le Noyau vérifie l'outil, la finalité, la cible et les droits de lecture ou d'utilisation.
3. La fonction compétente consulte uniquement les informations autorisées.
4. Le Noyau réduit et protège le résultat selon la finalité et le canal.
5. Une nouvelle instance de prompt reçoit le résultat admissible.
6. Le LLM prépare la réponse finale.
7. Le Noyau vérifie la divulgation avant la communication.

Cette boucle peut être limitée afin d'éviter les recherches successives non maîtrisées. Une consultation ne doit pas permettre au modèle de parcourir progressivement des données qu'il n'aurait pas été autorisé à recevoir dans un seul contexte.

Actions conversationnelles et communications

Une réponse de P.O.U.B.E.L.L.E. sur Twitch, Discord ou le Poste de commande constitue techniquement une action de communication. Les échanges ordinaires doivent pouvoir être envoyés sans confirmation humaine lorsqu'ils respectent un cadre préautorisé :

• Le modèle de prompt permet cette diffusion.
• Le canal et la cible sont établis.
• Les données utilisées et divulguées sont autorisées.
• Le texte satisfait les contrôles applicables.
• L'envoi ne produit pas de conséquence critique supplémentaire.

Le besoin de conversation ne doit pas être rendu impraticable par une limitation imposant arbitrairement un message de P.O.U.B.E.L.L.E. tous les X échanges. Un outil de réponse conversationnelle peut donc être déclaré sans fréquence maximale prédéfinie, tout en restant soumis aux protections générales contre les boucles, le spam technique et les abus.

Une communication majeure, une annonce sensible, une diffusion à grande échelle, un message privé administratif ou une formulation susceptible de révéler une donnée protégée peut nécessiter un cadre plus strict ou une confirmation particulière. Ces règles seront précisées avec les interfaces et les communications multiplateformes.

Mémoire et synthèses

P.O.U.B.E.L.L.E. peut proposer la création, la correction ou l'oubli d'une information selon les règles du chapitre 16. Le LLM peut préparer une catégorie et un contenu synthétique, mais le Noyau applique seul la modification persistante.

Les règles déjà établies restent applicables :

• Une proposition automatique de souvenir est contrôlée avant son enregistrement.
• Une demande ordinaire d'une personne peut conduire à la mémorisation d'une information autorisée sans confirmation supplémentaire.
• Une information présentant une sensibilité particulière exige l'avertissement et la validation prévus.
• Une catégorie interdite à la mémorisation durable doit être refusée.
• Une demande d'oubli exige l'identification et la confirmation explicite de la personne.
• Une suppression doit empêcher toute réapparition du contenu dans les futurs contextes.

L'outil ne doit jamais transformer l'espace mémoire en stockage libre ou contourner les limites de catégories, de durée et de remplacement.

Modification contrôlée de données

Le fait qu'une donnée soit non sensible ne signifie pas qu'elle peut être modifiée librement. Toute modification doit conserver une autorité, une finalité et une cible établies.

Trois situations générales sont distinguées :

Situation	Comportement attendu
Valeur correcte établie par une règle déterministe	Une correction automatique peut être autorisée après les contrôles ordinaires.
Demande d'une personne sur sa propre donnée modifiable	L'opération peut être exécutée après vérification de l'identité, de la permission et de la valeur proposée.
Modification seulement suggérée par le LLM	Aucune exécution automatique sans règle indépendante ou confirmation humaine adaptée.

Le LLM peut comprendre une demande comme la modification d'un nom d'affichage et en extraire la valeur envisagée. Le Noyau doit néanmoins vérifier que la personne peut modifier cette donnée, que le format est admissible et que l'opération ne produit aucune conséquence interdite.

Une correction automatique, déterministe et non sensible doit conserver les valeurs avant et après ainsi que la règle qui établit la valeur correcte. Lorsqu'elle est exécutée, elle déclenche une notification unique et consolidée adressée aux Super administrateurs et au Capitaine. Si la situation reste ambiguë, la modification doit être suspendue ou transmise à une personne habilitée.

Notifications et demandes d'intervention

P.O.U.B.E.L.L.E. peut signaler une anomalie, transmettre le résultat d'un diagnostic ou demander l'intervention d'une personne habilitée. Le Noyau choisit le destinataire selon le périmètre, la présence et les responsabilités actuelles ; le LLM ne sélectionne pas librement une personne ni un canal privé.

Une analyse communautaire peut, par exemple, produire une demande privée de vérification adressée à un Modérateur présent sur le direct. Le message peut expliquer l'élément détecté et l'incertitude correspondante, mais il ne doit pas présenter la sanction comme décidée.

Une notification ne doit pas devenir un moyen de divulguer davantage d'informations que nécessaire. Elle doit également éviter les répétitions lorsque plusieurs événements proches concernent la même situation. Les règles détaillées de regroupement, de priorité et de destinataire seront précisées dans les chapitres consacrés aux interfaces, aux permissions et à la modération.

Trois niveaux généraux d'action

Sans anticiper la matrice détaillée des actions critiques, trois niveaux fonctionnels sont reconnus.

Niveau	Signification
Action préautorisée	Peut être exécutée automatiquement lorsque les contrôles ordinaires, les préconditions et les limites sont satisfaits.
Action soumise à confirmation	Reste suspendue jusqu'à la décision d'une personne actuellement habilitée.
Action interdite	Ne peut pas être exécutée, même si une personne, P.O.U.B.E.L.L.E. ou le LLM la demande.

La classification doit être définie outil par outil. Une même catégorie peut contenir des actions de niveaux différents, et une opération ordinaire peut devenir critique en raison de sa cible, de son volume, de son contexte ou de ses conséquences cumulées.

Autorité de confirmation

Lorsqu'une confirmation est nécessaire, son auteur dépend de la nature de l'action :

• Une personne concernée confirme une opération sensible portant sur ses propres données.
• Un Modérateur ou un Administrateur habilité confirme une intervention relevant de son périmètre.
• Un Super administrateur confirme une opération d'administration technique autorisée.
• Le Capitaine confirme les opérations exceptionnelles relevant de son autorité.

La confirmation reste liée à une action, une cible, une durée et un contexte précis. Le Noyau doit vérifier de nouveau l'identité, les permissions et les préconditions avant l'exécution. Une confirmation antérieure ne constitue pas une autorisation permanente.

P.O.U.B.E.L.L.E. et le LLM ne peuvent jamais confirmer leur propre proposition. Le fait que P.O.U.B.E.L.L.E. occupe la fonction de commandant en second ne remplace pas l'autorité humaine requise.

Actions interdites

La liste suivante constitue un socle initial non définitif. D'autres interdictions pourront être ajoutées à mesure que les outils et systèmes seront détaillés.

P.O.U.B.E.L.L.E. et le LLM ne doivent jamais pouvoir utiliser un outil afin de :

• Modifier leurs propres permissions ou capacités.
• Modifier le canon, le modèle actif, les modèles de prompt ou les règles de sécurité.
• Désactiver les contrôles, confirmations ou mécanismes de traçabilité.
• Effacer, falsifier ou réécrire les journaux et traces d'audit.
• Accéder aux secrets d'authentification.
• Exécuter librement du code, une commande système ou une requête non cataloguée.
• Exporter massivement des données privées.
• Fusionner, supprimer ou réattribuer une identité sans la procédure humaine requise.
• Confirmer une action critique qu'ils ont proposée.
• Présenter comme réussie une action dont le résultat n'est pas établi.
• Contourner le Noyau, une extension ou les règles du service externe.
• Créer automatiquement un nouvel outil ou élargir ses paramètres autorisés.

Une personne habilitée ne peut pas utiliser P.O.U.B.E.L.L.E. pour contourner une interdiction générale qui s'appliquerait à la même opération depuis le Poste de commande.

Cycle d'une proposition d'action

Le cycle général complète le traitement défini au chapitre 8 :

1. Une personne, P.O.U.B.E.L.L.E. ou le Noyau produit une intention rattachée à un traitement.
2. Le Noyau détermine si l'intention est déjà suffisamment structurée ou si une contribution linguistique du LLM apporte une valeur utile.
3. Si le LLM est utile, le modèle de prompt lui présente uniquement les outils admissibles pour ce cas.
4. Le LLM peut alors produire une proposition textuelle structurée.
5. Le Service LLM vérifie que le format est interprétable et restitue la proposition au Noyau.
6. Dans tous les cas, le Noyau vérifie l'origine, la finalité, l'outil, la cible et les paramètres.
7. Il applique les permissions, la classification, les préconditions et les limites de fréquence.
8. Il refuse les actions interdites et suspend celles qui nécessitent une confirmation.
9. Une personne habilitée confirme ou refuse lorsque cela est nécessaire.
10. Le Noyau autorise, refuse, abandonne, annule ou déclare non applicable la conséquence.
11. La fonction interne ou l'extension compétente exécute uniquement l'instruction autorisée.
12. Le résultat disponible est retourné au Noyau.
13. Le Noyau consolide l'état réel, met à jour les informations concernées et produit les traces nécessaires.
14. P.O.U.B.E.L.L.E. peut communiquer le résultat établi dans les limites de divulgation applicables.

Chaque étape peut échouer ou rendre la suite inutile. Le Noyau ne doit pas poursuivre une branche dont les préconditions ne sont plus satisfaites, ni répéter une conséquence déjà établie.

Résultats, erreurs et incertitudes

Une instruction transmise ne prouve pas que l'action a réussi. L'extension ou la fonction responsable doit retourner un état exploitable, puis le Noyau détermine ce qui est réellement établi.

Une conséquence peut notamment rester prévue, en attente, en cours, réussie, refusée, échouée, abandonnée, annulée, expirée, non applicable ou incertaine. Ces états conservent les significations définies au chapitre 8.

P.O.U.B.E.L.L.E. ne doit annoncer une réussite que lorsque le résultat est suffisamment confirmé. En cas d'incertitude, elle peut signaler que l'opération a été demandée, qu'une réponse reste attendue ou qu'Horizon ne peut pas encore établir son résultat. Une formulation optimiste du LLM ne doit jamais masquer un échec ou une exécution partielle.

Une reprise doit tenir compte des conséquences déjà réussies et des capacités du service cible. Horizon doit éviter qu'un nouvel appel au LLM ou une répétition de l'événement produise plusieurs fois la même opération.

Limites de fréquence et prévention des abus

Chaque outil peut définir une politique adaptée à sa finalité :

• Utilisation sans fréquence maximale prédéfinie.
• Limite par personne.
• Limite par cible.
• Limite par canal ou interface.
• Limite globale.
• Délai minimal entre deux utilisations.
• Limite propre aux actions automatiques de P.O.U.B.E.L.L.E.
• Limite propre à un événement ou à une période.

Un outil conversationnel peut rester sans plafond fonctionnel afin que P.O.U.B.E.L.L.E. puisse répondre à une personne qui poursuit réellement l'échange. Cette absence de plafond ne désactive pas les protections techniques contre les boucles, les répétitions involontaires, la saturation ou le spam automatisé.

Les limites chiffrées seront définies outil par outil après observation des usages. Leur dépassement peut entraîner un refus temporaire, un report, une réponse de repli ou une notification selon le contexte ; il ne doit pas conduire le modèle à rechercher un autre outil pour contourner la limite.

Outil absent ou proposition invalide

Lorsqu'une proposition référence un outil absent, non présenté ou indisponible, ou lorsqu'elle contient des paramètres invalides, le Noyau doit :

1. Refuser la proposition concernée.
2. Ne pas deviner automatiquement un outil équivalent.
3. Demander éventuellement une nouvelle proposition corrigée lorsque le modèle de prompt l'autorise.
4. Appliquer sinon le comportement de repli prévu.
5. Conserver uniquement la trace nécessaire à l'explication ou au diagnostic.

Une correction automatique du format ne peut porter que sur une ambiguïté sans effet sur la cible, la portée ou la permission. Toute interprétation susceptible d'élargir l'action doit être refusée ou soumise à une nouvelle demande explicite.

Traçabilité et page des actions

Une action produisant une conséquence fonctionnelle doit rester rattachée à son traitement. La trace peut notamment comprendre, selon la nature et le risque :

• L'origine de la demande.
• La personne ou l'identité spéciale de P.O.U.B.E.L.L.E. à l'origine de la proposition.
• L'outil demandé.
• La cible.
• Les paramètres non sensibles nécessaires.
• Les contrôles effectués.
• La confirmation éventuelle et son auteur.
• La décision du Noyau.
• L'instruction transmise.
• Le résultat réel.
• Les erreurs, reprises ou incertitudes.
• Les dates et références du traitement.

Le contenu complet d'une conversation ordinaire ne doit pas être dupliqué systématiquement dans ces traces. Une référence, une catégorie ou une métadonnée peut suffire lorsque le message lui-même n'est pas nécessaire à l'explication de l'action.

Une page dédiée doit permettre de consulter un nombre limité d'actions récentes. Le volume affiché pourra être de vingt, cinquante, cent entrées ou une autre valeur adaptée à l'espace disponible ; il reste à définir. Cette fenêtre d'affichage ne détermine pas, à elle seule, la durée de conservation des journaux.

La visibilité doit suivre les responsabilités :

• Un Modérateur consulte les actions relevant de son périmètre de modération.
• Un Administrateur consulte les actions relevant des plateformes qu'il administre.
• Un Super administrateur consulte les actions techniques et administratives relevant de ses permissions Horizon.
• Le Capitaine dispose de la vision correspondant à son autorité générale.

L'accès à la page ne donne pas automatiquement accès à tous les contenus associés. Les données sensibles doivent rester masquées, réduites ou inaccessibles lorsque le rôle de la personne ne justifie pas leur consultation. Les règles détaillées relèveront des permissions, de la vie privée et de la journalisation.

Structure du catalogue détaillé

L'Annexe K décrira les outils effectivement retenus. Chaque entrée pourra préciser, selon les besoins :

• L'identifiant et le nom.
• La famille fonctionnelle, le domaine d'exécution et la finalité.
• Les origines de demande autorisées.
• Les paramètres et formats attendus.
• Les cibles possibles.
• Les données consultées ou modifiées.
• Les permissions nécessaires.
• Le niveau général de risque.
• La confirmation éventuelle.
• Les préconditions.
• Le résultat attendu.
• Les états d'erreur possibles.
• Le comportement de répétition ou d'idempotence.
• Les limites de fréquence.
• Les traces nécessaires.
• La fonction ou l'extension responsable de l'exécution.

Une propriété peut être héritée d'une catégorie ou d'une règle générale lorsqu'il n'est pas utile de la répéter pour chaque outil. Cette factorisation ne doit toutefois pas rendre ambiguës la permission, la confirmation ou la portée réelle de l'opération.

Le catalogue sera établi après les soixante-huit chapitres, comme les autres annexes, afin de reprendre les outils révélés par les interfaces, les systèmes fonctionnels, l'administration, la sécurité et l'exploitation. Le présent chapitre fournit la structure commune sans prétendre figer dès maintenant une liste exhaustive.

Garanties fonctionnelles

Les garanties suivantes doivent rester vraies pour chaque outil :

• Une capacité permet de demander une opération sans en garantir l'autorisation.
• Le LLM ne possède aucune connexion directe aux outils.
• Le Noyau connaît l'origine, la finalité, la cible et les paramètres de la proposition.
• Une personne ne gagne aucun droit supplémentaire en passant par P.O.U.B.E.L.L.E.
• P.O.U.B.E.L.L.E. n'emprunte aucune permission humaine.
• Une sollicitation interne du Noyau reste soumise aux protections applicables.
• Seuls les outils pertinents sont présentés dans le contexte.
• Une action critique reste suspendue jusqu'à une confirmation valide.
• Une interdiction ne peut pas être contournée par reformulation ou changement d'outil.
• Une opération externe n'est réussie que lorsque son résultat est établi.
• Une action répétée ne doit pas produire plusieurs fois la même conséquence sans intention explicite.
• Une limitation de fréquence doit être adaptée à la finalité de l'outil.
• Une conversation légitime ne doit pas être interrompue par un plafond arbitraire.
• Une action importante reste traçable sans reproduire inutilement les contenus personnels.
• Chaque personne ne consulte que les actions relevant de son périmètre de responsabilités.
• Les catégories et interdictions pourront être complétées sans affaiblir les garanties déjà établies.

Limites du présent chapitre

Le présent chapitre ne définit pas :

• La liste définitive des outils accessibles à P.O.U.B.E.L.L.E.
• Les commandes et paramètres propres à Twitch, Discord ou au Poste de commande.
• Les actions détaillées des protocoles et systèmes communautaires.
• Les permissions exactes de chaque rôle sur chaque outil.
• La classification détaillée des risques et des actions critiques.
• Les personnes précises habilitées à confirmer chaque opération.
• Les valeurs chiffrées des limites de fréquence.
• Le nombre définitif d'entrées présenté sur la page des actions.
• La durée complète de conservation des traces.
• Les contrats techniques, formats d'API et mécanismes d'appel internes.
• Les stratégies détaillées de reprise propres à chaque intégration.

Les fonctions Twitch, Discord et Web seront précisées dans la Partie VII. Les systèmes fonctionnels de La Tanière seront décrits dans la Partie VIII. Les permissions, la classification et les actions critiques relèveront de la Partie IX. Les outils de modération et d'administration seront détaillés dans la Partie X, puis les contrats techniques dans la Partie XI.

Synthèse

P.O.U.B.E.L.L.E. dispose de capacités de service propres lui permettant de consulter, communiquer, proposer une modification, mobiliser la mémoire, demander une intervention ou participer aux systèmes de La Tanière. Ces capacités sont limitées par leur finalité et ne reproduisent aucun rôle humain.

Une demande peut provenir d'une personne agissant dans son propre périmètre, d'une initiative encadrée de P.O.U.B.E.L.L.E. ou du Noyau à la suite d'un événement. Dans les trois cas, le modèle peut préparer une proposition textuelle structurée, mais le Noyau contrôle l'outil, la cible, les paramètres, les permissions, les limites et les confirmations avant toute exécution.

Les actions préautorisées peuvent être exécutées automatiquement lorsque leurs conditions sont satisfaites. Les actions critiques restent suspendues jusqu'à une confirmation humaine valide, tandis que les actions interdites demeurent impossibles. P.O.U.B.E.L.L.E. et le LLM ne peuvent ni confirmer leurs propres propositions, ni accéder directement aux outils, ni élargir leurs capacités.

Chaque résultat doit refléter l'exécution réellement établie. Les actions fonctionnelles restent traçables et une page permettra aux responsables de consulter les entrées récentes correspondant à leur périmètre. Le catalogue exhaustif sera construit dans l'Annexe K après les soixante-huit chapitres, lorsque l'ensemble des interfaces et systèmes aura révélé les outils nécessaires.