refactor(docs): réorganiser ADR et règles métier pour clarté

**Changements majeurs** :

1. **Suppression ADR-010 (Commandes volant et likes)** :
   - Contenu consolidé dans Règle 05 (section 5.3)
   - Raison : ADR-010 était du métier déguisé en architecture
   - Section "Implémentation Technique" ajoutée à Règle 05
   - Pattern correct (addition) vs incorrect (multiplication)

2. **Déplacement ADR-011 → Compliance** :
   - `docs/adr/011-conformite-stores.md` → `docs/compliance/stores-submission.md`
   - Raison : Nature opérationnelle/légale, pas architecture technique
   - Nouveau dossier `/docs/compliance/` créé

3. **Renumérotation ADR (010-022)** :
   - Combler les trous de numérotation (010 et 011)
   - ADR-012→010, ADR-013→011, ..., ADR-024→022
   - 22 ADR numérotés en continu (001-022)
   - Historique Git préservé (git mv)

4. **Mise à jour références** :
   - Règle 03 : ADR-010 → Règle 05 (section 5.3)
   - Règle 09 : ADR-010 → Règle 05 (section 5.3)
   - INCONSISTENCIES-ANALYSIS.md : toutes références mises à jour
   - Incohérence #15 annulée (faux problème : modes séparés)

**Résultat** :
- ✅ Séparation claire ADR (technique) vs Règles métier (fonctionnel)
- ✅ Documentation compliance séparée
- ✅ Numérotation ADR continue sans trous
- ✅ Single Source of Truth (pas de redondance)

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

docs/adr/013-strategie-tests.md

@@ -0,0 +1,86 @@
+# ADR-013 : Stratégie Tests
+
+**Statut** : Accepté
+**Date** : 2025-01-20
+
+## Contexte
+
+RoadWave nécessite une couverture tests robuste avec documentation vivante des use cases. La stratégie doit équilibrer vélocité développement et qualité.
+
+## Décision
+
+Approche **multi-niveaux** : unitaires, intégration, BDD (Gherkin), E2E, load testing.
+
+## Stratégie par type
+
+| Type | Framework | Cible | Fréquence |
+|------|-----------|-------|-----------|
+| **Unitaires** | Testify | 80%+ couverture | Chaque commit |
+| **Intégration DB** | Testify + Testcontainers | Repositories critiques | Avant merge PR |
+| **BDD (Gherkin)** | Godog | User stories | Avant release |
+| **E2E Mobile** | Flutter integration_test | Parcours critiques | Nightly |
+| **Load** | k6 | N/A | Avant mise en prod |
+
+## Tests unitaires (Testify)
+
+- **Framework** : `github.com/stretchr/testify`
+- **Couverture minimale** : 80% sur packages `internal/*/service.go`
+- **Exécution** : Chaque commit (CI rapide ~30s)
+
+## Tests BDD (Gherkin + Godog)
+
+- **Framework** : `github.com/cucumber/godog`
+- **Couverture** : Tous les cas d'usage du [README.md](../../README.md) traduits en `.feature`
+- **Exécution** : Avant release
+- **Détails** : Voir [ADR-007](007-tests-bdd.md) pour contexte complet
+
+## Tests intégration (Testcontainers)
+
+- **Framework** : `github.com/testcontainers/testcontainers-go`
+- **Scope** : Repositories avec PostGIS/Redis (requêtes spatiales complexes)
+- **Exécution** : Avant merge PR
+- **Justification** : Validation des requêtes PostGIS impossibles à mocker
+
+## Tests E2E Mobile (Flutter)
+
+- **Framework** : `integration_test` (Flutter officiel)
+- **Scope** : Parcours critiques (authentification, lecture audio, géolocalisation)
+- **Exécution** : Nightly builds
+- **Justification** : Validation de l'intégration complète mobile + backend
+
+## Load testing (k6)
+
+- **Framework** : `grafana/k6`
+- **Objectif** : API p99 < 100ms à 10K RPS
+- **Scénarios** : Recommandations géolocalisées, streaming HLS, authentification
+- **Exécution** : Avant mise en production
+
+## Alternatives considérées
+
+| Approche | Avantages | Inconvénients | Décision |
+|----------|-----------|---------------|----------|
+| **Tests unitaires uniquement** | Rapides, simples | Pas de validation intégration | ❌ Insuffisant pour PostGIS |
+| **TDD strict (100% couverture)** | Qualité maximale | Vélocité réduite (-40%) | ❌ Trop coûteux pour MVP |
+| **BDD sans tests unitaires** | Documentation vivante | Feedback lent (3-5min/run) | ❌ Cycle développement trop lent |
+| **Stratégie multi-niveaux** | Équilibre qualité/vitesse | Complexité CI/CD | ✅ **Choisi** |
+
+## Justification
+
+- **80% unitaires** : Feedback rapide (<30s), détection précoce des régressions
+- **BDD** : Documentation vivante alignée avec les règles métier
+- **Testcontainers** : Seule façon fiable de tester PostGIS `ST_DWithin`, `ST_Distance`
+- **E2E ciblés** : Validation des parcours critiques sans ralentir le développement
+- **k6** : Détection des régressions de performance avant production
+
+## Conséquences
+
+- Dépendances :
+  - `github.com/stretchr/testify`
+  - `github.com/cucumber/godog`
+  - `github.com/testcontainers/testcontainers-go`
+  - `grafana/k6` (AGPL-3.0, usage interne OK)
+- Temps CI : ~3-5 min (tests unitaires + BDD)
+- Tests intégration/E2E : nightly builds (15-30 min)
+- Load tests : avant chaque release majeure
+
+**Librairies** : Voir [ADR-018](018-librairies-go.md) pour analyses complètes des frameworks de tests