# Cahier des Charges Techniques & Specifications Fonctionnelles

## Projet

**Systeme d'Information et de Logistique Evenementielle Interconnecte**  
**Client :** Communaute de Communes Des Savanes (CCDS)

## 1. Architecture technique & configuration globale

### 1.1 Exigences environnementales & compatibilite

Le systeme doit fonctionner comme une plateforme web complete, sans imposer l'installation d'une application native externe aux agents techniques ou aux usagers.

Exigences :

- aucune application PWA, APK ou iOS dediee ne doit etre obligatoire ;
- toutes les interactions doivent etre possibles depuis un navigateur web standard ;
- l'interface d'administration doit etre optimisee pour bureau et tablette ;
- l'interface terrain / restitution doit etre concue en approche mobile-first pour des ecrans de 4 a 7 pouces ;
- les emails emis par la plateforme doivent etre compatibles avec Outlook, Gmail, Apple Mail, Yahoo et les principaux webmails.

### 1.2 Gestion de la securite, roles et permissions (RBAC)

La base de donnees et la logique applicative doivent implementer strictement trois niveaux d'acces.

#### Super-administrateur

- acces complet en lecture / ecriture sur l'ensemble du systeme ;
- seul role autorise a creer, suspendre ou supprimer des comptes ;
- seul role autorise a configurer l'inventaire materiel global ;
- seul role autorise a modifier les variables de pilotage du systeme ;
- seul role autorise a definir les stocks plafonds, les valeurs de remplacement et les regles sensibles.

#### Administrateur

- instruction complete des demandes associations ;
- validation / refus des dossiers ;
- affectation des services et agents techniques ;
- pilotage du calendrier, de la logistique et des retours ;
- traitement des dossiers de cautionnement et d'arbitrage en cas de litige ;
- impossibilite de modifier la structure de base de l'inventaire ou les comptes utilisateurs.

#### Utilisateur simple / agent de terrain

- acces limite a ses missions affectees ;
- interface mobile epuree ;
- consultation et cloture de ses seules missions logistiques ;
- absence d'acces aux modules globaux d'administration, stock, comptes, statistiques et reglage.

### 1.3 Journal d'audit inviolable

Le systeme doit integrer un journal d'audit en mode **append-only** :

- aucune modification d'une ligne d'audit ne doit etre possible ;
- aucune suppression d'une ligne d'audit ne doit etre possible, y compris pour le super-administrateur ;
- les ecritures doivent etre ajoutees chronologiquement uniquement.

Chaque enregistrement doit contenir au minimum :

- `timestamp` : date et heure issues exclusivement de l'horloge serveur ;
- `user_id` et `user_role` ;
- `action_type` ;
- `payload` lisible en langage clair ;
- `ip_address`.

Exemple attendu :

`Le 18/05 à 14h22, l'Admin X a accepté la demande #412`

## 2. Specifications des modules back-office

### 2.1 Tableau de bord operationnel

Le tableau de bord est l'ecran d'accueil par defaut apres authentification administrative.

Il doit fonctionner comme un centre de decision et se mettre a jour de facon dynamique sans rechargement complet de page.

Composants attendus :

#### Bandeau d'alertes logistiques

- **Alerte rouge** : nombre de restitutions en retard  
  Condition : `date actuelle > date restitution + 3 jours`
- **Alerte orange** : nombre de litiges / degradations non arbitres
- **Badge bleu** : nouvelles demandes en attente d'instruction

Chaque indicateur doit etre cliquable et appliquer un filtre direct sur les dossiers concernes.

#### Flux operationnel journalier

Deux colonnes :

- **Departs / matin** : mises a disposition ou livraisons du jour
- **Retours / apres-midi** : restitutions attendues au jour J

Chaque ligne doit faire apparaitre :

- l'association ;
- le type de mission ;
- le statut d'assignation ;
- un acces rapide au dossier.

#### Composant de visualisation des stocks

- graphique donut ou barres ;
- quantites disponibles / engagees / bloquees ;
- lecture simple par categorie de materiel.

#### Fil d'activite

- affichage des 5 derniers evenements du journal d'audit ;
- lecture chronologique claire ;
- acces au journal complet.

### 2.2 Module unifie "Dossier & assignation logistique"

Le systeme doit supprimer les blocages de navigation entre consultation et action.

#### Depuis la fiche dossier

La fiche complete d'une demande acceptee doit integrer un bloc :

`Assigner un service recuperateur`

Ce bloc doit permettre :

- de choisir un service ou agent via un menu relie a l'annuaire interne ;
- de valider l'assignation sans quitter la fiche ;
- de declencher le workflow de terrain.

#### Depuis l'ecran d'assignation

Un bouton secondaire :

`Voir la demande`

doit ouvrir un panneau lateral ou une drawer affichant :

- details de l'association ;
- liste complete du materiel ;
- dates ;
- lieu / manifestation ;
- informations utiles a la decision.

### 2.3 Calendrier logistique predictif

Le calendrier doit etre relie a l'inventaire reel.

#### Regle d'indexation stock

Lorsqu'une demande est validee sur une periode donnee :

- les quantites reservees doivent etre deduites du stock global ;
- cette deduction ne s'applique que sur la plage temporelle concernee.

#### Affichage visuel attendu

Chaque dossier doit produire trois phases visibles :

