@ferrflow/doc 7.21.10 → 7.22.1

package/docs-en/ci/github-actions.md

@@ -43,6 +43,8 @@ FerrFlow needs `contents: write` to:
 
 If your repository has branch protection rules, create a dedicated token with the necessary permissions and pass it as `FERRFLOW_TOKEN` or configure the action's `token` input.
 
+Release commits and tags use the repository's git identity. If the job sets none, FerrFlow commits as `github-actions[bot]`, the account a `GITHUB_TOKEN` push is attributed to anyway. Outside GitHub Actions, a release with no `user.name` and `user.email` stops before bumping anything.
+
 <aside class="ferr-aside ferr-aside--tip"><div class="ferr-aside__body"><p>Prefer not to manage a token? Set <code>bot: true</code> to author releases as <code>ferrflow[bot]</code> with zero secrets: see the <a href="/docs/ci/hosted-bot">Hosted bot</a> guide.</p>
 </div></aside>
 

package/docs-en/ci/gitlab-ci.md

@@ -45,6 +45,12 @@ release:
     - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
 ```
 
+## Using `CI_JOB_TOKEN`
+
+The examples above pass the job token as `GITLAB_TOKEN: $CI_JOB_TOKEN`. FerrFlow recognises it because its value equals `CI_JOB_TOKEN`, and authenticates the way GitLab expects for a job token: API calls carry a `JOB-TOKEN` header and git pushes as `gitlab-ci-token`. The same applies when the job token is passed as `FERRFLOW_TOKEN`. Any other token (project, group or personal access token) is sent as `PRIVATE-TOKEN` and pushes as `oauth2`.
+
+What a job token may do is set per project under **Settings > CI/CD > Job token permissions**. Pushing the release commit and tags needs **Allow Git push requests to the repository**. When GitLab refuses one of the API calls FerrFlow makes with a job token, use a project access token with the `api` scope instead.
+
 ## Using a deploy token
 
 If `CI_JOB_TOKEN` doesn't have permission to push tags, create a project deploy token with `write_repository` access and store it as a CI variable:

package/docs-en/configuration/config-file.md

@@ -17,6 +17,14 @@ If no config file is found, FerrFlow auto-detects common version files in the cu
 <aside class="ferr-aside ferr-aside--tip"><div class="ferr-aside__body"><p>Add <code>&quot;$schema&quot;: &quot;https://ferrflow.com/schema/ferrflow.json&quot;</code> to your JSON config for editor autocompletion and validation.</p>
 </div></aside>
 
+FerrFlow warns about any key it does not recognise, in every config format and in included files, and suggests the closest valid key when there is one. The key is ignored and the command carries on:
+
+```
+Warning: unknown key `workspace.hooks.post-bump` in ferrflow.json, ignored. Did you mean `postBump`?
+```
+
+A misspelled option otherwise looks exactly like one left at its default, so treat these warnings as errors in your config.
+
 ## Config formats
 
 <div class="ferr-tabs">
@@ -181,7 +189,7 @@ Global settings that apply to all packages.
 | `releaseCommitMode`     | string  | `"commit"`                                                                  | How to handle the release commit: `"commit"`, `"pr"`, or `"none"`                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                |
 | `releaseCommitScope`    | string  | `"grouped"`                                                                 | In a monorepo where several packages are bumped at once, whether to create a single `"grouped"` commit or one commit `"per-package"`. Only matters when multiple packages bump.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |
 | `releaseCommitBody`     | string  | `"none"`                                                                    | What goes in the body of the release commit, below the subject. `"none"` keeps the single-line subject. `"summary"` lists one line per released package with its commit count. `"full"` embeds the changelog section written for each package — under `"grouped"` scope each section is headed `## <package> <version>`.                                                                                                                                                                                                                                                                                                                                                                                         |
