Bonnes pratiques générales pour configurer des projets Firebase
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Cette page présente des bonnes pratiques générales et générales pour configurer des projets Firebase et enregistrer vos applications dans un projet afin de disposer d'un workflow de développement clair qui utilise des environnements distincts. Une fois que vous avez pris connaissance des bonnes pratiques de cette page, consultez nos consignes de sécurité générales.
Comprendre la hiérarchie des projets Firebase
Ce schéma présente la hiérarchie de base d'un projet Firebase. Voici les principales relations:
Un projet Firebase est comme un conteneur pour toutes vos applications, ainsi que pour les ressources et services provisionnés pour le projet.
Un projet Firebase peut comporter une ou plusieurs applications Firebase enregistrées (par exemple, les versions iOS et Android d'une application, ou les versions sans frais et payante d'une application).
Toutes les applications Firebase enregistrées dans le même projet Firebase partagent et ont accès à toutes les mêmes ressources et services provisionnés pour le projet.
Voici quelques exemples :
Toutes les applications Firebase enregistrées dans le même projet Firebase partagent les mêmes backends, comme Firebase Hosting, Authentication, Realtime Database, Cloud Firestore, Cloud Storage et Cloud Functions.
Toutes les applications Firebase enregistrées dans le même projet Firebase sont associées à la même propriété Google Analytics, où chaque application Firebase est un flux de données distinct dans cette propriété.
Où se situe un projet Google Cloud dans cette hiérarchie ?
Un aspect de la hiérarchie des projets Firebase qui n'est pas indiqué dans le diagramme ci-dessus est la relation avec un projet Google Cloud. Un projet Firebase n'est en réalité qu'un projet Google Cloud pour lequel des configurations et des services spécifiques à Firebase sont activés.
Notez que toutes les applications enregistrées dans le même projet Firebase partagent et ont également accès aux mêmes ressources et services Google Cloud.
Enregistrer des variantes d'application avec des projets Firebase
Voici quelques conseils importants pour enregistrer vos variantes d'application avec un projet Firebase:
Assurez-vous que toutes les applications enregistrées dans un projet Firebase sont des variantes de plate-forme de la même application du point de vue de l'utilisateur final. Enregistrez les versions iOS, Android et Web de la même application ou du même jeu avec le même projet Firebase.
Si vous disposez de plusieurs variants de compilation pouvant partager les mêmes ressources Firebase, enregistrez les variantes dans le même projet Firebase. Par exemple, un blog et une application Web dans le même projet, ou les versions sans frais et payante de la même application dans le même projet.
Si vous disposez de plusieurs variantes de compilation basées sur l'état de la version (plutôt que sur l'activité ou l'accès des utilisateurs finaux courants, comme ci-dessus), enregistrez chaque variante avec un projet Firebase distinct. Par exemple, votre version de débogage par rapport à votre version de publication : enregistrez chacune de ces versions dans son propre projet Firebase.
Les builds basés sur l'état de la version ne doivent pas partager les mêmes ressources Firebase, car cela risque de polluer ou même de remplacer vos données de production.
Les variantes de plate-forme de chacune de ces variantes de compilation doivent se trouver dans le même projet Firebase. Par exemple, enregistrez les builds de débogage iOS et Android dans un projet Firebase "dev", car ils peuvent tous deux interagir avec les mêmes données et ressources non destinées à la production.
Éviter l'architecture mutualisée
La multi-propriété peut entraîner de graves problèmes de configuration et de confidentialité des données, y compris des problèmes involontaires liés à l'agrégation des données analytiques, à l'authentification partagée, à des structures de base de données trop complexes et à des difficultés liées aux règles de sécurité.
En règle générale, si un ensemble d'applications ne partage pas les mêmes données et configurations, nous vous recommandons vivement d'enregistrer chaque application avec un projet Firebase différent.
Par exemple, si vous développez une application blanche, chaque application associée à un libellé indépendant doit disposer de son propre projet Firebase, et les versions iOS et Android de ce libellé doivent se trouver dans le même projet Firebase. Pour des raisons de confidentialité, chaque application associée à un libellé indépendant ne doit pas partager de données avec les autres.
Étapes suivantes
Consultez les consignes de sécurité générales pour différents environnements. Vous devez vous assurer que chaque environnement et ses données sont sécurisés.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/07/25 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Il n'y a pas l'information dont j'ai besoin","missingTheInformationINeed","thumb-down"],["Trop compliqué/Trop d'étapes","tooComplicatedTooManySteps","thumb-down"],["Obsolète","outOfDate","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Mauvais exemple/Erreur de code","samplesCodeIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/07/25 (UTC)."],[],[],null,["This page provides general, high-level best practices for setting up Firebase\nprojects and registering your apps with a project so that you have a clear\n[development workflow](/docs/projects/dev-workflows/overview-environments) that\nuse distinct environments. Once you're familiar with the best practices on this\npage, check out our\n[general security guidelines](/docs/projects/dev-workflows/general-security-guidelines).\n| **Key Point:** We recommend reading our guides thoroughly, but here's the top takeaway about development workflows: \n| **Firebase recommends using a *separate* Firebase project for *each* environment\n| in your development workflow.**\n\nUnderstanding the hierarchy of Firebase projects\n\n\nThis diagram shows the basic hierarchy of a Firebase project. Here are the key\nrelationships:\n\n- A **Firebase project** is like a container for all your apps and any resources\n and services provisioned for the project.\n\n- A Firebase project can have one or more **Firebase Apps** registered to it\n (for example, both the iOS and Android versions of an app, or both the free\n and paid versions of an app).\n\n- All Firebase Apps registered to the same Firebase project **share and have\n access to all the same resources and services provisioned for the project**.\n Here are some examples:\n\n - All the Firebase Apps registered to the same Firebase project share the same\n backends, like Firebase Hosting, Authentication, Realtime Database, Cloud Firestore,\n Cloud Storage, and Cloud Functions.\n\n - All Firebase Apps registered to the same Firebase project are associated\n with the same Google Analytics property, where each Firebase App is a\n separate data stream in that property.\n\nWhere does a Google Cloud project fit into this hierarchy?\n\nOne aspect of the Firebase project hierarchy that's not shown in the diagram\nabove is the relationship with a Google Cloud project. **A Firebase project is\nactually just a Google Cloud project that has additional *Firebase-specific*\nconfigurations and services enabled for it.**\nNote that all the apps registered to the same Firebase project also share and\nhave access to all the same Google Cloud resources and services, too.\n\nLearn more about the Firebase and Google Cloud relationship in\n[Understand Firebase projects](/docs/projects/learn-more#firebase-cloud-relationship)\n\nRegistering app variants with Firebase projects **Key Point:** All the apps registered to a Firebase project share and can access the same data as well as the resources and services provisioned for the project, which includes database instances, storage buckets, functions, etc.\n\nHere are some important tips for registering your app variants with a Firebase\nproject:\n\n- Ensure that all apps registered to a Firebase project are **platform variants\n of the same application** from an end-user perspective. Register the iOS,\n Android, and web versions of the same app or game with the *same* Firebase\n project.\n\n- If you have **multiple build variants that could *share the same Firebase\n resources*** , register the variants with the *same* Firebase project. Some\n examples are a blog and a web app in the same project, or both the free and\n paid versions of the same app in the same project.\n\n- If you have **multiple build variants that are *based on release status***\n (rather than on common end-user activity or access, like above), register each\n variant with a *separate* Firebase project. An example is your debug vs\n release build -- register each of these builds in its own Firebase project.\n\n - Builds based on release status should not share the same Firebase resources\n because that risks your debug data polluting or even overriding your prod\n data.\n\n - The *platform* -variants of each of these build variants should be in the\n *same* Firebase project. For example, register both the iOS and the Android\n debug builds in a \"dev\" Firebase project because they can both interact with\n the same non-prod data and resources.\n\n| **Note:** For each Android app, if you provide a SHA-1 key for the app, you need to provide a package name and SHA-1 key combination that is globally unique across all of Google Cloud.\n\nAvoiding multi-tenancy **Key Point:** Connecting several different logically independent apps and/or web sites to a single Firebase project (often called \"multi-tenancy\") is not recommended.\n\nMulti-tenancy can lead to serious configuration and data privacy concerns,\nincluding unintended issues with analytics aggregation, shared authentication,\noverly-complex database structures, and difficulties with security rules.\n\nGenerally, **if a set of apps don't share the same data and configurations,\nstrongly consider registering each app with a different Firebase project.**\n\nFor example, if you develop a white-label application, each independently\nlabeled app should have its own Firebase project, and the iOS and Android\nversions of that label should be in the same Firebase project. Each\nindependently labeled app shouldn't (for privacy reasons) share data with the\nothers.\n\nNext steps\n\n- Review the\n [general security guidelines](/docs/projects/dev-workflows/general-security-guidelines)\n for different environments. You want to make sure each environment and its\n data are secure.\n\n- Review the [Firebase launch checklist](/support/guides/launch-checklist)."]]
Ce schéma présente la hiérarchie de base d'un projet Firebase. Voici les principales relations: