Docs: Added CONTRIBUTING.md

CONTRIBUTING.md

@@ -0,0 +1,136 @@
+# Guide de Contribution au Projet d'Attrition RH
+
+Nous vous remercions de l'intérêt que vous portez à ce projet et de votre souhait d'y contribuer ! Ce guide a pour but de vous aider à comprendre comment contribuer de manière efficace.
+
+## 🚀 Comment Commencer ?
+
+1.  **Forker & Cloner (si vous n'êtes pas un collaborateur direct) :**
+    * Si vous êtes un contributeur externe, "forkez" d'abord le dépôt, puis clonez votre fork.
+    * Si vous êtes un collaborateur direct, clonez simplement le dépôt :
+      ```bash
+      git clone [URL_DU_REPO_GITHUB]
+      cd nom-du-dossier-projet
+      ```
+
+2.  **Installer Poetry :**
+    Ce projet utilise [Poetry](https://python-poetry.org/) pour la gestion des dépendances et des environnements virtuels. Suivez les [instructions d'installation officielles](https://python-poetry.org/docs/#installation).
+
+3.  **Installer les Dépendances du Projet :**
+    Une fois Poetry installé, à la racine du projet :
+    ```bash
+    poetry install
+    ```
+    Cela créera un environnement virtuel et installera toutes les dépendances nécessaires (y compris celles de développement).
+
+4.  **Activer l'Environnement Virtuel :**
+    ```bash
+    poetry shell
+    ```
+
+5.  **Configurer les Variables d'Environnement (Base de Données) :**
+    * Copiez le fichier d'exemple `.env.example` en `.env` :
+      ```bash
+      cp .env.example .env
+      ```
+    * Modifiez le fichier `.env` avec vos identifiants pour la base de données PostgreSQL locale (voir `README.md` pour plus de détails). Ce fichier est ignoré par Git.
+
+6.  **Démarrer la Base de Données Locale (si nécessaire) :**
+    Si vous travaillez sur des aspects nécessitant la base de données :
+    ```bash
+    docker-compose up -d
+    ```
+    N'oubliez pas d'initialiser les tables (`poetry run python -m src.database.init_db`) et de peupler les données (`poetry run python -m scripts.populate_employees_table`) si c'est votre première configuration.
+
+## 🛠️ Workflow de Développement
+
+Nous suivons un workflow basé sur Git pour assurer la qualité et la cohérence du code.
+
+### 1. Branches
+
+* **`main`** : Contient la version la plus stable et déployée. Aucun push direct n'est autorisé. Les modifications arrivent via des Pull Requests depuis `develop` après validation.
+* **`develop`** : Branche principale d'intégration. Toutes les nouvelles fonctionnalités et corrections sont fusionnées ici avant de passer sur `main`. Aucun push direct n'est autorisé ; passez par une Pull Request.
+* **Branches de Fonctionnalités/Corrections :**
+    * Toujours créer une nouvelle branche à partir de la dernière version de `develop`.
+    * Utilisez une convention de nommage claire :
+        * Pour les nouvelles fonctionnalités : `feature/nom-court-de-la-feature` (ex: `feature/api-logging`)
+        * Pour les corrections de bugs : `fix/description-bug` (ex: `fix/prediction-endpoint-500-error`)
+        * Pour la documentation : `docs/sujet-documentation` (ex: `docs/update-contributing-guide`)
+        * Pour les tâches diverses : `chore/description-tache` (ex: `chore/upgrade-dependencies`)
+    ```bash
+    git checkout develop
+    git pull origin develop
+    git checkout -b feature/ma-nouvelle-feature
+    ```
+
+### 2. Commits
+
+* Rédigez des messages de commit clairs, concis et en français (ou en anglais si c'est la convention du projet).
+* Utilisez les préfixes de **Conventional Commits** pour indiquer la nature du commit :
+    * `feat:` (nouvelle fonctionnalité)
+    * `fix:` (correction de bug)
+    * `docs:` (changements dans la documentation)
+    * `style:` (formatage, points-virgules manquants, etc. ; pas de changement de code)
+    * `refactor:` (refonte du code qui ne corrige pas de bug ni n'ajoute de fonctionnalité)
+    * `test:` (ajout ou correction de tests)
+    * `chore:` (mise à jour de tâches de build, configuration, etc.)
+    * `ci:` (changements dans les fichiers et scripts de CI/CD)
+* Essayez de faire des commits atomiques (un changement logique par commit).
+
+### 3. Qualité du Code
+
+* **Formatage :** Nous utilisons **Black** pour le formatage automatique du code. Avant de commiter, lancez :
+    ```bash
+    poetry run black .
+    ```
+* **Linting :** Nous utilisons **Ruff** pour le linting (détection d'erreurs, de code smells, et application de règles de style). Avant de commiter, lancez :
+    ```bash
+    poetry run ruff check . --fix # Pour corriger automatiquement ce qui peut l'être
+    poetry run ruff format . # Ruff peut aussi remplacer Black pour le formatage
+    ```
+    (Note: Le workflow CI vérifiera le formatage avec `black --check .` et le linting avec `ruff check .`)
+
+### 4. Tests
+
+* Toute nouvelle fonctionnalité ou correction de bug doit être accompagnée de **tests pertinents** (unitaires, fonctionnels, d'intégration).
+* Assurez-vous que tous les tests passent localement avant de pousser votre code :
+    ```bash
+    poetry run pytest
+    ```
+* Vérifiez la couverture de test et essayez de la maintenir ou de l'augmenter :
+    ```bash
+    poetry run pytest --cov=src tests/
+    ```
+    (Note: Le workflow CI exécutera ces tests.)
+
+## 🔄 Processus de Pull Request (PR)
+
+1.  Une fois votre travail terminé sur votre branche de fonctionnalité, poussez votre branche sur GitHub :
+    ```bash
+    git push origin feature/ma-nouvelle-feature
+    ```
+2.  Sur GitHub, créez une **Pull Request** de votre branche de fonctionnalité vers la branche `develop`.
+3.  Donnez un **titre clair** et une **description détaillée** à votre PR, expliquant les changements apportés et pourquoi.
+4.  Assurez-vous que tous les **checks de la CI (GitHub Actions) passent** sur votre PR (formatage, linting, tests).
+5.  Si vous travaillez en équipe, assignez un ou plusieurs relecteurs.
+6.  Une fois la PR approuvée et les checks de la CI au vert, elle peut être fusionnée dans `develop` par un mainteneur du projet. Privilégiez le "Squash and merge" pour garder un historique propre sur `develop`.
+7.  Après la fusion, la branche de fonctionnalité peut être supprimée sur GitHub et localement.
+
+## 🐞 Rapporter des Bugs
+
+* Utilisez l'onglet **"Issues"** du dépôt GitHub pour signaler les bugs.
+* Veuillez inclure autant d'informations que possible :
+    * Version du code (hash de commit ou tag).
+    * Étapes pour reproduire le bug.
+    * Comportement observé.
+    * Comportement attendu.
+    * Messages d'erreur complets et tracebacks.
+
+## ✨ Proposer des Améliorations
+
+* Les suggestions d'amélioration sont les bienvenues ! Veuillez ouvrir une **"Issue"** sur GitHub pour discuter de votre idée avant de commencer à développer.
+
+## ❓ Questions ?
+
+Si vous avez des questions sur la contribution, n'hésitez pas à ouvrir une "Issue" pour en discuter.
+
+Merci pour votre contribution !