# Publication et review

> Soumettre en review (portail ou capibara deploy), ce que le build automatisé et la review vérifient, la validation automatique, les motifs de refus, publier, mettre à jour, le kill switch, le retrait de fiche et la fiche marketplace.
> Catégorie : Distribution · mis à jour le 2026-09-04 · plateforme v1

## Soumettre une version en review

Depuis un brouillon (`DRAFT`) valide, la soumission déclenche deux choses
immédiatement :

1. Une **revalidation complète du manifeste**, avec le même schéma que
   l'éditeur du portail. Si elle échoue, la version repart directement en
   `REJECTED` avec le détail des erreurs — sans attendre personne.
2. Un **build automatisé** : validation du manifeste, audit des dépendances
   du dépôt lié (registre npm), scan des sources (secrets, motifs interdits)
   et, pour le code hébergé, le bundle — construit par la plateforme au
   moment de `capibara deploy` (ou à la publication si la version vient de
   l'éditeur du portail). Aucun code tiers n'est exécuté hors de la sandbox.
   Un build rouge bloque la version avec le détail ; un build vert n'est pas
   une approbation : la review humaine juge le fond.

> Ne soumettez pas une app que vous n'avez pas testée : le harnais
> `@capibara-dev/sdk/testing` en local, puis `capibara dev` sur votre
> organisation de test (cf. [La CLI capibara](/dev/docs/cli)).

### Depuis la CLI

```bash
capibara deploy                    # bundle + version du manifeste → REVIEW
capibara deploy --version 1.2.0    # impose le semver
capibara deploy --publish          # publie une version APPROVED
capibara status                    # l'état de chaque version
```

`capibara dev` ne passe **jamais** par la review : il n'alimente que votre
installation de test (version brouillon). Une version en `REVIEW`,
`APPROVED` ou `PUBLISHED` n'est jamais réécrite (`version_locked`) :
incrémentez `version` dans le manifeste.

---

## Ce que la review vérifie

- **Le manifeste** — champs cohérents, permissions et capabilities
  proportionnées à ce que l'app annonce faire (cf. [Permissions et
  consentement du tenant](/dev/docs/permissions) et [Capabilities, bornes et
  erreurs](/dev/docs/capabilities)).
- **Les accès demandés, version par version** — le panneau de review affiche
  le **diff des permissions** avec la dernière version publiée (ajoutées,
  retirées, conservées, chacune avec sa phrase de consentement) et les
  **surfaces déclarées** (menus, widgets, panneaux, blocs et pages du site,
  planifications, routes HTTP, événements, collections, réglages). Un accès
  nouveau est jugé au regard de ce qu'il sert.
- **Un backend tiers = review humaine, toujours** — une page embarquée
  (`embedUrl`), des appels sortants (`http.fetch:<hôte>`) ou une app sans
  code hébergé mais avec des contributions ne passent JAMAIS par la validation
  automatique, même quand elle est active : l'équipe lit ce qui part vers
  l'extérieur.
- **La description honnête** — la baseline `i18n`, la tagline et la
  description de la fiche marketplace doivent correspondre à ce que l'app
  fait réellement. Une promesse non tenue (ex. « synchronisation en temps
  réel » pour un traitement en réalité manuel) est un motif de refus.
- **La catégorie correcte** — cohérente avec la fonction principale de
  l'app, pas choisie pour la visibilité.
- **Les permissions et capabilities** — au minimum nécessaire (principe du
  moindre privilège).
- **Le support** — un `support.email` valide et surveillé.
- **La sécurité et la qualité générale du code** — le build automatisé a
  déjà écarté les secrets en dur, les motifs interdits et les dépendances
  vulnérables ; la review lit ce que le build ne peut pas juger (usage des
  données, comportement).

---

## Délais et validation automatique

Il n'y a pas de délai contractuel affiché à ce stade : les versions
soumises sont traitées **dans l'ordre d'arrivée** par l'équipe Capibara.
Suivez le statut de votre version (`REVIEW`, `APPROVED`, `REJECTED`)
directement depuis la page de votre app sur le portail — aucune action de
votre part n'est nécessaire pendant l'attente. Chaque décision (approbation,
refus motivé) vous est envoyée par e-mail.

**Validation automatique.** L'instance peut activer une option (réglage de
la plateforme, désactivée par défaut) qui approuve une version **sans
lecture humaine** quand tout est réuni : build réussi, rapport propre
(aucun contrôle en échec ni en attente), version encore en `REVIEW`, et
**aucun backend tiers** — une page embarquée (`embedUrl`), un appel sortant
(`http.fetch:<hôte>`), un `backend: { url }` ou une app hybride avec des
contributions restent toujours lus par un humain. Vous recevez le même
e-mail d'approbation ; la publication reste votre geste.

---

