# What we prove

```json
{"@context":"https://schema.org","@type":"WebPage","name":"Ce que nous prouvons \u2014 Mnemom","description":"Les Alignment Cards sont la sp\u00e9cification d'intention. La proof chain est le lien d'ex\u00e9cution. Sign\u00e9es Ed25519, cha\u00een\u00e9es par hash, ind\u00e9pendantes du mod\u00e8le \u2014 la r\u00e9ponse zone-neutre \u00e0 \u00ab prouver quoi, exactement ? \u00bb","url":"https://www.mnemom.ai/fr/what-we-prove","inLanguage":"fr-FR","dateModified":"2026-06-08","publisher":{"@type":"Organization","@id":"https://www.mnemom.ai#organization","name":"Mnemom","url":"https://www.mnemom.ai"}}
```

```json
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://www.mnemom.ai/fr"},{"@type":"ListItem","position":2,"name":"Prouver quoi, exactement ?","item":"https://www.mnemom.ai/fr/what-we-prove"}]}
```

Pour les équipes régulées

# Prouver quoi, exactement ?

Les audit logs prouvent qu'un agent a fait quelque chose. Ce n'est pas suffisant quand un seul faux pas coûte 10 M$ et qu'un régulateur demande des preuves. Mnemom lie ce que l'agent était autorisé à faire à ce qu'il a réellement fait — cryptographiquement, à travers chaque modèle, à chaque appel.

