# Indicateurs de fonctionnalité

Activez une surface Beeuni pour un projet et découvrez ce que chaque indicateur contrôle.

Canonical page: https://beeuni.ai/docs/fr/feature-flags

Un indicateur de fonctionnalité active une fonctionnalité Beeuni pour un projet. N’importe quelle fonctionnalité peut être proposée derrière un indicateur — expérimentale, bêta ou entièrement stable. « Expérimental » est un badge de stabilité associé à un indicateur, et non le nom du système.

Les indicateurs sont propres à chaque projet. Activer un indicateur dans un projet ne change rien dans un autre projet ni pour les autres comptes.

- [Apps](/docs/fr/feature-flags/apps): Déployez des sites statiques, des bundles, des Dockerfiles et des images OCI sur des URL stables.

<a id="turn-a-flag-on"></a>

## Activer un indicateur

1. Ouvrez **Settings → Feature flags**. L’onglet répertorie tous les indicateurs pris en charge par la plateforme.
2. Consultez la ligne : le nom de l’indicateur, son badge de stabilité, une phrase de description et son origine — `Default on`, `Default off` ou
   `Overridden for this project`.
3. Utilisez le commutateur. La modification s’applique immédiatement au projet actuel.

Vous devez disposer de l’autorisation `project.settings.write` pour le projet. Pour tout autre appelant, la route renvoie `403`.

<a id="from-the-cli"></a>

### Depuis la CLI

Les mêmes commutateurs sont accessibles aux scripts et aux agents via `beeuni projects features` :

```bash
beeuni projects features                # every flag: key, state, origin
beeuni projects features enable reminders
beeuni projects features disable reminders
beeuni projects features reset reminders  # drop the override; follow the platform default
beeuni projects features --json          # the full catalog as JSON
```

Ajoutez `--project <id>` pour agir sur un projet autre que celui associé ou défini par défaut. Un indicateur que la plateforme déclare indisponible reste désactivé, quels que soient les paramètres du projet ; la CLI l’affiche sous la forme `n/a` / `unavailable`.

> **L’état des indicateurs ne se trouve pas dans votre dépôt**
>
> L’état des indicateurs propres à chaque projet est stocké dans la base de données, sur la ligne du projet. Il n’est jamais lu depuis `beeuni.yaml`. Un indicateur que vous activez n’est pas transféré avec un clone ou un fork du dépôt.

<a id="stability-badges"></a>

## Badges de stabilité

Le badge décrit le niveau de garantie, pas le commutateur. Un indicateur `stable` doit tout de même être activé explicitement : `apps` est stable et reste désactivé par défaut.

| Badge | Signification |
|---|---|
| Experimental | La fonctionnalité et son contrat peuvent encore évoluer. |
| Beta | La fonctionnalité fonctionne et sa forme se stabilise. |
| Stable | Le contrat est garanti. L’indicateur doit tout de même être activé explicitement. |

<a id="how-a-flag-is-enforced"></a>

## Application d’un indicateur

Chaque indicateur déclare un mode d’application.

| Mode | Comportement du serveur lorsque l’indicateur est désactivé |
|---|---|
| `routes` | La requête HTTP est rejetée avec `403`. |
| `behavioral` | Le comportement ne se produit pas — aucun connecteur n’est matérialisé, aucune variable d’environnement n’est injectée, aucun agent n’est enregistré. |
| `ui-only` | Le serveur n’applique délibérément aucune restriction. L’indicateur masque uniquement la fonctionnalité côté client. |

Un rejet `routes` est identique partout :

```json
{
  "error": "Apps is not enabled for this project. Contact Beeuni to enable it.",
  "code": "feature_disabled",
  "feature": "apps"
}
```

La chaîne `error` désigne la liste des indicateurs, et non un onglet en particulier. Cette liste correspond à l’onglet **Experimental** de Settings.

Testez `code`, jamais le texte du message. Le SDK exporte `isFeatureDisabledError(error)` et `featureDisabledKey(error)` à cette fin.

<a id="every-flag"></a>

## Tous les indicateurs

Ordre du registre — le même que celui affiché dans **Settings → Feature flags**.

Apps sont activés par projet par Beeuni. Contactez Beeuni pour demander l’accès. Settings affiche ensuite **Managed by Beeuni**.