## Motifs de refus courants

- Manifeste invalide ou champs incohérents entre eux (ex. `capabilities`
  déclarant `ui.widget` sans widget correspondant dans `contributes`).
- Permissions ou capabilities disproportionnées par rapport à la
  fonctionnalité décrite.
- Description ou tagline trompeuse, ou qui promet une fonctionnalité non
  implémentée.
- Absence de `support.email`, ou adresse manifestement non surveillée.
- Comportement suspect détecté à la lecture (appel réseau vers un domaine non
  déclaré dans `capabilities`, tentative de contournement des permissions).
- Contenu ou comportement contraire aux CGV Marketplace (logiciel
  malveillant, tracker non déclaré, violation de droits de tiers).

Un refus est toujours accompagné de notes explicites. Corrigez et resoumettez
— une version `REJECTED` redevient un brouillon modifiable.

---

## Publier une version approuvée

Une fois `APPROVED`, la publication est **une action volontaire** : rien ne
se publie automatiquement. Au premier `publish` d'un projet, la fiche
marketplace est créée automatiquement, avec :

- l'**accroche** reprise de votre baseline `i18n.fr` (modifiable ensuite) ;
- la **catégorie** du projet ;
- un **statut** `LISTED` (visible et installable).

Les publications suivantes du même projet mettent à jour la version publiée
sur la fiche existante.

### Retrait de fiche (`DELISTED`)

Distinct du kill switch : l'équipe Capibara peut **retirer votre fiche du
marketplace** (motif obligatoire, envoyé par e-mail). La fiche n'apparaît
plus au catalogue et ne peut plus être installée ; les organisations qui
l'ont déjà installée **continuent de l'utiliser** (sauf incident distinct).
La remise en ligne est notifiée de la même façon. Une fiche `DELISTED`
garde ses versions : corriger et republier ne la remet pas en ligne tout
seul — répondez au motif via l'espace support de votre app.

---

## Mettre à jour (nouvelle version)

Il n'y a pas de mise à jour « en place » : vous incrémentez le `version`
(semver) dans le manifeste, enregistrez un nouveau brouillon (portail ou
`capibara deploy --version x.y.z`), et refaites le cycle `submit` →
review → `publish`. Chaque version garde son propre
historique (`DRAFT`/`REVIEW`/`APPROVED`/`PUBLISHED`/`REJECTED`) — vous
pouvez avoir plusieurs versions dans des états différents en parallèle (par
exemple une `PUBLISHED` en production pendant qu'une prochaine est en
`REVIEW`).

Côté tenant, les mises à jour **ne sont jamais appliquées automatiquement** :
un administrateur doit ouvrir la fiche de son app installée et re-consentir
explicitement aux permissions de la nouvelle version pour l'appliquer.
Prévoyez que certains de vos utilisateurs restent sur une version antérieure
un moment.

---

## Le kill switch (incident global ou par tenant)

En cas d'incident (faille de sécurité découverte, comportement abusif,
signalement fondé), l'équipe Capibara peut **désactiver une version**
immédiatement :

- **Globalement** — la version est isolée pour tous les tenants qui l'ont
  installée.
- **Pour un seul tenant** — si le problème n'affecte qu'un espace précis
  (ex. donnée corrompue chez ce client), sans braquer le reste de votre base
  installée.

Chaque désactivation est enregistrée avec un motif et **vous est notifiée
par e-mail** (version, portée globale ou organisation, motif) ; elle peut
être levée dès que le problème est résolu. Pendant l'incident, toute
invocation de la version répond `killed` (cf. [Capabilities, bornes et
erreurs](/dev/docs/capabilities)) et l'API publique refuse les façades de ses
installations (423). Traitez-le en priorité : c'est le mécanisme qui protège
vos utilisateurs (et votre réputation de développeur) en attendant un
correctif — en général, une nouvelle version soumise en review.

---

## La fiche marketplace

Éditable depuis la page de votre app sur le portail, une fois une
première version publiée :

| Champ | Contrainte |
|---|---|
| Accroche (`tagline`) | ≤ 140 caractères. |
| Description (`descriptionMd`) | ≤ 20 000 caractères, en Markdown. |
| Captures d'écran | jusqu'à 8, chacune une URL d'image que vous hébergez (pas d'upload dédié pour la fiche — utilisez votre propre hébergement d'images). |
| Catégorie | reprise du projet, modifiable. |
| Icône | image carrée, ≤ 1 Mo, uploadée depuis l'en-tête de votre app sur le portail — affichée sur le portail **et** la fiche marketplace. |

Une fiche soignée (accroche claire, captures réelles de l'app en
fonctionnement, description qui explique le bénéfice concret) reste le
meilleur levier d'installation — la review juge la conformité, pas
l'attractivité, mais les deux vont mieux ensemble.