Authentification
L’accès à l’application nécessite une identité valide. Les services backend la vérifient de nouveau avant les opérations sensibles.
Confiance · Document vivant
Nous expliquons le fonctionnement actuel de l’application : ce qui est stocké, où les données sont traitées, qui peut y accéder et ce qui change lorsqu’une organisation exige une architecture Enterprise.

Architecture standard actuelle
Une photo n’est pas stockée comme un élément isolé. Elle est associée au contexte du projet et produit des données dérivées qui permettent de la localiser et de la retrouver.
Le web ou l’application mobile prépare l’image et ses miniatures. Lorsqu’elles existent, la date, l’auteur, la position GPS et l’orientation sont conservés.
Firebase Authentication identifie l’utilisateur. L’application utilise cette identité pour vérifier son appartenance à l’équipe et son rôle dans le projet.
L’image est stockée dans Cloud Storage. Sa fiche, sa position et son état de traitement sont enregistrés dans Cloud Firestore.
L’image est envoyée à Gemini pour créer une description et des étiquettes. Les métadonnées nécessaires à la recherche sont indexées dans Algolia ; l’image originale ne fait pas partie de cet index.
L’application récupère les résultats et vérifie à nouveau l’appartenance au projet avant de fournir les fiches des photos.
Protection
Authentification
L’accès à l’application nécessite une identité valide. Les services backend la vérifient de nouveau avant les opérations sensibles.
Équipes et rôles
Les projets sont organisés par équipe. Propriétaires, administrateurs, éditeurs et autres collaborateurs disposent de capacités différentes.
Chiffrement
Google Cloud chiffre par défaut les données stockées et les communications utilisent HTTPS/TLS. La configuration standard utilise des clés gérées par Google.
Règles et validation
Firestore et Storage appliquent des règles relatives à l’identité, l’appartenance, au type et à la taille des fichiers. La suppression complète est exécutée côté serveur afin d’éviter les données orphelines.
IA et recherche
Les nouvelles photos sont traitées automatiquement avec l’API Gemini afin de produire une description et des termes visuels utiles en plusieurs langues. Pic on Site stocke le résultat sous forme de métadonnées et l’utilise pour la recherche et les rapports ; il n’entraîne actuellement aucun modèle propriétaire avec les photos envoyées.
La facturation est active sur le projet de production. Selon les conditions actuelles de Gemini applicables aux services payants, Google n’utilise pas les entrées —y compris les images— ni les réponses pour améliorer ses produits. Google peut conserver des journaux limités à des fins de sécurité, de prévention des abus et d’obligations légales. Cette condition dépend du service et du contrat applicables et sera revue si l’intégration change.
Algolia reçoit un index contenant des identifiants et métadonnées utiles —par exemple étiquettes, auteur, dates ou présence de GPS—, et non la photo originale. La localisation contractuelle de cet index n’est actuellement pas incluse dans une garantie régionale standard.
Conditions de données de l’API GeminiConservation et reprise
Fichiers
Le bucket actuel conserve les objets supprimés pendant 7 jours grâce au soft delete. Le versionnage des objets n’est pas activé.
Base de données
Firestore réplique les données dans nam5 pour leur disponibilité. La restauration à un instant donné n’est actuellement pas activée.
Comptes et projets
L’application permet de supprimer un compte. Le contenu des projets partagés peut être conservé comme dossier de projet après anonymisation de l’identité ; toute propriété partagée doit d’abord être transférée ou résolue.
Engagements
Le service standard ne publie pas encore de SLA, RPO ou RTO contractuel spécifique. Si un projet les exige, ils doivent être définis dans une proposition Enterprise.
Enterprise · Sur accord
Ces options ne constituent pas un réglage automatique dans l’application et ne sont pas incluses dans le service standard. Elles exigent conception, migration, validation de compatibilité et accord technique et contractuel.

Pic on Site administre l’infrastructure partagée actuelle. C’est le mode de départ et il utilise les emplacements documentés sur cette page.
Un environnement dédié ou régional dans un emplacement pris en charge peut être étudié. Base de données, fichiers, Functions, recherche et IA doivent être examinés ensemble : choisir uniquement le bucket ne garantit pas une résidence complète.
Un déploiement dans un projet Google Cloud/Firebase contrôlé par l’organisation peut être étudié. Le client gère région, facturation, IAM et politiques ; l’accès opérationnel de Pic on Site, les mises à jour et le support sont explicitement convenus.
La disponibilité, les régions, les délais et le prix dépendent du périmètre. Un échange commercial ne signifie pas qu’un mode est déjà déployé ou certifié.
Responsabilité partagée
L’organisation doit décider ce qui est photographié, qui peut y accéder, pendant combien de temps les données sont conservées et ce qui peut être partagé. Évitez de capter des données personnelles, documents confidentiels ou installations sensibles inutiles. Revoyez membres et rôles lorsque les équipes changent et exportez les dossiers qui doivent être conservés hors du service.
Propriété : le contenu fourni reste la propriété de la partie qui en détient les droits. Pic on Site ne requiert que les licences techniques nécessaires pour l’héberger, le traiter et l’afficher dans le cadre du service.
Sources et périmètre
Cette description combine l’inspection du déploiement et du code actuels de Pic on Site avec la documentation officielle des fournisseurs. L’architecture peut évoluer ; la date affichée en haut indique la dernière vérification.
Enterprise
Indiquez-nous pays, volume, utilisateurs, intégrations, conservation, identité et niveau de contrôle attendu. Nous distinguerons ce qui est disponible de ce qui nécessite un projet Enterprise.