Chaque équipe de développement fait face au même problème : de nouveaux développeurs arrivent, demandent « à quoi ressemblent les données ? », et personne n'a de réponse claire. Le savoir vit dans des fils Slack, des pages Notion obsolètes, ou dans la tête des développeurs seniors. FireSchema résout cela en transformant votre schéma Firestore en une source de vérité navigable et versionnée.

Le problème de la documentation

La plupart des équipes documentent la structure de leur base de données de l'une de ces façons :

-Des pages Notion ou Confluence qui deviennent obsolètes en quelques semaines
-Des fichiers README avec des tableaux markdown que personne ne met à jour
-Savoir tribal — les développeurs seniors expliquent le modèle de données encore et encore
-Aucune documentation — les développeurs font de l'ingénierie inverse à partir du code

Le résultat : une intégration plus lente, plus de bugs liés à de mauvaises hypothèses, et du temps perdu à répondre aux mêmes questions.

FireSchema comme source de vérité

Les fichiers FireSchema vivent dans votre dépôt, juste à côté de votre code. Ils sont versionnés, vérifiables dans les PRs, et toujours à jour parce qu'ils font partie de votre workflow de développement — pas d'un système de documentation séparé.

Versionné — les changements sont suivis dans git avec votre code
Vérifiable en PR — les modifications de schéma passent par la revue de code
Toujours exact — les développeurs mettent à jour les schémas en même temps que le code
Zéro maintenance — aucune plateforme de documentation séparée à gérer

Comment les équipes utilisent FireSchema

Intégration des développeurs

Un nouveau développeur rejoint votre équipe. Au lieu de planifier une présentation de 2 heures sur le modèle de données, vous lui indiquez vos docs FireSchema. Il peut explorer chaque collection, voir les types de champs et les descriptions, comprendre les relations entre sous-collections et examiner les règles de validation — le tout dans une interface interactive qu'il peut parcourir à son rythme.

Planification des fonctionnalités

Avant de développer une nouvelle fonctionnalité, votre équipe examine les schémas pertinents. « Quels champs possède la collection orders ? Quel est l'enum de status ? Est-ce que createdAt est obligatoire ? » Au lieu de fouiller dans le code, tout le monde ouvre la documentation des schémas et dispose du même point de référence pour les discussions de planification.

Revues de code

Une PR ajoute un nouveau champ à une collection Firestore. Le relecteur vérifie la mise à jour du schéma correspondant : le type de champ est-il correct ? Est-il documenté ? La description est-elle pertinente ? Les modifications de schéma deviennent partie intégrante de votre checklist de revue, empêchant les changements non documentés de passer inaperçus.

Workflow réel : Ajouter une nouvelle collection

Voici à quoi ressemble un workflow d'équipe avec FireSchema :

1. Créer le fichier de schéma

Le développeur crée un nouveau fichier .schema.json qui décrit la structure de la collection :

schemas/notifications.schema.jsonJSON

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "collection": "notifications",
  "description": "User notification preferences and history",
  "schema": {
    "type": "object",
    "properties": {
      "userId": {
        "type": "string",
        "description": "Reference to the user document"
      },
      "type": {
        "type": "string",
        "enum": ["email", "push", "sms"],
        "description": "Notification channel"
      },
      "enabled": {
        "type": "boolean",
        "description": "Whether this notification type is active"
      }
    },
    "required": ["userId", "type", "enabled"]
  }
}

2. Soumettre une PR avec le schéma + le code

Le fichier de schéma est commité avec le code de la fonctionnalité. Les relecteurs peuvent voir à la fois l'implémentation et la documentation dans la même PR.

3. La documentation des schémas se met à jour automatiquement

Une fois fusionné, le visualiseur FireSchema hébergé récupère automatiquement le nouveau fichier. Aucune mise à jour manuelle de la documentation nécessaire.

Avantages pour votre équipe

Intégration plus rapide

Les nouveaux développeurs comprennent le modèle de données en quelques heures, pas en quelques semaines. La documentation interactive leur permet d'explorer à leur rythme.

Moins de bugs

Quand tout le monde connaît les types de champs attendus, les enums et les champs obligatoires, moins de mauvaises hypothèses arrivent en production.

Meilleure communication

Les équipes produit, backend et frontend partagent la même référence de données. « Consulte le schéma » devient la réponse standard.

Historique d'audit

Parce que les schémas vivent dans git, vous pouvez voir quand une collection a été modifiée, par qui et pourquoi — grâce à l'historique des commits.

Impact concret

Une équipe d'ingénierie de 12 personnes a adopté FireSchema pour leur application Firestore avec 24 collections. Résultats après 3 mois :

-Temps d'intégration réduit de 2 semaines à 3 jours
-Les bugs liés aux données ont diminué de 40 %
-Les messages Slack « que signifie ce champ ? » ont diminué de 60 %
-Les modifications de schéma font désormais partie de 100 % des PRs concernées

Commencer avec votre équipe

Configurer FireSchema pour votre équipe prend 5 minutes :

1Follow the Quick Start guide to create your first schema files
2Ajoutez un dossier schemas/ à votre dépôt
3Déployez le visualiseur sur la documentation interne de votre équipe (Vercel, GitHub Pages ou tout hébergeur statique)
4Ajoutez les mises à jour de schéma à votre checklist de PR

Documentation d'équipe avec FireSchema