fix flyway docs & add fr localization

docs/workflow/FlyWay for postgresql + CICD/FlyWay workflow + CICD.md

@@ -1,306 +0,0 @@
-# Flyway Setup Guide for PostgreSQL + Tomcat Deployment
-
-## Goal
-
-This setup allows automatic database updates during deployment.
-
-Each database modification is added as a new SQL migration file. During CI/CD deployment, Flyway executes only the missing migrations safely and in order.
-
-This avoids:
-
-- giant SQL files
-- duplicate executions
-- manual tracking of DB changes
-- production inconsistencies
-
----
-
-# Environment
-
-This guide is adapted for:
-
-- PostgreSQL 17
-- Java 17
-- Maven Wrapper (`mvnw.cmd`)
-- Tomcat deployment
-- Existing production databases
-- Windows CI/CD runner
-
----
-
-# 1. Add Flyway to Maven
-
-## Add Flyway Maven Plugin
-
-In `pom.xml`:
-
-```xml
-<plugin>
-    <groupId>org.flywaydb</groupId>
-    <artifactId>flyway-maven-plugin</artifactId>
-    <version>11.0.0</version>
-</plugin>
-```
-
----
-
-## 2. Create Migration Folder
-
-Create this folder inside the project:
-
-```text
-src/main/resources/db/migration
-```
-
----
-
-# 3. Migration Naming Convention while for each Db modification a new file is added
-
-Flyway requires this exact format:
-
-```text
-V<version>__<description>.sql
-```
-
-Examples:
-
-```text
-V1__initial_schema.sql
-V2__task301_add_tables_t1_t2.sql
-V3__add_client_phone.sql
-V4__fix_invoice_indexes.sql
-```
-
-Important:
-
-- Use TWO underscores (`__`) after the version
-- Never rename old migrations after execution
-- Never modify old executed migrations
-
----
-
-# 4. Existing Database Initialization (One-Time Only)
-
-Since the database already exists in production, Flyway must first create its history table.
-
-## First Migration
-
-Create:
-
-```text
-V1__initial_schema.sql
-```
-
-This file represents the current database structure.
-
----
-
-## Baseline Existing Database
-
-Run once only:
-
-```cmd
-mvn flyway:baseline ^
--Dflyway.url=jdbc:postgresql://localhost:5432/TrizTresorie ^
--Dflyway.user=postgres ^
--Dflyway.password=YOUR_PASSWORD ^
--Dflyway.baselineVersion=1
-```
-
-This creates:
-
-```text
-flyway_schema_history
-```
-
-and marks version `1` as already applied WITHOUT executing the SQL.
-
----
-
-# 5. Adding New Database Changes
-
-Every new database modification must be added as a new migration file.
-
-Example:
-
-```text
-V2__task301_add_tables_t1_t2.sql
-```
-
-Example content:
-
-```sql
-CREATE TABLE table1 (
-    id BIGSERIAL PRIMARY KEY
-);
-
-CREATE TABLE table2 (
-    id BIGSERIAL PRIMARY KEY
-);
-```
-
-Commit the migration file with the application code.
-
----
-
-# 6. Running Migrations
-
-To execute pending migrations:
-
-```cmd
-mvn flyway:migrate ^
--Dflyway.url=jdbc:postgresql://localhost:5432/TrizTresorie ^
--Dflyway.user=postgres ^
--Dflyway.password=YOUR_PASSWORD
-```
-
-Flyway will:
-
-1. Check `flyway_schema_history`
-2. Detect already executed migrations
-3. Execute only new migrations
-4. Save execution history automatically
-
----
-
-# 7. CI/CD Integration
-
-Add this step before starting Tomcat.
-
-## Example
-
-```yaml
-# --------------------------------------------------
-# Run database migrations
-# --------------------------------------------------
-- name: Run database migrations
-  shell: cmd
-  run: |
-    cd %WORKSPACE_DIR%
-    mvnw.cmd flyway:migrate ^
-    -Dflyway.url=%DB_URL% ^
-    -Dflyway.user=%DB_USER% ^
-    -Dflyway.password=%DB_PASSWORD%
-```
-
-Recommended:
-
-- Store DB credentials in CI/CD secrets or environment variables
-- Do not hardcode passwords inside the repository
-
----
-
-# 8. Recommended Developer Workflow
-
-When a developer needs a database change:
-
-## DO
-
-Create a new migration:
-
-```text
-V5__add_product_status.sql
-```
-
-Commit and push.
-
----
-
-## DO NOT
-
-Do NOT modify:
-
-```text
-V1__initial_schema.sql
-```
-
-or any already executed migration.
-
-Always create a new migration instead.
-
----
-
-# 9. Important Notes
-
-## Migration Order
-
-Flyway executes migrations in version order:
-
-```text
-V1
-V2
-V3
-V4
-```
-
----
-
-## Failed Migrations
-
-If a migration fails:
-
-- deployment stops
-- Tomcat should not start
-- database remains protected from partial execution
-
-Fix the migration and rerun deployment.
-
----
-
-## Production Safety
-
-Do not:
-
-- delete `flyway_schema_history`
-- modify old executed migrations
-- manually rerun executed SQL files
-
----
-
-# 10. Example Project Structure
-
-```text
-project/
-│
-├── src/
-│   └── main/
-│       └── resources/
-│           └── db/
-│               └── migration/
-│                   ├── V1__initial_schema.sql
-│                   ├── V2__task301_add_tables_t1_t2.sql
-│                   ├── V3__add_client_phone.sql
-│                   └── V4__fix_indexes.sql
-│
-├── pom.xml
-└── mvnw.cmd
-```
-
----
-
-# 11. Final Deployment Flow
-
-Recommended deployment sequence:
-
-1. Clone source
-2. Build application
-3. Stop Tomcat
-4. Backup configuration
-5. Deploy new application
-6. Restore configuration
-7. Run Flyway migrations
-8. Start Tomcat
-9. Cleanup workspace
-
----
-
-# Result
-
-With this setup:
-
-- database updates become automatic
-- all environments stay synchronized
-- production deployments become safer
-- developers only add new migration files
-- no manual SQL tracking is needed
-

