Aller au contenu
MapMyStaff
Architecture et validations serveur

Comment une action devient-elle une décision vérifiée et enregistrée?

Dans les parcours documentés, l’interface prépare une demande, puis les contrôles côté serveur varient selon le module, l’endpoint et la version. Ils peuvent valider des champs, des types de demande, des routes, des adresses ou des règles avant que le parcours poursuive son traitement.

Schéma de lecturePas un pipeline universel
1
DemandeL’interface transmet les informations prévues pour l’action.
2
EndpointLes validations prévues dépendent du module et de la version.
3
Traitement du moduleLa suite dépend du fonctionnement documenté de cet endpoint.
01Validation par endpoint

Les validations ne sont pas identiques pour toutes les actions.

Le dossier de confiance confirme des validations de champs, de types de demande, de routes, d’adresses ou de règles selon le module.

Le point essentiel est la portée : les validations sont propres à l’endpoint et à la version. Une règle confirmée pour un parcours ne doit pas être présentée comme active partout.

Limite : cette page décrit l’architecture observée; elle ne constitue pas la liste exhaustive de tous les endpoints.
Voir les contrôles de sécurité
Portée documentée
1
ChampsPrésence, format ou valeurs prévues selon l’action.
Selon endpoint
2
Types de demandeLe type attendu peut faire partie de la validation.
Selon endpoint
3
Routes et adressesCertains parcours valident une route ou une adresse.
Selon endpoint
4
RèglesLes règles appliquées dépendent du module et de l’endpoint.
Selon endpoint
02Identité et contrôles d’entrée

Le contrôle appliqué dépend du contexte technique du parcours.

Les parcours protégés peuvent utiliser Firebase Authentication. Certains accès documentés s’appuient sur le groupe du document utilisateur.

App Check et reCAPTCHA Enterprise peuvent s’ajouter sur des fonctions configurées. Ils ne remplacent pas la validation serveur et ne s’appliquent pas automatiquement à chaque appel.

À compléter : la matrice complète des rôles et permissions par collection et endpoint n’est pas présentée comme finalisée.
Contrôles possibles selon le parcours
Firebase Authentication

Authentification des comptes et état de session sur les parcours protégés qui utilisent ce module.

Accès par groupe

Certains contrôles lisent users/{uid}.groupId, notamment le groupe administrateur 1.

App Check / reCAPTCHA

Jeton d’application et signal anti-abus pour des fonctions configurées, notamment certains formulaires Web.

Limitation anti-abus

Des compteurs horaires par empreinte IP et courriel sont documentés pour les demandes Web.

03Dépendances et services

Les services externes interviennent comme dépendances de parcours précis.

Le dossier documente Google Firebase / Google Cloud, reCAPTCHA Enterprise, Postmark et HERE ou OSRM. Leur présence ne signifie pas qu’ils interviennent tous dans chaque action.

Pour HERE / OSRM, la qualité dépend notamment des adresses, des fournisseurs, des clés et de la disponibilité des services.

Gouvernance : tout nouveau fournisseur doit être ajouté au registre, évalué et documenté avant activation.
Dépendances documentées
FGoogle Firebase / Google Cloud

Hébergement, authentification, Firestore, fonctions et App Check selon la configuration.

RreCAPTCHA Enterprise

Signal anti-abus associé aux parcours configurés.

PPostmark

Courriels transactionnels des formulaires Web documentés.

HHERE / OSRM

Géocodage, itinéraires et repli selon les parcours documentés.

🔐

Secrets et journaux

Les clés sensibles sont attendues dans l’environnement serveur, hors des scripts publics. Les journaux nécessaires au diagnostic doivent éviter les secrets et les renseignements inutiles.

04Questions techniques

Vérifiez ce qui est confirmé — et ce qui reste borné.

Cette page reste volontairement centrée sur la structure des contrôles et des dépendances. La page Sécurité présente les risques visés; le Centre de confiance regroupe la preuve, la portée et les éléments à confirmer.

Consulter le Centre de confiance
Questions de portée
Pourquoi les vérifications ne sont-elles pas les mêmes partout?

Parce que le dossier de confiance les décrit par module, endpoint et version. Les champs, types de demande, routes, adresses ou règles à contrôler varient selon l’action.

App Check ou reCAPTCHA remplacent-ils les validations serveur?

Non. Le dossier indique explicitement que ces mécanismes ne remplacent pas la validation serveur et ne s’appliquent pas automatiquement à chaque appel.

Où les secrets techniques doivent-ils être conservés?

Les clés sensibles sont attendues dans l’environnement serveur, pas dans les scripts publics. Leur gestion opérationnelle doit rester hors du dépôt public.

La matrice des rôles et permissions est-elle complète?

Non. Le dossier de confiance indique que la matrice complète par collection et endpoint reste à compléter.

Pour aller plus loin

Reliez le schéma technique à la portée documentée.

Le Centre de confiance indique ce qui est confirmé et ce qui reste à compléter; la page Sécurité résume les mécanismes en langage opérationnel.