- **Sortie / livraison** : bleu
- **Manifestation / indisponibilite stock** : phase d'utilisation
- **Alerte restitution** : jaune

#### Interactions attendues

Au clic sur un evenement du calendrier :

- consulter l'agent ou service affecte ;
- reassigner la mission ;
- telecharger le PDF finalise si disponible.

### 2.4 Cartographie interactive & implantation territoriale

La cartographie doit etre connectee a la base de donnees et servir a la fois le grand public et l'administration.

Technologies recommandees :

- Leaflet.js
- ou Mapbox GL JS

Traitements attendus :

- geocodage automatique des adresses via `api-adresse.data.gouv.fr` ou `Nominatim`
- stockage des coordonnees geographiques
- clustering obligatoire pour eviter la surcharge visuelle

Filtres attendus :

- annuaire public par thematique ;
- vue logistique admin ;
- heatmap / densite ;
- filtres territoriaux sur Iracoubo, Kourou, Saint-Elie, Sinnamary.

## 3. Specifications du workflow mobile terrain

### 3.1 Declenchement & routage

Un traitement planifie quotidien doit verifier les dossiers.

Pour tout dossier dont la restitution theorique est a **J-4** :

- generer un jeton d'acces securise temporaire ;
- construire une URL unique ;
- injecter cette URL dans l'email du service ou agent affecte.

Exemple de forme attendue :

`https://ccds.fr/restitution/v1?token=sha256_unique_hash`

### 3.2 Interface mobile & gestion non bloquante

Lors de l'ouverture sur smartphone :

- les donnees de mise a disposition sont pre-remplies et figees ;
- l'agent ne modifie pas les donnees source de la demande ;
- le constat terrain se fait sur l'etat reel de restitution.

#### Bloc "Restitution de materiel"

Boutons radio exclusifs :

- `Conforme`
- `Non conforme / Partiel`

Comportement attendu :

- `Conforme` valide globalement le retour ;
- `Non conforme / Partiel` active obligatoirement le bloc observations.

#### Bloc "Observations contradictoires"

Cases a cocher :

- equipement manquant
- accessoires / visserie manquants
- armature deformee
- toile / bache dechiree
- impact / choc majeur
- restitution sale
- materiel humide

Des qu'une case est cochee :

- le champ texte libre devient obligatoire.

### 3.3 Double signature, horodatage et resilience GPS

#### Horodatage certifie

Le backend doit ecraser toute date / heure issue de l'appareil.

La date officielle est generee exclusivement par le serveur au moment de la soumission.

#### Gestion robuste de la geolocalisation

Le script `navigator.geolocation` doit :

- fonctionner en asynchrone ;
- comporter un timeout strict de `5000 ms` ;
- ne jamais bloquer la validation finale.

Scenarios :

- **Succes** : les coordonnees sont jointes a la soumission
- **Echec** : la valeur `Non disponible` est enregistree, mais la validation continue normalement

#### Signature tactile

Le systeme doit integrer :

- une zone de signature pour l'agent ;
- une zone de signature pour l'emprunteur ;
- les qualites associees ;
- un rendu suffisamment fluide pour un usage doigt / stylet.

### 3.4 Generation dynamique du PDF & archivage

Apres validation finale :

- le serveur compile le document officiel ;
- fusionne les donnees, signatures et metadonnees ;
- applique le logo CCDS ;
- produit un PDF A4 sur une page si le contenu le permet.

Contraintes de sortie :

- CSS imprimee calibree ;
- signatures visibles ;
- mise en page stable ;
- envoi automatique en piece jointe :
  - a l'association ;
  - a la DSU ;
- mise a jour du statut en base.

## 4. Protocole expeditif automatise : gestion des litiges

Si la restitution est saisie comme `Non conforme / Partiel` ou `Mauvais etat` :

### 4.1 Rupture de flux & gel logistique

Le dossier passe en :

`LITIGE / ATTENTE ARBITRAGE`

Le materiel concerne doit etre marque indisponible pour :

- bloquer son retour dans le calendrier ;
- empecher sa relocation par erreur.

### 4.2 Interface d'arbitrage financier

La fiche admin du dossier doit permettre :

- de saisir le cout d'un devis ;
- de saisir un cout interne ;
- ou d'appliquer la valeur de remplacement a neuf issue de l'inventaire.

### 4.3 Notification & cloture

Le systeme doit proposer :

- un bouton `Generer courrier de litige`
- un document pre-rempli pour notifier l'association

Le dossier ne peut etre cloture definitivement qu'apres arbitrage explicite parmi :

- retenue partielle sur caution
- encaissement total
- classement sans suite

La decision doit :

- mettre a jour le stock ;
- liberer ou non le materiel ;
- etre ecrite dans le journal d'audit.

## 5. Vision d'ensemble

La plateforme doit etre comprise comme un **ecosysteme logistique connecte et predictif**.

Elle doit permettre :

- de centraliser la gestion associative ;
- de piloter le materiel dans le temps ;
- de fluidifier les workflows terrain ;
- de proteger juridiquement et financierement la collectivite ;
- d'offrir a la direction un vrai centre de controle.

## 6. Resultat attendu

Le systeme final ne doit pas etre un simple outil de gestion administrative.

Il doit devenir :

- une plateforme de service public numerique ;
- un centre de pilotage logistique ;
- un outil de tracabilite ;
- un support de decision ;
- et un cadre fiable pour l'arbitrage, le stock et les operations terrain.