Produits et Services

Des exigences à l’exécution : comprendre les rôles

Commencer par un diagnostic accompagné

Vous portez une question métier, de conformité ou de conception. Le point de départ est une situation précise : comprendre ce qu’une exigence implique, retrouver les éléments qui soutiennent un contrôle, ou éclaircir un usage de l’IA dans un processus.

La restitution, selon le périmètre convenu : une synthèse sourcée des constats, des inconnues et des lacunes, accompagnée d’un plan d’actions priorisé. Elle permet de préparer une décision et de retrouver ce qui la soutient.

Vous apportez	Nous examinons ensemble	Vous recevez
Une règle ou un processus, avec les documents et éléments disponibles	Les exigences, les contrôles annoncés, les éléments vérifiables et les écarts	Une synthèse avec ses sources et ses limites, puis les prochaines vérifications ou décisions proposées

Le diagnostic est un accompagnement à cadrer, pas un logiciel à installer. Un premier échange à distance sert à choisir la question. Une proposition précise ensuite le périmètre, les accès autorisés, la confidentialité, les livrables et les conditions commerciales. Aucun accès technique ou document sensible n’est requis pour prendre contact.

Discuter d’un diagnostic accompagné →

La page de contact aide à préparer votre message ; vous le relisez avant de l’envoyer depuis votre messagerie.

Cinq rôles distincts, une même question : que peut-on autoriser et prouver ?

Couche	Son rôle	Ce qu’elle ne prétend pas faire
TENIR	Cadre de diagnostic des systèmes sous pression et des options à préserver.	Ce n’est ni une API ni un produit de conformité.
REG	Standard proposé de gouvernance de l’exécution : autorité (standing), structure, engagement (commit), preuves et comportement en échec.	Une spécification ne démontre pas qu’un système la respecte.
REG+	Médiation hors runtime entre intention normative versionnée, hypothèses de déploiement et contraintes. Elle vise un profil candidat et ses invariants, ou un rejet motivé.	Pas un moteur autonome d’admission livré ou certifié ; la formalisation et les conditions de vérification restent à compléter.
TENIR-Gov	Logiciel d’application du contrôle à la frontière d’exécution, dans un périmètre de déploiement déclaré.	La bêta mono-hôte ne garantit ni un effet externe exactement une fois ni la conformité de tout environnement.
Prevent / Prepare	Deux méthodes d’examen proposées par TENIR Labs : exigences → contrôles candidats ; systèmes → pièces vérifiables.	Ce sont des parcours de travail, pas une seconde définition de REG.

Différenciation centrale : les modèles et les politiques peuvent proposer une action ; le droit de l’engager et la preuve de son effet sont des questions séparées. Une décision locale signée n’est pas un reçu du fournisseur externe.

Architecture logique et frontière d’intégration

Exigence métier + hypothèses vérifiables + contraintes
               │
         REG+ (médiation hors runtime)
               │ profil candidat / rejet / inconnues
               ▼
Agent ou application ── intention d'action versionnée
               │
               ▼
