Plan de Montée de Version

1.1 Objectif du Document

Ce document définit la stratégie complète de gestion des versions pour l'écosystème REWAPP. Il établit les conventions de versioning, les processus de release, les procédures de migration et les mécanismes de communication pour garantir des mises à jour fluides et transparentes.

1.2 Portée

Ce plan couvre l'ensemble des composantes de l'écosystème REWAPP :

• Application Mobile (iOS/Android) - Angular + Ionic
• Site Vitrine - Next.js + Tailwind CSS
• Dashboard Admin - React + Ant Design/MUI
• Dashboard Partenaire - React (PWA) + Vite
• Backend API - Microservices NestJS
• Base de Données - PostgreSQL (migrations Prisma)

1.3 Documents de Référence

• 10.1 Plan de Déploiement
• 10.5 CI/CD Pipeline
• 14.1 Plan de Maintenance
• 14.2 Procédures de Support
• 4.5 Stack Technique Détaillé

2.1 Semantic Versioning (SemVer)

REWAPP adopte la convention Semantic Versioning 2.0 (semver.org) pour toutes ses composantes.

2.2 Versioning par Composant

Chaque composant de l'écosystème REWAPP maintient sa propre version indépendante :

2.3 Versioning des APIs

L'API Backend REWAPP utilise un versioning explicite dans l'URL pour garantir la stabilité.

/api/v{N}/{resource}

Règles de Versioning API

• Nouvelle version majeure API pour tout breaking change
• Support minimum de 2 versions simultanées
• Dépréciation annoncée 6 mois avant retrait
• Header X-API-Version pour informer du cycle de vie

X-API-Version: v1
X-API-Deprecated: false
X-API-Sunset: null

2.4 Compatibilité et Rétrocompatibilité

3.1 Types de Releases

3.2 Cycle de Release Standard

3.3 Workflow de Développement (GitFlow)

Branches Principales

• main : Code en production, toujours stable
• develop : Intégration des développements en cours

Branches de Travail

