# Cadre de Cohérence Technique
## Produits numériques des ministères sociaux

*Version 1.0 - Draft*

---

## 1. Introduction et enjeux

### 1.1 Contexte

Les ministères sociaux (Travail, Santé, Solidarités) développent de nombreux produits numériques à destination des citoyens, des professionnels et des agents. Ces développements, nécessitent un cadre technique commun pour garantir :

- **Cohérence** : éviter l'hétérogénéité technologique génératrice de dette technique
- **Sécurité** : protection des données sensibles (santé, situation sociale, professionnelle)
- **Efficacité** : mutualisation des bonnes pratiques et réduction des coûts
- **Interopérabilité** : faciliter les échanges entre systèmes et services

### 1.2 Public cible

Ce cadre s'adresse aux :
- **Startups d'État** incubées à la Fabrique numérique
- **Prestataires externes** développant pour les ministères sociaux
- **Équipes internes** en charge du maintien en condition opérationnelle (MCO)
- **Product owners** et **responsables techniques** des produits

### 1.3 Principes directeurs

- **Pragmatisme** : ne pas tout imposer, mais baliser les choix techniques
- **Simplicité** : privilégier les solutions éprouvées et maintenues
- **Conformité** : respect des référentiels nationaux (RGS, RGPD, RGAA, RGI, RGESN)
- **Évolutivité** : adapter les exigences selon la maturité du produit
- **Sécurité by design** : intégrer la sécurité dès la conception

---

## 2. Architecture et technologies

### 2.1 Langages et runtimes

**Recommandé**
- **Node.js** : stack de référence pour sa cohérence avec l'écosystème DNUM, rapidité de développement, facilité de recrutement

**Alternatives**
- **Java Spring Boot** : pour les backends nécessitant une forte montée en charge (>10k utilisateurs simultanés)

**Critères de choix**
- **Node.js** : applications web, API, prototypage rapide, équipes JavaScript
- **Java Spring Boot** : trafic massif, contraintes performance critiques, threading avancé

### 2.2 Frameworks frontend

**Recommandé**
- **Next.js** : framework de référence React avec SSR, SSG, API routes, compatibilité DSFR native

**Alternatives**
- **Angular Universal** ou **Nuxt.js** : uniquement si contraintes métier fortes avec justification obligatoire

**Critères de choix**
- **Next.js** : développement standard, équipe React, intégration DSFR
- **Alternatives** : contraintes techniques spécifiques non couvertes par Next.js

### 2.3 Frameworks backend

**Recommandé**
- **Express** : framework simple et léger, standard de facto Node.js

**Alternatives**
- **NestJS** : structure enterprise, decorators, inspiration Angular
- **Fastify** : performance optimisée, alternative moderne à Express

**Critères de choix**
- **Express** : simplicité, écosystème mature, équipes débutantes Node.js
- **NestJS** : applications complexes, équipes Angular, scalabilité enterprise
- **Fastify** : besoins performance critiques, APIs haute charge

**Cohérence technologique**
- **NestJS + Angular** : même philosophie (decorators, DI, modules), même créateur
- **Express + React** : simplicité, flexibilité, apprentissage rapide

### 2.4 Plateformes backend intégrées

**Solutions complètes**
- **Strapi** : CMS headless avec interface admin, génération APIs automatique
- **Supabase** : backend-as-a-service avec base données, auth, storage

**Critères de choix**
- **Strapi** : gestion contenu, équipes non-techniques, prototypage rapide
- **Supabase** : POC/MVP ultra-rapide, authentification intégrée
- **Frameworks custom** : besoins spécifiques, contrôle total, scalabilité

### 2.5 Design et interface

**Standard obligatoire**
- **DSFR** : système de design officiel de l'État, garantit conformité RGAA via `@codegouvfr/react-dsfr`

**Compléments autorisés**
- **TailwindCSS** : accélération du développement CSS
- **Shadcn/ui** : composants modernes complémentaires

### 2.6 Applications mobiles

**Recommandé**
- **React Native** : cohérence stack JavaScript/TypeScript, Expo CLI (prototypage) / React Native CLI (production)

**Alternatives**
- **Applications natives** : Swift (iOS), Kotlin (Android) pour performances critiques uniquement

**Critères de choix**
- **React Native** : cohérence équipe web, développement multiplateforme
- **Natif** : performances critiques, intégration OS profonde

### 2.7 Applications desktop

**Recommandé**
- **Electron** : cohérence stack web Node.js/React/TypeScript, réutilisation code existant

**Alternatives**
- **Tauri** : backend Rust + frontend web, binaires légers, performances optimisées

**Critères de choix**
- **Electron** : équipe web existante, prototypage rapide
- **Tauri** : contraintes performance, optimisation ressources, compétences Rust disponibles

### 2.8 Données et stockage

