Phase bêta Open source

Vos données. Vos clés. Votre contrôle.

MindooDB est une base de données de synchronisation local-first, chiffrée de bout en bout, pour une collaboration sécurisée — les serveurs peuvent stocker et synchroniser, mais pas lire. Fonctionne en client-serveur, en peer-to-peer et en local uniquement. Pour les navigateurs, Node.js et React Native. C'est aussi le moteur de Haven, l'espace de travail graphique et collaboratif destiné aux équipes qui veulent ce modèle de confiance sans développer leur propre client.

Concept du chiffrement de bout en bout : les données sont chiffrées de l'appareil jusqu'au serveur ou au cloud
Introduction

À voir et à écouter

Une introduction approfondie à MindooDB — générée par NotebookLM à partir de la documentation de MindooDB.

Vidéo de présentation

Un aperçu visuel de la façon dont MindooDB garde les données chiffrées de bout en bout tout en permettant la collaboration en temps réel et la synchronisation local-first.

Et NotebookLM, cela se prononce « MindooDB » (avec un i bref). Mais peu importe. :-)

Stockage zero trust
Un serveur compromis ne livre que du texte chiffré

Les clés restent sur les appareils. Trois couches de chiffrement indépendantes : AES-256-GCM au repos, RSA par utilisateur en transit, TLS sur le réseau. Les serveurs ne voient jamais de texte en clair.

UX local-first
Travailler sans réseau

Créer et modifier en local. La réconciliation commence par les métadonnées et ne synchronise que ce qui a changé — la bande passante suit le delta, pas la taille totale.

Collaboration
Des fusions sans conflit

Les CRDT Automerge font converger automatiquement les modifications concurrentes. Synchronisation indépendante de l'ordre — les entrées peuvent arriver dans n'importe quelle séquence.

Fonctionnement

Les serveurs peuvent synchroniser & stocker — mais pas lire

Les clés restent sur les appareils
Les clients gardent leurs clés privées ; le serveur stocke des blobs chiffrés ; la synchronisation échange les entrées chiffrées manquantes.
Les clients chiffrent avant la synchronisation. Les serveurs stockent du texte chiffré. La synchronisation n'échange que les entrées chiffrées qui vous manquent.
  • Signer chaque modification (auteur + intégrité)
  • Chiffrer avant que les données quittent l'appareil (confidentialité)
  • Stockage append-only (piste d'audit)
  • Synchronisation adressée par contenu (ne transférer que ce qui manque)
  • Fonctionne en client-serveur et en peer-to-peer
Ce que vous pouvez construire

Cas d'usage et possibilités

Historique signé et infalsifiable
Historique append-only, chaîné cryptographiquement, pour l'auditabilité et l'intégrité.
Accès fin
Les clés nommées permettent un contrôle d'accès fondé sur le besoin d'en connaître, pour les documents sensibles.
Pièces jointes chiffrées
Envoi par blocs, lecture en streaming et déduplication à l'échelle du tenant.
Voyage dans le temps
Retrouver l'état d'un document à n'importe quel horodatage et parcourir tout son historique.
Vues virtuelles
Vues hiérarchiques catégorisées avec totaux (inspirées de Domino/Notes).
Synchroniser partout
Déploiements peer-to-peer, client-serveur et hybrides, avec les mêmes primitives. Le mode de synchronisation dense réduit la bande passante lors de la première installation sur mobile.
Prise en main

Choisissez votre runtime et lancez-vous

Ces extraits proviennent de la suite de tests de MindooDB, pour rester alignés sur des usages réels.

Pourquoi MindooDB ?

Quand choisir MindooDB plutôt qu'une alternative

MindooDB est conçu pour les applications où le chiffrement de bout en bout, le fonctionnement hors ligne et la collaboration entre plusieurs parties sont indispensables. Voici quand il convient le mieux.

Choisir MindooDB si :
  • Vous avez besoin d'un chiffrement de bout en bout et ne pouvez pas faire confiance à votre hébergeur
  • Vous exigez des pistes d'audit complètes, à l'intégrité cryptographique
  • Il vous faut un fonctionnement local-first pour des interventions sur le terrain ou à distance
  • Vous collaborez entre organisations et avez besoin d'un contrôle d'accès fin
  • Vous avez besoin de mesures techniques pour la conformité — chiffrement, pistes d'audit signées et effacement coordonné des données, qui soutiennent les programmes HIPAA, SOX, RGPD et PCI-DSS
  • Vous avez besoin d'une collaboration entre plusieurs parties avec des niveaux d'accès différents
Envisager une alternative si :
  • Vous n'avez besoin que d'opérations CRUD simples, sans collaboration
  • Vous disposez toujours d'une connexion réseau fiable et n'avez pas besoin du local-first
  • Vous n'avez pas besoin de chiffrement de bout en bout et pouvez faire confiance à votre hébergeur
  • Vos besoins en contrôle d'accès sont simples et n'exigent pas de chiffrement au niveau des documents
  • Vous avez besoin de requêtes relationnelles complexes qui ne conviennent pas au modèle documentaire
  • Vous avez un très haut débit d'écriture susceptible de mettre à l'épreuve les stores append-only
Comparatif rapide
Caractéristique MindooDB PostgreSQL/Firebase Blockchains
Chiffrement de bout en bout Oui (les serveurs ne peuvent pas déchiffrer) Non (clés côté serveur) Non (publiques par défaut)
Local-first Intégré Logique sur mesure nécessaire Réseau nécessaire
Pistes d'audit Append-only, chaînées cryptographiquement Implémentation sur mesure nécessaire Enregistrements publics immuables
Collaboration entre organisations Contrôle d'accès fin Contrôle d'accès côté serveur Visibilité tout ou rien
Confidentialité des données Privées par défaut Dépend de la sécurité du serveur Publiques par défaut

Voir le comparatif détaillé →

Confiance & transparence

Maturité pour la production & signaux de confiance

État actuel

MindooDB est un logiciel en bêta — les API peuvent changer sans préavis. Les fonctions de base sont stables et testées, mais nous recommandons une évaluation approfondie avant toute mise en production.

Ce qui est stable
  • Les protocoles fondamentaux de chiffrement et de synchronisation
  • Les opérations CRDT sur les documents
  • Les vues virtuelles et l'indexation
  • Le stockage des pièces jointes
Ce qui peut changer
  • Les noms et signatures des méthodes d'API
  • Les options de configuration
  • Les structures de données internes
Sécurité & transparence
  • Open source — l'intégralité du code sur GitHub
  • Audit de sécurité — documenté dans les documents d'audit de sécurité
  • Modèle de menace — part du principe que les serveurs sont compromis
  • Garanties cryptographiques — signatures Ed25519, chiffrement AES-256-GCM
Communauté

Développement actif, documentation complète et communauté grandissante. Voir sur GitHub →