MongoDB est idéal pour des modèles documentaires, des itérations rapides et des agrégations puissantes. Pour des transactions complexes multi-entités, une base SQL peut rester préférable.

On part des access patterns réels. Embedding pour les lectures atomiques fréquentes, références quand les documents grossissent ou sont partagés. On évite les tableaux non bornés et les documents géants.

Explain plans, index adaptés (composés, partiels), projections, TTL et pipelines d’agrégation optimisés. L’objectif : réduire le coût CPU/IO de chaque requête.

Pas obligatoire mais souvent pertinent : sécurité réseau, backups gérés, alertes, scaling et suivi. Nous optimisons aussi la facture (sizing, index, politique de rétention).

Oui, les transactions multi-documents existent, mais on les utilise avec parcimonie pour préserver les performances. Une bonne modélisation limite leur besoin.

On choisit une clé de sharding stable, on prépare le capacity planning, on met en place des politiques de rétention et des tests de restore réguliers.

Rôles/permissions minimales, réseau privé/allow-list, gestion des secrets, chiffrement en transit, audit trail et sauvegardes testées.