Aperçu de la sécurité

Comment les utilisateurs sont vérifiés

• •Firebase Authentication gère toute l'identité des utilisateurs. SHIFT_ ne stocke jamais de mots de passe en clair.
• •Chaque requête authentifiée porte un jeton d'identité Firebase — un JWT signé qui expire après une heure. Chaque route protégée le vérifie cryptographiquement avant de lire la moindre donnée.
• •La connexion avec Apple et avec Google est prise en charge nativement; un jeton natif n'est accepté que pour les audiences connues de Firebase.
• •La connexion biométrique sur mobile ne déverrouille les identifiants enregistrés qu'après que l'appareil a confirmé la personne.

Contrôle d'accès par rôle

• •Chaque compte porte un rôle explicite : client, professionnel, organisation, admin ou super-admin. Le rôle est lu côté serveur à chaque requête et ne peut pas être modifié depuis l'application — les règles de la base de données refusent toute écriture du rôle par le compte lui-même, et seul un super-admin peut promouvoir un compte.
• •Les modes optionnels (professionnel, client, organisation) sont des indicateurs distincts avec leurs propres contrôles : un super-admin qui teste en tant que professionnel dispose exactement des outils de ce rôle.

Modèle d'accès des clients (sur invitation seulement)

Les clients ne peuvent pas s'inscrire eux-mêmes. L'accès passe par un professionnel : un code ou un lien d'invitation, le lien ou le code QR de réservation du professionnel, ou le lien de recommandation d'un client. Les codes d'invitation sont à usage unique, liés à une adresse courriel, et expirent.

Chemin 1 — Règles de sécurité Firestore

Quand l'application web ou mobile lit directement la base de données, les serveurs de Google appliquent nos règles; elles ne peuvent pas être contournées depuis un navigateur ou un appareil. Chaque enregistrement est limité aux personnes à qui il appartient : une réservation à son client et à son professionnel, un message aux participants de sa conversation, un avis aux deux parties concernées (et aux administrateurs), une notification à son destinataire. La liste des utilisateurs n'est jamais lisible anonymement, et les données publiques du répertoire proviennent d'une projection côté serveur qui ne renvoie que ce dont un répertoire a besoin — nom, photo, secteur, ville — jamais de coordonnées.

Chemin 2 — Routes serveur authentifiées

Les opérations qui exigent un accès privilégié s'exécutent sur nos serveurs. Chaque route vérifie elle-même le jeton de l'appelant, prend l'utilisateur agissant dans ce jeton — jamais dans le corps de la requête — et confirme que l'appelant est partie à la réservation, à la conversation ou au paiement avant d'agir.

Les champs monétaires d'une réservation (payée, solde payé, montant facturé) ne peuvent être écrits que par le professionnel à qui l'argent est dû; un client peut déclarer avoir payé, jamais se marquer lui-même comme payé. La date, l'heure ou la durée d'une réservation terminée ne peuvent être réécrites par personne.

Chaque modification de nos règles de base de données passe par une suite de tests automatisés qui vérifie les deux directions : les parcours légitimes doivent continuer de fonctionner, et les lectures d'un autre utilisateur, l'élévation de privilèges et la manipulation des paiements doivent être refusées. Chaque suite a d'abord fait la preuve qu'elle échouait contre les règles qu'elle remplaçait.

Sécurité du transport

Tout le trafic est chiffré en TLS 1.2 ou plus. Firebase Hosting, Cloud Run et tous les points d'accès de l'API imposent HTTPS. Les sessions vocales utilisent des connexions WebSocket chiffrées.

Authentification de l'API

Chaque requête protégée vérifie le jeton d'identité Firebase avant l'exécution du moindre gestionnaire — signature, émetteur, audience et expiration, à l'aide des clés publiques de Google. Un compte supprimé est refusé même pendant que son dernier jeton est techniquement valide. L'utilisateur agissant est toujours tiré du jeton vérifié, jamais d'un identifiant fourni dans la requête.

Les notifications identifient leur appelant

Les routes qui envoient les courriels, textos et alertes liés aux réservations lisent les deux parties dans l'enregistrement de la réservation lui-même et consignent qui a fait la demande : une partie à la réservation (par son jeton), un administrateur, ou l'un de nos propres services muni d'un secret partagé conservé dans Secret Manager. Toute autre demande est enregistrée et, une fois le déploiement terminé, refusée.

Rappels de connexion signés

