Authentification des comptes et état de session sur les parcours protégés qui utilisent ce module.
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.
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.
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.
Certains contrôles lisent users/{uid}.groupId, notamment le groupe administrateur 1.
Jeton d’application et signal anti-abus pour des fonctions configurées, notamment certains formulaires Web.
Des compteurs horaires par empreinte IP et courriel sont documentés pour les demandes Web.
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.
Hébergement, authentification, Firestore, fonctions et App Check selon la configuration.
Signal anti-abus associé aux parcours configurés.
Courriels transactionnels des formulaires Web documentés.
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.
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 confiancePourquoi 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.
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.
