# Rôle `serveur_ops_site`

> **Généré** par `scripts/fiche_role.py` depuis les `meta/` de ce rôle.
> Ne pas éditer à la main : corriger la déclaration, puis régénérer.

> **Pour qui :** celui qui doit agir sur ce rôle et veut savoir, avant de toucher quoi que ce soit, qui lui parle, ce qu'il rend, et ce qu'il coûte.

```mermaid
graph LR
  R["<b>ops_site</b>"]
  R -.->|"sonde « pouvoir-materialiser »"| ICINGA[["Icinga"]]
```

## Qui lui parle

*Aucun flux entrant déclaré — `meta/flux.yml` absent ou sans `ingress`.*

## Ce qu'il rend à la supervision

| sonde | TTL | ce qu'elle voit |
|---|---|---|
| `pouvoir-materialiser` | 5400 s | Le runner du site peut-il encore materialiser, et son secret est-il toujours protege ? La carte de la fabric, la voute du site et sa cle ne font tomber aucun service en disparaissant — on s'en apercoit quand un ecosysteme doit naitre. Et une voute dechiffree en transit ne fait echouer aucun deploiement : Ansible la lit tres bien, elle expose simplement tout. |

## Ce qu'il expose en séries

*Aucun exportateur déclaré — voir `docs/metriques-conception.md`.*

## Ce qu'il coûte, et qui entre

- **Empreinte** : 0 cœur(s), 0 Mo, 0 Go.
- **Authentification** : `sans-auth-humaine` — Ce role n'expose aucune interface : il DETIENT un pouvoir au lieu d'en offrir un. Ce qui le protege n'est pas une authentification mais le fait que la voute deposee reste CHIFFREE et que son mot de passe soit tape a l'execution, jamais stocke.