Cahier des charges Application de chat en temps réel

• Une startup souhaite développer une application mobile de messagerie instantanée destinée aux apprenants et formateurs afin de faciliter la communication en temps réel.
• L’application doit être réalisée avec Flutter pour assurer une compatibilité Android et iOS, et doit reposer sur une architecture client–serveur avec WebSockets.
• Le projet doit permettre aux utilisateurs d’échanger des messages texte en temps réel, de consulter l’historique des conversations et de gérer leur statut de connexion.

• Messagerie instantanée bidirectionnelle (faible latence).
• Persistance de l’historique des messages.
• Connexions sécurisées et authentifiées.
• Bon comportement en cas de perte de connexion (reconnexion, file d’envoi).
• Extensibilité (channels, groupes, pièces jointes).

• Authentification des utilisateurs
• Inscription (username, email, mot de passe).
• Connexion sécurisée (JWT ou équivalent).
• Messagerie
• Envoi et réception de messages en temps réel.
• Affichage de l’historique des messages (stockage en base + cache local).
• Statut des messages : envoyé, délivré, lu.
• Indicateurs
• Présence en ligne/hors ligne.
• Indicateur « en train d’écrire ».
• Interface utilisateur (Flutter)
• Page de connexion/inscription.
• Page de liste de conversations.
• Écran de discussion (chat screen).
• Gestion des erreurs
• Déconnexion automatique en cas d’inactivité ou d’expiration du token.
• Tentative de reconnexion automatique en cas de perte du réseau.

• Frontend (client)
• Framework : Flutter (iOS/Android).
• Packages recommandés : web_socket_channel (ou socket_io_client si serveur Socket.IO), provider / riverpod / bloc pour état, shared_preferences / sqflite pour cache local.
• Composants : ChatScreen, service WebSocket réutilisable, stockage local pour cache + file d’envoi.
• Backend (serveur)
• WebSocket endpoint (ex : wss://api.example.com/ws/chat).
• Authentification via JWT (token transmis au handshake / lors des requêtes REST).
• Persistance : NoSQL (MongoDB) ou SQL (Postgres / MySQL) pour messages et métadonnées.
• Composant d’API REST pour auth/historique.
• Option : support de montée en charge (Phoenix/Elixir, Go, Node.js cluster, service managé).

• TLS obligatoire (WSS).
• Conteneurisation (Docker) + orchestration (Kubernetes ou services managés).
• CI/CD pour build et déploiement.
• Monitoring (Prometheus/Grafana, Sentry pour erreurs).

• Table / collection users
• id (uuid)
• username (string)
• email (string)
• password_hash (string)
• avatar_url (string)
• last_seen (datetime)
• created_at, updated_at
• Table / collection messages
• id (uuid ou bigint)
• conversation_id (uuid) — ou sender_id + recipient_id si 1:1
• sender_id
• recipient_id (nullable pour groupes)
• text
• type (text/image/file)
• status (sent/delivered/read)
• timestamp (datetime)
• metadata (json)
• Table conversations (1:1 ou groupe)
• id
• type (private/group)
• participants (array)
• created_at

• Handshake : connexion WebSocket avec JWT dans un header ou query param sécurisé.
• Format général :

{
  "type": "message_type",
  "payload": { ... },
  "requestId": "optional-client-id"
}

• Types courants :
• message.send
• message.receive
• message.ack
• typing.start / typing.stop
• presence.update
• history.request / history.response

• POST /api/auth/login — connexion
• POST /api/auth/register — inscription
• GET /api/users — recherche utilisateurs
• GET /api/conversations/:id/messages — historique paginé
• POST /api/messages — envoi fallback
• GET /api/health — health check

• Connexion via WebSocket + JWT.
• Envoi et réception de messages (optimistic UI).
• Reconnexion automatique (exponential backoff).
• Cache offline (sqflite) + file d’envoi persistante.
• Sécurité : ne pas exposer les tokens dans logs.

• Transport : TLS (WSS) obligatoire.
• Auth : JWT + refresh token.
• Validation côté serveur : XSS, longueur messages.
• Protection anti-spam : rate limiting.
• Données personnelles : conformité RGPD.
• Mots de passe : bcrypt/argon2.

• Latence <200ms.
• Disponibilité HA.
• Durabilité (sauvegardes régulières).
• Scalabilité (Redis/Kafka pour propagation).
• Monitoring & alerting.

• Frontend : Flutter app.
• Backend : WebSocket server + API REST.
• Database : Postgres / MongoDB.
• Redis : pub/sub.
• Infrastructure : NGINX, Docker, Kubernetes.

• US-01 : Connexion
• US-02 : Envoyer un message
• US-03 : Historique
• US-04 : Indicateur de saisie

• Tests unitaires (parser, WebSocket service).
• Tests d’intégration (E2E login → message).
• Tests de charge (10k connexions).
• Tests de sécurité (XSS, injection, token forgery).

• Logs structurés JSON.
• Métriques (connexions, messages/s, erreurs).
• Alerting (Sentry, Prometheus).

• Artefacts : Docker backend, APK/IPA Flutter.
• Pipeline CI/CD.
• Load balancing + TLS.
• Runbooks (rollback, purge messages).

• Spécification technique complète.
• Code Flutter + Backend.
• Dockerfiles + scripts de déploiement.
• Plan de tests.
• Documentation API.

{
  "type": "message.receive",
  "payload": {
    "id": "1694860800000",
    "sender": "alice",
    "text": "Bonjour !",
    "timestamp": "2025-09-16T07:00:00Z",
    "status": "sent"
  }
}

• Utiliser wss:// en production.
• Ne pas exposer tokens dans query string.
• Redis pub/sub pour multi-instances.
• Protocole JSON simple et extensible.