13.2
Définition des KPIs Techniques
La solution de cashback nouvelle génération
< 200ms
Temps réponse P95
99.9%
Uptime API Core
< 0.1%
Taux erreur 5xx
> 1000
RPS
1
INTRODUCTION
1.1 Objectif du Document
Ce document définit l'ensemble des indicateurs clés de performance (KPIs) techniques permettant de mesurer, surveiller et optimiser les performances de la plateforme REWAPP. Ces métriques sont essentielles pour garantir une expérience utilisateur optimale et assurer la stabilité de l'infrastructure.
1.2 Périmètre
Les KPIs techniques couvrent l'ensemble de l'écosystème REWAPP :
- Application Mobile (iOS/Android)
- Site Vitrine (Next.js)
- Dashboard Admin (React)
- Dashboard Partenaire (React PWA)
- Backend API (NestJS)
- Infrastructure Cloud (AWS)
- Intégrations tierces (Solution bancaire, FCM, SendGrid)
1.3 Fréquence de Mesure
Fréquences de Mesure des KPIs
| Type de Mesure | Fréquence | Outils |
|---|---|---|
| Temps réel | Continu (streaming) | CloudWatch, Prometheus |
| Agrégations | Toutes les 5 minutes | Grafana, DataDog |
| Rapports quotidiens | Chaque jour à 6h00 UTC | Rapports automatisés |
| Revues hebdomadaires | Chaque lundi | Réunion tech weekly |
| Bilans mensuels | Premier jour du mois | Dashboard de synthèse |
2
KPIs DE PERFORMANCE
2.1 Temps de Réponse API
Le temps de réponse API est un indicateur critique pour l'expérience utilisateur. REWAPP cible des temps de réponse ultra-rapides pour garantir une navigation fluide.
Métriques Principales
Objectifs de Latence par Percentile
| Métrique | Objectif | Critique | Mesure |
|---|---|---|---|
| P50 (médiane) | < 100ms | > 200ms | Temps de réponse pour 50% des requêtes |
| P95 | < 200ms | > 500ms | Temps de réponse pour 95% des requêtes |
| P99 | < 500ms | > 1000ms | Temps de réponse pour 99% des requêtes |
| P99.9 | < 1000ms | > 2000ms | Temps de réponse pour 99.9% des requêtes |
Objectifs par Type d'Endpoint
Latence P95 par Catégorie
| Type d'Endpoint | Objectif P95 | Exemples |
|---|---|---|
| Lecture simple | < 100ms | GET /users/me, GET /points/balance |
| Lecture avec joins | < 150ms | GET /transactions, GET /partners |
| Écriture simple | < 200ms | POST /transactions, PUT /users |
| Opérations complexes | < 500ms | POST /qrcode/generate, POST /withdrawal |
| Intégrations externes | < 2000ms | Liaison bancaire, vérification transaction |
Formules de Calcul
Temps de réponse = Timestamp réponse - Timestamp requête (en millisecondes)
Moyenne pondérée = Σ(temps × poids) / Σ(poids)
2.2 Throughput (Débit)
Le throughput mesure la capacité du système à traiter un volume élevé de requêtes simultanées.
Métriques de Débit
| Métrique | Objectif | Critique | Description |
|---|---|---|---|
| Requêtes par seconde (RPS) | > 1000 RPS | < 500 RPS | Nombre de requêtes traitées/seconde |
| RPS pic | > 5000 RPS | < 2000 RPS | Capacité en période de pointe |
| Transactions par minute | > 500 TPM | < 100 TPM | Transactions cashback traitées |
| QR codes générés/minute | > 200/min | < 50/min | Génération de QR codes |
Objectifs par Phase de Croissance
Évolution des Capacités
| Phase | Utilisateurs | RPS Cible | TPM Cible |
|---|---|---|---|
| Pilote (M1-M6) | 5 000 | 100 RPS | 50 TPM |
| Croissance (M6-M12) | 50 000 | 500 RPS | 200 TPM |
| Scale (Année 2) | 200 000 | 2000 RPS | 1000 TPM |
| Maturité (Année 3) | 500 000 | 5000 RPS | 3000 TPM |
2.3 Taux d'Erreur
Le taux d'erreur mesure la fiabilité des services et la qualité des réponses API.
Classification des Erreurs
| Code | Type | Objectif | Critique | Action |
|---|---|---|---|---|
4xx |
Erreurs client | < 5% | > 10% | Amélioration UX, validation |
5xx |
Erreurs serveur | < 0.1% | > 0.5% | Alerte immédiate, investigation |
Timeouts |
Dépassements | < 0.5% | > 1% | Optimisation, scaling |
Circuit breaker |
Protections déclenchées | < 0.01% | > 0.1% | Investigation services |
Formules de Calcul
Taux d'erreur global = (Erreurs 4xx + Erreurs 5xx) / Total requêtes × 100
Taux d'erreur serveur = Erreurs 5xx / Total requêtes × 100
Taux de succès = (Total requêtes - Erreurs) / Total requêtes × 100
Objectifs par Service
SLA par Service
| Service | Taux Erreur Max | Taux Succès Min |
|---|---|---|
| API Authentification | 0.05% | 99.95% |
| API Transactions | 0.1% | 99.9% |
| API QR Code | 0.1% | 99.9% |
| API Points | 0.05% | 99.95% |
| Intégration bancaire | 0.5% | 99.5% |
2.4 Disponibilité (Uptime)
La disponibilité mesure le temps pendant lequel les services sont opérationnels et accessibles.
Objectifs de Disponibilité
| Service | SLA Cible | Downtime Autorisé/An | Downtime Autorisé/Mois |
|---|---|---|---|
| API Core | 99.9% | 8h 45min | 43 min |
| Application Mobile | 99.9% | 8h 45min | 43 min |
| Dashboard Partenaire | 99.5% | 43h 48min | 3h 36min |
| Dashboard Admin | 99.5% | 43h 48min | 3h 36min |
| Site Vitrine | 99.9% | 8h 45min | 43 min |
Types de Disponibilité Mesurés
| Type | Description | Méthode de Calcul |
|---|---|---|
| Disponibilité globale | Accessibilité du service | (Uptime / Temps total) × 100 |
| Disponibilité effective | Service fonctionnel | (Temps fonctionnel / Temps total) × 100 |
| Disponibilité dégradée | Service partiellement opérationnel | Pondéré selon criticité fonctions |
3
KPIs DE SCALABILITÉ
3.1 Capacité de Charge
La capacité de charge mesure la quantité maximale de travail que le système peut supporter avant dégradation.
Métriques de Charge
| Métrique | Objectif | Critique | Description |
|---|---|---|---|
| Utilisateurs simultanés | > 10 000 | < 5 000 | Connexions actives en parallèle |
| Connexions DB actives | < 80% pool | > 95% pool | Connexions PostgreSQL |
| Connexions Redis | < 70% | > 90% | Connexions cache |
| File d'attente | < 1000 jobs | > 5000 jobs | Jobs Bull Queue en attente |
Tests de Charge Réguliers
Planning des Tests
| Type de Test | Fréquence | Objectif | Outil |
|---|---|---|---|
| Test de charge | Hebdomadaire | Valider capacité nominale | K6 |
| Test de stress | Mensuel | Identifier points de rupture | K6, Artillery |
| Test d'endurance | Trimestriel | Vérifier stabilité 24h+ | K6 |
| Test de pic | Avant événements | Simuler pics de trafic | K6, Locust |
3.2 Temps de Scaling
Le temps de scaling mesure la réactivité du système face aux variations de charge.
Objectifs de Scaling
| Opération | Objectif | Critique | Description |
|---|---|---|---|
| Scale-up horizontal | < 2 min | > 5 min | Ajout nouvelle instance |
| Scale-down | < 5 min | > 15 min | Suppression instance inactive |
| Scale-up vertical | < 10 min | > 30 min | Augmentation ressources instance |
| Déploiement nouveau service | < 5 min | > 15 min | Container prêt à recevoir trafic |
Politiques d'Auto-Scaling
Configuration Auto-Scaling
| Déclencheur | Seuil Up | Seuil Down | Cooldown |
|---|---|---|---|
| CPU | > 70% pendant 2 min | < 30% pendant 10 min | 5 min |
| Mémoire | > 80% pendant 2 min | < 40% pendant 10 min | 5 min |
| Requêtes en attente | > 100 pendant 1 min | < 10 pendant 5 min | 3 min |
| Latence P95 | > 300ms pendant 2 min | < 100ms pendant 10 min | 5 min |
3.3 Utilisation des Ressources
L'utilisation des ressources permet d'optimiser les coûts tout en maintenant les performances.
Métriques d'Utilisation
| Ressource | Optimal | Sous-utilisé | Sur-utilisé |
|---|---|---|---|
| CPU | 40-70% | < 20% | > 85% |
| Mémoire RAM | 50-75% | < 30% | > 90% |
| Disque I/O | 30-60% | < 10% | > 80% |
| Réseau | 20-50% | < 5% | > 70% |
| Connexions DB | 40-70% | < 20% | > 85% |
Allocations Cibles par Service
Configuration des Services
| Service | CPU | RAM | Instances Min | Instances Max |
|---|---|---|---|---|
| API Gateway | 2 vCPU | 4 GB | 2 | 10 |
| Auth Service | 1 vCPU | 2 GB | 2 | 8 |
| Transaction Service | 2 vCPU | 4 GB | 2 | 12 |
| QR Code Service | 1 vCPU | 2 GB | 2 | 6 |
| Notification Service | 1 vCPU | 2 GB | 1 | 4 |
| Workers (Bull Queue) | 2 vCPU | 4 GB | 2 | 8 |
3.4 Coûts Infrastructure
Les coûts infrastructure sont surveillés pour optimiser le rapport performance/prix.
Métriques de Coût
| Métrique | Objectif | Formule |
|---|---|---|
| Coût par transaction | < 0.005€ | Coût infra mensuel / Nb transactions |
| Coût par utilisateur actif | < 0.50€/mois | Coût infra mensuel / MAU |
| Coût par requête | < 0.00001€ | Coût infra mensuel / Nb requêtes |
| Ratio coût/revenus infra | < 15% | Coût infra / Revenus × 100 |
Budget Prévisionnel Infrastructure
Évolution des Coûts
| Phase | Utilisateurs | Coût Mensuel | Coût/Utilisateur |
|---|---|---|---|
| Pilote | 5 000 | 1 500€ | 0.30€ |
| Croissance | 50 000 | 8 000€ | 0.16€ |
| Scale | 200 000 | 25 000€ | 0.125€ |
| Maturité | 500 000 | 50 000€ | 0.10€ |
4
KPIs DE QUALITÉ LOGICIELLE
4.1 Couverture de Tests
La couverture de tests mesure le pourcentage de code vérifié par des tests automatisés.
Objectifs de Couverture
| Type de Test | Objectif | Minimum | Outil |
|---|---|---|---|
| Tests unitaires | > 80% | 70% | Jest |
| Tests d'intégration | > 60% | 50% | Supertest |
| Tests E2E | > 40% | 30% | Cypress, Detox |
| Tests API | > 90% | 80% | Postman, Newman |
Couverture par Module
Objectifs par Module
| Module | Couverture Cible | Priorité |
|---|---|---|
| Authentification | > 95% | Critique |
| Transactions | > 90% | Critique |
| QR Code | > 90% | Critique |
| Points & Fidélité | > 85% | Haute |
| Notifications | > 75% | Moyenne |
| Admin | > 70% | Moyenne |
| Reporting | > 60% | Basse |
4.2 Taux de Bugs en Production
Le taux de bugs en production mesure la qualité des releases déployées.
Classification des Bugs
| Sévérité | Description | Objectif/Mois | SLA Résolution |
|---|---|---|---|
| Critique (P0) | Blocage complet, perte données | 0 | 1 heure |
| Majeur (P1) | Fonctionnalité principale impactée | < 2 | 4 heures |
| Modéré (P2) | Fonctionnalité secondaire impactée | < 10 | 24 heures |
| Mineur (P3) | Inconfort utilisateur, cosmétique | < 30 | 1 semaine |
Métriques de Qualité
Indicateurs de Qualité
| Métrique | Objectif | Formule |
|---|---|---|
| Densité de bugs | < 0.5 bugs/KLOC | Nb bugs / (Lignes de code / 1000) |
| Bugs par release | < 3 | Nb bugs découverts post-release |
| Taux de régression | < 5% | Bugs réintroduits / Total bugs corrigés |
| Escape rate | < 10% | Bugs prod / Total bugs détectés |
4.3 Temps de Résolution
Le temps de résolution mesure la réactivité de l'équipe face aux problèmes.
Objectifs par Sévérité
| Sévérité | MTTR Cible | MTTR Max | Escalade |
|---|---|---|---|
| Critique (P0) | 30 min | 1 heure | Immédiate |
| Majeur (P1) | 2 heures | 4 heures | 1 heure |
| Modéré (P2) | 8 heures | 24 heures | 4 heures |
| Mineur (P3) | 48 heures | 1 semaine | 24 heures |
Métriques de Résolution
| Métrique | Description | Objectif |
|---|---|---|
| MTTR | Mean Time To Resolve - Temps moyen de résolution | < 4 heures |
| MTTA | Mean Time To Acknowledge - Temps moyen de prise en charge | < 15 min |
| MTTD | Mean Time To Detect - Temps moyen de détection | < 5 min |
| First Response Time | Temps première réponse | < 30 min |
4.4 Dette Technique
La dette technique mesure les compromis techniques qui devront être adressés.
Métriques de Dette
| Métrique | Objectif | Critique | Outil |
|---|---|---|---|
| Dette estimée (jours) | < 20 jours | > 60 jours | SonarQube |
| Code smells | < 100 | > 500 | SonarQube |
| Duplication code | < 3% | > 10% | SonarQube |
| Complexité cyclomatique moyenne | < 10 | > 20 | SonarQube |
| Maintainability rating | A ou B | D ou E | SonarQube |
Stratégie de Réduction de la Dette
- Allocation de 20% du sprint à la réduction de dette technique
- Revue trimestrielle de la dette avec priorisation
- Refactoring systématique lors des corrections de bugs
- Documentation des décisions techniques et trade-offs
5
KPIs DE SÉCURITÉ
5.1 Vulnérabilités Détectées
Le suivi des vulnérabilités assure la sécurité continue de la plateforme.
Classification CVSS
| Sévérité | Score CVSS | Objectif Actif | SLA Correction |
|---|---|---|---|
| Critique | 9.0 - 10.0 | 0 | Immédiat (< 24h) |
| Haute | 7.0 - 8.9 | 0 | 72 heures |
| Moyenne | 4.0 - 6.9 | < 5 | 30 jours |
| Basse | 0.1 - 3.9 | < 20 | 90 jours |
Sources de Détection
Outils de Détection
| Source | Fréquence | Outils |
|---|---|---|
| Scan dépendances | Continu (CI/CD) | Snyk, npm audit |
| Analyse statique (SAST) | Chaque commit | SonarQube, Semgrep |
| Analyse dynamique (DAST) | Hebdomadaire | OWASP ZAP |
| Pentest externe | Annuel | Prestataire certifié |
| Bug bounty | Continu | Programme privé |
5.2 Temps de Correction
Le temps de correction des vulnérabilités est un indicateur critique de la posture sécurité.
Objectifs de Correction
| Sévérité | Détection → Patch | Patch → Déploiement | Total |
|---|---|---|---|
| Critique | < 4h | < 4h | < 8h |
| Haute | < 24h | < 24h | < 48h |
| Moyenne | < 7 jours | < 7 jours | < 14 jours |
| Basse | < 30 jours | < 30 jours | < 60 jours |
5.3 Incidents de Sécurité
Le suivi des incidents permet d'améliorer continuellement la posture de sécurité.
Métriques d'Incidents
| Métrique | Objectif | Critique |
|---|---|---|
| Incidents critiques/an | 0 | > 1 |
| Tentatives intrusion bloquées | Tracking | Alertes anomalies |
| Comptes compromis | 0 | > 0.01% utilisateurs |
| Fuites de données | 0 | > 0 |
| Temps de détection intrusion | < 1 heure | > 24 heures |
Types d'Incidents Surveillés
- Tentatives de brute force sur authentification
- Injections SQL/NoSQL
- Cross-Site Scripting (XSS)
- Accès non autorisés aux données
- Fraude QR code
- Abus API (rate limiting)
5.4 Conformité
La conformité mesure l'alignement avec les normes et réglementations.
Normes et Certifications
| Norme | Périmètre | Objectif | Audit |
|---|---|---|---|
| RGPD | Données personnelles | 100% conforme | Annuel |
| PCI DSS | Données bancaires | Via partenaire agréé | Annuel |
| ISO 27001 | Sécurité information | Certification Y2 | Annuel |
| SOC 2 Type II | Contrôles sécurité | Objectif Y3 | Annuel |
Métriques de Conformité
| Métrique | Objectif | Mesure |
|---|---|---|
| Consentements RGPD valides | 100% | Utilisateurs avec consentement actif |
| Demandes RGPD traitées dans délai | 100% | < 30 jours |
| Chiffrement données sensibles | 100% | Données au repos et en transit |
| Rotation des secrets | 100% | Tous les 90 jours |
| Audit trail complet | 100% | Actions admin tracées |
6
KPIs APPLICATIFS MOBILES
6.1 Performance App Mobile
Les performances de l'application mobile impactent directement l'expérience utilisateur.
Métriques de Performance Mobile
| Métrique | iOS Cible | Android Cible | Critique |
|---|---|---|---|
| Temps de lancement (cold start) | < 2s | < 3s | > 5s |
| Temps de lancement (warm start) | < 1s | < 1.5s | > 3s |
| Taille de l'app | < 50 MB | < 60 MB | > 100 MB |
| Consommation mémoire | < 150 MB | < 200 MB | > 300 MB |
| Consommation batterie/heure | < 3% | < 4% | > 8% |
| Temps génération QR | < 500ms | < 500ms | > 2s |
Métriques de Navigation
Temps de Chargement par Écran
| Écran | Temps Chargement Cible | Critique |
|---|---|---|
| Écran d'accueil | < 500ms | > 1.5s |
| Historique transactions | < 1s | > 3s |
| Génération QR code | < 500ms | > 2s |
| Liste partenaires | < 1s | > 3s |
| Profil utilisateur | < 500ms | > 1.5s |
6.2 Stabilité Applicative
La stabilité mesure la fiabilité de l'application en conditions réelles.
Métriques de Stabilité
| Métrique | Objectif | Critique | Outil |
|---|---|---|---|
| Crash-free users | > 99.5% | < 98% | Sentry, Crashlytics |
| Crash-free sessions | > 99.9% | < 99% | Sentry, Crashlytics |
| ANR rate (Android) | < 0.1% | > 0.5% | Play Console |
| Errors par session | < 0.5 | > 2 | Sentry |
Suivi par Version
Critères de Rollback
| Métrique | Seuil Rollback | Action |
|---|---|---|
| Crash rate nouvelle version | > 2% (vs précédente) | Rollback automatique |
| ANR rate nouvelle version | > 0.5% (vs précédente) | Investigation urgente |
| Plaintes utilisateurs | > 10/jour sur même bug | Hotfix prioritaire |
7
KPIs INFRASTRUCTURE CLOUD
7.1 Santé des Services
La santé des services AWS est surveillée en continu.
Métriques par Service AWS
| Service | Métrique Clé | Objectif | Alerte |
|---|---|---|---|
| ECS Fargate | Running tasks | 100% healthy | < 80% |
| RDS PostgreSQL | CPU utilization | < 70% | > 85% |
| RDS PostgreSQL | Connections | < 80% max | > 90% |
| ElastiCache Redis | Memory usage | < 75% | > 90% |
| ElastiCache Redis | Cache hit ratio | > 90% | < 80% |
| ALB | Healthy hosts | 100% | < 100% |
7.2 Coûts et Optimisation
L'optimisation des coûts cloud est un objectif permanent.
Répartition Budgétaire
| Service | Part Budget | Optimisation |
|---|---|---|
| Compute (ECS) | 40% | Reserved capacity, spot instances |
| Database (RDS) | 25% | Reserved instances, right-sizing |
| Cache (ElastiCache) | 10% | Right-sizing |
| Storage (S3) | 5% | Lifecycle policies, tiers |
| Network (ALB, CloudFront) | 10% | Caching, compression |
| Autres (CloudWatch, etc.) | 10% | Log retention, sampling |
8
TABLEAUX DE BORD ET MONITORING
8.1 Dashboards par Audience
Dashboards par Rôle
| Audience | Dashboard | Métriques Clés | Refresh |
|---|---|---|---|
| Direction | Executive Summary | Uptime, erreurs critiques, coûts | Quotidien |
| Équipe Tech | Operations Dashboard | Tous KPIs performance/infra | Temps réel |
| Équipe Sécurité | Security Dashboard | Vulnérabilités, incidents | Temps réel |
| Product | App Performance | Crash rate, temps chargement | Horaire |
| Support | Health Status | Disponibilité, alertes actives | Temps réel |
8.2 Outils de Monitoring
Stack de Monitoring
| Catégorie | Outil | Usage |
|---|---|---|
| APM | Sentry |
Error tracking, performance mobile |
| Infrastructure | AWS CloudWatch |
Métriques AWS natives |
| Visualization | Grafana |
Dashboards custom |
| Logs | CloudWatch Logs / ELK |
Centralisation logs |
| Alerting | PagerDuty |
Gestion alertes on-call |
| Synthetic | Checkly |
Tests E2E automatisés |
9
SEUILS D'ALERTE ET ESCALADE
9.1 Niveaux d'Alerte
Classification des Alertes
| Niveau | Couleur | Description | Notification |
|---|---|---|---|
| Info | Bleu | Information, pas d'action | Slack uniquement |
| Warning | Jaune | Dégradation, surveillance | Slack + Email |
| Critique | Orange | Impact utilisateur | Slack + SMS |
| Urgent | Rouge | Service indisponible | Slack + SMS + Appel |
9.2 Matrice d'Escalade
0 min - Alerte automatique
Notification immédiate équipe on-call via PagerDuty
2
15 min - Escalade N1
Si non pris en charge, escalade au Lead technique
3
30 min - Escalade N2
Notification de l'Engineering Manager
4
1 heure - Escalade N3
Notification du CTO
5
2 heures - War room
Mobilisation direction + équipe complète
9.3 Exemples de Seuils Configurés
Configuration des Seuils
| Métrique | Warning | Critique | Urgent |
|---|---|---|---|
| API Latency P95 | > 300ms | > 500ms | > 1000ms |
| Error rate 5xx | > 0.5% | > 1% | > 5% |
| CPU usage | > 70% | > 85% | > 95% |
| Memory usage | > 75% | > 90% | > 95% |
| DB connections | > 70% | > 85% | > 95% |
| Queue depth | > 500 | > 1000 | > 5000 |
10
CONCLUSION
10.1 Récapitulatif des KPIs Critiques
KPIs Prioritaires
| Catégorie | KPI Principal | Objectif |
|---|---|---|
| Performance | Temps de réponse API P95 | < 200ms |
| Disponibilité | Uptime API Core | 99.9% |
| Fiabilité | Taux d'erreur 5xx | < 0.1% |
| Scalabilité | Throughput | > 1000 RPS |
| Qualité | Crash-free users | > 99.5% |
| Sécurité | Vulnérabilités critiques | 0 |
10.2 Processus de Revue
- Daily standup : Revue des alertes des dernières 24h
- Weekly tech review : Analyse des tendances, identification des optimisations
- Monthly report : Bilan complet des KPIs, comparaison M-1
- Quarterly review : Revue stratégique, ajustement des objectifs
10.3 Amélioration Continue
Révision des Objectifs KPIs
Les objectifs des KPIs seront revus et ajustés :
- À chaque phase de croissance (pilote → scale)
- Suite aux incidents majeurs (post-mortem)
- En fonction des retours utilisateurs
- Selon l'évolution des standards du marché
L'équipe technique s'engage à maintenir ces KPIs et à alerter proactivement en cas de dégradation, garantissant ainsi la qualité de service attendue par les utilisateurs REWAPP.
Notre Engagement
"REWAPP : Excellence technique au service de l'expérience utilisateur"