---
type: explanation
title: Vérifier sans backend
summary: Ce qu'est la vérification hébergée, à qui elle s'adresse, et comment Caputchin vérifie un envoi et le relaie vers un webhook ou un e-mail pour que tu n'exécutes jamais de backend.
---

Un token Caputchin ne prouve rien tant que quelque chose ne le confirme pas. Normalement, ce quelque chose est [ton propre backend](/docs/integration-guides/verify-on-your-backend), qui appelle `/siteverify` et décide s'il faut faire confiance à la requête. La vérification hébergée déplace cette étape vers Caputchin : ton formulaire poste vers un relais Caputchin, Caputchin vérifie le token, laisse tomber tout ce qui échoue, et ne relaie que les envois vérifiés vers une destination que tu choisis.

C'est la même décision de confiance que la vérification backend, exécutée du côté de Caputchin plutôt que du tien. L'intérêt, c'est qu'il n'y a pas d'appel `/siteverify` à écrire ni de secret à garder sur un serveur, parce qu'il n'y a pas de serveur.

La vérification hébergée est une fonctionnalité payante, disponible sur Alpha et au-dessus.

## À qui elle s'adresse

La vérification hébergée existe pour le cas où exécuter un backend juste pour vérifier un token est plus que ce dont le projet a besoin.

| Tu es | Pourquoi ça convient |
|---|---|
| Un site statique (Webflow, Framer, HTML pur sur un CDN) | Il n'y a pas de serveur pour recevoir le formulaire ou appeler `/siteverify`. |
| Un constructeur no-code (Wix, Squarespace, Carrd) | Tu ne peux pas ajouter de code de vérification côté serveur. |
| Un développeur solo ou une petite équipe | Un formulaire de contact ou d'inscription ne vaut pas la peine de monter et d'exploiter un backend. |
| Déjà sur un backend, mais pas pour ce formulaire | Tu peux pointer un formulaire vers le relais et laisser le reste de ta stack tranquille. |

Si tu exécutes bien un backend et veux vérifier là, utilise plutôt [vérifier sur ton backend](/docs/integration-guides/verify-on-your-backend). Les deux sont des alternatives, pas des couches.

## Comment ça marche

```mermaid
sequenceDiagram
  autonumber
  participant U as Visiteur
  participant B as Navigateur (widget)
  participant F as Relais Caputchin
  participant D as Ta destination (webhook ou e-mail)

  U->>B: Remplit le formulaire et l'envoie
  B->>F: POST des champs plus le token caputchin
  Note over F: Vérifie le token, puis le retire de la charge
  alt Token valide
    F->>D: Livre l'envoi
    D-->>F: Accuse réception
    F-->>B: 200 avec le résultat de livraison
  else Token manquant ou invalide
    F-->>B: Rejeté, rien de livré
  end
```

Le relais retient l'envoi en mémoire seulement le temps qu'il faut pour le livrer. Il n'y a aucun stockage entre le post et la livraison, et le champ `caputchin-token` est retiré avant que la charge n'atteigne ta destination.

## Destinations

Tu en configures une ou les deux par clé de site. Activer les deux est un schéma courant : envoie vers un webhook pour le traitement et envoie-toi une copie par e-mail.

| Destination | Ce que tu reçois |
|---|---|
| **Webhook** | Un `POST` JSON portant les champs de ton formulaire plus les métadonnées de vérification de Caputchin. |
| **E-mail** | Un e-mail simple avec les champs du formulaire et un pied de page notant que Caputchin a vérifié l'envoi. |

Les livraisons ne sont pas signées. C'est le secret de l'URL du relais qui authentifie un appel de webhook, donc garde l'URL hors des dépôts publics et du code côté client. Le [tutoriel de configuration](/docs/hosted-verification/set-up) montre la charge exacte du webhook.

## Ce qui reste privé

La vérification hébergée suit la même posture sans-donnée-visiteur que le reste de Caputchin :

- **Les envois ne sont jamais stockés.** Ils vivent en mémoire de processus le temps du relais, puis ils ont disparu. Construis ton propre relevé côté webhook si tu en veux un.
- **Aucune donnée sur l'envoyeur n'est collectée.** Pas d'IP, pas de User-Agent, pas d'empreinte, pas de pistage.
- **La télémétrie est seulement agrégée.** Caputchin compte les réussites et échecs de livraison pour que tu voies si tes destinations sont en bonne santé, jamais le contenu d'un envoi. Vois [statistiques](/docs/hosted-verification/statistics).

## Comment une URL fournie par le client reste sûre

Une URL que les serveurs de Caputchin appelleront est un risque classique de Server-Side Request Forgery. Le relais rejette toute URL de webhook dont l'hôte est une adresse privée, de bouclage, link-local ou de métadonnées cloud, à la fois quand tu l'enregistres et de nouveau juste avant chaque livraison. Les catégories bloquées incluent :

| Catégorie | Exemples |
|---|---|
| Bouclage et non spécifiée | `127.0.0.1`, `0.0.0.0`, `::1` |
| Privée (RFC 1918) | `10.x.x.x`, `172.16.x.x` à `172.31.x.x`, `192.168.x.x` |
| Link-local et métadonnées cloud | `169.254.x.x`, en particulier le point de terminaison de métadonnées `169.254.169.254` |
| NAT de classe opérateur | `100.64.x.x` à `100.127.x.x` |
| Multicast et réservées | `224.x.x.x` et au-dessus |
| Noms d'hôte internes | `localhost` et tout hôte se terminant par `.local`, `.localhost` ou `.internal` |
| IPv6 privée | adresses link-local (`fe80::/10`) et unique-local (`fc00::/7`) |

Les encodages qui tentent de déguiser une adresse bloquée sont attrapés aussi : un hôte en entier décimal comme `http://2130706433/` ou un hôte hexadécimal comme `http://0x7f000001/` (qui signifient tous deux `127.0.0.1`) sont rejetés. Seules les URL `http` et `https` sont acceptées ; tout autre schéma est refusé. Le relais refuse aussi de suivre les redirections, donc un point de terminaison de webhook ne peut pas renvoyer l'appel vers une cible interne. Une URL bloquée remonte comme une erreur générique plutôt que spécifique, donc elle ne peut pas servir à sonder un réseau. Ton webhook doit donc vivre à une URL `https` publique.

## Ce qui est laissé de côté intentionnellement

- **Pas de boîte de réception d'envois.** Il n'y a aucun historique stocké des envois à parcourir dans le tableau de bord.
- **Pas d'adaptateurs Discord, Slack, Telegram ou SMS propriétaires.** Webhook et e-mail seulement. Un webhook peut diffuser vers n'importe lequel de ton côté.
- **Pas de téléversement de fichiers.** Le relais accepte les champs texte ; un envoi portant un fichier est rejeté.
- **Pas de transformation de charge.** Ce que le formulaire poste est ce que ta destination reçoit, plus les métadonnées de vérification.

## Voir aussi

- [Configurer la vérification hébergée](/docs/hosted-verification/set-up) : une marche à suivre qui la câble d'abord à une boîte de test.
- [Statistiques de vérification hébergée](/docs/hosted-verification/statistics) : lire la santé de livraison.
- [Vérifier sur ton backend](/docs/integration-guides/verify-on-your-backend) : l'alternative quand tu exécutes bien un serveur.