# Fichier beeuni.toml hérité

État de la prise en charge et procédure de migration de beeuni.toml v1 vers beeuni.yaml v2.

Canonical page: https://beeuni.ai/docs/fr/project/legacy-toml

Cette page concerne le manifeste v1 (`beeuni.toml`, `beeuni_version: 1`). Pour consulter le manifeste actuel, voir [Référence du manifeste](/docs/fr/project/manifest).

<a id="support-status"></a>

## État de la prise en charge

Beeuni prend toujours en charge les manifestes v1. La plateforme recherche le manifeste d’un projet dans cet ordre : `beeuni.yaml`, puis `beeuni.yml`, puis `beeuni.toml`. Le modèle de démarrage actuel crée un `beeuni_version: 2` `beeuni.yaml`. Un projet v1 continue de fonctionner sans mise à niveau forcée.

La v1 accepte la syntaxe TOML ou YAML. La version 2 accepte uniquement YAML. Un manifeste v2 écrit en TOML échoue à la validation.

<a id="migrate-to-v2"></a>

## Migrer vers la v2

Créez `beeuni.yaml` à la racine du dépôt. Définissez `beeuni_version: 2`.
Convertissez `[[agents]]` en une map `agents:`, indexée par nom d’agent.
Renommez le champ `env` de chaque agent en `secrets`. Listez tous les secrets dont l’agent a besoin — la v2 n’accorde aucun secret par défaut.
Ajoutez `default_agent` en indiquant l’agent exécuté par défaut.
Supprimez `[[channels]]`. Reconnectez chaque canal depuis le tableau de bord.
Si vous utilisez `[sandbox]` ou `[[sandboxes]]`, déplacez chaque définition d’image sous `sandbox.templates`.
Exécutez `beeuni validate` sur `beeuni.yaml`. Corrigez toutes les erreurs signalées.
Supprimez `beeuni.toml`.

Le comportement de l’agent — prompt système, `model`, `mode`, `temperature` et plus encore — ne change jamais d’emplacement. Il se trouve déjà dans le frontmatter `.md` de chaque agent, sous `.beeuni/opencode/agents/`, en v1 comme en v2. Voir [Agents](/docs/fr/project/agents).

Vérifiez le résultat avec `beeuni validate --file beeuni.yaml`. Récupérez le schéma v2 complet avec `beeuni schema --version 2`. Consultez la [Référence CLI](/docs/fr/cli) pour ces deux commandes.

<a id="key-differences"></a>

## Principales différences

| v1 (`beeuni_version: 1`) | v2 (`beeuni_version: 2`) | Modification |
|---|---|---|
| `[[agents]]` (tableau) | `agents:` (map indexée par nom) | Convertissez chaque élément du tableau en entrée de map. |
| `[[agents]].env` | `agents.<name>.secrets` | Renommé. La valeur par défaut passe de `all` à `none` — voir l’encadré ci-dessous. |
| `[[agents]].model` | supprimé | Inactif en v1 (analysé, jamais appliqué). Le comportement de l’agent provient toujours du frontmatter `.md` de l’agent. |
| `[[agents]].file` | `agents.<name>.file` | Inactif en v1 (analysé, jamais appliqué). En v2, indique le `.md` de l’agent. |
| aucun `default_agent` | `default_agent` (obligatoire) | Doit désigner un agent déclaré et activé. |
| `[[channels]]` | supprimé | Le routage des canaux est géré depuis le tableau de bord. Un canal connecté apparaît sous la forme d’une entrée `connectors:` avec `provider: channel`. |
| `[sandbox]` (singulier, clés d’image directement dessus) | `sandbox.templates` (liste) | Déplacez chaque image dans une entrée de modèle. |
| `[[sandboxes]]` | `sandbox.templates` | Renommé. |

> **Par défaut, aucun secret en v2**
>
> En v1, un agent sans champ `env` reçoit par défaut tous les secrets du projet. En v2, un agent sans champ `secrets` n’en reçoit aucun. Lors de la migration, listez tous les secrets dont chaque agent a besoin — un agent qui perd un secret sans avertissement peut échouer en cours de tâche.

Certaines actions `beeuni_permissions` sont tolérées pour des raisons de compatibilité en v1 (`project.session.exec`, `project.gateway.routing.edit`, `project.schedule.read`, `project.schedule.write`, `project.webhook.read`, `project.webhook.write`, `channel.read`, `channel.connect`, `channel.send`, `channel.disconnect`) — la plateforme émet un avertissement, mais les autorise. Ces mêmes actions provoquent une erreur bloquante en v2. Supprimez-les de l’autorisation `beeuni_permissions` de tout agent avant la migration.