[Contrôle REG à la frontière d'exécution]
  1. Standing : autorité, portée, durée et révocation
  2. Structure : état, engagements, fraîcheur, contraintes
  3. Commit   : liaison action/grant/état, anti-rejeu et concurrence
               │ décision admissible et encore valide
               ▼
Connecteur autorisé ── API / fournisseur externe
               │ reçu ou résultat indéterminé
               ▼
Réconciliation + registre de décisions et de preuves

Contrat d’intégration minimal à convenir : identité et délégation de l’agent ; identifiant de l’intention et clé d’idempotence ; action et paramètres canoniques ; version du profil et état consulté ; validité temporelle ; réponse du connecteur ; corrélation et provenance des reçus. Les champs exacts doivent être alignés avec les RFC et la version de l’implémentation retenue.

Cas limites à éprouver avant ENFORCE : ordre concurrent, révocation entre évaluation et engagement, réessai après réponse perdue, journal périmé, disponibilité du registre, contournement du connecteur et attestation indépendante du fournisseur. UNKNOWN ne vaut ni succès ni échec ; la reprise doit être explicitement conditionnée.

Cette architecture est une vue logique cible, non une preuve d’intégration active. Lisez l’architecture détaillée, le statut publié et les démonstrations simulées pour séparer contrats, implémentation et comportement observé.

Deux parcours d’accompagnement : Prévenir et Préparer

Les produits et leur état d’avancement — capacités, accès et limites.
Les accompagnements — périmètres, déroulement et livrables.
Les démonstrations — ce que vous pouvez explorer et ce que chaque exemple permet d’observer.

Après le diagnostic : des étapes facultatives

Si la question concerne l’IA, l’examen peut porter sur sa présence réelle dans les outils, les données traitées, les décisions ou actions influencées et les protections disponibles. Un usage déclaré et un usage observé restent distingués.

Un pilote d’observation non bloquant peut ensuite être étudié si une intégration est justifiée et autorisée. Il nécessite une analyse des impacts techniques, des données et des responsabilités ; il n’est pas présenté comme sans risque ni comme déjà déployable chez tout client.

La gouvernance bloquante (ENFORCE) est une étape ultérieure soumise à validation des invariants, des modes de défaillance et des garanties dans un périmètre défini. Elle n’est ni automatique ni incluse dans le diagnostic.

Le problème

Deux écarts peuvent apparaître dans les organisations :

En amont : une exigence est publiée, mais ses conditions d’application, ses dépendances et ses hypothèses implicites restent dans l’ombre. On applique sans savoir ce qui est réellement requis.

En aval : des systèmes fonctionnent, des procédures existent — mais au moment de rendre des comptes, on ne peut pas démontrer clairement ce qui est couvert, partiellement vérifié ou absent.

Les deux parcours d’accompagnement peuvent examiner ces écarts séparément puis ensemble.

Parcours A — PRÉVENIR

De l’exigence vers la maîtrise

« Qu’implique réellement cette règle pour nos systèmes, nos décisions et nos risques ? »

Découvrir : extraire le texte, conserver la distinction entre source et interprétation
Révéler : faire apparaître les conditions implicites, les dépendances cachées, les ambiguïtés
Clarifier : transformer l’intention en règles candidates, sans masquer ce qui reste incertain
Rapprocher : identifier les contrôles qui répondent — ou devraient répondre — à chaque exigence
Livrer : un plan de prévention avec risques identifiés, hypothèses critiques et prochaines vérifications

Parcours B — PRÉPARER

Des systèmes vers la preuve

« Si un auditeur ou un régulateur demande demain, que pouvons-nous démontrer ? »

Définir le périmètre : ce qui est inclus, ce qui est laissé de côté
Recenser : documents, configurations, traces, tests — et marquer ce qui est déclaré mais absent
Qualifier : origine, date, validité, lien avec l’exigence, niveau de confiance
Rapprocher : faire correspondre ce qui est attendu à ce qui est disponible
Constituer : un dossier structuré, exportable, avec un registre explicite des lacunes
Agir : lister ce qui doit être retrouvé, vérifié ou créé pour compléter la réponse

Convergence : la matrice des écarts

Lorsque les deux parcours sont alimentés, la méthode met en regard :

Ce qui est attendu	Ce qui est disponible	État
Exigence clarifiée	Contrôle identifié	Couverture candidate — à vérifier
Exigence clarifiée	Contrôle déclaré ⚠️	À vérifier
Exigence clarifiée	Preuve absente ❌	Lacune — action requise
Hypothèse non résolue	—	À clarifier avant décision
Référence ambiguë	—	En attente de formulation stable

Aucune case ne devient “conforme” sur simple présence. Chaque conclusion porte son origine, sa date et ses limites.

Comment lire la restitution

Une pièce disponible, une déclaration et un contrôle vérifié portent des statuts différents. Une lacune reste visible et précise ce qu’elle empêche de conclure. La restitution aide à décider de la prochaine vérification ; elle ne constitue ni une certification, ni un avis juridique, ni une validation de production. Cet accompagnement ne revendique pas un audit en temps réel des systèmes et ne produit pas de preuves pour combler les absences.

État du projet

État de référence du 21 octobre 2026 :

Version : 0.1 — cadrage consolidé, Working Draft.
Accessible : un exemple simulé public, sans données client.
En développement : Discovery testé sur branche de travail, en aperçu privé ; Translation Studio en prototype ; Préparation en construction.
À éprouver : la valeur et le format de l’accompagnement lors des premières missions réelles.

Lire la spécification de cadrage REG v0.1 — Working Draft → Voir le dossier simulé — aucune donnée client → Nous contacter →