Les connexions à des services tiers (comme l'agenda Google) portent une valeur d'état signée et de courte durée : une autorisation ne peut aboutir que pour le compte qui l'a lancée.

Limitation du débit

Le serveur public Agent Connect applique des limites : 500 requêtes par 15 minutes globalement, 60 par minute par adresse IP sur les points d'accès des outils. Les points d'accès IA de la plateforme web sont limités sur l'ensemble des instances, avec des limites de longueur d'entrée.

Validation des entrées

Le service Python valide chaque corps de requête avec Pydantic. Firestore est interrogé par des appels SDK paramétrés — aucune requête construite à partir de texte brut, ce qui rend les attaques par injection classiques structurellement impossibles.

Restrictions CORS

Le service de messagerie n'accepte les requêtes d'autres origines que depuis shiftsyndicate.ca (et localhost pendant le développement). Toute autre origine est rejetée avant d'atteindre un gestionnaire.

Défense contre l'injection d'instructions

Chaque session IA commence par une instruction côté serveur que l'utilisateur ne peut ni remplacer ni précéder. Les schémas d'injection connus sont détectés autant en clavardage qu'en voix, et un refus du personnage n'est jamais le seul contrôle : l'accès aux outils est décidé par le serveur, pas par le modèle.

Registre de fonctions limité par rôle

L'assistant ne peut appeler que les fonctions déclarées pour le rôle de la session. Avant toute exécution, le serveur consulte la liste d'autorisations; un appel bloqué renvoie un refus d'accès avant toute interrogation des données.

Outils liés à l'identifiant

Chaque outil reçoit l'identifiant de l'utilisateur authentifié comme paramètre prédéfini. Les utilisateurs ne peuvent ni le fournir ni le remplacer.

Propriété des conversations

Chaque conversation est enregistrée avec les identités auxquelles elle appartient. Toute incohérence renvoie HTTP 403 avant le chargement du contenu.

Les assistants externes sont en lecture seule

Quand SHIFT_ est utilisé par un assistant IA externe (le connecteur MCP), chaque rôle sauf un super-admin vérifié dispose d'une boîte à outils en lecture seule : aucun message, aucune modification de réglage, aucun texto sortant. Les questions à la base de données se limitent à une liste de collections d'analyse autorisées, et les secrets, sessions et corps de messages sont caviardés de chaque réponse.

Limite d'itérations de l'agent

La boucle de l'agent est plafonnée à cinq itérations par requête : une instruction malveillante ne peut pas déclencher une chaîne illimitée d'appels d'outils.

Authentification des sessions vocales

Le point d'accès vocal exige un jeton d'identité Firebase valide à la connexion et plafonne le nombre de tours par connexion. Les connexions non authentifiées sont rejetées avant l'ouverture d'une session.

Isolation des identifiants de l'IA

La clé du modèle d'IA n'existe que dans Secret Manager. Elle n'est jamais envoyée à un navigateur ni incluse dans une réponse.

Restrictions de l'IA publique

Les visiteurs non authentifiés n'atteignent que trois fonctions (recherche dans le répertoire, FAQ, prise de coordonnées). Ils ne peuvent lire ni réservations, ni fiches d'utilisateurs, ni données financières.

Gestion des secrets et des identifiants

Les secrets de production (clés d'API, identifiants SMS, clés Stripe, clés du modèle d'IA, secrets entre services) résident dans Google Secret Manager et sont montés sur nos services à l'exécution — jamais dans le code source ni dans une configuration versionnée. Un analyseur pré-commit bloque toute valeur ressemblant à un identifiant avant qu'elle n'entre dans le dépôt, l'historique est analysé pour les mêmes motifs, et tout identifiant jamais exposé est remplacé chez le fournisseur.

Sécurité des paiements

SHIFT_ ne manipule jamais de données brutes de carte de paiement. La saisie et le traitement des cartes sont assurés par Stripe, un processeur certifié PCI DSS niveau 1. La plateforme ne conserve que des identifiants Stripe de client et de paiement — jamais de numéros de carte, de codes de sécurité ni de numéros de compte bancaire. Les taxes sont calculées par Stripe à partir de l'adresse d'affaires déclarée par le professionnel.

Tout le calcul s'exécute sur Google Cloud Run — des conteneurs sans serveur entièrement gérés, chaque instance dans son propre bac à sable isolé. Les images de conteneurs sont construites par Cloud Build et stockées dans Artifact Registry, jamais tirées de registres publics.

Certifications GCP couvrant notre couche d'infrastructure : SOC 1/2/3, ISO 27001, FedRAMP High, HIPAA, PCI DSS niveau 1.

L'accès au projet est contrôlé par Google Cloud IAM; seuls les développeurs fondateurs détiennent un accès de propriétaire du projet. Les services atteignent Firebase par le réseau privé de Google, pas par l'internet public.

• •Cloud Run consigne les métadonnées des requêtes, les traces d'erreurs et les événements applicatifs dans Google Cloud Logging, conservés 30 jours.
• •Firebase Authentication enregistre les connexions, déconnexions, renouvellements de jeton et modifications de compte.
• •Les accusés de livraison des notifications poussées sont collectés et les jetons d'appareil périmés retirés automatiquement.
• •Les comportements anormaux (lectures massives, pics d'échecs d'authentification) apparaissent dans Cloud Monitoring.
• •Chaque déploiement est vérifié contre le commit en service, et la page d'état publique rapporte ce qui est réellement en ligne.
• •Les problèmes de sécurité sont traités immédiatement. Les utilisateurs touchés sont avisés conformément à la LPRPDE du Canada et à la Loi 25 du Québec. Les sessions peuvent être révoquées sur toute la plateforme en quelques minutes.

Revue de sécurité pré-soumission (14 septembre 2026)

• •Lectures anonymes de chaque collection sensible (utilisateurs, réservations, messages, avis, notifications, factures, facturation, jetons d'appareil, sessions, mémoire de l'IA) refusées — vérifié en production.
• •Historique du dépôt analysé pour des identifiants depuis la revue précédente — propre; aucun fichier de clé versionné.
• •Secret entre services confirmé monté depuis Secret Manager sur chaque environnement d'exécution.
• •Avis de sécurité des dépendances au plancher — aucun correctif disponible en attente.