TENIR Labs · proposition éditoriale
Souveraineté d’exécution
Votre cloud est souverain. Vos agents le restent-ils ?
Sources et contexte de lecture
Proposition éditoriale TENIR Labs ; pages Offre, Architecture et Statut
Rendu public simplifié, lecture du 19 octobre 2026. KB3 : ligne de rendu doctrinale instituée et active. Elle rend le sens ; elle n’est pas le code, ni une constitution. KB2 : ligne antérieure. Ce site ne certifie aucune implémentation. Lire le statut détaillé →
Sur cette page
Garder les données sous votre contrôle est essentiel. Garder la maîtrise de ce que vos agents peuvent engager, relancer ou exporter l’est tout autant.
TENIR vous aide à définir les limites de l’action autonome, à traiter les situations d’incertitude et à préciser les preuves nécessaires avant de poursuivre.
Pour les équipes IA, risque et architecture · environnements sensibles · processus critiques
Environnement et périmètre
Votre environnement
Où le système opère
Données · Modèles · Clés · Accès · Infrastructure
Le périmètre de l’action
Ce qu’il peut engager
- Un mandat et une mission explicites
- Des limites de ressources partagées
- Un traitement défini de l’incertitude
- Une décision reliée à ses preuves
Tenir · trancher · prouver. Deux niveaux complémentaires de maîtrise. Une exigence commune : conserver l’autorité opérationnelle.
Le point de bascule
Une donnée peut rester locale. Une action peut malgré tout dépasser son mandat.
Autorité
Un accès n’est pas un mandat illimité
Un agent dispose d’un outil. Cela ne suffit pas à l’autoriser à engager n’importe quel montant, dans n’importe quelle mission ou sous n’importe quelles conditions.
Continuité
Continuer exige des conditions claires
Une perte de connexion change ce qui est connu. Définissez à l’avance ce qui peut continuer, ce qui doit attendre et qui peut autoriser la reprise.
Preuve
Un silence n’est pas une non-exécution
Un service peut avoir exécuté l’action sans renvoyer sa réponse. Avant de réessayer, distinguez l’intention, l’envoi et l’effet confirmé.
Le reçu manque
Parcours illustratif · 5 étapes
Le contrôle doit tenir. Un agent initie un paiement. Montant : [à définir après cadrage]. La réponse du prestataire se perd. Le parcours montre pourquoi « réessayer » devient une décision de gouvernance.
Cadre · explicite
Fixer ce qui doit rester intact
Le processus de trésorerie opère dans un environnement contrôlé. L’exigence métier reste explicite : une même intention de paiement ne doit pas produire deux effets.
Exigence à préserver
Une intention. Au plus un paiement effectif.
État de la situation
Cadre déclaré. L’hébergement et le contrôle de l’action sont deux sujets à traiter ensemble.
Mandat · borné
Nommer ce que l’outil n’autorise pas
L’agent dispose d’un moyen de paiement. Le mandat de cette mission est plus étroit : une intention, montant : [à définir après cadrage], au plus un effet. L’accès à l’outil ne l’autorise pas à engager n’importe quel montant, dans n’importe quelle mission, ni sous n’importe quelles conditions.
Exigence à préserver
Un mandat explicite. Un montant. Une seule intention.
État de la situation
Mandat nommé. L’accès et le droit d’engager restent deux décisions distinctes.
Incident · réponse absente
La réponse du prestataire ne revient pas
L’agent a initié le paiement. Montant : [à définir après cadrage]. La réponse se perd. Une perte de connexion change ce qui est connu : l’intention a été formée, l’envoi peut avoir eu lieu, l’effet n’est pas confirmé.
Exigence à préserver
Ne pas lire l’absence de réponse comme un échec certain, ni comme un succès.
État de la situation
Effet inconnu. Ce qui était su avant l’envoi ne suffit plus à continuer.
Retenue · reprise conditionnée
« Réessayer » n’est pas une suite automatique
Ce qui peut continuer, ce qui doit attendre, et qui peut autoriser la reprise se définissent à l’avance. Une relance exige des conditions de reprise. L’expiration d’un délai ne les remplace pas. Tant que l’effet reste non confirmé, une seconde exécution pourrait produire le deuxième paiement que l’exigence interdit.
Dans le vocabulaire du runtime, UNKNOWN décrit un résultat non confirmé. HOLD est une décision de retenue, notamment sur une demande de relance du même effet logique. L’autorisation historique reste distincte. Ce parcours décrit cette condition. Il ne rend pas le verdict. HOLD n’est pas la posture HOLDING-FIRST.
Exigence à préserver
Au plus un paiement effectif, y compris quand le premier résultat est inconnu.
État de la situation
Retenue. La reprise n’est pas ouverte par le seul silence.
Preuve · trois faits distincts
Distinguer l’intention, l’envoi et l’effet
Un service peut avoir exécuté l’action sans renvoyer sa réponse. Avant de réessayer, ces trois faits se tiennent séparés. Le silence n’établit pas la non-exécution. La preuve attendue n’est pas la preuve testée, et la preuve testée n’est pas une confirmation de cet effet-ci.
Exigence à préserver
Ne reprendre que lorsque l’intention, l’envoi et l’effet confirmé sont distingués.
État de la situation
Preuves non confondues. Le scénario s’arrête sur la question. Il ne livre pas un reçu.
Scénario explicatif, sans transaction réelle ni moteur de gouvernance connecté. La navigation décrit les conditions attendues ; elle ne démontre pas une garantie en production.
Relier la règle à l’action réelle
La question n’est pas seulement : « Cet agent a-t-il accès ? » Elle devient : « Cette action reste-t-elle admissible, avec ce mandat, ces engagements et ce que nous savons maintenant ? »
Au-delà de la requête isolée
Prendre en compte les engagements cumulés et les ressources partagées entre agents, dans un périmètre de stockage et de concurrence explicite.
Une incertitude qui compte dans la décision
Traiter un résultat inconnu comme un état à résoudre. Une relance exige des conditions de reprise, pas seulement l’expiration d’un délai.
Des garanties dont on connaît les limites
Relier chaque prétention à un scénario, un mécanisme de contrôle et une preuve vérifiable. Distinguer ce qui est attendu, testé et effectivement confirmé.
Diagnostic accompagné
Avant d’élargir l’autonomie, rendez ses limites explicites. Partez d’un processus réel. Identifiez les points où un agent peut engager une ressource, ne plus savoir si un résultat a eu lieu, ou poursuivre sous des hypothèses devenues fausses.
Cartographier
Actions, dépendances, autorités et points d’engagement.
Définir
Invariants, cas de retenue et conditions de reprise.
Éprouver
Scénarios d’incident, contrôles à vérifier et preuves à conserver.
Parlons de votre processus critique ↗
Un périmètre concret. Des décisions et des preuves à examiner. La forme du livrable est l’exemple de fiche. Le cadre du service est la page Offre. Les conditions se conviennent avant l’intervention.
Périmètre et statut
- Cette page est une proposition éditoriale. Elle ne décrit pas un déploiement, un client, ni une transaction réalisée.
- Les cinq étapes sont un scénario explicatif. Aucun moteur de gouvernance n’y est connecté. Les conditions affichées sont attendues. Elles ne sont pas une garantie démontrée en production.
- Montant : [à définir après cadrage]. Ce n’est pas une mesure observée.
- Ce qui est attendu, ce qui est testé et ce qui est effectivement confirmé restent trois registres. Cette page reste dans le premier. L’état du runtime est sur la page Statut.
- Le diagnostic accompagné est un format à cadrer. Aucun prix ni délai n’est fixé ici.