> ## Documentation Index
> Fetch the complete documentation index at: https://docs.samsa.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Provenance du contenu
> Comment l'API Samsa marque les images générées par IA — signature C2PA, filigrane invisible, exclusion SVG — et comment vérifier un fichier.
Les images produites par l'API Samsa sont des contenus générés ou modifiés par IA.
Cette page explique comment ces sorties sont marquées pour la provenance, comment
vérifier un fichier, et le seul format que le marquage ne peut pas couvrir.
Le marquage de provenance des sorties de l'API est en cours de déploiement. La
chaîne de signature et de filigrane est **dark-launched** — construite et déployée
derrière un flag — et s'applique aux fichiers raster livrés une fois active. Le
comportement décrit ici est l'état visé au lancement ; tant que le flag n'est pas
activé, les fichiers livrés par l'API ne sont pas encore marqués.
## Ce qui est marqué
Une fois le marquage de provenance actif, chaque image **raster** livrée par l'API —
génération, Magic Edit, img2img, variations, redimensionnement, upscale et suppression
d'arrière-plan — porte deux marqueurs :
* **Un manifeste C2PA.** Un enregistrement Content Credentials standard du secteur,
signé cryptographiquement et intégré au fichier, indiquant que l'image est générée
ou modifiée par IA et comment elle a été produite.
* **Un filigrane invisible.** Une marque durable et imperceptible portée par l'image
elle-même, afin que la provenance survive à une capture d'écran ou à un retrait des
métadonnées qui supprimerait le manifeste C2PA.
### Générée par IA vs modifiée par IA
L'enregistrement de provenance reflète **comment l'image a été produite**, déduit de
l'opération :
| Marqueur | Opérations |
| ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| **Générée par IA** | Génération d'image à partir d'un prompt (`POST /images/generations`) |
| **Modifiée par IA** | Opérations qui transforment une image d'entrée — Magic Edit, img2img, variations, redimensionnement, upscale, suppression d'arrière-plan |
Le marquage visuel EU AI Act qu'un spectateur voit est appliqué lorsqu'une image est
**téléchargée dans l'app Samsa** — c'est un label de la couche de présentation, et
il n'est **pas** appliqué aux fichiers livrés par l'API. L'API renvoie l'asset avec
son manifeste C2PA et son filigrane intégrés ; ajouter un label visible sur l'image
pour tes propres utilisateurs finaux est le choix de ton intégration.
## Vérifier un fichier
Le manifeste C2PA est lisible avec tout outil Content Credentials standard — rien de
spécifique à Samsa n'est requis :
* **Content Credentials Verify** — le vérificateur web sur
[contentcredentials.org/verify](https://contentcredentials.org/verify) : dépose une
image pour inspecter son manifeste.
* **`c2patool`** — l'[outil en ligne de commande C2PA](https://github.com/contentauth/c2pa-rs)
open source pour lire et valider les manifestes dans un pipeline.
Les deux rapportent les affirmations du manifeste et valident sa signature, pour que
tu puisses confirmer la provenance d'un fichier indépendamment de Samsa.
## SVG : une exclusion de périmètre au titre de l'art. 50(2)
La [vectorisation](/fr/api-reference/image-ops/vectorize) produit un **SVG**, qui ne
peut porter ni manifeste C2PA ni filigrane intégré. La sortie SVG est donc une
**exclusion de périmètre documentée au titre de l'art. 50(2) du EU AI Act** : les
fichiers vectoriels sont livrés **sans signature et sans filigrane**.
Parce que cette sortie ne peut pas être marquée, une requête de vectorisation doit
reconnaître l'exclusion avec `svg_acceptance: true` :
La reconnaissance `svg_acceptance` est une **preuve de divulgation / d'audit, pas
une renonciation à la conformité.** Elle enregistre que l'appelant a été informé que
le SVG est livré sans marquage ; elle ne change rien à l'obligation de marquage
sous-jacente, qui reste celle du fournisseur et est conditionnée par la faisabilité
technique.
Deux barrières indépendantes s'appliquent, et les deux rejettent **avant toute
facturation de credits** :
| Barrière | Exigence | Échec |
| -------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- |
| Reconnaissance | `svg_acceptance` doit être le booléen littéral `true` | [`422 svg_acceptance_required`](/fr/api-reference/image-ops/vectorize) |
| Acceptation des politiques | Ton organisation a accepté les ToS/AUP actuels (vérifié côté serveur — le flag de la requête n'est jamais cru comme ce fait) | `403 svg_phase1_scope_out_required` |
Accepte les conditions générales et la politique d'utilisation acceptable actuelles,
puis réessaie ; c'est l'enregistrement d'acceptation vérifié côté serveur — non le
flag de la requête — qui débloque la livraison.
## Voir aussi
L'opération SVG et son contrat de requête `svg_acceptance`.
Les six opérations derrière ces sorties.
L'enveloppe d'erreur et les codes de statut.
Ce que coûte chaque opération.