> ## Documentation Index
> Fetch the complete documentation index at: https://docs.arkatech.fr/llms.txt
> Use this file to discover all available pages before exploring further.

# Développement, Tests et Cycle de Vie

**Objectif :** Transformer les spécifications en fonctionnalités stables et documentées.

### Responsabilités et Outils

* **Responsable :** Manager des Développeurs ou Lead Dev.
* **Intervenants :** Développeurs (Front & Back), Chef de Projet (Clarification des US).
* **Outils :**
  * **Ticketing :** Jira / YouTrack / Monday / Asana (Gestion du flux).
  * **Code :** GitHub / GitLab (Dépôt du code et Code Review).
  * **Documentation :** Wiki Technique (Notion/Confluence/WikiJS).
  * **Environnements :** Local (Dev) -> Staging (Test).

### Création des Tâches Techniques

Une fois l'US validée par le client, elle doit être "traduite" en tickets techniques (Jira/YouTrack/Monday/Asana).

* **Qui :** Le **Manager Dev** ou un Lead Dev.
* **Comment :** On découpe l'US en sous-tâches.
  * *Exemple pour l'US Mot de passe :*
    1. \[Backoffice] Création de l'API Endpoint `POST /reset-password`.
    2. \[Backoffice] Template d'emailing (Amélioration du socle).
    3. \[Front-end] Intégration de la page de saisie (Maquette Figma).

### Cycle de vie d'un Ticket (Workflow)

Un ticket ne peut pas simplement être "À faire" ou "Fait". Il doit suivre ce cycle :

1. **Backlog :** Tâche identifiée mais non priorisée.
2. **Ready for Dev :** Spécifications claires, maquettes prêtes, prêt à être pris.
3. **In Progress :** Le développeur travaille dessus.
4. **Code Review (Peer Review) :** Un autre développeur vérifie le code (Qualité/Sécurité).
5. **Ready for QA :** Le développeur a fini, le CP doit tester.
6. **Testing :** Le CP effectue les tests de conformité.
7. **Ready for Prod :** Validé et prêt pour la mise en production.
8. **Released :** Le code est déployé sur le serveur final. L'utilisateur peut l'utiliser.

### Répartition du temps sur un Ticket (Estimation)

Pour un ticket estimé à **1 journée (8h)**, la répartition type en grande entreprise est :

* **Analyse & Setup (5%) :** Lecture du ticket, mise à jour de son environnement local. (\~30m)
* **Développement (50%) :** Écriture du code et des tests unitaires. (\~4h)
* **Auto-test (25%) :** Vérifier que ça marche, documenter l'API ou le changement dans le Wiki Technique. (\~2h)
* **Documentation (15%) :** Vérifier que ça marche, documenter l'API ou le changement dans le Wiki Technique. (\~1h)
* **Correction / Revue (5%) :** Ajustements suite aux retours de la Code Review. (\~30m)

### La Documentation Technique (Wiki Dev)

Contrairement au Wiki Projet (fonctionnel), le **Wiki Technique** est géré par le Manager Dev et les développeurs :

* **Architecture du Backoffice :** Schéma de la base de données, liste des hooks disponibles.
* **Guide de style :** Règles de nommage du code pour que tout le monde code de la même façon.
* **Procédure de déploiement :** Comment mettre en ligne les modifications sans tout casser.
