site/CHANGELOG.md

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

site/CONTRIBUTING.md

@@ -1,86 +0,0 @@
-# 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

@@ -1,52 +0,0 @@
-# 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

@@ -1,13 +0,0 @@
-# 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)