docs/workflow/FlyWay for postgresql + CICD/_category_.json

@@ -1,8 +0,0 @@
-{
-  "label": "Data Base Modification Workflow + flyway + CICD",
-  "position": 2,
-  "link": {
-    "type": "generated-index",
-    "description": "Standard workflow for Data Base Modification + flyway + CICD."
-  }
-}

docs/workflow/database-migrations/01-setup.md

@@ -0,0 +1,54 @@
+---
+sidebar_position: 2
+title: "Setup & Initialization"
+---
+
+# Setup & Initialization
+
+---
+
+## 1. Add the Flyway Maven Plugin
+
+To integrate Flyway into the project, add the following plugin to your `pom.xml`:
+
+```xml
+<plugin>
+    <groupId>org.flywaydb</groupId>
+    <artifactId>flyway-maven-plugin</artifactId>
+    <version>11.0.0</version>
+</plugin>
+```
+
+---
+
+## 2. Create the Migration Directory
+
+Flyway looks for migrations in a specific classpath location by default. Create the following directory inside your project structure:
+
+```text
+src/main/resources/db/migration
+```
+
+---
+
+## 3. Existing Database Initialization (One-Time Only)
+
+Since the database already exists in production, Flyway must create its internal tracking table (`flyway_schema_history`) and baseline the existing schema. This ensures Flyway knows the starting point and doesn't try to recreate existing tables.
+
+### 3.1 Create the Initial Migration
+
+Create a file named `V1__initial_schema.sql` inside the migration folder. This file should contain the SQL representing the complete, current database structure.
+
+### 3.2 Baseline the Existing Database
+
+Run the following command **once** to initialize Flyway without executing the `V1` SQL script against the already populated database:
+
+```cmd
+mvn flyway:baseline ^
+-Dflyway.url=jdbc:postgresql://localhost:5432/TrizTresorie ^
+-Dflyway.user=postgres ^
+-Dflyway.password=YOUR_PASSWORD ^
+-Dflyway.baselineVersion=1
+```
+
+This creates the `flyway_schema_history` table and marks version `1` as already applied. From this point forward, Flyway will only execute migrations starting from `V2`.

