chore: instruction copilot

.github/instructions/documentation.instruction.md

@@ -0,0 +1,6 @@
+La documentation doit être en français et claire pour les utilisateurs francophones.
+Toutes la documentation doit être dans le dossier docs/
+Seul les fichiers README.md, CHANGELOG.md doivent être à la racine.
+La documentation doit être conscise et pertinente, sans répétitions inutiles entre les documents.
+Tout ce qui concerne la gestion de projet, roadmap ne doit pas apparaître dans la documentation.
+Tout ce qui concerne les modifications de type chore n'a pas besoin d'être documenté.

.github/instructions/general-commit.instruction.md

@@ -0,0 +1,28 @@
+### **Commit Guidelines (Conventionnel)**
+
+Les messages de commits se basent sur **Conventional Commits** (https://www.conventionalcommits.org/en/v1.0.0/) , pour une meilleure gestion des versions et une génération automatique du changelog.
+
+#### **Format standard** :
+
+```
+<type>(<scope>): <description> [#<ticket-id>]
+```
+
+- **Types autorisés** :
+
+  - `feat` : Nouvelle fonctionnalité.
+  - `fix` : Correction d’un bug.
+  - `docs` : Modifications liées à la documentation.
+  - `style` : Mise en forme du code (pas de changements fonctionnels).
+  - `refactor` : Refactorisation sans ajout de fonctionnalités ni correction de bugs.
+  - `test` : Ajout ou modification de tests.
+  - `chore` : Maintenance ou tâches diverses (ex. mise à jour des dépendances).
+
+- **Scope (optionnel)** : Précisez une partie spécifique du projet (`backend`, `frontend`, `API`, etc.).
+
+- **Exemples** :
+  ```
+  feat(frontend): ajout de la gestion des utilisateurs dans le dashboard [#1]
+  fix(backend): correction du bug lié à l'authentification JWT [#1]
+  docs: mise à jour du README avec les nouvelles instructions d’installation [#2]
+  ```

.github/instructions/issues.instruction.md

@@ -0,0 +1,22 @@
+- Chaque nouveau ticket doit faire l'objet d'une analyse pour définir les modifications à effectuer.
+- l'analyse doit être présente dans la description du ticket au format:
+
+# Description de la modification
+
+Définir la modification
+
+# Solution envisagée
+
+Définir l'implementation avec l'impact dans le code
+
+# Modification documentaire
+
+Définir les documents à modifier si il existe il peut ne pas y en avoir.
+
+# Tests
+
+Définir ici comment va être tester la fonctionnalité et les cas de test.
+
+- Une fois créer son label doit passer à `etat/En Pause`
+- Les labels 'subject' sont ensuites ajouté en fonction du sujet de modification.
+- le label 'workload' est défini en fonction de si la modification de code est longue (gros impact) à faire ou rapide (faible impact)