merge: promotion de develop vers main (doc + cloture #1)

Documente la chaine feature -> develop -> release -> tag et la regle
'tout commit lie a un ticket'.

closes #1

site/CHANGELOG.md

@@ -0,0 +1,5 @@
+## v0.2.0 (2026-06-16)
+
+### Feat
+
+- mise en place du workflow GitFlow et du versioning par tags (commitizen)

site/CONTRIBUTING.md

@@ -0,0 +1,86 @@
+# Process de développement — GitFlow (sans hotfix)
+
+Ce projet suit une variante de **GitFlow** sans branches *hotfix*, avec des
+commits conventionnels et un versionnage automatique géré par **commitizen** (`cz`).
+
+## 1. Les branches
+
+| Branche      | Rôle                                                        | Durée de vie |
+|--------------|-------------------------------------------------------------|--------------|
+| `main`       | Code en **production**. Chaque commit = une version taguée. | permanente   |
+| `develop`    | Branche d'**intégration**. Reçoit les features terminées.   | permanente   |
+| `feature/*`  | Développement d'une fonctionnalité. Part de `develop`.      | temporaire   |
+| `release/*`  | Préparation d'une **version (tag)**. Part de `develop`.     | temporaire   |
+
+> Pas de branche `hotfix` : les correctifs urgents passent par une `feature/*`
+> classique (ou directement par une `release/*` si déjà en cours).
+
+```
+main     ●────────────────────────●──────────────● (v0.1.0)   (v0.2.0)
+          \                      /                /
+develop    ●──●──●──────●──────●────●──●────────●
+               \      /             \          /
+feature/*       ●──●●               ●──●──●  (release/0.2.0)
+```
+
+## 2. Outils
+
+Installation de commitizen (une seule fois) :
+
+```bash
+pip3 install --user commitizen      # fournit la commande `cz`
+cz version                          # ou : python3 -m commitizen version
+```
+
+Le **numéro de version** du projet est stocké dans [`cz.toml`](./cz.toml).
+
+## 3. Cycle d'une fonctionnalité (`feature/*`)
+
+```bash
+# 1. Créer la branche depuis develop
+git switch develop
+git switch -c feature/ma-fonctionnalite
+
+# 2. Coder, puis committer avec commitizen (commits conventionnels)
+cz commit            # alias : cz c  — assistant interactif (type, scope, message)
+
+# 3. Pousser
+git push -u origin feature/ma-fonctionnalite
+
+# 4. Fusionner dans develop (via Merge Request, ou en local)
+git switch develop
+git merge --no-ff feature/ma-fonctionnalite
+git branch -d feature/ma-fonctionnalite
+```
+
+### Types de commits conventionnels (impactent la version)
+- `feat:` → nouvelle fonctionnalité → incrémente le **MINEUR** (0.1.0 → 0.2.0)
+- `fix:`  → correction de bug → incrémente le **CORRECTIF** (0.1.0 → 0.1.1)
+- `feat!:` ou `BREAKING CHANGE:` → incrémente le **MAJEUR** (0.x → 1.0.0)
+- `docs:`, `chore:`, `refactor:`, `test:`, `style:`, `ci:` → pas de bump
+
+## 4. Cycle d'une release (branche de tag)
+
+La création d'un tag de version se fait via une branche `release/*` et `cz bump`.
+
+```bash
+# 1. Créer la branche de release depuis develop
+git switch develop
+git switch -c release/x.y.z
+
+# 2. Calculer la nouvelle version + créer le tag + MAJ CHANGELOG.md
+#    (cz lit cz.toml, déduit la version depuis les commits, met à jour le fichier)
+cz bump                       # ajoute aussi un commit "bump: version X -> Y" et le tag vX.Y.Z
+
+# 3. Fusionner la release dans main ET dans develop
+git switch main
+git merge --no-ff release/x.y.z
+git switch develop
+git merge --no-ff release/x.y.z
+git branch -d release/x.y.z
+
+# 4. Pousser branches + tags
+git push origin main develop --follow-tags
+```
+
+> `cz bump --dry-run` permet de prévisualiser la prochaine version sans rien modifier.

site/DEMO.md

@@ -0,0 +1,52 @@
+# Démo — GitFlow + commitizen + tickets
+
+Chaîne complète : **chaque commit est lié à un ticket**, les versions et le
+CHANGELOG sont générés **automatiquement** (jamais à la main).
+
+## Règle d'or
+> Aucun commit sans ticket. Chaque message de commit référence une issue de la
+> forge avec un mot-clé : `closes #N`, `fixes #N` ou `resolves #N`.
+
+## 1. Créer le ticket (Forgejo)
+Ouvrir une issue dans la forge → on obtient un numéro, ex. `#12`.
+
+## 2. Développer sur une feature, commit lié au ticket
+```bash
+git switch develop
+git switch -c feature/ma-tache
+cz commit            # commit conventionnel guidé
+# Exemple de message (cf. `cz example`) :
+#   fix: correct minor typos in code
+#
+#   see the issue for details on the typos fixed
+#
+#   closes #12        <-- lien obligatoire vers le ticket
+```
+
+## 3. Intégrer dans develop
+```bash
+git switch develop
+git merge --no-ff feature/ma-tache
+```
+
+## 4. Générer le CHANGELOG (automatique)
+```bash
+cz changelog         # (re)génère CHANGELOG.md à partir des commits
+```
+
+## 5. Créer la release et le tag (automatique)
+```bash
+git switch -c release/x.y.z develop
+cz bump              # déduit la version (SemVer), MAJ cz.toml + CHANGELOG.md, crée le tag vX.Y.Z
+git switch main   && git merge --no-ff release/x.y.z
+git switch develop && git merge --no-ff release/x.y.z
+git push forge main develop --follow-tags
+```
+
+## Correspondance commit → version (SemVer)
+| Commit              | Effet sur la version      |
+|---------------------|---------------------------|
+| `fix:`              | correctif (0.0.**+1**)    |
+| `feat:`             | mineur (0.**+1**.0)       |
+| `feat!:` / BREAKING | majeur (**+1**.0.0)       |
+| `docs:` `chore:` …  | aucun bump                |

site/cz.toml

@@ -0,0 +1,13 @@
+# Configuration du versioning du projet (commitizen / "gitcz")
+# C'est ce fichier qui porte le NUMÉRO DE VERSION du projet.
+# `cz bump` lit/incrémente automatiquement la valeur `version` ci-dessous
+# en fonction des commits conventionnels, puis crée le tag git correspondant.
+[tool.commitizen]
+name = "cz_conventional_commits"   # Type de commits : Conventional Commits (feat:, fix:, ...)
+version = "0.2.0"                   # <== NUMÉRO DE VERSION du projet
+version_scheme = "semver"          # Versionnage sémantique MAJEUR.MINEUR.CORRECTIF
+tag_format = "v$version"           # Format des tags de release : v0.1.0, v0.2.0, ...
+major_version_zero = true          # Tant que la version commence par 0.x, pas de passage en 1.0 automatique
+update_changelog_on_bump = true    # Met à jour CHANGELOG.md à chaque release
+changelog_incremental = true
+annotated_tag = true               # Tags annotés (recommandé pour les releases)