docs/workflow/database-migrations/02-creating-migrations.md

@@ -0,0 +1,49 @@
+---
+sidebar_position: 3
+title: "Creating Migrations"
+---
+
+# Creating Migrations
+
+---
+
+Every new database modification must be added as a **completely new** migration file. 
+
+## Naming Convention
+
+Flyway requires an exact naming format to recognize and order migrations correctly:
+
+```text
+V<version>__<description>.sql
+```
+
+### Examples
+- `V1__initial_schema.sql`
+- `V2__task301_add_tables_t1_t2.sql`
+- `V3__add_client_phone.sql`
+- `V4__fix_invoice_indexes.sql`
+
+> [!WARNING]
+> **Important Rules:**
+> - You **must** use exactly TWO underscores (`__`) after the version number.
+> - **Never** modify old executed migrations.
+> - **Never** rename old migrations after they have been executed on any environment.
+> - Always create a new migration file for new changes.
+
+---
+
+## Example Workflow
+
+If you need to add new tables for a specific task (e.g., Task 301), create a file named `V2__task301_add_tables_t1_t2.sql` with the necessary content:
+
+```sql
+CREATE TABLE table1 (
+    id BIGSERIAL PRIMARY KEY
+);
+
+CREATE TABLE table2 (
+    id BIGSERIAL PRIMARY KEY
+);
+```
+
+Commit this file alongside your application code changes and push it to the repository.

docs/workflow/database-migrations/03-cicd-integration.md

@@ -0,0 +1,89 @@
+---
+sidebar_position: 4
+title: "Execution & CI/CD Integration"
+---
+
+# Execution & CI/CD Integration
+
+---
+
+## Running Migrations Manually
+
+To execute pending migrations locally or manually on a specific environment:
+
+```cmd
+mvn flyway:migrate ^
+-Dflyway.url=jdbc:postgresql://localhost:5432/TrizTresorie ^
+-Dflyway.user=postgres ^
+-Dflyway.password=YOUR_PASSWORD
+```
+
+When you run this command, Flyway will:
+1. Check the `flyway_schema_history` table.
+2. Detect which migrations have already been executed.
+3. Execute only the new, pending migrations in version order.
+4. Save the execution history automatically.
+
+---
+
+## CI/CD Integration
+
+In your deployment pipeline, the database migration step must occur **before** the application server (e.g., Tomcat) starts.
+
+### Example Runner Step
+
+```yaml
+# --------------------------------------------------
+# Run database migrations
+# --------------------------------------------------
+- name: Run database migrations
+  shell: cmd
+  run: |
+    cd %WORKSPACE_DIR%
+    mvnw.cmd flyway:migrate ^
+    -Dflyway.url=%DB_URL% ^
+    -Dflyway.user=%DB_USER% ^
+    -Dflyway.password=%DB_PASSWORD%
+```
+
+> [!IMPORTANT]
+> Store database credentials securely using CI/CD secrets or environment variables. Do not hardcode passwords inside the repository scripts.
+
+---
+
+## Final Deployment Flow
+
+A standard, safe deployment sequence utilizing Flyway should follow these steps:
+
+1. Clone the source code.
+2. Build the application.
+3. Stop Tomcat.
+4. Backup configuration files.
+5. Deploy the new application artifacts.
+6. Restore configuration files.
+7. **Run Flyway migrations.**
+8. Start Tomcat.
+9. Clean up the workspace.
+
+---
+
+## Project Structure Reference
+
+For reference, a properly configured project will have a structure similar to this:
+
+```text
+project/
+│
+├── src/
+│   └── main/
+│       └── resources/
+│           └── db/
+│               └── migration/
+│                   ├── V1__initial_schema.sql
+│                   ├── V2__task301_add_tables_t1_t2.sql
+│                   ├── V3__add_client_phone.sql
+│                   └── V4__fix_indexes.sql
+│
+├── pom.xml
+└── mvnw.cmd
+```

