Skip to main content
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.