**Base de données recommandée**
- **PostgreSQL** : standard pour toutes nouvelles applications

**Alternatives base de données**
- **Bases existantes** : intégrations legacy uniquement
- **Redis** : cache, sessions, données temporaires

**Accès aux données recommandé**
- **SQL natif** : équipes expérimentées, contrôle total
- **Knex.js** : query builder, compromis performance/productivité

**Alternatives accès données (ORM)**
- **Prisma** : ORM moderne Node.js, génération types automatique
- **TypeORM** : ORM avec decorators, intégration native NestJS
- **Drizzle** : ORM type-safe léger, SQL-like syntax
- **Hibernate** : ORM de référence Java Spring Boot

**Critères de choix**
- **SQL natif/Knex** : équipe SQL experte, requêtes complexes, performance critique
- **Prisma** : développement rapide, équipes TypeScript, génération automatique
- **TypeORM** : projets NestJS, équipes Angular (même approche decorators)
- **Drizzle** : type-safety maximale, contrôle SQL, performance

### 2.9 APIs et interfaces

**Standards recommandés**
- **REST** : standard par défaut avec OpenAPI/Swagger obligatoire

**Alternatives**
- **GraphQL** : justification métier forte uniquement
- **gRPC** : communication inter-services haute performance

**Standards obligatoires**
- **Versioning** : obligatoire dès mise en production
- **Documentation** : OpenAPI/Swagger systématique
- **Authentification** : tokens JWT avec expiration courte

**Critères de choix**
- **REST** : simplicité, documentation automatique, standard industrie
- **GraphQL** : besoins requêtes complexes, optimisation réseau, frontend flexible
- **gRPC** : microservices, performance critique, typage strict

---

## 3. Sécurité et conformité

### 3.1 Authentification et autorisation

**Standards obligatoires**
- **FranceConnect** : authentification citoyens avec FranceConnect+ pour données sensibles
- **ProConnect** : authentification agents et professionnels des ministères sociaux

**Alternatives techniques**
- **OAuth 2.0/OIDC** : authentification APIs
- **SAML** : intégration SI existants uniquement
- **JWT** : tokens avec expiration courte (<1h) + refresh tokens

**Critères de choix**
- **FranceConnect** : services citoyens, démarches administratives personnelles
- **ProConnect** : applications internes, agents ministères sociaux, outils professionnels
- **OAuth 2.0** : APIs, authentification machine-to-machine
- **SAML** : contrainte d'intégration SI legacy existants

### 3.2 Protection des données

**Conformité RGPD obligatoire**
- **Privacy by design** : protection dès conception
- **Minimisation** : collecte données strictement nécessaires
- **Consentement** : mécanismes clairs et révocables
- **Droit oubli** : processus suppression automatisés

**Standards applicatifs obligatoires**
- **Logs sans données personnelles** : jamais de PII dans les logs applicatifs
- **Validation inputs** : sanitization systématique des données entrantes
- **Headers sécurité** : CSP, HSTS, X-Frame-Options obligatoires
- **Gestion erreurs** : messages sans exposition données sensibles
- **Sessions sécurisées** : durée appropriée, invalidation propre

### 3.3 Anonymisation et pseudonymisation

**Obligations légales**
- **Environnements développement** : données anonymisées uniquement
- **Analytics** : suppression identifiants personnels
- **Échanges inter-services** : pseudonymisation systématique

**Outils recommandés**
- **Faker.js** : génération données test
- **K-anonymat** : jeux données statistiques

**Alternatives outils**
- **Suppression sélective** : champs sensibles ciblés
- **Pseudonymisation cryptographique** : clés dédiées

**Standards processus**
- **Pipelines automatisés** : génération données test
- **Audit trails** : traçabilité processus
- **Validation** : équipes métier et juridiques

**Critères de choix**
- **Faker.js** : développement rapide, données réalistes
- **K-anonymat** : analyses statistiques, conformité recherche
- **Suppression** : données ultra-sensibles, sécurité maximale
- **Pseudonymisation** : traçabilité nécessaire, réversibilité contrôlée

### 3.4 Sécurité applicative

**Standards obligatoires**
- **OWASP Top 10** : vérification systématique
- **SonarQube** : analyse statique avec règles sécurité
- **Tests pénétration** : obligatoires avant mise production

**DevSecOps obligatoire**
- **Scans vulnérabilités** : intégrés pipelines CI/CD
- **Secrets management** : jamais en dur dans code
- **Container scanning** : images sécurisées

**Critères d'application**
- **OWASP Top 10** : toutes applications web
- **Tests pénétration** : applications critiques, données sensibles
- **Container scanning** : tous déploiements conteneurisés
- **Secrets externes** : tous environnements production

---

## 4. Standards de développement et qualité

### 4.1 Langages et standards

