# Valider une configuration

`sovrium validate` décode un fichier de configuration face à `AppSchema` — le schéma que le serveur décode au démarrage — et signale chaque problème trouvé. La commande ne touche aucune base de données, ne lie aucun port et n'exige aucun environnement : c'est donc l'endroit le moins coûteux pour attraper une configuration cassée.

```bash
sovrium validate app.yaml
sovrium validate config.json
sovrium validate app.ts
```

Elle accepte `.json`, `.yaml`, `.yml` et `.ts`, et résout chaque inclusion `$ref` avant toute vérification — une configuration répartie sur vingt fichiers est donc validée comme l'objet unique qu'elle devient.

## À quoi ressemble un succès

```text
Valid configuration: my-app
```

Code de sortie `0`. Comme il s'agit du même décodage que celui effectué au démarrage, une configuration qui valide démarrera.

## À quoi ressemble un échec

Les problèmes s'affichent en arbre indenté sous un seul en-tête, avec le code de sortie `1`.

**Lisez-le par le bas.** L'arbre descend à travers le schéma avant d'atteindre votre configuration : le haut est de la mécanique — des dizaines de lignes `From side refinement failure` — et les deux dernières lignes portent le constat.

```text
Validation failed:
  { { { { App | filter } | filter } | filter } | filter }
  └─ From side refinement failure
     ... (de nombreuses lignes similaires)
                 └─ App
                    └─ ["tabels"]
                       └─ is unexpected, expected: "name" | "version" | "description" | ...
```

Celui-ci dit : vous avez écrit `tabels`, et ce n'est pas une propriété. Passer par `tail` est une habitude raisonnable :

```bash
sovrium validate app.yaml 2>&1 | tail -5
```

## Les trois classes d'erreur

| Classe                 | Exemple                                        | Détectée par                     |
| ---------------------- | ---------------------------------------------- | -------------------------------- |
| Structurelle           | `name` manquant ; un nombre donné à une chaîne | Le décodage `AppSchema`          |
| Propriété non reconnue | `tabels:` au lieu de `tables:`                 | Le rejet des propriétés en excès |
| Type de champ inconnu  | `type: web-site` sur un champ de table         | Le balayage post-décodage        |

La deuxième mérite qu'on s'y arrête : `sovrium validate` rejette les propriétés que le schéma ne connaît pas, au lieu de les ignorer. Sans cela, une clé mal orthographiée serait silencieusement écartée, et la fonctionnalité que vous croyiez avoir configurée n'apparaîtrait tout simplement jamais.

La troisième s'exécute _après_ le décodage, et s'affiche en clair plutôt qu'en arbre :

```text
Validation failed:
  Unknown field type "web-site" in field "website"
```

Avec une [configuration multi-fichiers](/fr/docs/configuration-refs), le constat est attribué à la partie dont il provient — `companies.yaml: Unknown field type ...`.

:::callout
**Les types de champ en un seul mot ne sont pas signalés.** Le balayage ne signale un type que s'il ne le reconnaît pas **et** qu'il contient un `-` ou un `_`. Un mot simple comme `colour` est traité comme un alias plausible, passe la validation, et échoue plus tard à la génération SQL. Vérifiez l'orthographe face à l'[Aperçu des types de champs](/fr/docs/field-types-overview) plutôt que de vous reposer sur ce seul balayage.
:::

## Codes de sortie

| Code de sortie | Signification                                                                      |
| -------------- | ---------------------------------------------------------------------------------- |
| `0`            | La configuration est valide                                                        |
| `1`            | Configuration invalide (erreur de décodage, type de champ inconnu, fichier absent) |

Tout échec vaut `1` : contrôler un pipeline tient donc en une ligne.

```bash
sovrium validate app.yaml || exit 1
```

Exécutez-la avant l'étape de déploiement. C'est le dernier point où une mauvaise configuration coûte des secondes plutôt qu'un retour arrière.

## Validation programmatique

Pour valider dans un script plutôt que dans un shell, `validateConfig()` retourne le résultat sous forme de données au lieu de quitter :

```typescript
import { validateConfig } from 'sovrium'

const result = validateConfig(JSON.parse(await Bun.file('app.json').text()))
if (!result.valid) console.error(result.errors.join('\n'))
```

Elle est délibérément plus permissive que le CLI : elle tolère les propriétés non reconnues et saute le balayage des types de champ inconnus. Utilisez-la comme garde-fou en mémoire, et gardez `sovrium validate` comme barrière avant déploiement. Détails complets sur [Validation et génération de schéma](/fr/docs/typescript-validate).

## Pages associées

- [Commandes de projet](/fr/docs/cli-project) — `sovrium validate` aux côtés d'`init`, `build`, `schema`.
- [Configuration de l'éditeur](/fr/docs/json-schema-editors) — attraper les erreurs structurelles à la frappe.
- [Configurations multi-fichiers](/fr/docs/configuration-refs) — comment les fichiers `$ref` sont attribués dans les erreurs.
- [Dépannage](/fr/docs/troubleshooting) — les autres erreurs qu'un démarrage peut afficher.