---
title: "Cycles de vie"
url: https://developers.dagio.ai/fr/lifecycles/
---

# Cycles de vie

   
                      
                                                                  
                  
              
          
   

## Un état porte un sens métier

Le cycle de vie décrit les états d’un objet et les transitions admises. Pour une soumission, Brouillon, À approuver, Acceptée et Refusée représentent des situations différentes. Un libellé ou une couleur ne définit pas à lui seul les opérations possibles.

| Élément | Valeurs attendues | Description |
| --- | --- | --- |
| États | Clés stables et libellés | Situations métier reconnues |
| État initial | Un état déclaré | Situation à la création |
| Transition | Origine, destination et Action | Changement explicite |
| Conditions | Règles et droits | Exigences avant changement |
| Effets | Opérations déclarées | Conséquences de la transition |

## Exemple

Une soumission naît Brouillon. **Demander une approbation** la fait passer à À approuver lorsque le client et le contenu sont valides. **Accepter** exige le rôle autorisé et enregistre la décision. Modifier directement le Field d’état dans une vue ne doit pas contourner cette transition.

## Concevoir la reprise

Ouvrez la source archivée concernée, puis **Restaurer cette source de fusion**. Cette commande
ouvre une revue ; elle ne restaure rien avant votre confirmation et la vérification de vos accès.

La restauration technique est distincte d'une transition métier. Restaurer une source archivée
par une fusion Knowledge confirmée utilise le reçu d'archive de cette même fusion et une nouvelle
revue explicite; cela n'annule ni l'Entry créée ni ses Links de provenance. Les droits actuels et
la policy de restauration déclarée restent requis. Une tête archivée ou un périmètre possédé
modifié doit être résolu avant confirmation. Après une réponse incertaine, reprendre la demande
revue et sa clé d'origine.

Si un descendant était déjà archivé avant la fusion, il reste dans cet état. La fusion ne le
réactive pas et ne modifie pas son contenu ; restaurer la fusion ne réactive que les contenus
effectivement archivés par cette opération. Les références restent intactes.

Définissez les transitions de correction et de réouverture nécessaires à votre activité. Distinguez l’état métier de la soumission et l’état technique du Flow qui la prépare : une exécution interrompue ne signifie pas que le client a refusé la proposition.

La [référence Foundation](https://developers.dagio.ai/fr/reference/workspace-model-foundation/) décrit les déclarations; le [suivi des Flows](https://developers.dagio.ai/fr/results/) explique leur présentation à l’usager.

<!-- surface-examples:start -->

## Exemples appliqués : Passer de prospect à client actif

La transition Activer vérifie les informations et demande confirmation avant de modifier l’état.

### Configuration

Fragment à placer dans `lifecycles[]`. [Propriétés et valeurs admises](https://developers.dagio.ai/fr/reference/workspace-model-foundation/).

```json
{
  "key": "client-status",
  "definitionPaths": [
    "workspace/clients/surface/client"
  ],
  "fieldKey": "status",
  "initialState": "prospect",
  "states": [
    "prospect",
    "active",
    "inactive"
  ],
  "transitions": [
    {
      "key": "activate",
      "label": "Activer le client",
      "from": [
        "prospect"
      ],
      "to": "active",
      "ruleKeys": [
        "company-required"
      ],
      "confirmation": true
    }
  ]
}
```

### Variante et raccordement

Fragment à placer dans `rules[]`. [Propriétés et valeurs admises](https://developers.dagio.ai/fr/reference/workspace-model-foundation/).

```json
{
  "contract": "WorkspaceRule@1",
  "key": "company-required",
  "label": "Entreprise renseignée",
  "expression": {
    "kind": "present",
    "field": {
      "definitionPath": "workspace/clients/surface/client",
      "fieldKey": "company"
    }
  }
}
```

### Exemple de disposition UI

La disposition illustrative ci-dessous situe cette configuration dans l’app Clients/Soumissions. Chaque fragment s’insère à l’emplacement indiqué; ses références aux Fields, Queries et Actions correspondent aux déclarations du Model.

1. Objet concerné
2. Changement proposé
3. Vérifications
4. Confirmer

<!-- surface-examples:end -->