Distribution

Publication et review

Mis à jour le 4 septembre 2026Plateforme v1 Markdown brut

Soumettre une version en review

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

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.
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).

Depuis la CLI

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 et Capabilities, bornes et
erreurs).
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) 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.