docs/workflow/database-migrations/_category_.json

@@ -0,0 +1,8 @@
+{
+  "label": "Database Migrations",
+  "position": 2,
+  "link": {
+    "type": "generated-index",
+    "description": "Standard workflow for managing database schema changes using Flyway across different environments."
+  }
+}

docs/workflow/database-migrations/index.md

@@ -0,0 +1,27 @@
+---
+sidebar_position: 1
+title: "Overview & Goal"
+---
+
+# Overview & Goal
+
+---
+
+This guide details the setup and workflow for using **Flyway** to manage automatic database updates during deployments.
+
+By adding each database modification as a new SQL migration file, Flyway can safely execute only the missing migrations in the correct sequence during the CI/CD pipeline. 
+
+This approach eliminates the need for giant SQL files, prevents duplicate executions, removes the need for manual tracking of database changes, and ensures consistency across production environments.
+
+---
+
+## Environment Context
+
+This guide is specifically tailored for the following stack:
+
+- **Database:** PostgreSQL 17
+- **Runtime:** Java 17
+- **Build Tool:** Maven Wrapper (`mvnw.cmd`)
+- **Server:** Tomcat
+- **Database State:** Existing production databases
+- **CI/CD Environment:** Windows runners

i18n/fr/docusaurus-plugin-content-docs/current.json

@@ -35,6 +35,14 @@
     "message": "Workflow standard de l'attribution des tâches à l'achèvement en utilisant la stratégie rebase-then-merge.",
     "description": "The generated-index page description for category 'Developer Task Workflow' in sidebar 'docsSidebar'"
   },