• feature/* : Nouvelles fonctionnalités
• bugfix/* : Corrections de bugs
• release/* : Préparation des releases
• hotfix/* : Correctifs d'urgence

# 1. Développement
feature/nouvelle-fonctionnalite → develop

# 2. Préparation Release
develop → release/v1.2.0 → main (+ tag v1.2.0) + develop

# 3. Hotfix
main → hotfix/correction-critique → main (+ tag v1.2.1) + develop

3.4 Critères de Go/No-Go

4.1 Changelog et Documentation

Chaque repository maintient un fichier CHANGELOG.md au format Keep a Changelog :

# Changelog

## [1.2.0] - 2025-11-24

### Added
- Nouveau système de paliers de fidélité (#234)
- Notifications push personnalisées (#245)

### Changed
- Amélioration des performances de génération QR (#256)

### Fixed
- Correction du calcul des points expirés (#267)

### Security
- Mise à jour des dépendances de sécurité (#278)

## [1.1.0] - 2025-10-15
...

4.2 Notes de Version (Release Notes)

Exemple de Release Notes

4.3 Guides de Migration

Les guides de migration sont fournis pour chaque release majeure ou changement breaking.

1. 1

   Prérequis

   Version source minimale, dépendances requises, backup recommandé

2. 2

   Étapes de Migration

   Étape par étape avec commandes, points de contrôle, validations intermédiaires

3. 3

   Changements Breaking

   Liste des incompatibilités, modifications API, nouveau format de données

4. 4

   Rollback

   Procédure de retour arrière, données à restaurer

5. 5

   FAQ Migration

   Questions fréquentes, problèmes connus

4.4 Support des Versions Précédentes

5.1 Stratégie de Déploiement Progressif

REWAPP utilise une stratégie de rollout progressif pour minimiser les risques :

5.2 Feature Flags

REWAPP utilise des feature flags pour activer/désactiver des fonctionnalités sans redéploiement.

Conventions de Nommage

{type}_{feature_name}

Exemples :
- feature_new_dashboard
- ops_maintenance_mode
- experiment_checkout_v2

5.3 Canary Releases

Pour les fonctionnalités à haut risque, un déploiement Canary est utilisé :

1. 1

   5% du trafic pendant 2 heures

   Déploiement initial sur un petit groupe

2. 2

   Analyse des métriques

   Erreurs, latence, conversion

3. 3

   Si OK : passage à 25%

   Extension progressive

4. 4

   Si KO : rollback automatique

   Retour immédiat à la version précédente

5.4 Monitoring Post-Release

6.1 Politique de Dépréciation

6.2 Cycle de Vie d'une Fonctionnalité

6.3 Communication des Dépréciations

Canaux de Communication

• Documentation API : Badge "Deprecated" sur les endpoints
• Réponses API : Header X-API-Deprecated: true
• Console développeur : Avertissements dans les logs
• Email : Notification aux partenaires utilisant la fonctionnalité
• Changelog : Section dédiée aux dépréciations
• Dashboard Partenaire : Notification in-app

X-API-Deprecated: true
X-API-Deprecated-Message: This endpoint will be removed on 2026-06-01. Use /api/v2/points instead.
X-API-Sunset: 2026-06-01

7.1 Communication Interne

7.2 Communication Externe (Utilisateurs)

Notifications In-App

• Modal au premier lancement post-mise à jour
• Badge "Nouveautés" sur écran profil
• Lien vers release notes complètes

7.3 Communication Partenaires

7.4 Templates de Communication

Template Annonce Release (Utilisateurs)

Template Annonce Breaking Change (Partenaires)

8.1 Application Mobile (iOS/Android)

Versioning Mobile

• iOS : CFBundleShortVersionString (X.Y.Z) + CFBundleVersion (Build N)
• Android : versionName (X.Y.Z) + versionCode (entier incrémental)

Forçage de Mise à Jour

• Version minimale requise configurable côté serveur
• Si version app < version minimale → écran de mise à jour obligatoire
• Soft update (recommandé) vs Hard update (bloquant)

8.2 Site Vitrine et Dashboards

Déploiement Web

• Automatique sur merge vers main
• CDN CloudFront avec invalidation cache
• Zero downtime garanti
• Rollback : Redéploiement version précédente (< 5 min)

Versioning Web

• Version embarquée dans le build
• Visible dans les meta tags et console
• Cache busting automatique (hash dans noms de fichiers)

8.3 Backend API

Déploiement API

• Blue-Green deployment sur ECS Fargate
• Health checks obligatoires
• Rollback automatique si échec health check
• Temps de déploiement : < 15 minutes

Versioning API

• Version dans URL : /api/v1/*
• Header de réponse : X-API-Version
• Documentation Swagger versionnée

Migrations de Schéma API

• Changements additifs uniquement (nouveaux champs optionnels)
• Breaking changes → nouvelle version majeure API
• Période de transition avec support dual-version

8.4 Base de Données

9.1 Hotfix et Correctifs d'Urgence

Critères de Hotfix

• Bug critique affectant > 10% des utilisateurs
• Faille de sécurité confirmée
• Perte de données potentielle
• Fonctionnalité core inopérante (transactions, QR code, virements)

Procédure Hotfix

1. 1

   Création branche

   hotfix/description depuis main

2. 2

   Développement

   Correctif avec scope minimal

3. 3

   Tests

   Unitaires + Intégration (CI)

4. 4

   Review

   1 approbation minimum (processus accéléré)

5. 5

   Merge

   Vers main ET develop

6. 6

   Tag & Déploiement

   vX.Y.Z (increment PATCH), déploiement accéléré

9.2 Rollback de Version

Déclencheurs de Rollback

• Taux d'erreur > 1% pendant 5 minutes
• Latence P95 > 500ms pendant 5 minutes
• Fonctionnalité critique non opérationnelle
• Échec smoke tests post-déploiement

9.3 Post-Mortem

Tout incident de version nécessite un post-mortem dans les 48h.

Template Post-Mortem

1. 1

   Résumé de l'Incident

   Date et durée, impact (utilisateurs affectés, fonctionnalités), sévérité

2. 2

   Timeline

   Chronologie détaillée des événements

3. 3

   Cause Racine

   Analyse technique de la cause

4. 4

   Actions de Résolution

   Étapes pour résoudre l'incident

5. 5

   Actions Préventives

   Mesures pour éviter la récurrence, améliorations du processus

6. 6

   Leçons Apprises

   Ce qui a bien fonctionné, ce qui peut être amélioré

10.1 KPIs de Release

10.2 Suivi de l'Adoption

10.3 Reporting

Rapports de Release

• Rapport Hebdomadaire : Releases effectuées, incidents rencontrés, métriques de qualité
• Rapport Mensuel : Tendances des KPIs, analyse des incidents, améliorations du processus
• Rapport Trimestriel : Bilan des releases majeures, ROI des améliorations, roadmap des optimisations

11.1 Récapitulatif

Ce plan de montée de version établit un cadre rigoureux pour gérer les évolutions de l'écosystème REWAPP :

• Semantic Versioning : Convention claire et prévisible
• Processus de Release Structuré : Phases définies avec critères de validation
• Rollout Progressif : Minimisation des risques via feature flags et canary
• Communication Transparente : Utilisateurs et partenaires informés à chaque étape
• Gestion des Incidents : Procédures de hotfix et rollback testées

11.2 Points Clés

11.3 Évolutions Prévues

Court terme (6 mois)

• Automatisation complète des release notes
• Dashboard de suivi d'adoption des versions
• Intégration des feature flags dans le Dashboard Admin

Moyen terme (12 mois)

• A/B testing intégré au système de feature flags
• Déploiement multi-région avec versioning par région
• API versioning automatique avec contract testing