-| `forge`                 | string  | `"auto"`                                                                    | Git forge override: `"auto"` detects from the remote URL, and for an unrecognised host it probes the API over HTTPS to auto-detect a self-hosted **GitLab**, **GitHub Enterprise**, or **Gitea / Forgejo** instance (cached, ~2s, best-effort). Set `"github"`, `"gitlab"`, `"gitea"` (Gitea / Forgejo / Codeberg), or `"bitbucket"` (Bitbucket Cloud) to force a forge — needed only when the host isn't reachable over HTTPS or you want to skip probing. Gitea auth uses `GITEA_TOKEN` / `FORGEJO_TOKEN`; Bitbucket uses `BITBUCKET_TOKEN`. All cover release creation — on Bitbucket, which has no release object, the release is the annotated tag FerrFlow pushes. PR mode is GitHub/GitLab only.          |
+| `forge`                 | string  | `"auto"`                                                                    | Git forge override: `"auto"` detects from the remote URL, and for an unrecognised host it probes the API over HTTPS to auto-detect a self-hosted **GitLab**, **GitHub Enterprise**, or **Gitea / Forgejo** instance (cached, ~2s, best-effort). The same answer picks the credential git pushes with, so a self-hosted GitLab pushes with `GITLAB_TOKEN` whatever its host name. Set `"github"`, `"gitlab"`, `"gitea"` (Gitea / Forgejo / Codeberg), or `"bitbucket"` (Bitbucket Cloud) to force a forge — needed only when the host isn't reachable over HTTPS or you want to skip probing. Gitea auth uses `GITEA_TOKEN` / `FORGEJO_TOKEN`; Bitbucket uses `BITBUCKET_TOKEN`. All cover release creation — on Bitbucket, which has no release object, the release is the annotated tag FerrFlow pushes. PR mode is GitHub/GitLab only.          |
 | `skipCi`                | boolean | depends on mode                                                             | Add `[skip ci]` to release commits. Defaults to `true` when mode is `"commit"`, `false` otherwise.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               |
 | `commitSkipMarkers`     | array   | `["[skip ci]", "[ci skip]", "[no ci]", "[skip actions]", "[actions skip]"]` | Markers that cause FerrFlow to skip a commit when computing the next version. Matched case-insensitively, subject line only.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     |
 | `commitFormats`         | object  | permissive conventional                                                     | Which commit subjects map to which bump level. Each of `major` / `minor` / `patch` takes a pattern string, a list of patterns, or `"all"` as a catch-all; `*` matches any run of characters (including `/`) and `?` exactly one. Resolution is major → minor → patch, first match wins. `caseSensitive` (default `true`) lowercases both sides when false. Defaults also accept capitalised and slash-separated variants (`Feat:`, `feat/`, `feature:`, `Fix/`, `Perf:`, `Refactor/`, and so on), listed in full under [permissive defaults](/docs/reference/conventional-commits). Breaking markers (`feat!:`, `fix(api)!:`, a `BREAKING CHANGE:` footer) are always detected regardless of what is configured. |

package/docs-en/reference/cli.md

@@ -395,7 +395,7 @@ ferrflow doctor [OPTIONS]
 | `--format <FMT>` | `human` (default) or `json`                                           |
 | `--online`       | Also probe the forge API (GitHub rate limit / auth); requires a token |
 
