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

docs/workflow/task-workflow/02-merging-and-completing.md

@@ -57,6 +57,10 @@ and used the aspose-cells library for the file generation.
 Tested with datasets of up to 10,000 rows.
 ```
 
+![Task Comment](img/3.png)
+
 ## Step 14 — Stop the Timer
 
 Stop your timer. The task is complete.
+
+![Timer Stop](img/4.png)

docs/workflow/task-workflow/index.md

@@ -23,11 +23,15 @@ The team uses a **rebase-then-merge** workflow. Each task is developed in isolat
 - Read the task carefully, including any comments or attachments.
 - Make sure you understand the requirements before starting. If anything is unclear, ask before writing any code.
 
+![Task Description](img/1.png)
+
 ## Step 2 — Start the Timer
 
 - Start your timer as soon as you begin working on the task.
 - The timer should reflect actual working time on the task, so start it now and not before you have read and understood it.
 
+![Timer Start](img/2.png)
+
 ## Step 3 — Update Your Local `dev` Branch
 
 Before creating your feature branch, make sure your local `dev` is up to date:

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/database-operations/dead-pc-recovery/index.md

@@ -13,5 +13,5 @@ Il existe deux situations possibles lorsque vous arrivez sur le site d'un client
 
 | **Situation**                                               | **Ce que cela signifie**                               | **Procédure**                                            |
 | ----------------------------------------------------------- | ------------------------------------------------------ | -------------------------------------------------------- |
-| **A — Windows démarre, mais le service DB ne démarre pas**  | Vous pouvez naviguer normalement dans le système       | Aller directement à la Partie A                         |
-| **B — Windows ne démarre pas du tout**                      | Vous avez besoin d'une clé USB Linux pour le disque    | Aller d'abord à la Partie B, puis suivre l'extraction    |
+| **A — Windows démarre, mais le service DB ne démarre pas**  | Vous pouvez naviguer normalement dans le système de fichiers | Aller directement à la Partie A                         |
+| **B — Windows ne démarre pas du tout**                      | Il vous faut une clé USB Linux live pour accéder au disque | Aller d'abord à la Partie B, puis suivre l'extraction    |

i18n/fr/docusaurus-plugin-content-docs/current/database-operations/dead-pc-recovery/windows-boots.md

@@ -18,7 +18,7 @@ Les bases de données SQL Server se composent de trois types de fichiers maximum
 | **Fichier**                 | **Extension** | **Contient**                              |
 | --------------------------- | ------------- | ----------------------------------------- |
 | Fichier de données principal | `.mdf`        | Le schéma et les données de la base       |
-| Fichier de données secondaire| `.ndf`        | Données de débordement (pas toujours présent) |
+| Fichier de données secondaire| `.ndf`        | Données supplémentaires (pas toujours présent) |
 | Journal de transactions     | `.ldf`        | Historique des transactions               |
 
 **Emplacements par défaut selon la version de SQL Server :**
@@ -65,4 +65,4 @@ PostgreSQL stocke toutes les bases de données dans un répertoire unique appel
 - Notez le numéro de version de PostgreSQL d'après le chemin du dossier — vous en aurez besoin lors de la restauration.
 
 **Notes :**
-- **Notez la version.** Pour chaque base de données du cluster, il existe un sous-répertoire dans `PGDATA/base`, nommé d'après l'OID de la base de données. Comme ces identifiants internes sont spécifiques à chaque version, le répertoire de données doit être restauré sur une machine exécutant la **version exacte de PostgreSQL**.
+- **Notez la version.** Pour chaque base de données du cluster, il existe un sous-répertoire dans `PGDATA/base`, nommé d'après l'OID de la base de données. Ces identifiants internes étant spécifiques à chaque version, le répertoire de données doit être restauré sur une machine exécutant la **même version majeure de PostgreSQL**.

i18n/fr/docusaurus-plugin-content-docs/current/database-operations/sql-server-backup-restore/backing-up.md

@@ -11,9 +11,9 @@ Avant d'effectuer une sauvegarde, choisissez le type approprié à votre situati
 
 | Type                    | **Ce qu'il capture**                                      | **Quand l'utiliser**                                     |
 | ----------------------- | --------------------------------------------------------- | -------------------------------------------------------- |
-| **Complète (Full)**     | L'intégralité de la base de données                       | Référence hebdomadaire ; requis avant tout autre type   |
-| **Différentielle**      | Les changements depuis la dernière sauvegarde complète    | Quotidiennement ; plus rapide et léger qu'une complète  |
-| **Journal (Log)**       | Toute l'activité du journal depuis la dernière sauvegarde | Horaire ou plus ; permet la récupération point-in-time   |
+| **Complète (Full)**     | L'intégralité de la base de données                       | Sauvegarde de référence hebdomadaire ; requise avant tout autre type |
+| **Différentielle**      | Les changements depuis la dernière sauvegarde complète    | Quotidiennement ; plus rapide et légère qu'une complète  |
+| **Journal (Log)**       | Toute l'activité du journal depuis la dernière sauvegarde | Toutes les heures ou plus ; permet la récupération point-in-time |
 
 ---
 
@@ -40,7 +40,7 @@ Avant d'effectuer une sauvegarde, choisissez le type approprié à votre situati
 
 ![Lancer la sauvegarde](img/4.png)
 
-7. Une fenêtre de confirmation apparaîtra une fois l'opération terminée avec succès.
+7. Un message de confirmation apparaîtra une fois l'opération terminée.
 
 ![Succès de la sauvegarde](img/5.png)
 

i18n/fr/docusaurus-plugin-content-docs/current/database-operations/sql-server-backup-restore/restoring.md

@@ -7,7 +7,7 @@ title: "Restaurer une Base de Données"
 
 ---
 
-**AVERTISSEMENT :** La restauration d'une base de données **remplace son contenu actuel**. Confirmez toujours que vous ciblez le bon serveur et la bonne base de données avant de procéder. Fermez au préalable toutes les connexions actives vers la base de données cible.
+**AVERTISSEMENT :** La restauration d'une base de données **remplace son contenu actuel**. Vérifiez toujours que vous ciblez le bon serveur et la bonne base de données avant de procéder. Fermez toutes les connexions actives vers la base de données cible au préalable.
 
 ---
 
@@ -67,7 +67,7 @@ title: "Restaurer une Base de Données"
 
 ![Ajouter les fichiers journaux](img/25.png)
 
-2. SSMS listera tous les jeux de sauvegarde dans la séquence correcte dans la grille. Vérifiez que toutes les entrées nécessaires sont cochées.
+2. SSMS listera tous les jeux de sauvegarde dans le bon ordre dans la grille. Vérifiez que toutes les entrées nécessaires sont cochées.
 3. Pour restaurer à un point précis dans le temps, cliquez sur le bouton **Timeline…** en haut de la page **General**. Dans la boîte de dialogue **Backup Timeline**, déplacez le curseur ou saisissez une date et une heure précises, puis cliquez sur **OK**.
 
 ![Chronologie de restauration](img/26.png)

i18n/fr/docusaurus-plugin-content-docs/current/getting-started/environment-setup/01-java-and-maven.md

@@ -10,7 +10,7 @@ title: "Java et Maven"
 # Étape 1 — Installer le Java SE Development Kit (JDK) 8
 
 1. Téléchargez le **JDK 8** depuis :
-	- [Les assets de release Gitea](http://145.239.66.197:3000/othmane/team-resources/releases/tag/jdk-8u481-windows-x64)
+	- [Ressources Gitea](http://145.239.66.197:3000/othmane/team-resources/releases/tag/jdk-8u481-windows-x64)
 	- [L'archive officielle d'Oracle](https://www.oracle.com/asean/java/technologies/javase/javase8u211-later-archive-downloads.html) si vous avez un compte.
 2. Lancez l'installateur et terminez l'installation. Notez le chemin d'installation (par ex., `C:\Program Files\Java\jdk1.8.0_xxx`).
 3. Configurez la variable d'environnement `JAVA_HOME` :
@@ -19,7 +19,7 @@ title: "Java et Maven"
 	- Sous **Variables système**, cliquez sur **Nouvelle** :
 		- Nom de la variable : `JAVA_HOME`
 		- Valeur de la variable : `C:\Program Files\Java\jdk1.8.0_xxx` _(votre chemin JDK réel)_
-	- Trouvez la variable **`Path`** sous Variables système → cliquez sur **Modifier → Nouveau**, et ajoutez : `%JAVA_HOME%\bin`
+	- Repérez la variable **`Path`** sous Variables système → cliquez sur **Modifier → Nouveau**, et ajoutez : `%JAVA_HOME%\bin`
 	- Cliquez sur **OK** sur toutes les fenêtres.
 4. Ouvrez une **nouvelle** fenêtre de terminal et vérifiez :
 
@@ -28,14 +28,14 @@ java -version
 javac -version
 ```
 
