Cahier des Charges
Étape | Sujet | État |
1 | Objectifs et cahier des charges | ✅ Validé |
2 | Définition des indicateurs | ✅ Validé |
3 | Principe général de saisie | ✅ Validé* |
4 | Centres et identifiants permanents | ✅ Validé |
5 | Utilisateurs et comptes personnels | ✅ Validé |
6 | Rôles et permissions | ✅ Validé |
7 | Hiérarchie des pages et des accès | 🟠 En cours |
7.1 | Interface publique | ✅ Validé |
7.2 | Interface Accueil | ✅ Validé |
7.3 | Interface Transport / Missions | ✅ Validé et clos |
7.4 | Interface Responsable de centre | ⏭️ Prochaine étape |
8 | Nationalités : référentiel, recherche et cas particuliers | À définir |
9 | Déplacements et kilométrage : règles détaillées et cohérence | À finaliser à partir du 7.3 |
10 | Contrôles de validation et règles de cohérence | À définir |
11 | Correction, suppression et délais de modification | À définir |
12 | Audit et traçabilité | À définir |
13 | Périodes, clôtures, validation et publication annuelle | À définir |
14 | Statistiques attendues et séparation public / privé | À définir |
15 | Conception de la base de données V2 | À concevoir |
16 | Portabilité TEST → PROD et indépendance des identifiants techniques | À concevoir |
17 | Charte graphique et ergonomique de la plateforme V2 | À définir avant développement des interfaces |
18 | Développement du moteur V2 | Développement |
19 | Développement de l’interface Accueil | Développement |
20 | Développement de l’interface Transport / Missions | Développement |
21 | Développement du tableau de bord Centre | Développement |
22 | Développement du tableau de bord Gestionnaire FNAAM | Développement |
23 | Adaptation/réutilisation des graphiques et composants V1 | Développement |
24 | Statistiques de nationalités | Développement |
25 | Tableau de bord qualité des données | Développement |
26 | Tests fonctionnels | Tests |
27 | Tests de sécurité et contrôle des droits | Tests |
28 | Pilote sur un ou deux centres | Pilote |
29 | Intégration visuelle finale CSS / Elementor / responsive | Finalisation |
30 | Préparation du package et migration PROD | Déploiement |
31 | Documentation, formation et accompagnement au démarrage | Déploiement |
Plateforme statistique V2
Cahier des charges fonctionnel
Version de travail actualisée
17 septembre 2026
Principe de travail : le fonctionnement de la plateforme est défini avant son développement. Les points restant à préciser sont traités progressivement dans les chapitres correspondants.
Ce cahier des charges a été conçu pour être accessible aussi bien aux responsables de la FNAAM et de ses centres qu’aux personnes chargées de la réalisation technique de la plateforme.
Les textes présentés en gras italique correspondent aux intitulés, boutons, menus, messages ou informations qui seront directement visibles par les utilisateurs dans l’application.
Certains termes nécessaires à la description du fonctionnement de la plateforme peuvent être plus techniques. Ils sont signalés par une présentation spécifique et expliqués simplement dans le Lexique situé à la fin du document.
Le document décrit en priorité ce que la plateforme doit permettre de faire et les règles qu’elle doit respecter. Les choix purement techniques de réalisation ne sont détaillés que lorsqu’ils ont une incidence sur son fonctionnement, sa sécurité ou son évolution.
La plateforme V2 doit fournir aux centres d’accueil des marins et à la FNAAM un outil commun de collecte, de suivi, de consolidation et d’analyse de l’activité.
Une information est saisie une seule fois, par la personne qui la connaît, au moment où elle est disponible.
Est considéré comme marin accueilli tout marin qui fréquente le centre au cours d’une journée. Un même marin présent plusieurs fois dans la même journée n’est compté qu’une fois. S’il revient un autre jour, il est de nouveau comptabilisé.
Le registre d’arrivée, papier ou numérique selon le mode retenu, constitue la source de l’information et permet notamment de renseigner la nationalité.
Le nombre de marins transportés correspond aux marins pris en charge lors des déplacements Navire → Centre. Le trajet de retour Centre → Navire ne les comptabilise pas une seconde fois.
Marins transportés = somme des marins pris en charge sur les navettes Navire → Centre.
Une visite à bord correspond à une intervention de l’équipe du centre directement auprès des marins à bord d’un navire. Une intervention sur un navire vaut une visite, quel que soit le nombre de personnes présentes. Deux interventions sur le même navire dans la même journée valent deux visites.
La nationalité est rattachée au marin accueilli pour la journée. Le total des nationalités enregistrées pour une journée doit être cohérent avec le nombre de marins accueillis. La liste contrôlée, la recherche et le traitement des cas « inconnue / non renseignée » seront précisés au chapitre 8.
Le déploiement initial privilégie un relevé simple du compteur kilométrique lors de la prise d’un véhicule et lorsqu’il est rendu ou remplacé. La plateforme calcule automatiquement la distance parcourue pour chaque véhicule et le cumul de la journée.
Les missions restent enregistrées individuellement. La V2 initiale ne cherche donc pas à répartir artificiellement le kilométrage exact entre Transport, Visite à bord et Autre mission.
L’architecture devra permettre ultérieurement, si la FNAAM le souhaite, un mode détaillé avec relevé kilométrique par mission, sans remettre en cause les données historiques enregistrées en mode simple.
Après connexion, l’utilisateur local choisit l’activité qu’il exerce sur l’appareil utilisé : Accueil ou Transport / Missions. Il ne s’agit pas de rôles différents mais de deux interfaces adaptées au travail en cours.
Les informations d’accueil sont principalement consolidées à partir du registre d’arrivée du centre, afin de limiter le temps consacré à la saisie informatique. La plateforme permet également une saisie au fil des arrivées lorsque l’organisation du centre s’y prête, sans que ce mode de fonctionnement soit imposé. Chaque centre reste libre de choisir son mode d’organisation pour l’enregistrement des marins. Il peut notamment conserver son registre d’arrivée comme support principal ou choisir d’utiliser un mode tablette/kiosque permettant aux marins de s’enregistrer eux-mêmes.
Les déplacements sont enregistrés au moment de leur réalisation depuis une interface mobile simple. Chaque mission est identifiée individuellement : Transport de marins, Visite à bord ou Autre mission.
La plateforme consolide automatiquement les données issues des différentes interfaces. L’accueil ne ressaisit pas les missions effectuées par les chauffeurs.
Le centre définit qui réalise la consolidation des informations de la journée. Cette organisation relève du fonctionnement interne de chaque centre et peut donc différer d’un centre à l’autre. La personne chargée de cette consolidation vérifie la cohérence des informations enregistrées au cours de la journée avant de procéder à la validation.
Avant la validation, la plateforme vérifie qu’aucune activité susceptible d’alimenter les données de la journée n’est encore en cours. Si une activité est toujours en cours, la validation de la journée est impossible. La plateforme indique la nature de l’activité concernée ainsi que l’utilisateur qui l’a actuellement en cours.
Impossible de valider la journée : une activité est encore en cours pour Jean Dupont — Transport / Missions.
La validation constitue un contrôle fonctionnel de la journée et non une signature électronique. Si une donnée est corrigée après validation, la journée repasse automatiquement à l’état À revalider.
La plateforme assure automatiquement le suivi des journées qui n’ont pas été correctement clôturées. Lorsqu’une journée reste non clôturée, un courriel est envoyé automatiquement au ou aux Responsables de centre concernés. Il indique la date, la ou les activités bloquantes et, lorsque cela s’applique, l’utilisateur concerné. Le détail des contrôles et rappels sera précisé au chapitre 10.
Chaque centre possède une identité permanente indépendante des identifiants techniques WordPress. Cette identité doit survivre aux migrations, changements de site et évolutions techniques.
Une personne = un compte. Les comptes partagés sont proscrits afin de conserver une traçabilité exploitable.
Un utilisateur est rattaché à un seul centre actif à la fois dans la V2 initiale. Une mutation vers un autre centre conserve le même compte personnel et l’historique de ses rattachements.
Selon l’organisation du centre, plusieurs personnes peuvent partager la fonction de Responsable de centre. La plateforme autorise au maximum deux Responsables de centre actifs par centre.
Les deux Responsables disposent des mêmes droits dans la plateforme et utilisent chacun leur compte personnel afin de conserver la traçabilité des actions réalisées.
Aucune fonction essentielle à l’administration ou à la gestion de la plateforme ne doit dépendre exclusivement d’une seule personne.
Rôle technique : WordPress, composants, maintenance, base de données, sauvegardes/restaurations, sécurité, diagnostic et évolution technique. Il n’assure pas la gouvernance statistique quotidienne.
La FNAAM demeure responsable et détentrice de la plateforme et de ses données, indépendamment de la personne chargée de son administration technique.
L’Administrateur système administre la plateforme pour le compte de la FNAAM ; il ne doit jamais en devenir le point de dépendance unique.
Un accès administrateur d’urgence distinct doit être conservé par la FNAAM selon une procédure sécurisée. Lors d’un changement d’administrateur, le nouveau responsable reçoit son propre compte nominatif ; les droits de l’ancien sont ensuite retirés.
Un accès de secours est également prévu pour la fonction de Gestionnaire FNAAM. Il est conservé de manière sécurisée par la FNAAM et n’est utilisé qu’en cas de nécessité afin de rétablir l’accès à la gestion fonctionnelle et de désigner un nouveau Gestionnaire FNAAM.
Toute utilisation de cet accès est enregistrée et entraîne ensuite le renouvellement de ses informations de connexion.
Il n’existe pas de hiérarchie technique entre chauffeur, accueillant, bénévole ou salarié : ce sont des activités, pas des rôles. Le même utilisateur peut effectuer différentes activités avec le même compte.
Pendant la période autorisée, les utilisateurs locaux peuvent consulter et corriger les données opérationnelles de leur centre. Toute modification est tracée.
En validant cette journée, je confirme avoir vérifié les informations enregistrées pour l’activité du centre à cette date.
Après authentification, chaque utilisateur accède à un espace adapté à son rôle et à son centre. Les fonctions hors de ses droits ne sont pas seulement masquées : leur accès doit être interdit côté serveur.
Toutes les interfaces fonctionnelles comportent un bouton « Aide » clairement identifiable. Il fournit une aide contextuelle courte et un accès au mode d’emploi complet.
Les plages horaires déterminent les périodes pendant lesquelles un utilisateur peut commencer une nouvelle journée d’activité dans les applications Accueil et Transport / Missions. Une journée commencée pendant une période autorisée peut se poursuivre au-delà de l’horaire prévu jusqu’à sa clôture.
Le ou les Responsables de centre peuvent définir et modifier les jours et plages horaires applicables à leur centre, ainsi que prévoir des exceptions lorsque son activité le nécessite.
Les applications Accueil et Transport / Missions peuvent être rendues indisponibles en dehors des jours et plages horaires habituels d’activité du centre. Ces règles s’appliquent à tous les utilisateurs de ces applications, y compris aux Responsables de centre lorsqu’ils participent à l’activité opérationnelle du centre.
Le site institutionnel FNAAM existant est conservé et enrichi d’une page dédiée « Les chiffres de la FNAAM ». Les éléments statistiques publics doivent pouvoir être réutilisés dans plusieurs pages du site.
Chaque fiche individuelle d’un adhérent affiche les trois indicateurs principaux : Marins accueillis — Marins transportés — Visites à bord.
Elle présente également les quatre nationalités les plus représentées parmi les marins accueillis pour l’année statistique publiée.
La présentation graphique actuelle des compteurs peut être conservée ; seules les valeurs et l’année de référence sont alimentées automatiquement par la plateforme.
L’affichage public porte sur la dernière année publiée. Le passage à l’année N-1 intervient normalement au 31 mars de l’année N, sous réserve de la validation et de la consolidation des données.
Le kilométrage n’est pas un indicateur principal des fiches individuelles, mais peut être utilisé dans les statistiques nationales publiques.
Après connexion, l’utilisateur local voit une question simple : « Que faites-vous aujourd’hui ? » avec deux choix : ACCUEIL et TRANSPORT / MISSIONS.
Le choix est propre à la session et à l’appareil. Un même utilisateur peut utiliser simultanément Accueil sur un ordinateur et Transport / Missions sur un smartphone. « Changer d’activité » permet de passer d’une interface à l’autre sans modifier le profil.
Une mission en cours est enregistrée centralement et ne disparaît pas lors d’un changement d’interface. Un rappel discret peut signaler une mission active depuis l’interface Accueil.
L’interface Accueil permet à l’utilisateur de saisir les informations issues du registre d’arrivée, principalement sous forme de consolidation afin de limiter le temps nécessaire à l’enregistrement des données. La saisie au fil des arrivées reste possible lorsque le centre souhaite utiliser ce mode de fonctionnement. Les informations principales sont la nationalité et le navire ; la nécessité de conserver le nom du marin reste à trancher selon le registre actuel, la détection des doublons et les contraintes de confidentialité. Selon l’organisation retenue par le centre, l’enregistrement peut également être réalisé directement par les marins au moyen du mode tablette/kiosque décrit au chapitre 7.2.3.
Chaque centre reste libre d’utiliser ou non un mode tablette/kiosque. Lorsqu’il est choisi, une tablette dédiée peut permettre aux marins de s’enregistrer eux-mêmes. Cette interface ne donne aucun accès au site interne. Elle doit rester simple, multilingue au minimum en français/anglais et alimenter les mêmes données d’activité que la saisie réalisée à partir du registre. Le centre peut conserver le registre d’arrivée comme support principal ou comme solution de secours.
La page de validation sert également de synthèse de l’activité du jour : accueil, nationalités, navires, transports, visites, autres missions, kilomètres, missions éventuellement ouvertes et anomalies. Une journée modifiée après validation repasse à l’état « À revalider ».
La consultation et la correction des journées précédentes restent possibles selon les droits et les règles de période qui seront définies au chapitre 11.
L’utilisateur dispose d’un espace personnel de restitution, distinct des statistiques officielles du centre. Par défaut, il peut présenter l’activité du mois en cours : marins enregistrés, journées d’accueil, journées validées et une petite évolution temporelle. Si l’utilisateur effectue aussi des missions, les deux volets peuvent être réunis.
Après avoir choisi Transport / Missions, l’utilisateur sélectionne le véhicule utilisé et renseigne obligatoirement son kilométrage de départ. Tant que cette étape n’est pas validée, les fonctions de mission ne sont pas accessibles.
Le menu opérationnel propose ensuite : Transport de marins, Visite à bord, Autre mission, Mon activité, Changer de véhicule et Fin de journée.
Chaque déplacement physique du véhicule est une navette. Deux sens sont distingués :
Marins transportés = somme des marins pris en charge sur les navettes Navire → Centre. Navettes réalisées = total des navettes Navire → Centre + Centre → Navire.
Lorsqu’une mission Visite à bord est en cours, l’utilisateur dispose d’un bouton Début de visite.
Lorsqu’il sélectionne Début de visite, l’interface affiche les informations nécessaires à l’enregistrement de la visite :
Pendant la visite, celle-ci reste indiquée comme étant en cours. Une fois l’intervention à bord terminée, l’utilisateur sélectionne Fin de visite.
La plateforme enregistre alors une visite à bord. Si des marins ont été pris en charge, leur nombre alimente également l’indicateur Marins transportés.
La fin d’une visite ne termine pas la mission. L’utilisateur peut commencer une nouvelle visite à bord, y compris sur le même navire, ou poursuivre son déplacement. La mission ne se termine qu’au retour au centre lorsque l’utilisateur sélectionne Fin de mission.
La plateforme conserve le début et la fin de chaque visite. Ces informations pourront permettre ultérieurement de calculer la durée des visites par navire. Cette durée n’est toutefois pas exploitée comme indicateur dans la première version, afin de conserver un fonctionnement simple.
Le motif est obligatoire et reste libre. La plateforme propose en priorité les motifs précédemment utilisés par le centre, en privilégiant les plus fréquents. L’utilisateur peut sélectionner une proposition existante ou saisir un nouveau motif.
Le texte du motif ne crée pas automatiquement une nouvelle catégorie statistique : toutes ces missions restent regroupées sous « Autres missions ».
Chaque mission possède une commande « Fin de mission ». Après validation, l’utilisateur revient au choix des missions. Le fonctionnement reste volontairement identique pour les trois types de missions.
Le bouton « Changer de véhicule » est disponible entre deux missions mais également en cours de mission, notamment en cas de panne.
L’utilisateur renseigne le kilométrage de fin du véhicule quitté, sélectionne le nouveau véhicule et saisit son kilométrage de départ. Si une mission est en cours, elle reste ouverte et se poursuit avec le nouveau véhicule : elle n’est ni clôturée, ni dupliquée, ni comptabilisée une seconde fois.
Un motif de changement simple peut être conservé (par exemple : Panne, Organisation, Autre) afin d’expliquer l’utilisation successive de plusieurs véhicules.
Les éventuels kilomètres exceptionnels liés à la récupération d’un véhicule en panne restent marginaux et ne sont pas intégrés aux statistiques d’activité.
La structure de données doit permettre à une même mission d’être associée successivement à plusieurs véhicules.
À chaque changement de véhicule, la distance du véhicule quitté est définitivement calculée à partir de son compteur de départ et de son compteur de fin. Le nouveau véhicule ouvre une nouvelle séquence kilométrique.
À la fin de la journée, le compteur final n’est demandé que pour le dernier véhicule encore utilisé. La plateforme additionne ensuite automatiquement les distances de tous les véhicules utilisés au cours de la journée.
Le détail par véhicule est conservé ; le total journalier n’est qu’un calcul dérivé.
L’utilisateur choisit explicitement « Fin de journée ». Une confirmation forte l’informe qu’il devra renseigner le kilométrage final du véhicule en cours.
Le kilométrage retour doit être supérieur ou égal au kilométrage de départ correspondant. Une fois validé, la plateforme calcule le dernier trajet, cumule les différents véhicules et confirme l’enregistrement de la journée.
Un résumé court avant la clôture pourra rappeler le nombre de navettes, marins transportés, visites à bord et autres missions afin d’aider l’utilisateur à repérer un oubli.
L’espace personnel peut présenter, par défaut pour le mois en cours : nombre de navettes, marins transportés, visites à bord, autres missions et kilomètres parcourus. Cette restitution personnelle reste distincte des statistiques officielles du centre.
Les données déjà enregistrées doivent être conservées côté serveur. Une fermeture accidentelle du navigateur ou un changement d’appareil ne doit pas faire disparaître une mission ou une journée en cours. Une véritable utilisation hors connexion pourra être étudiée ultérieurement.
Le déploiement initial privilégie la simplicité d’utilisation. Les missions sont enregistrées individuellement, tandis que le kilométrage est relevé à la prise et à la restitution/changement de véhicule. Une évolution future vers un relevé kilométrique détaillé par mission doit rester possible.
Base de données : Ensemble structuré dans lequel la plateforme conserve les informations nécessaires à son fonctionnement.
Identifiant : Valeur permettant de reconnaître de manière unique un centre, un utilisateur ou un autre élément de la plateforme.
WordPress : Outil utilisé comme base du site internet de la FNAAM.
PHP : Langage informatique utilisé pour une partie du fonctionnement de WordPress et de la plateforme.
API : Mécanisme permettant à différentes parties de la plateforme d’échanger des informations de manière contrôlée.
Responsive : Conception permettant à une interface de s’adapter automatiquement à la taille de l’écran : ordinateur, tablette ou smartphone.
Session : Période d’utilisation ouverte après la connexion d’un utilisateur sur un appareil ou un navigateur.
Traçabilité : Conservation de l’historique des actions importantes : saisies, corrections, validations et interventions.
Archivage : Conservation d’un élément devenu inactif afin de préserver son historique sans le laisser apparaître dans l’usage courant.