**Standard obligatoire**
- **TypeScript** : obligatoire pour tout développement JavaScript, strict mode activé

**Outils obligatoires**
- **ESLint** : règles strictes + spécifiques sécurité
- **Prettier** : formatage automatique
- **Husky** : hooks Git validation pré-commit

**Critères d'application**
- **TypeScript** : tous nouveaux projets JavaScript, améliore maintenabilité
- **ESLint strict** : projets production, détection erreurs précoce
- **Prettier** : tous projets, cohérence formatage équipe

### 4.2 Tests et couverture

**Standards par phase**
- **MVP/POC** : tests critiques uniquement (>50% couverture)
- **Stabilisation** : couverture minimale 70%
- **Production** : couverture >80% avec tests E2E

**Outils recommandés**
- **Jest** : tests unitaires et intégration
- **Playwright** : tests end-to-end
- **Testing Library** : tests composants React

**Critères de choix**
- **Jest** : écosystème JavaScript, intégration simple
- **Playwright** : tests E2E modernes, multi-navigateurs
- **>80% couverture** : applications critiques, données sensibles
- **>50% couverture** : prototypage, validation concept

### 4.3 Qualité et métriques

**Standard obligatoire**
- **SonarQube** : intégration obligatoire avec seuils définis

**Seuils qualité obligatoires**
- **Bugs** : 0 toléré
- **Vulnérabilités** : 0 tolérée
- **Code Smells** : < 100 (nouveaux projets)
- **Duplication** : < 3%
- **Maintainability** : A ou B

**Critères d'application**
- **Seuils stricts** : tous projets production
- **Seuils assouplis** : prototypage, exploration technique

### 4.4 Observabilité et monitoring

**Standards obligatoires**
- **Sentry** : monitoring erreurs obligatoire
- **Logs structurés** : format JSON avec corrélation requêtes

**Outils recommandés**
- **Prometheus/Grafana** : métriques applicatives et infrastructure
- **APM** : monitoring performances applicatives

**Critères de choix**
- **Sentry** : toutes applications, alertes temps réel
- **Prometheus** : monitoring avancé, métriques business
- **APM** : applications critiques, optimisation performance
- **Logs JSON** : tous environnements, facilite debugging

---

## 5. Infrastructure et déploiement

### 5.1 Orchestration

**Standard obligatoire**
- **Kubernetes** : orchestrateur unique, déploiements rootless, namespaces isolation

**Configuration obligatoire**
- **RBAC** : contrôle accès granulaire
- **Images légères** : Alpine Linux ou Distroless
- **Multi-stage builds** : optimisation taille
- **Registry sécurisé** : scan vulnérabilités

**Critères d'application**
- **Kubernetes** : tous déploiements production
- **Images légères** : optimisation ressources, sécurité
- **RBAC** : isolation équipes, sécurité renforcée

### 5.2 Environnements

**Standards obligatoires**
- **Développement** : déploiement automatique sur merge
- **Staging** : réplique production pour tests complets
- **Production** : haute disponibilité avec monitoring renforcé

**Gestion configuration obligatoire**
- **Variables environnement** : configuration externalisée
- **Secrets externes** : Kubernetes Secrets ou solutions dédiées
- **Pas de configuration en dur** : jamais dans images

**Critères d'application**
- **3 environnements minimum** : séparation développement/staging/production
- **Secrets externes** : tous environnements, sécurité
- **Monitoring renforcé** : production uniquement

### 5.3 CI/CD

**Pipeline standard obligatoire**
1. **Tests** : unitaires, intégration, sécurité
2. **Build** : compilation et création artefacts
3. **Scan** : vulnérabilités et qualité code
4. **Deploy** : déploiement automatisé avec rollback

**Outils recommandés**
- **GitLab CI** ou **GitHub Actions** : automatisation
- **ArgoCD** : déploiement GitOps
- **Helm** : gestion configurations Kubernetes

**Critères de choix**
- **GitLab CI** : intégration GitLab, pipeline complexes
- **GitHub Actions** : écosystème GitHub, simplicité
- **ArgoCD** : déploiements GitOps, visibilité
- **Rollback automatique** : tous déploiements production

### 5.4 Continuité

**Standards sauvegarde**
- **Bases données** : sauvegarde quotidienne, rétention 30j
- **Données critiques** : sauvegarde temps réel avec réplication
- **Tests restauration** : mensuels avec documentation

**Plan reprise activité**
- **RTO** : <4h services critiques
- **RPO** : <1h données critiques
- **Procédures** : documentation et tests réguliers

**Critères d'application**
- **RTO/RPO stricts** : applications critiques
- **Tests mensuels** : toutes applications production
- **Documentation à jour** : procédures opérationnelles

---

## 6. Gouvernance et processus

### 6.1 Décisions techniques

