03 - Workflow de Développement

Audience : Développeurs
Durée estimée : 15-30 minutes (lecture)
Prérequis : 02 - Lancement des Services terminé

---

1. Vue d’ensemble

Le workflow de développement suit la méthodologie Vertical Slice Workflow définie dans le SOP (docs/SOP/Standard-operating-procedure.md).

Le cycle de vie d’un objet est : DOC → SPEC → CODE → TEST → INTÉG

---

2. Cycle de vie d’un objet

2.1. Étape 1 — DOC : La Fiche d’Objet

• Action : Transformer le template générique en fiche d’objet concrète
• Emplacement : docs/[Couche]/[Dossier]/[nom].objectData.md
• Règle d’or : La fiche d’objet est la source de vérité absolue. Le code ne doit jamais diverger de la fiche.

2.2. Étape 2 — SPEC : Contrats d’Entrée/Sortie

• Action : Documenter les contrats avant toute ligne de code
• Contenu :
  • Inputs : Paramètres, headers, body
  • Outputs : Status codes, headers de réponse, body
  • Side effects : Écritures KV, Queues, R2, Webhooks
  • Erreurs : Cas d’erreur et codes HTTP associés

2.3. Étape 3 — CODE : Implémentation

• Action : Développement strictement guidé par la fiche d’objet
• Règle : Aucune supposition n’est permise ; la fiche dicte l’implémentation.

2.4. Étape 4 — TEST : Validation à 3 Niveaux

Niveau	Moment d’exécution	Méthodologie
Unitaire	Immédiatement après le code	Vitest / Testing Library (composants) ; tests isolés pour Workers (wrangler dev + curl)
Intégration	Avant de passer à l’objet suivant du même slice	Test de l’objet avec ses dépendances directes (ex: schéma Sanity + requête GROQ + rendu Astro)
End-to-End (E2E)	À la fin du slice complet	Playwright : parcours utilisateur réel (ex: publier un article → webhook → rebuild → recherche Pagefind)

2.5. Étape 5 — INTÉG : Vérification de Cohérence

• Action : “Integration check” pour s’assurer que le nouvel objet ne casse aucun objet existant
• Méthode : Relance des tests E2E des slices précédents

---

3. Workflow Quotidien Type

3.1. Matin

1. Sélectionner l’objet du jour (dans le slice en cours)
2. Ouvrir la fiche d’objet associée
3. Vérifier le statut des dépendances en amont

3.2. Phase DOC (30-60 min)

4. Compléter la fiche avec les valeurs réelles
5. Définir les contrats d’entrée/sortie
6. Rédiger les cas de test attendus

3.3. Phase CODE (2-4h)

7. Implémentation guidée par la fiche
8. Tests unitaires itératifs

3.4. Phase INTÉG (30-60 min)

9. Tests d’intégration avec les objets liés du même slice
10. Mise à jour de la fiche si la réalité technique a divergé

3.5. Fin de journée

11. Commit formaté : slice[X]-objet[Y]: implémentation + fiche à jour
12. Vérification du statut du CI

---

4. Utilisation de Taskfile

4.1. Commandes principales

# Lister toutes les tâches
task --list

# Installer les dépendances
task install

# Lancer le serveur de développement
task dev

# Lancer le Sanity Studio
task dev:studio

# Lancer les Workers Cloudflare
task dev:form-handler
task dev:submission-processor

# Construire l'application
task build

# Lancer les tests
task test

# Lancer le linting
task lint

# Vérifier les types
task typecheck

# Vérifier la qualité (lint + typecheck)
task check

4.2. Commandes Workers

# Typecheck des services Workers
task typecheck:services

# Typecheck du form-handler
task typecheck:form-handler

# Typecheck du submission-processor
task typecheck:submission-processor

4.3. Commandes de nettoyage

# Nettoyer tout (node_modules + builds)
task clean

# Nettoyer uniquement les node_modules
task clean:deps

# Nettoyer uniquement les builds
task clean:build

---

5. Workflow Git

5.1. Créer une branche

# Se mettre sur develop
git checkout develop

# Pull les dernières modifications
git pull origin develop

# Créer une branche feature
git checkout -b feature/slice-X-tache

5.2. Commiter les modifications

# Ajouter les fichiers
git add .

# Commiter
git commit -m "feat: description de la modification"

# Pusher
git push origin feature/slice-X-tache

5.3. Créer une Pull Request

1. Aller sur GitHub
2. Cliquer sur “New Pull Request”
3. Sélectionner la branche feature/slice-X-tache vers develop
4. Remplir le template de PR
5. Soumettre pour review

---

6. Dépannage

6.1. Problèmes courants

Symptôme	Cause probable	Solution
Fiche d’objet non synchronisée	Code modifié sans mise à jour de la fiche	Mettre à jour la fiche avant commit
Tests unitaires échouent	Implémentation incorrecte	Corriger l’implémentation selon la fiche
Tests d’intégration échouent	Dépendances mal configurées	Vérifier les dépendances et la configuration
Typecheck échoue	Types incorrects	Corriger les types selon l’interface définie

6.2. Ressources

• SOP : docs/SOP/Standard-operating-procedure.md
• Taskfile : Taskfile.yaml
• Documentation Astro : https://docs.astro.build/
• Documentation Sanity : https://www.sanity.io/docs

---

7. Checklist de validation

Avant de commiter une modification, vérifier :

• La fiche d’objet est à jour
• Les contrats d’entrée/sortie sont documentés
• L’implémentation suit la fiche d’objet
• Les tests unitaires passent
• Les tests d’intégration passent
• Le typecheck passe
• Le linting passe
• Le commit est formaté correctement

---

8. Prochaine étape

Une fois le workflow compris, passer à : 04 - Tests et Validation

---

9. Historique des modifications

Date	Version	Description	Auteur
2026-09-16	1.0	Création initiale	Devin