-The report groups checks into five sections — **Repo** (git repository, commit history, clean working tree, remote, tags), **Config** (which config file wins, whether it parses, plus the full `ferrflow validate` check suite), **Versioning** (strategy, each package's on-disk version, and whether its lockfile agrees with it), **Forge** (detected forge and whether an auth token is present in the environment), and **CI** (workflow files, and whether a workflow pins the `FerrLabs/FerrFlow` action). Every check reports green, a warning, or an error.
+The report groups checks into five sections — **Repo** (git repository, commit history, clean working tree, git identity, remote, tags), **Config** (which config file wins, whether it parses, plus the full `ferrflow validate` check suite), **Versioning** (strategy, each package's on-disk version, and whether its lockfile agrees with it), **Forge** (detected forge and whether an auth token is present in the environment), and **CI** (workflow files, and whether a workflow pins the `FerrLabs/FerrFlow` action). Every check reports green, a warning, or an error.
 
 Two of the **Versioning** checks are about lockfiles, and both matter for anything that builds with `--locked`. A lockfile recording a different version than the manifest beside it is reported outright, since that combination makes `cargo build --locked` refuse to run. A lockfile that is not covered by [`updateLockfiles`](/docs/configuration/config-file/) is flagged before it drifts, because nothing will keep it in step on the next release. Version comparison applies to `Cargo.lock`: pnpm, yarn, poetry, uv, bundler and mix lock dependencies without restating the version of the package that owns them, so there is nothing to compare, and those get the `updateLockfiles` check only.
 

package/docs-fr/ci/github-actions.md

@@ -43,6 +43,8 @@ FerrFlow a besoin de `contents: write` pour :
 
 Si votre repository a des règles de protection de branche, créez un token dédié avec les permissions nécessaires et passez-le via `FERRFLOW_TOKEN` ou configurez l'input `token` de l'action.
 
+Les commits et tags de release utilisent l'identité git du dépôt. Si le job n'en définit aucune, FerrFlow commite en tant que `github-actions[bot]`, le compte auquel un push via `GITHUB_TOKEN` est de toute façon attribué. Hors de GitHub Actions, une release sans `user.name` ni `user.email` s'arrête avant de modifier quoi que ce soit.
+
 <aside class="ferr-aside ferr-aside--tip"><div class="ferr-aside__body"><p>Vous préférez ne pas gérer de token ? Mettez <code>bot: true</code> pour attribuer les releases à <code>ferrflow[bot]</code> sans aucun secret : voir le guide <a href="/fr/docs/ci/hosted-bot">Bot hébergé</a>.</p>
 </div></aside>
 

package/docs-fr/ci/gitlab-ci.md

@@ -45,6 +45,12 @@ release:
     - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
 ```
 
+## Utiliser `CI_JOB_TOKEN`
+
+Les exemples ci-dessus passent le token du job via `GITLAB_TOKEN: $CI_JOB_TOKEN`. FerrFlow le reconnaît parce que sa valeur est égale à `CI_JOB_TOKEN`, et s'authentifie comme GitLab l'attend pour un token de job : les appels d'API portent un en-tête `JOB-TOKEN` et git pousse en tant que `gitlab-ci-token`. C'est aussi le cas quand le token du job est passé dans `FERRFLOW_TOKEN`. Tout autre token (token d'accès de projet, de groupe ou personnel) est envoyé en `PRIVATE-TOKEN` et pousse en tant que `oauth2`.
+
+Ce qu'un token de job a le droit de faire se règle par projet dans **Settings > CI/CD > Job token permissions**. Pousser le commit et les tags de release nécessite **Allow Git push requests to the repository**. Quand GitLab refuse un des appels d'API que FerrFlow fait avec un token de job, utilisez plutôt un token d'accès de projet avec le scope `api`.
+
 ## Utiliser un deploy token
 
 Si `CI_JOB_TOKEN` n'a pas les permissions pour pousser des tags, créez un deploy token de projet avec l'accès `write_repository` et stockez-le comme variable CI :

package/docs-fr/configuration/config-file.md

@@ -17,6 +17,14 @@ Si aucun fichier de configuration n'est trouvé, FerrFlow détecte automatiqueme
 <aside class="ferr-aside ferr-aside--tip"><div class="ferr-aside__body"><p>Ajoutez <code>&quot;$schema&quot;: &quot;https://ferrflow.com/schema/ferrflow.json&quot;</code> à votre configuration JSON pour l&#39;autocomplétion et la validation dans votre éditeur.</p>
 </div></aside>
 
+FerrFlow signale toute clé qu'il ne reconnaît pas, quel que soit le format de configuration et y compris dans les fichiers inclus, et propose la clé valide la plus proche quand il y en a une. La clé est ignorée et la commande continue :
+
+```
+Warning: unknown key `workspace.hooks.post-bump` in ferrflow.json, ignored. Did you mean `postBump`?
+```
+
+Sans cet avertissement, une option mal orthographiée ressemble en tout point à une option laissée à sa valeur par défaut : traitez-le comme une erreur dans votre configuration.
+
 ## Formats de configuration
 
 <div class="ferr-tabs">
@@ -181,7 +189,7 @@ Paramètres globaux qui s'appliquent à tous les packages.
 | `releaseCommitMode`     | string  | `"commit"`                                                                  | Gestion du commit de release : `"commit"`, `"pr"` ou `"none"`                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              |
 | `releaseCommitScope`    | string  | `"grouped"`                                                                 | Dans un monorepo où plusieurs packages sont bumpés en même temps, créer un seul commit `"grouped"` ou un commit `"per-package"`. N'a d'effet que quand plusieurs packages bumpent.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         |
 | `releaseCommitBody`     | string  | `"none"`                                                                    | Ce que contient le corps du commit de release, sous la ligne de sujet. `"none"` conserve le sujet sur une seule ligne. `"summary"` liste une ligne par package publié avec son nombre de commits. `"full"` intègre la section de changelog écrite pour chaque package — en scope `"grouped"`, chaque section est titrée `## <package> <version>`.                                                                                                                                                                                                                                                                                                                                                                                                                                                                          |
-| `forge`                 | string  | `"auto"`                                                                    | Forçage du forge git : `"auto"` détecte depuis l'URL du remote, et pour un hôte non reconnu il sonde l'API en HTTPS pour auto-détecter une instance auto-hébergée de **GitLab**, **GitHub Enterprise** ou **Gitea / Forgejo** (mis en cache, ~2s, best-effort). Renseignez `"github"`, `"gitlab"`, `"gitea"` (Gitea / Forgejo / Codeberg) ou `"bitbucket"` (Bitbucket Cloud) pour forcer un forge — nécessaire uniquement si l'hôte n'est pas joignable en HTTPS ou pour éviter le sondage. L'auth Gitea utilise `GITEA_TOKEN` / `FORGEJO_TOKEN` ; Bitbucket utilise `BITBUCKET_TOKEN`. Tous couvrent la création de release — sur Bitbucket, qui n'a pas d'objet release, la release est le tag annoté que FerrFlow pousse. Le mode PR reste GitHub/GitLab.                                                               |
+| `forge`                 | string  | `"auto"`                                                                    | Forçage du forge git : `"auto"` détecte depuis l'URL du remote, et pour un hôte non reconnu il sonde l'API en HTTPS pour auto-détecter une instance auto-hébergée de **GitLab**, **GitHub Enterprise** ou **Gitea / Forgejo** (mis en cache, ~2s, best-effort). Ce même résultat choisit l'identifiant avec lequel git pousse : une instance GitLab auto-hébergée pousse avec `GITLAB_TOKEN`, quel que soit son nom d'hôte. Renseignez `"github"`, `"gitlab"`, `"gitea"` (Gitea / Forgejo / Codeberg) ou `"bitbucket"` (Bitbucket Cloud) pour forcer un forge — nécessaire uniquement si l'hôte n'est pas joignable en HTTPS ou pour éviter le sondage. L'auth Gitea utilise `GITEA_TOKEN` / `FORGEJO_TOKEN` ; Bitbucket utilise `BITBUCKET_TOKEN`. Tous couvrent la création de release — sur Bitbucket, qui n'a pas d'objet release, la release est le tag annoté que FerrFlow pousse. Le mode PR reste GitHub/GitLab.                                                               |
 | `skipCi`                | boolean | dépend du mode                                                              | Ajouter `[skip ci]` aux commits de release. Par défaut `true` en mode `"commit"`, `false` sinon.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |
 | `commitSkipMarkers`     | array   | `["[skip ci]", "[ci skip]", "[no ci]", "[skip actions]", "[actions skip]"]` | Marqueurs qui font ignorer un commit par FerrFlow lors du calcul de la prochaine version. Comparaison insensible à la casse, sur la ligne de sujet uniquement.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             |
 | `commitFormats`         | object  | conventionnel permissif                                                     | Quels sujets de commit correspondent à quel niveau de bump. Chacun de `major` / `minor` / `patch` accepte un motif, une liste de motifs, ou `"all"` comme fourre-tout ; `*` correspond à n'importe quelle suite de caractères (y compris `/`) et `?` à exactement un. Résolution : major → minor → patch, premier motif gagnant. `caseSensitive` (défaut `true`) met les deux côtés en minuscules quand il vaut `false`. Les défauts acceptent aussi les variantes capitalisées et séparées par une barre oblique (`Feat:`, `feat/`, `feature:`, `Fix/`, `Perf:`, `Refactor/`, etc.), listées en entier dans [défauts permissifs](/fr/docs/reference/conventional-commits). Les marqueurs de rupture (`feat!:`, `fix(api)!:`, un pied de page `BREAKING CHANGE:`) sont toujours détectés quelle que soit la configuration. |

package/docs-fr/reference/cli.md

@@ -319,7 +319,7 @@ ferrflow doctor [OPTIONS]
 | `--format <FMT>` | `human` (défaut) ou `json`                                                     |
 | `--online`       | Sonder aussi l'API de la forge (rate limit / auth GitHub) ; nécessite un token |
 
-Le rapport groupe les vérifications en cinq sections : **Repo** (dépôt git, historique de commits, arbre de travail propre, remote, tags), **Config** (quel fichier de config l'emporte, s'il parse, plus toute la suite de vérifications de `ferrflow validate`), **Versioning** (stratégie, version sur disque de chaque package, et si son lockfile est d'accord avec elle), **Forge** (forge détectée et présence d'un token d'auth dans l'environnement) et **CI** (fichiers de workflow, et si un workflow épingle l'action `FerrLabs/FerrFlow`). Chaque vérification est verte, un avertissement, ou une erreur.
+Le rapport groupe les vérifications en cinq sections : **Repo** (dépôt git, historique de commits, arbre de travail propre, identité git, remote, tags), **Config** (quel fichier de config l'emporte, s'il parse, plus toute la suite de vérifications de `ferrflow validate`), **Versioning** (stratégie, version sur disque de chaque package, et si son lockfile est d'accord avec elle), **Forge** (forge détectée et présence d'un token d'auth dans l'environnement) et **CI** (fichiers de workflow, et si un workflow épingle l'action `FerrLabs/FerrFlow`). Chaque vérification est verte, un avertissement, ou une erreur.
 
 Deux des vérifications **Versioning** portent sur les lockfiles, et les deux comptent pour tout ce qui compile avec `--locked`. Un lockfile qui enregistre une version différente du manifeste voisin est signalé directement, cette combinaison faisant échouer `cargo build --locked`. Un lockfile que [`updateLockfiles`](/fr/docs/configuration/config-file/) ne couvre pas est signalé avant qu'il ne dérive, puisque rien ne le maintiendra à jour à la prochaine release. La comparaison de version s'applique à `Cargo.lock` : pnpm, yarn, poetry, uv, bundler et mix verrouillent les dépendances sans redonner la version du package qui les possède, il n'y a donc rien à comparer, et ceux-là n'ont que la vérification `updateLockfiles`.
 

package/docs-fr-v4/ci/github-actions.md

@@ -66,7 +66,7 @@ FerrFlow ajoute `[skip ci]` dans le message des commits de version par défaut p
 
 ## Commentaires de preview sur les PR
 
-FerrFlow peut poster un commentaire sur chaque pull request montrant quelles versions seront bump\u00e9es au merge. Le commentaire est mis \u00e0 jour automatiquement \u00e0 chaque push.
+FerrFlow peut poster un commentaire sur chaque pull request montrant quelles versions seront bumpées au merge. Le commentaire est mis à jour automatiquement à chaque push.
 
 ```yaml title=".github/workflows/preview.yml"
 name: FerrFlow Preview
@@ -92,15 +92,15 @@ jobs:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 ```
 
-Si aucun changement publiable n'est d\u00e9tect\u00e9, le commentaire l'indique.
+Si aucun changement publiable n'est détecté, le commentaire l'indique.
 
 ## Exemple monorepo
 
-Dans un monorepo, FerrFlow publie chaque package modifi\u00e9 en une seule ex\u00e9cution :
+Dans un monorepo, FerrFlow publie chaque package modifié en une seule exécution :
 
 ```yaml
 - uses: FerrLabs/ferrflow@v4
   env:
     GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-# Cr\u00e9e api@v1.3.0 et site@v0.5.1 en une seule \u00e9tape si les deux ont chang\u00e9
+# Crée api@v1.3.0 et site@v0.5.1 en une seule étape si les deux ont changé
 ```

package/docs-fr-v4/ci/gitlab-ci.md

@@ -55,7 +55,7 @@ release:
 
 ## Commentaires de preview sur les MR
 
-FerrFlow peut poster un commentaire sur chaque merge request montrant quelles versions seront bump\u00e9es au merge. Le commentaire est mis \u00e0 jour automatiquement \u00e0 chaque push.
+FerrFlow peut poster un commentaire sur chaque merge request montrant quelles versions seront bumpées au merge. Le commentaire est mis à jour automatiquement à chaque push.
 
 ```yaml title=".gitlab-ci.yml"
 ferrflow-preview:
@@ -70,8 +70,8 @@ ferrflow-preview:
     - if: $CI_PIPELINE_SOURCE == "merge_request_event"
 ```
 
-Si aucun changement publiable n'est d\u00e9tect\u00e9, le commentaire l'indique.
+Si aucun changement publiable n'est détecté, le commentaire l'indique.
 
 ## GitLab Releases
 
-Lorsque `GITLAB_TOKEN` est d\u00e9fini, FerrFlow cr\u00e9e une GitLab Release avec le changelog g\u00e9n\u00e9r\u00e9 comme notes de release, de la m\u00eame mani\u00e8re que l'int\u00e9gration GitHub.
+Lorsque `GITLAB_TOKEN` est défini, FerrFlow crée une GitLab Release avec le changelog généré comme notes de release, de la même manière que l'intégration GitHub.

package/docs-fr-v4/configuration/config-file.md

@@ -3,16 +3,16 @@ title: Configuration
 description: Référence complète du fichier de configuration FerrFlow.
 ---
 
-FerrFlow supporte six formats de fichier de configuration, recherch\u00e9s dans cet ordre :
+FerrFlow supporte six formats de fichier de configuration, recherchés dans cet ordre :
 
 1. `ferrflow.json`
 2. `ferrflow.json5`
 3. `ferrflow.toml`
-4. `ferrflow.ts` (n\u00e9cessite `tsx`)
-5. `ferrflow.js` (n\u00e9cessite `node`)
+4. `ferrflow.ts` (nécessite `tsx`)
+5. `ferrflow.js` (nécessite `node`)
 6. `.ferrflow` (JSON)
 
-Si aucun fichier de configuration n'est trouv\u00e9, FerrFlow d\u00e9tecte automatiquement les fichiers de version courants dans le r\u00e9pertoire actuel.
+Si aucun fichier de configuration n'est trouvé, FerrFlow détecte automatiquement les fichiers de version courants dans le répertoire actuel.
 
 <aside class="ferr-aside ferr-aside--tip"><div class="ferr-aside__body"><p>Ajoutez <code>&quot;$schema&quot;: &quot;https://ferrflow.com/schema/ferrflow.json&quot;</code> à votre configuration JSON pour l&#39;autocomplétion et la validation dans votre éditeur.</p>
 </div></aside>
@@ -102,20 +102,20 @@ package:
 </div></div>
 </div>
 
-<aside class="ferr-aside ferr-aside--note"><div class="ferr-aside__body"><p>Les configurations JSON, JSON5, et TypeScript/JavaScript utilisent des cl\u00e9s en <strong>camelCase</strong> (<code>tagTemplate</code>, <code>versionedFiles</code>).
-La configuration TOML utilise des cl\u00e9s en <strong>snake_case</strong> (<code>tag_template</code>, <code>versioned_files</code>).
-Les configurations YAML supportent les deux, mais <strong>camelCase</strong> est recommand\u00e9 pour la coh\u00e9rence avec JSON.
-Toutes les formes sont \u00e9quivalentes.</p>
+<aside class="ferr-aside ferr-aside--note"><div class="ferr-aside__body"><p>Les configurations JSON, JSON5, et TypeScript/JavaScript utilisent des clés en <strong>camelCase</strong> (<code>tagTemplate</code>, <code>versionedFiles</code>).
+La configuration TOML utilise des clés en <strong>snake_case</strong> (<code>tag_template</code>, <code>versioned_files</code>).
+Les configurations YAML supportent les deux, mais <strong>camelCase</strong> est recommandé pour la cohérence avec JSON.
+Toutes les formes sont équivalentes.</p>
 </div></aside>
 
 ### Configurations TypeScript et JavaScript
 
-Les fichiers de config TypeScript (`.ts`) et JavaScript (`.js`) utilisent un export ESM par d\u00e9faut. L'export peut \u00eatre un objet ou une fonction asynchrone.
+Les fichiers de config TypeScript (`.ts`) et JavaScript (`.js`) utilisent un export ESM par défaut. L'export peut être un objet ou une fonction asynchrone.
 
-<aside class="ferr-aside ferr-aside--warning"><div class="ferr-aside__body"><p>Les configs TypeScript n\u00e9cessitent <code>tsx</code> (<code>npm install -g tsx</code>). Les configs JavaScript n\u00e9cessitent <code>node</code> (v18+).</p>
+<aside class="ferr-aside ferr-aside--warning"><div class="ferr-aside__body"><p>Les configs TypeScript nécessitent <code>tsx</code> (<code>npm install -g tsx</code>). Les configs JavaScript nécessitent <code>node</code> (v18+).</p>
 </div></aside>
 
-L'avantage principal des configs TS/JS : les **hooks sous forme de fonctions**. Au lieu de commandes shell, vous pouvez \u00e9crire des hooks natifs avec acc\u00e8s complet au contexte :
+L'avantage principal des configs TS/JS : les **hooks sous forme de fonctions**. Au lieu de commandes shell, vous pouvez écrire des hooks natifs avec accès complet au contexte :
 
 ```ts title="ferrflow.ts"
 export default {
@@ -144,21 +144,21 @@ export default {
 
 #### Objet de contexte des hooks
 
-Les hooks en fonction re\u00e7oivent un objet de contexte avec ces champs :
+Les hooks en fonction reçoivent un objet de contexte avec ces champs :
 
 | Champ          | Type           | Description                                                |
 | -------------- | -------------- | ---------------------------------------------------------- |
 | `package`      | string         | Nom du package                                             |
-| `oldVersion`   | string         | Version avant le bump (vide pour la premi\u00e8re release) |
-| `newVersion`   | string         | Version apr\u00e8s le bump                                 |
+| `oldVersion`   | string         | Version avant le bump (vide pour la première release) |
+| `newVersion`   | string         | Version après le bump                                 |
 | `bumpType`     | string         | `major`, `minor`, `patch`, ou `none`                       |
 | `tag`          | string         | Nom complet du tag git                                     |
 | `dryRun`       | boolean        | Vrai si `--dry-run` est actif                              |
 | `packagePath`  | string         | Chemin absolu vers la racine du package                    |
-| `channel`      | string ou null | Nom du channel de pr\u00e9-release                         |
-| `isPrerelease` | boolean        | Vrai si c'est une pr\u00e9-release                         |
+| `channel`      | string ou null | Nom du channel de pré-release                         |
+| `isPrerelease` | boolean        | Vrai si c'est une pré-release                         |
 
-Les hooks sous forme de commandes shell et de fonctions peuvent \u00eatre m\u00e9lang\u00e9s dans la m\u00eame config.
+Les hooks sous forme de commandes shell et de fonctions peuvent être mélangés dans la même config.
 
 ## `workspace`