| Clé | Nom | Stabilité | Valeur par défaut |
|---|---|---|---|
| `marketplace` | Marketplace | Beta | Activé |
| `connectors_api_discover` | Connectors API Discover | Experimental | Désactivé |
| `agentmail_email` | AgentMail Email | Experimental | Désactivé |
| `llm_gateway` | LLM Gateway | Experimental | Activé  |
| `meta_agent` | Meta Agent | Experimental | Désactivé |
| `apps` | Apps | Stable | Désactivé |
| `monitors` | Monitors | Experimental | Désactivé |
| `reminders` | Reminders | Beta | Désactivé |
| `warm_sessions` | Warm Sessions | Beta | Activé |
| `secrets_egress` | Network-Enforced Secrets | Experimental | Activé |
| `pi_harness` | Pi Harness  | Experimental | Désactivé |

<a id="what-each-flag-gates"></a>

### Fonctionnalités contrôlées par chaque indicateur

- **`marketplace`** — parcourir et installer des compétences depuis les registres de la communauté et des fournisseurs.
- **`connectors_api_discover`** — parcourir les interfaces API directes, MCP, GraphQL, CLI et Postman, à côté des applications OAuth gérées. Voir [Connecteurs](/docs/fr/connect/connectors).
- **`agentmail_email`** — attribuer des connexions de boîte de réception AgentMail afin que les e-mails entrants démarrent et poursuivent des sessions.
- **`llm_gateway`** — faire passer le projet par la passerelle LLM Beeuni gérée. Voir [Modèles](/docs/fr/project/models).
- **`meta_agent`** — ajouter un agent coordinateur géré par la plateforme qui lance et gère des sessions spécialisées.
- **`apps`** — déployer des sites statiques, des bundles, des Dockerfiles et des images OCI vers des URL serverless stables. Voir [Applications](/docs/fr/feature-flags/apps).
- **`monitors`** — exécuter des observateurs 24 h/24 et 7 j/7 depuis votre dépôt, qui déclenchent des événements dans les sessions. Voir [Déclencheurs](/docs/fr/connect/triggers).
- **`reminders`** — des rappels planifiés qui relancent une session, une fois ou de façon répétée. Désactivée, la route des rappels répond `feature_disabled` et les rappels existants ne se déclenchent pas. Voir [Rappels](/docs/fr/connect/reminders).
- **`warm_sessions`** — maintenir un sandbox démarré tant qu'un projet est ouvert, afin qu'une nouvelle session démarre sans démarrage à froid.
- **`secrets_egress`** — appliquer le contrôle réseau à un secret : le sandbox conserve un identifiant, et Beeuni ne substitue la vraie valeur que pour les requêtes vers des hôtes approuvés. Voir [Secrets](/docs/fr/project/secrets).
- **`pi_harness`** — exécuter les sessions de ce projet sur le harnais d'agent pi, dans le sandbox de session habituel (`BEEUNI_HARNESS=pi`). Activée : chaque nouvelle session ou session redémarrée lance pi, quelles que soient les indications du manifeste. Désactivée : le manifeste décide — `runtime: pi` lance toujours pi, toute autre valeur lance le moteur d’agent par défaut. pi appelle les modèles uniquement par l'intermédiaire de la passerelle LLM : si `llm_gateway` est désactivée, chaque session lance le moteur d’agent par défaut, quelles que soient la valeur de ce paramètre ou les indications du manifeste. Même structure de dépôt, mêmes agents et compétences dans les deux cas ; une session en cours conserve son harnais jusqu'à son redémarrage ou sa reprise. Les sous-agents fonctionnent sur pi : l'agent délègue avec l'outil `task` à `general`, à `explore` (en lecture seule) ou à tout agent du projet avec `mode: subagent` dans son `.md`, et la transcription affiche les étapes de chaque sous-agent à leur place. Les sessions pi chargent également les packages pi.dev : voir [`harnesses:`](/docs/fr/project/manifest#harnesses). pi ne prend pas en charge toutes les fonctionnalités de session d'le moteur d’agent par défaut : voir le tableau comparatif dans [Harnais](/docs/fr/work/harnesses#what-each-harness-supports).

<a id="graduated-flags"></a>

### Indicateurs généralisés

Une fonctionnalité généralisée est activée pour tous les projets et ne dispose d'aucun interrupteur.

- **Agents en tant que principaux** est le comportement standard et ne dispose d'aucun interrupteur. Une session d'agent agit en tant qu'agent lui-même — avec ses permissions Beeuni dans les limites de son rôle, quel que soit l'utilisateur qui la lance. Voir [Permissions des agents](/docs/fr/project/permissions).
- **Centre de révision** est sorti du système d'indicateurs. La page Review, la ligne Review de la barre latérale et la ligne de la palette de commandes s'affichent pour tous les projets ; les permissions `project.review.read` et `project.review.act` restent applicables.
  `review_center` n'est plus une clé d'indicateur : `PATCH /v1/projects/:id/features` répond `400` `Unknown feature flag`, et `beeuni projects features enable
  review_center` prints that error and exits `1`. Une dérogation enregistrée avant la généralisation n'a aucun effet.
- **Ordinateurs** est sorti du système d'indicateurs. Chaque membre peut connecter son propre ordinateur depuis la barre latérale du projet ; le paramètre `TUNNEL_ENABLED` de la plateforme est le seul verrou. `agent_tunnel` n'est plus une clé d'indicateur : `PATCH /v1/projects/:id/features` répond `400` `Unknown feature flag`.
  Voir [Ordinateurs](/docs/fr/connect/computers).
- **Microsoft Teams** est sorti du système d'indicateurs. Chaque projet peut connecter Teams depuis **Connectors → Channels** ; un administrateur du tenant doit toujours donner son consentement une fois, ou le projet doit fournir son propre bot. `teams` n'est plus une clé d'indicateur : `PATCH /v1/projects/:id/features` répond `400` `Unknown feature flag`. Une dérogation enregistrée avant la généralisation n'a aucun effet. Voir [Microsoft Teams](/docs/fr/connect/teams).

<a id="side-effects-of-a-toggle"></a>

## Effets secondaires d'un changement

Certains indicateurs mettent l'état de la plateforme en convergence une fois l'écriture validée.

| Indicateur | Effet après le changement |
|---|---|
| `agentmail_email` | Beeuni relance la matérialisation du connecteur de canal, qui apparaît ou disparaît selon la valeur de l'indicateur. |
| `llm_gateway` | Beeuni propage le nouveau mode fournisseur aux sandboxes actifs. |

Ces effets sont des opérations de convergence, et non une partie de la réussite du changement. La réponse de l'API ne les attend pas. Chaque effet fait l'objet d'une nouvelle tentative, et les réconciliateurs qui les exécutent sont idempotents et se relancent lors de leurs vérifications périodiques.

<a id="read-and-set-a-flag-from-code"></a>

## Lire et définir un indicateur dans le code

Lisez l'état effectif par projet via les détails du projet ou le hook React :

```tsx
import { useFeatureFlag } from '@beeuni/sdk/react';

function AppsNavItem({ projectId }: { projectId: string }) {
  const apps = useFeatureFlag(projectId, 'apps');
  if (!apps.enabled) return null;
  return <Link href={`/projects/${projectId}/apps`}>Apps</Link>;
}
```

`enabled` vaut `true` uniquement si le serveur a renvoyé exactement `true`. Un identifiant de projet manquant, une requête en cours ou une erreur donnent tous `false`. Appliquez une logique de refus par défaut.

Définissez la dérogation du projet avec le client :

```ts
const p = beeuni.project(projectId);

await p.updateFeatureFlag('apps', true);   // turn it on for this project
await p.updateFeatureFlag('apps', null);   // clear the override, inherit the default
```

`updateFeatureFlag` appelle `PATCH /v1/projects/:id/features`. `feature` est l'une des valeurs `FEATURE_FLAG_KEYS`, exportée depuis `@beeuni/sdk` et typée `FeatureFlagKey`. Voir la référence du SDK.

Gérez la désactivation d'une fonctionnalité dans le code, et non à partir d'un message :

```ts
import { featureDisabledKey, isFeatureDisabledError } from '@beeuni/sdk';

try {
  await beeuni.project(projectId).apps.list();
} catch (error) {
  if (isFeatureDisabledError(error)) {
    console.log(`${featureDisabledKey(error)} is off for this project`);
  }
}
```