-Les deux doivent retourner `1.8.x`. Si `javac` n'est pas trouvé, `JAVA_HOME` ou le `PATH` n'a pas été configuré correctement.
+Les deux doivent afficher `1.8.x`. Si `javac` n'est pas trouvé, `JAVA_HOME` ou le `PATH` n'a pas été configuré correctement.
 
 ---
 
 # Étape 2 — Installer Apache Maven
 
 1. Téléchargez Maven : _(Téléchargez l'**archive binaire zip**)_
-	- [Les assets de release Gitea](http://145.239.66.197:3000/othmane/team-resources/releases/tag/apache-maven-3.9.15-bin)
+	- [Ressources Gitea](http://145.239.66.197:3000/othmane/team-resources/releases/tag/apache-maven-3.9.15-bin)
 	- [Apache](https://maven.apache.org/download.cgi)
 2. Extrayez-le dans un chemin stable sans espaces (par ex., `C:\dev\maven`).
 3. Configurez les variables d'environnement :
@@ -55,16 +55,16 @@ Il devrait afficher la version de Maven et confirmer qu'il utilise votre JDK 8.
 
 # Étape 3 — Configurer Maven pour le Registre Privé Gitea
 
-Le projet TrizStock comporte plusieurs dépendances héritées qui ne sont pas disponibles sur Maven Central. Elles sont hébergées sur le registre Maven privé de l'équipe dans Gitea. Sans cette configuration, votre build ne parviendra pas à résoudre ces dépendances.
+Le projet TrizStock comporte plusieurs anciennes dépendances qui ne sont pas disponibles sur Maven Central. Elles sont hébergées sur le registre Maven privé de l'équipe dans Gitea. Sans cette configuration, votre build ne parviendra pas à résoudre ces dépendances.
 
-1. Accédez au fichier de paramètres utilisateur de Maven. S'il n'existe pas, créez-le :
+1. Accédez au fichier de configuration utilisateur de Maven. S'il n'existe pas, créez-le :
 
 ```text
 C:\Users\VOTRE_NOM_D_UTILISATEUR_WINDOWS\.m2\settings.xml
 ```
 
 2. Téléchargez le `settings.xml.template` depuis le [dépôt de ressources](http://145.239.66.197:3000/othmane/team-resources/src/branch/main/_global/maven/settings.xml.template) de l'équipe.
-3. Copiez le contenu du template dans votre `settings.xml` et remplacez les espaces réservés par vos identifiants Gitea réels :
+3. Copiez le contenu du template dans votre `settings.xml` et remplacez les placeholders par vos identifiants Gitea réels :
 
 ```xml
 <settings>

i18n/fr/docusaurus-plugin-content-docs/current/getting-started/environment-setup/02-tomcat-server.md

@@ -10,7 +10,7 @@ title: "Serveur Tomcat"
 # Étape 4 — Installer Apache Tomcat 9
 
 1. Téléchargez **Tomcat 9** (distribution zip — ne **pas** utiliser l'installateur Windows) :
-	- [Les assets de release Gitea](http://145.239.66.197:3000/othmane/team-resources/releases/tag/apache-tomcat-9.0.117)
+	- [Ressources Gitea](http://145.239.66.197:3000/othmane/team-resources/releases/tag/apache-tomcat-9.0.117)
 	- [Apache](https://tomcat.apache.org/download-90.cgi)
 2. Extrayez-le dans un chemin stable sans espaces (par ex., `C:\dev\tomcat9`).
 3. **N'ajoutez pas Tomcat au PATH de votre système.** NetBeans le gérera directement et a seulement besoin de connaître le répertoire.

i18n/fr/docusaurus-plugin-content-docs/current/getting-started/environment-setup/03-database-setup.md

@@ -12,7 +12,7 @@ title: "Configuration de la Base de Données"
 ## 5.1 — Installer SQL Server 2012
 
 1. Obtenez l'installateur de SQL Server 2012 (`SQLEXPR_x64_ENU.exe`) depuis :
-	- [Les assets de release Gitea](http://145.239.66.197:3000/othmane/team-resources/releases/tag/SQLEXPR_x64_ENU)
+	- [Ressources Gitea](http://145.239.66.197:3000/othmane/team-resources/releases/tag/SQLEXPR_x64_ENU)
 	- [Microsoft](https://www.microsoft.com/en-us/download/details.aspx?id=56042)
 2. Lancez l'installateur et choisissez **New SQL Server stand-alone installation**.
 3. Sur l'écran **"Database Engine Configuration"**, sous **Authentication Mode**, sélectionnez **Mixed Mode** (Authentification SQL Server et Authentification Windows).
@@ -48,7 +48,7 @@ SQL Server désactive le protocole TCP/IP par défaut sur les nouvelles installa
 5. Appliquez à tous les profils (Domaine, Privé, Public).
 6. Nommez la règle `SQL Server 1433` et cliquez sur **Terminer**.
 
-## 5.6 — Créer l'identifiant de connexion de l'application
+## 5.6 — Créer le login applicatif
 
 1. Installez **SQL Server Management Studio (SSMS)**. Téléchargez-le depuis [Microsoft](https://aka.ms/ssmsfullsetup).
 2. Ouvrez SSMS et connectez-vous à votre instance locale :
@@ -60,8 +60,8 @@ SQL Server désactive le protocole TCP/IP par défaut sur les nouvelles installa
 > 📝 **Remarque — Vérifiez votre `database.properties` avant de continuer.**
 >
 > Ouvrez votre fichier `database.properties` et vérifiez la valeur de `db.username`.
-> - S'il s'agit de **`sa`**, ignorez complètement les étapes 3 à 9. Le compte `sa` existe déjà et a été configuré avec le bon mot de passe (`Root123456`) lors de l'installation. Aucun nouvel identifiant n'a besoin d'être créé.
-> - S'il s'agit de **tout autre nom d'utilisateur**, continuez avec les étapes 3 à 9 ci-dessous pour créer cet identifiant.
+> - S'il s'agit de **`sa`**, ignorez les étapes 3 à 9. Le compte `sa` existe déjà et a été configuré avec le bon mot de passe (`Root123456`) lors de l'installation. Aucun nouveau login n'a besoin d'être créé.
+> - S'il s'agit de **tout autre nom d'utilisateur**, continuez avec les étapes 3 à 9 ci-dessous pour créer ce login.
 
 3. Dans l'**Explorateur d'objets**, développez **Security → Logins**.
 4. Faites un clic droit sur **Logins → New Login**.
@@ -75,13 +75,13 @@ SQL Server désactive le protocole TCP/IP par défaut sur les nouvelles installa
 
 # Étape 6 — Restaurer la Base de Données de Test
 
-1. Téléchargez le fichier de sauvegarde de la base de données de test du projet Stock depuis les [assets de release Gitea](http://145.239.66.197:3000/othmane/team-resources/releases/tag/life_07-04-2026).
+1. Téléchargez le fichier de sauvegarde de la base de données de test du projet Stock depuis les [ressources Gitea](http://145.239.66.197:3000/othmane/team-resources/releases/tag/life_07-04-2026).
 2. Ouvrez **SSMS** et connectez-vous à votre instance locale SQL Server.
 3. Dans l'**Explorateur d'objets**, faites un clic droit sur **Databases → Restore Database…**
 4. Sélectionnez **Device** comme source, cliquez sur **…** (Parcourir), puis cliquez sur **Add** et accédez au fichier `.bak` téléchargé. Cliquez sur **OK**.
 5. Les détails de la sauvegarde s'afficheront dans la grille **Backup sets to restore**. Confirmez que la bonne entrée est cochée.
 6. Cliquez sur **OK** pour restaurer. Une fenêtre de succès apparaîtra une fois l'opération terminée.
 7. Dans l'**Explorateur d'objets**, faites un clic droit sur **Databases → Refresh**. La base de données `TrizStockLife` devrait maintenant apparaître.
-8. Vérifiez que l'identifiant de connexion créé à l'Étape 5.6 a bien accès :
+8. Vérifiez que le login créé à l'Étape 5.6 a bien accès :
 	- Développez **TrizStockLife → Security → Users**.
-	- Si votre identifiant de connexion n'est pas listé, faites un clic droit sur **Users → New User**, et mappez le login à cette base de données avec le rôle **`db_owner`**.
+	- Si votre login n'est pas listé, faites un clic droit sur **Users → New User**, et mappez le login à cette base de données avec le rôle **`db_owner`**.

i18n/fr/docusaurus-plugin-content-docs/current/getting-started/environment-setup/04-git-and-repository.md

@@ -34,7 +34,7 @@ git config --global user.email "votre.email@entreprise.com"
 
 ## 7.3 — Configurer les Fins de Ligne (Line Endings)
 
-Il s'agit d'un **paramètre critique** pour l'équipe. Une configuration incorrecte des fins de ligne provoque des diffs inutiles, pollue l'historique des commits et peut briser l'analyse des fichiers côté serveur.
+Il s'agit d'un **paramètre critique** pour l'équipe. Une mauvaise configuration des line endings provoque des diffs inutiles, pollue l'historique des commits et peut casser l'analyse des fichiers côté serveur.
 
 Exécutez les commandes suivantes exactement comme écrit :
 
@@ -45,7 +45,7 @@ git config --global core.eol lf
 
 | Paramètre        | Valeur   | Raison                                                                                                                                              |
 | ---------------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `core.autocrlf`  | `false`  | Désactive la conversion automatique des fins de ligne. Git ne touchera pas aux fins de ligne lors du checkout ou du commit.                         |
+| `core.autocrlf`  | `false`  | Désactive la conversion automatique des fins de ligne. Git ne modifiera pas les fins de ligne lors du checkout ou du commit.                         |
 | `core.eol`       | `lf`     | Impose le LF (`\n`) comme fin de ligne pour tous les fichiers de l'arbre de travail, en cohérence avec le serveur et les environnements Linux. |
 
 > ⚠️ **Ne sautez pas cette étape.** Si `autocrlf` est laissé à sa valeur Windows par défaut (`true`), Git convertira silencieusement toutes les fins de ligne en CRLF lors du checkout et les ramènera en LF lors du commit. Cela fait apparaître chaque fichier comme modifié sous Windows, même si aucun changement réel n'a été effectué.

i18n/fr/docusaurus-plugin-content-docs/current/getting-started/environment-setup/05-ide-configuration.md

@@ -12,7 +12,7 @@ title: "Configuration de l'IDE"
 ## 10.1 — Installer NetBeans
 
 1. Téléchargez **NetBeans 17** depuis :
-	- [Les assets de release Gitea](http://145.239.66.197:3000/othmane/team-resources/releases/tag/Apache-NetBeans-17-bin-windows-x64)
+	- [Ressources Gitea](http://145.239.66.197:3000/othmane/team-resources/releases/tag/Apache-NetBeans-17-bin-windows-x64)
 	- [Apache](https://netbeans.apache.org/front/main/download/nb17/)
 2. Lancez l'installateur et terminez l'installation avec les paramètres par défaut.
 
@@ -50,7 +50,7 @@ Il se peut que NetBeans détecte un JDK plus récent si vous en avez un d'instal
 
 Cette étape finale confirme que l'ensemble de votre environnement est correctement configuré.
 
-## 11.1 — Builder le Projet
+## 11.1 — Compiler le Projet
 
 1. Dans NetBeans, faites un clic droit sur le projet **Stock** dans le panneau Projets.
 2. Sélectionnez **Clean and Build**.

i18n/fr/docusaurus-plugin-content-docs/current/getting-started/environment-setup/06-troubleshooting.md

@@ -12,7 +12,7 @@ title: "Dépannage & Références"
 | **Symptôme**                                          | **Cause probable**                                                    | **Solution**                                                         |
 | ----------------------------------------------------- | --------------------------------------------------------------------- | -------------------------------------------------------------------- |
 | `java -version` affiche la mauvaise version ou rien   | `JAVA_HOME` ou `PATH` mal configurés                                  | Revoir l'Étape 1, ouvrir un **nouveau** terminal après modification |
-| `javac` non trouvé                                    | JRE installé au lieu du JDK                                           | Réinstaller en utilisant le lien de téléchargement du JDK            |
+| `javac` non trouvé                                    | JRE installé au lieu du JDK                                           | Réinstaller le JDK (pas le JRE)                                      |
 | `mvn -version` non trouvé                             | Maven non présent dans le `PATH`                                      | Revoir l'Étape 2                                                     |
 | Le build Maven échoue (dépendance non trouvée)        | `settings.xml` non configuré ou mauvais identifiants                  | Revoir l'Étape 3                                                     |
 | Impossible de se connecter à SQL Server depuis SSMS   | TCP/IP désactivé ou port 1433 bloqué                                  | Revoir les Étapes 5.2 et 5.5                                         |
@@ -30,7 +30,7 @@ title: "Dépannage & Références"
 | -------------------------------------- | ------------------------------------------------------------------------------------------------------------- |
 | Dépôt de ressources de l'équipe        | [LIEN](http://145.239.66.197:3000/othmane/team-resources)                                                     |
 | Dépôt du projet Stock                  | [LIEN](http://145.239.66.197:3000/TrizTech/TrizStockRepository)                                               |
-| Assets de release de la base de données| [LIEN](http://145.239.66.197:3000/othmane/team-resources/releases/tag/life_07-04-2026)                        |
+| Ressources de la base de données      | [LIEN](http://145.239.66.197:3000/othmane/team-resources/releases/tag/life_07-04-2026)                        |
 | Registre Maven Gitea                   | [LIEN](http://145.239.66.197:3000/othmane/-/packages/)                                                        |
 | Template `database.properties`         | [LIEN](http://145.239.66.197:3000/othmane/team-resources/src/branch/main/uses/stock/database.properties)      |
 | Template `settings.xml`                | [LIEN](http://145.239.66.197:3000/othmane/team-resources/src/branch/main/_global/maven/settings.xml.template) |

i18n/fr/docusaurus-plugin-content-docs/current/getting-started/environment-setup/index.md

@@ -23,5 +23,5 @@ Assurez-vous d'avoir les éléments suivants avant de procéder :
 | Apache Maven                 | Récente     | Gestion des dépendances et build |
 | Apache Tomcat                | 9           | Serveur d'application Java EE    |
 | Microsoft SQL Server         | 2012        | Moteur de base de données        |
-| SQL Server Management Studio | Récente     | Client GUI de base de données    |
+| SQL Server Management Studio | Récente     | Client graphique de base de données |
 | NetBeans IDE                 | 17          | Environnement de développement   |

i18n/fr/docusaurus-plugin-content-docs/current/git-operations/command-line/push-pull.md

@@ -1,13 +1,13 @@
 ---
 sidebar_position: 3
-title: "Pousser & Tirer les Changements"
+title: "Push & Pull"
 ---
 
-# Pousser & Tirer les Changements
+# Push & Pull
 
 ---
 
-# Pousser (Push) les Changements
+# Push — Envoyer les modifications
 
 ## Objectif
 
@@ -22,7 +22,7 @@ Envoyer les commits du dépôt local vers le dépôt distant.
 
 ---
 
-# Tirer (Pull) les Changements
+# Pull — Récupérer les modifications
 
 ## Objectif
 
@@ -34,4 +34,4 @@ Récupérer les mises à jour du dépôt distant et les fusionner dans le dépô
 
 ![Pull Git](img/8.png)
 
-2. Examinez la sortie pour voir les mises à jour ou les résultats de fusion.
+2. Consultez la sortie pour voir les mises à jour ou les résultats de fusion.

i18n/fr/docusaurus-plugin-content-docs/current/git-operations/jetbrains/push-pull.md

@@ -1,13 +1,13 @@
 ---
 sidebar_position: 3
-title: "Pousser & Tirer les Changements"
+title: "Push & Pull"
 ---
 
-# Pousser & Tirer les Changements
+# Push & Pull
 
 ---
 
-# Pousser (Push) les Changements
+# Push — Envoyer les modifications
 
 ## Objectif
 
@@ -31,7 +31,7 @@ Envoyer les commits du dépôt local vers le dépôt distant.
 
 ---
 
-# Tirer (Pull) les Changements
+# Pull — Récupérer les modifications
 
 ## Objectif
 

i18n/fr/docusaurus-plugin-content-docs/current/git-operations/netbeans/push-pull.md

@@ -1,13 +1,13 @@
 ---
 sidebar_position: 3
-title: "Pousser & Tirer les Changements"
+title: "Push & Pull"
 ---
 
-# Pousser & Tirer les Changements
+# Push & Pull
 
 ---
 
-# Pousser (Push) les Changements
+# Push — Envoyer les modifications
 
 ## Objectif
 
@@ -36,11 +36,11 @@ Envoyer les commits du dépôt local vers le dépôt distant.
 
 ---
 
-# Pousser les Changements (Upstream)
+# Push vers Upstream
 
 ## Objectif
 
-Envoyer les commits du dépôt local vers le dépôt distant défini comme "upstream".
+Envoyer les commits du dépôt local vers le dépôt distant upstream.
 
 ## Étapes
 
@@ -52,7 +52,7 @@ Envoyer les commits du dépôt local vers le dépôt distant défini comme "upst
 
 ---
 
-# Tirer (Pull) les Changements
+# Pull — Récupérer les modifications
 
 ## Objectif
 
@@ -75,11 +75,11 @@ Récupérer les mises à jour du dépôt distant et les fusionner dans le dépô
 
 ---
 
-# Tirer les Changements (Upstream)
+# Pull depuis Upstream
 
 ## Objectif
 
-Récupérer les mises à jour du dépôt distant "upstream" et les fusionner dans le dépôt local.
+Récupérer les mises à jour du dépôt distant upstream et les fusionner dans le dépôt local.
 
 ## Étapes
 

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

i18n/fr/docusaurus-plugin-content-docs/current/workflow/task-workflow/01-development-and-rebasing.md

@@ -34,7 +34,7 @@ git checkout dev
 git pull
 ```
 
-> Cette étape est cruciale. Si un autre développeur a poussé sur `dev` pendant que vous travailliez, vous avez besoin de ces changements avant de rebaser, sinon vous risquez d'introduire des conflits ou d'écraser du travail.
+> Cette étape est cruciale. Si un autre développeur a fait un push sur `dev` pendant que vous travailliez, vous avez besoin de ces changements avant de rebaser, sinon vous risquez d'introduire des conflits ou d'écraser du travail existant.
 
 ## Étape 7 — Revenir sur Votre Branche de Fonctionnalité
 

i18n/fr/docusaurus-plugin-content-docs/current/workflow/task-workflow/02-merging-and-completing.md

@@ -21,16 +21,16 @@ git merge feature/<numéro_de_tâche>
 
 Parce que la branche de fonctionnalité vient d'être rebasée sur `dev`, cette fusion sera un "fast-forward" et produira un commit de fusion propre au sommet de `dev`.
 
-## Étape 11 — Pousser les Deux Branches vers le Dépôt Distant
+## Étape 11 — Push des Deux Branches vers le Dépôt Distant
 
-Poussez à la fois la branche `dev` et la branche de fonctionnalité vers le dépôt distant en une seule opération depuis NetBeans, ou via le terminal :
+Faites un push de la branche `dev` et de la branche de fonctionnalité vers le dépôt distant en une seule opération depuis NetBeans, ou via le terminal :
 
 ```bash
 git push origin dev
 git push origin feature/<numéro_de_tâche>
 ```
 
-> Les deux branches doivent être poussées. Pousser `dev` rend votre travail disponible pour le reste de l'équipe. Pousser la branche de fonctionnalité permet de garder le dépôt distant synchronisé et préserve l'historique complet de la tâche pour référence.
+> Les deux branches doivent faire l'objet d'un push. Le push de `dev` rend votre travail disponible pour le reste de l'équipe. Le push de la branche de fonctionnalité permet de garder le dépôt distant synchronisé et préserve l'historique complet de la tâche pour référence.
 
 ## Étape 12 — Copier le Hash du Commit de Fusion depuis Gitea
 
@@ -44,7 +44,7 @@ git push origin feature/<numéro_de_tâche>
 
 Retournez sur le ticket qui vous est assigné et postez un commentaire contenant :
 - Le **hash du commit de fusion** copié à l'Étape 12.
-- Une **description de ce qui a été fait** — ce qui a été implémenté, les décisions prises, tout ce qui est pertinent pour le réviseur ou pour une référence future.
+- Une **description de ce qui a été fait** — ce qui a été implémenté, les décisions prises, tout ce qui est pertinent pour le relecteur ou pour référence future.
 
 Exemple de commentaire :
 
@@ -57,6 +57,10 @@ et utilisation de la bibliothèque aspose-cells pour la génération du fichier.
 Testé avec des jeux de données allant jusqu'à 10 000 lignes.
 ```
 
+![Task Comment](img/3.png)
+
 ## Étape 14 — Arrêter le Chronomètre
 
 Arrêtez votre chronomètre. La tâche est terminée.
+
+![Timer Stop](img/4.png)

i18n/fr/docusaurus-plugin-content-docs/current/workflow/task-workflow/03-reference-and-troubleshooting.md

@@ -33,7 +33,7 @@ git rebase dev
 git checkout dev
 git merge feature/<numéro_de_tâche>
 
-# Pousser les deux branches
+# Push des deux branches
 git push origin dev
 git push origin feature/<numéro_de_tâche>
 ```
@@ -55,9 +55,9 @@ Ensuite, allez sur Gitea : copiez le hash du commit de fusion au sommet de `dev`
 
 | Erreur                                                  | Pourquoi c'est un problème                                                              |
 | ------------------------------------------------------- | --------------------------------------------------------------------------------------- |
-| Créer une branche de `dev` sans faire de pull d'abord  | Votre branche commence sur du code périmé, causant des conflits plus tard               |
+| Créer une branche depuis `dev` sans faire de pull d'abord | Votre branche part de code périmé, ce qui causera des conflits plus tard              |
 | Sauter le deuxième `git pull` avant de rebaser          | Vous rebasez sur un `dev` obsolète et manquez les changements de vos coéquipiers        |
 | Oublier de rebaser avant de fusionner                   | Produit un historique désordonné avec des commits de fusion intermédiaires inutiles     |
-| Pousser seulement `dev` et non la branche de fonctionnalité | La branche de fonctionnalité sur le dépôt distant n'est plus synchronisée               |
-| Pousser seulement la branche de fonctionnalité et non `dev` | Votre travail n'atteint jamais l'équipe                                                 |
-| Ne pas poster le hash du commit sur la tâche            | La tâche n'a plus de lien traçable vers le code qui l'implémente                        |
+| Ne faire un push que de `dev` sans la branche de fonctionnalité | La branche de fonctionnalité sur le dépôt distant n'est plus synchronisée               |
+| Ne faire un push que de la branche de fonctionnalité sans `dev` | Votre travail ne parvient jamais au reste de l'équipe                                    |
+| Ne pas poster le hash du commit sur la tâche            | La tâche n'a aucun lien traçable vers le code qui l'implémente                          |

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

@@ -11,7 +11,7 @@ title: "Aperçu & Démarrage du Travail"
 
 # Aperçu
 
-L'équipe utilise un workflow de type **rebase-then-merge** (rebasage puis fusion). Chaque tâche est développée de manière isolée sur sa propre branche de fonctionnalité, rebasée sur le dernier `dev` avant la fusion, puis les deux branches sont poussées ensemble vers le dépôt distant. Cela permet de garder l'historique de la branche `dev` propre et linéaire.
+L'équipe utilise un workflow de type **rebase-then-merge** (rebasage puis fusion). Chaque tâche est développée de manière isolée sur sa propre branche de fonctionnalité, rebasée sur le dernier `dev` avant la fusion, puis les deux branches font l'objet d'un push vers le dépôt distant. Cela permet de garder l'historique de la branche `dev` propre et linéaire.
 
 ---
 
@@ -23,11 +23,15 @@ L'équipe utilise un workflow de type **rebase-then-merge** (rebasage puis fusio
 - Lisez attentivement la tâche, y compris les commentaires ou les pièces jointes.
 - Assurez-vous de bien comprendre les exigences avant de commencer. Si quelque chose n'est pas clair, demandez avant d'écrire du code.
 
+![Task Description](img/1.png)
+
 ## Étape 2 — Lancer le Chronomètre
 
 - Lancez votre chronomètre dès que vous commencez à travailler sur la tâche.
 - Le chronomètre doit refléter le temps de travail réel sur la tâche, alors lancez-le maintenant et non avant d'avoir lu et compris le ticket.
 
+![Timer Start](img/2.png)
+
 ## Étape 3 — Mettre à Jour votre Branche `dev` Locale
 
 Avant de créer votre branche de fonctionnalité, assurez-vous que votre branche `dev` locale est à jour :
@@ -37,7 +41,7 @@ git checkout dev
 git pull
 ```
 
-> Ne créez jamais de branche à partir d'un `dev` obsolète. Tirez (pull) toujours d'abord pour éviter de baser votre travail sur du code périmé.
+> Ne créez jamais de branche à partir d'un `dev` obsolète. Faites toujours un pull d'abord pour éviter de baser votre travail sur du code périmé.
 
 ## Étape 4 — Créer la Branche de Fonctionnalité
 

package.json

@@ -15,9 +15,9 @@
   },
   "dependencies": {
     "@cmfcmf/docusaurus-search-local": "^2.0.1",
-    "@docusaurus/core": "3.10.0",
-    "@docusaurus/faster": "3.10.0",
-    "@docusaurus/preset-classic": "3.10.0",
+    "@docusaurus/core": "^3.10.1",
+    "@docusaurus/faster": "^3.10.1",
+    "@docusaurus/preset-classic": "^3.10.1",
     "@mdx-js/react": "^3.0.0",
     "clsx": "^2.0.0",
     "prism-react-renderer": "^2.3.0",
@@ -25,8 +25,8 @@
     "react-dom": "^19.0.0"
   },
   "devDependencies": {
-    "@docusaurus/module-type-aliases": "3.10.0",
-    "@docusaurus/types": "3.10.0"
+    "@docusaurus/module-type-aliases": "^3.10.1",
+    "@docusaurus/types": "^3.10.1"
   },
   "browserslist": {
     "production": [