[Lire la spéc de la card](https://docs.mnemom.ai/concepts/alignment-cards)[Voir ce que nous filtrons](/fr/security)

Spécification d'intention

### Alignment Cards

Une Alignment Card est un contrat signé : le périmètre dans lequel un agent est autorisé à opérer, exprimé assez structurellement pour qu'une machine l'applique et assez clairement pour qu'un CISO le signe.

-   Intention déclarée
    
    Ce que cet agent est autorisé à faire, en langage clair et en forme structurée signée.
    
-   Outils et scopes permis
    
    Surface exacte appelable. Rien en dehors de la card n'est atteignable au runtime.
    
-   Frontières de données
    
    Ce que l'agent peut lire, ce qu'il ne doit jamais écrire, et quelles zones sont hors limites.
    
-   Contrat d'escalade
    
    Quand l'agent doit transférer à un humain — et quelles preuves il doit apporter.
    
-   Obligations de conformité
    
    Liens vers les articles de l'EU AI Act, rôles HIPAA, clauses de rétention sectorielles.
    
-   Budget de drift
    
    Combien l'agent est autorisé à s'écarter du comportement de référence avant que l'AIP ne déclenche.
    

Lien d'exécution

### La proof chain

Chaque exécution produit une chaîne d'évidence signée. Chaque maillon atteste d'une part distincte de l'exécution de l'agent, rattachée au hash de la card et munie de preuves d'inclusion Merkle pour la vérification tierce.

1.  1
    
    Hash de la card
    
    L'intention déclarée, empreintée et signée.
    
2.  2
    
    Attestation d'entrées
    
    Chaque message, résultat d'outil et document récupéré qui a atteint l'agent.
    
3.  3
    
    Trace de décision
    
    Checkpoints de raisonnement, évaluations de politique et verdicts front-door — séquencés et signés.
    
4.  4
    
    Registre d'appels d'outils
    
    Chaque invocation d'outil, arguments et réponse — liés au scope permis par la card.
    
5.  5
    
    Certificat de sortie
    
    La réponse finale de l'agent, filtrée par back-door, signée Ed25519, liée à l'arbre de Merkle de l'exécution.
    

## Card en entrée. Preuve en sortie.

La card est la question que pose le régulateur. La preuve est la réponse que votre agent a déjà produite — signée, horodatée, vérifiable indépendamment.

Étape 1

Hash de la card

Étape 2

Attestation d'entrées

Étape 3

Trace de décision

Étape 4

Registre d'appels d'outils

Étape 5

Certificat de sortie

Chaque maillon signé Ed25519 · lié à l'arbre de Merkle avec preuves d'inclusion · exportable comme évidence pour régulateurs, auditeurs et underwriters.

## Quatre preuves que les régulateurs demandent réellement.

« On l'a loggé » n'est pas une preuve. Celles-ci le sont.

### Prouvez que l'agent a fait ce que la card déclarait.

Chaque réponse est liée cryptographiquement au hash de la card. Si l'exécution a divergé de l'intention, la preuve ne se vérifie pas.

### Prouvez qu'aucun outil non autorisé n'a été appelé.

Chaque appel d'outil tenté par l'agent est enregistré face au scope déclaré de l'Alignment Card. Les appels hors scope produisent une violation de frontière dans la trace signée.

### Prouvez qu'aucune donnée régulée n'a fuité.

Le filtrage back-door évalue chaque sortie face aux patterns PII/PHI/secrets ; le verdict est signé à côté de la sortie. Une fuite non caviardée ne peut pas produire un certificat valide.

### Prouvez que l'agent n'a pas été prompt-injecté en conformité.

Les verdicts front-door sur chaque message entrant font partie de la trace de décision. Une injection que l'agent a suivie est visible dans la chaîne ; une injection que l'agent a bloquée l'est aussi.

Posture zone-neutre

## Pourquoi les fournisseurs de modèles ne peuvent pas prouver cela pour vous.

La confiance d'agent est un problème inter-fournisseurs. Un plan de confiance construit à l'intérieur d'un lab frontalier est structurellement conflictuel — et structurellement incomplet.

### La confiance doit couvrir les fournisseurs.

Un Fortune 500 ne tourne pas sur un seul modèle. Claude, GPT, Gemini, Llama open-weights — tous en production, souvent sur le même workflow. Un plan de confiance construit par un seul vendeur de modèle est structurellement incapable d'attester des autres.

### Les dominants ne peuvent pas arbitrer.

Les fournisseurs de modèles ont un intérêt dans chaque verdict. Une vérification zone-neutre — le même standard d'évidence appliqué à chaque modèle, par une partie sans modèle à elle — est la seule posture qu'un régulateur créditera.

### Les cards sont portables ; les modèles ne le sont pas.

Une Alignment Card voyage avec l'agent à travers fournisseur, version et runtime. La proof chain est valide que le modèle sous-jacent soit changé demain, dans six mois, ou jamais.

Application runtime

## Mnemom AEGIS est le runtime qui transforme ces preuves cryptographiques en décisions d'application.

La chaîne de preuves produit des éléments de preuve signés. AEGIS est la couche de protection qui agit dessus — à quatre checkpoints, sur chaque gateway du réseau, avec des Managed Rules signées qui portent un objectif SLO de propagation inter-tenants P95 sous 30 secondes.

1

### AAP — Alignment Card

Déclare l'identité de l'agent, ses limites d'autonomie et ses engagements d'audit. Publique sur /.well-known/alignment-card.json.

2

### AIP — IntegrityCheckpoint

Vérifie le raisonnement de l'agent en vol. Verdict : clear, review-needed ou boundary-violation, avec preuve thinking-block hachée SHA-256.

3

### CLPI — Gouvernance + reçu

Gouverne le cycle de vie de la card sur cinq phases et ancre les Trust Ratings sur Base L2 pour vérification indépendante.

4

### Mnemom AEGIS — Chaîne d'évaluation

Filtre chaque transaction à quatre checkpoints × quatre modes ; signe les Managed Rules inter-tenants qui agissent sur l'image intégrée. Le runtime, le réseau et le reçu.

Construction honnête : AAP le déclare. AIP le vérifie en vol. CLPI gouverne son cycle de vie et ancre les preuves on-chain. AEGIS signe les défenses inter-tenants qui agissent dessus.

[Voir le learning network](/fr/learning-network)

## La card est le contrat. La chaîne est le reçu.

Câblez vos agents à Mnemom. Passez une card signée. Récupérez une réponse vérifiable à chaque action.

[Commencer sur le tier d'entrée](/fr/pricing)[Démarrage rapide](https://docs.mnemom.ai/quickstart)[Voir le flywheel](/fr/learning-network)

---
_Source: /fr/what-we-prove/index.html · Generated by build-markdown-mirrors.mjs · For agent-readability commitment #4 see https://www.mnemom.ai/for-agents_