**Standards obligatoires**
- **Architecture Decision Records (ADR)** : documentation obligatoire choix techniques majeurs
- **Revue de code** : minimum 1 reviewer par PR/MR

**Format ADR obligatoire**
- **Contexte** : problème et contraintes
- **Décision** : solution retenue et justification
- **Conséquences** : impacts techniques et organisationnels
- **Révision** : au moins annuelle

**Critères revue de code**
- **Fonctionnalité** : respect spécifications
- **Sécurité** : conformité standards
- **Performance** : optimisation requise
- **Maintenabilité** : qualité code

### 6.2 Documentation

**Standards obligatoires**
- **README** : installation, utilisation, contribution
- **API** : documentation OpenAPI/Swagger automatique
- **Base de données** : diagramme entité-relation/MCD
- **Architecture** : schéma fonctionnel simple des composants principaux

**Maintenance obligatoire**
- **Synchronisation** : à jour avec le code
- **Accessibilité** : plateforme centralisée (GitLab/GitHub Pages)
- **Versioning** : avec le code source

**Critères d'application**
- **Documentation complète** : tous projets production
- **Documentation minimale** : prototypage, README + API docs
- **Mise à jour automatique** : APIs via OpenAPI/Swagger

---

## 7. Mise en œuvre et temporalité

### 7.1 Phase MVP/POC

**Objectif**
- **Validation concept** : validation rapide du concept métier

**Stack minimale obligatoire**
- **Node.js + Next.js + PostgreSQL** : stack de base
- **DSFR** : interface utilisateur
- **Kubernetes/Docker Compose** : hébergement
- **Sentry** : monitoring de base

**Exigences allégées**
- **Tests critiques** : >50% couverture uniquement
- **Sécurité de base** : HTTPS, authentification simple
- **Anonymisation basique** : environnements développement

### 7.2 Phase Stabilisation

**Objectif**
- **Consolidation** : amélioration continue du produit

**Ajouts obligatoires**
- **Tests** : couverture >70%
- **SonarQube** : métriques qualité
- **Pipeline CI/CD** : automatisation complète
- **Monitoring avancé** : Prometheus/Grafana
- **Anonymisation industrialisée** : processus automatisés

**Standards appliqués**
- **Revue code** : systématique
- **Documentation** : technique complète
- **Tests charge** : si nécessaire

### 7.3 Phase Industrialisation

**Objectif**
- **Production robuste** : service industriel

**Durcissement requis**
- **Audit sécurité** : complet et validé
- **Tests pénétration** : obligatoires
- **Plan reprise activité** : testé et documenté
- **Conformité RGAA** : niveau AA
- **Certification HDS** : si données santé

**Processus matures**
- **ADR** : toute évolution majeure
- **Formation équipes** : continue
- **Métriques SLA** : performance et disponibilité

### 7.4 Critères passage entre phases

**MVP → Stabilisation**
- **Validation métier** : concept prouvé
- **Utilisateurs actifs** : >100 utilisateurs
- **Architecture stable** : technique validée
- **Financement** : pérennisé

**Stabilisation → Industrialisation**
- **Tests charge** : validés
- **Processus qualité** : en place
- **Équipe autonome** : formée
- **Documentation** : complète
- **Métriques production** : satisfaisantes

---

## 8. Retours d'expérience

### 8.1 Technologies à succès

**Succès confirmés**
- **Next.js** : adoption rapide, écosystème riche
- **PostgreSQL** : simplicité, robustesse, performances
- **DSFR** : accessibilité, conformité design
- **Docker/Kubernetes** : standardisation déploiements

**Bénéfices identifiés**
- **TypeScript** : réduction bugs production
- **Revue code** : qualité et partage connaissances
- **Tests automatisés** : détection précoce régressions

### 8.2 Difficultés rencontrées

**Problèmes techniques**
- **ORM multiples** : maintenance complexe, compétences dispersées
- **Stratégies test variables** : qualité inégale
- **Configurations diverses** : complexité opérationnelle

**Problèmes organisationnels**
- **Gestion secrets** : pratiques hétérogènes
- **Anonymisation** : processus manuels
- **Monitoring** : alerting insuffisant

**Solutions appliquées**
- **Standardisation progressive** : migration outils recommandés
- **Formation ciblée** : montée compétences
- **Outillage mutualisé** : templates partagés

---

## Annexes

### Ressources et références
- **DSFR** : https://www.systeme-de-design.gouv.fr/
- **RGS** : Référentiel général de sécurité
- **RGPD** : Règlement général sur la protection des données
- **RGAA** : Référentiel général d'amélioration de l'accessibilité
- **OWASP** : https://owasp.org/

---

*Ce document évolue en fonction des retours d'expérience et des évolutions technologiques. Version maintenue par l'équipe architecture de la DNUM des ministères sociaux.*