+  "sidebar.docsSidebar.category.Database Migrations": {
+    "message": "Migrations de Base de Données",
+    "description": "The label for category 'Database Migrations' in sidebar 'docsSidebar'"
+  },
+  "sidebar.docsSidebar.category.Database Migrations.link.generated-index.description": {
+    "message": "Workflow standard pour la gestion des modifications de schéma de base de données à l'aide de Flyway dans différents environnements.",
+    "description": "The generated-index page description for category 'Database Migrations' in sidebar 'docsSidebar'"
+  },
   "sidebar.docsSidebar.category.Git Operations": {
     "message": "Opérations Git",
     "description": "The label for category 'Git Operations' in sidebar 'docsSidebar'"

i18n/fr/docusaurus-plugin-content-docs/current/workflow/database-migrations/01-setup.md

@@ -0,0 +1,54 @@
+---
+sidebar_position: 2
+title: "Configuration & Initialisation"
+---
+
+# Configuration & Initialisation
+
+---
+
+## 1. Ajouter le Plugin Maven Flyway
+
+Pour intégrer Flyway au projet, ajoutez le plugin suivant à votre `pom.xml` :
+
+```xml
+<plugin>
+    <groupId>org.flywaydb</groupId>
+    <artifactId>flyway-maven-plugin</artifactId>
+    <version>11.0.0</version>
+</plugin>
+```
+
+---
+
+## 2. Créer le Répertoire de Migration
+
+Par défaut, Flyway recherche les migrations dans un emplacement spécifique du classpath. Créez le répertoire suivant dans la structure de votre projet :
+
+```text
+src/main/resources/db/migration
+```
+
+---
+
+## 3. Initialisation de la Base de Données Existante (Une Seule Fois)
+
+Étant donné que la base de données existe déjà en production, Flyway doit créer sa table de suivi interne (`flyway_schema_history`) et établir une ligne de base (baseline) du schéma existant. Cela permet à Flyway de connaître le point de départ et de ne pas essayer de recréer des tables existantes.
+
+### 3.1 Créer la Migration Initiale
+
+Créez un fichier nommé `V1__initial_schema.sql` dans le dossier de migration. Ce fichier doit contenir le code SQL représentant la structure complète et actuelle de la base de données.
+
+### 3.2 Établir la Ligne de Base (Baseline)
+
+Exécutez la commande suivante **une seule fois** pour initialiser Flyway sans exécuter le script SQL `V1` sur la base de données déjà peuplée :
+
+```cmd
+mvn flyway:baseline ^
+-Dflyway.url=jdbc:postgresql://localhost:5432/TrizTresorie ^
+-Dflyway.user=postgres ^
+-Dflyway.password=VOTRE_MOT_DE_PASSE ^
+-Dflyway.baselineVersion=1
+```
+
+Cela crée la table `flyway_schema_history` et marque la version `1` comme étant déjà appliquée. À partir de ce moment, Flyway n'exécutera que les migrations à partir de `V2`.

i18n/fr/docusaurus-plugin-content-docs/current/workflow/database-migrations/02-creating-migrations.md

@@ -0,0 +1,49 @@
+---
+sidebar_position: 3
+title: "Création de Migrations"
+---
+
+# Création de Migrations
+
+---
+
+Chaque nouvelle modification de la base de données doit être ajoutée sous la forme d'un **tout nouveau** fichier de migration.
+
+## Convention de Nommage
+
+Flyway exige un format de nommage exact pour reconnaître et ordonner correctement les migrations :
+
+```text
+V<version>__<description>.sql
+```
+
+### Exemples
+- `V1__initial_schema.sql`
+- `V2__task301_add_tables_t1_t2.sql`
+- `V3__add_client_phone.sql`
+- `V4__fix_invoice_indexes.sql`
+
+> [!WARNING]
+> **Règles Importantes :**
+> - Vous **devez** utiliser exactement DEUX tirets du bas (`__`) après le numéro de version.
+> - Ne modifiez **jamais** les anciennes migrations déjà exécutées.
+> - Ne renommez **jamais** les anciennes migrations après leur exécution sur un environnement.
+> - Créez toujours un nouveau fichier de migration pour les nouveaux changements.
+
+---
+
+## Exemple de Workflow
+
+Si vous devez ajouter de nouvelles tables pour une tâche spécifique (par ex., Tâche 301), créez un fichier nommé `V2__task301_add_tables_t1_t2.sql` avec le contenu nécessaire :
+
+```sql
+CREATE TABLE table1 (
+    id BIGSERIAL PRIMARY KEY
+);
+
+CREATE TABLE table2 (
+    id BIGSERIAL PRIMARY KEY
+);
+```
+
+Faites un commit de ce fichier avec les modifications de votre code applicatif et faites un push vers le dépôt.

i18n/fr/docusaurus-plugin-content-docs/current/workflow/database-migrations/03-cicd-integration.md

@@ -0,0 +1,89 @@
+---
+sidebar_position: 4
+title: "Exécution & Intégration CI/CD"
+---
+
+# Exécution & Intégration CI/CD
+
+---
+
+## Exécution Manuelle des Migrations
+
+Pour exécuter les migrations en attente localement ou manuellement sur un environnement spécifique :
+
+```cmd
+mvn flyway:migrate ^
+-Dflyway.url=jdbc:postgresql://localhost:5432/TrizTresorie ^
+-Dflyway.user=postgres ^
+-Dflyway.password=VOTRE_MOT_DE_PASSE
+```
+
+Lorsque vous exécutez cette commande, Flyway va :
+1. Vérifier la table `flyway_schema_history`.
+2. Détecter quelles migrations ont déjà été exécutées.
+3. Exécuter uniquement les nouvelles migrations en attente, dans l'ordre des versions.
+4. Enregistrer automatiquement l'historique d'exécution.
+
+---
+
+## Intégration CI/CD
+
+Dans votre pipeline de déploiement, l'étape de migration de la base de données doit se produire **avant** le démarrage du serveur d'application (par ex., Tomcat).
+
+### Exemple d'Étape de Runner
+
+```yaml
+# --------------------------------------------------
+# Exécuter les migrations de base de données
+# --------------------------------------------------
+- name: Run database migrations
+  shell: cmd
+  run: |
+    cd %WORKSPACE_DIR%
+    mvnw.cmd flyway:migrate ^
+    -Dflyway.url=%DB_URL% ^
+    -Dflyway.user=%DB_USER% ^
+    -Dflyway.password=%DB_PASSWORD%
+```
+
+> [!IMPORTANT]
+> Stockez les identifiants de la base de données en toute sécurité à l'aide de secrets CI/CD ou de variables d'environnement. Ne codez pas en dur les mots de passe dans les scripts du dépôt.
+
+---
+
+## Flux de Déploiement Final
+
+Une séquence de déploiement standard et sûre utilisant Flyway doit suivre ces étapes :
+
+1. Cloner le code source.
+2. Compiler l'application.
+3. Arrêter Tomcat.
+4. Sauvegarder les fichiers de configuration.
+5. Déployer les nouveaux artefacts de l'application.
+6. Restaurer les fichiers de configuration.
+7. **Exécuter les migrations Flyway.**
+8. Démarrer Tomcat.
+9. Nettoyer l'espace de travail.
+
+---
+
+## Référence de Structure de Projet
+
+Pour référence, un projet correctement configuré aura une structure similaire à celle-ci :
+
+```text
+project/
+│
+├── src/
+│   └── main/
+│       └── resources/
+│           └── db/
+│               └── migration/
+│                   ├── V1__initial_schema.sql
+│                   ├── V2__task301_add_tables_t1_t2.sql
+│                   ├── V3__add_client_phone.sql
+│                   └── V4__fix_indexes.sql
+│
+├── pom.xml
+└── mvnw.cmd
+```

i18n/fr/docusaurus-plugin-content-docs/current/workflow/database-migrations/_category_.json

@@ -0,0 +1,8 @@
+{
+  "label": "Migrations de Base de Données",
+  "position": 2,
+  "link": {
+    "type": "generated-index",
+    "description": "Workflow standard pour la gestion des modifications de schéma de base de données à l'aide de Flyway dans différents environnements."
+  }
+}

i18n/fr/docusaurus-plugin-content-docs/current/workflow/database-migrations/index.md

@@ -0,0 +1,27 @@
+---
+sidebar_position: 1
+title: "Aperçu & Objectif"
+---
+
+# Aperçu & Objectif
+
+---
+
+Ce guide détaille la configuration et le workflow permettant d'utiliser **Flyway** pour gérer les mises à jour automatiques de la base de données lors des déploiements.
+
+En ajoutant chaque modification de base de données sous la forme d'un nouveau fichier de migration SQL, Flyway peut exécuter en toute sécurité uniquement les migrations manquantes, dans l'ordre correct, au cours du pipeline CI/CD.
+
+Cette approche élimine le besoin de fichiers SQL géants, empêche les exécutions en double, supprime le besoin de suivi manuel des modifications de la base de données et garantit la cohérence entre les environnements de production.
+
+---
+
+## Contexte de l'Environnement
+
+Ce guide est spécifiquement conçu pour la stack suivante :
+
+- **Base de données :** PostgreSQL 17
+- **Runtime :** Java 17
+- **Outil de build :** Maven Wrapper (`mvnw.cmd`)
+- **Serveur :** Tomcat
+- **État de la base de données :** Bases de données de production existantes
+- **Environnement CI/CD :** Runners Windows