La base de données est la décision la plus durable de tout système : les frameworks passent, les données restent. Nous exploitons toutes celles-ci en production pour nos clients, et la bonne réponse est souvent « deux d'entre elles, pour des tâches différentes ». Voici notre façon d'y réfléchir.
Le relationnel d'abord
Si vos données ont des relations et votre activité des règles — réservations, commandes, factures, patients — commencez par du relationnel. Contraintes, transactions et jointures ne sont pas des reliques ; c'est la correction la moins chère que vous achèterez jamais.
MySQL / MariaDB
Rapide, omniprésent, peu coûteux à héberger, excellent sur Azure Database for MySQL et Amazon RDS. Notre choix pour les plateformes web et produits SaaS où le coût des licences compte et où la charge est majoritairement en lecture.
Microsoft SQL Server
Le partenaire naturel de .NET. Un outillage superbe, des types spatiaux (nous les utilisons pour l'appariement des chauffeurs), des index columnstore pour le reporting, des colonnes Always Encrypted pour les données médicales, et Azure SQL pour l'hébergement managé. Notre défaut pour les systèmes d'entreprise et de santé.
Oracle Database
Toujours l'épine dorsale des banques, des télécoms et des administrations. Nous travaillons avec Oracle là où il existe déjà — intégration PL/SQL, environnements RAC, migrations vers Oracle Cloud ou vers PostgreSQL lorsque la licence ne se justifie plus.
PostgreSQL
Absent de votre liste initiale, mais à connaître : un moteur open source aux fonctionnalités de niveau Oracle, avec JSONB et PostGIS. Souvent notre recommandation quand un client veut la puissance du relationnel sans frais de licence.
Bases documentaires : MongoDB
Lorsque chaque enregistrement est naturellement un document autonome à la forme flexible — un catalogue produit, une commande avec ses lignes intégrées, un journal d'événements — MongoDB brille. La mise à l'échelle horizontale et les requêtes géospatiales sont intégrées.
// MongoDB — an order document with embedded items
{
"_id": "ord_8f3c",
"customerId": "cus_120",
"status": "PickedUp",
"items": [ { "sku": "KEB-01", "qty": 2, "price": 7.5 } ],
"courier": { "id": "drv_44", "location": { "type": "Point", "coordinates": [24.94, 60.17] } },
"updatedAt": ISODate("2026-06-02T10:14:00Z")
}La contrepartie : la cohérence entre documents est de votre responsabilité. Nous gardons l'argent et l'identité en SQL et plaçons catalogues, journaux et analytique dans MongoDB.
Temps réel : Firebase
Firebase Realtime Database et Cloud Firestore ne sont pas des bases de données généralistes — ce sont des services de synchronisation auxquels une base est attachée. Pour les positions de chauffeurs en direct, le chat, la présence et les écrans collaboratifs, ils sont imbattables : le SDK mobile gère le cache hors ligne, la reconnexion et la diffusion vers des milliers de clients sans code serveur.
Un tableau de décision rapide
| Charge de travail | Notre choix habituel |
|---|---|
| Réservations, commandes, paiements, dossiers patients | SQL Server / MySQL / PostgreSQL |
| Catalogues, contenus, flux d'événements | MongoDB |
| Suivi en direct, chat, présence | Firebase Realtime DB / Firestore |
| Cache, limitation de débit, ensembles géospatiaux | Redis |
| Parcs d'entreprise existants | Oracle (intégrer, puis moderniser) |
Quel que soit votre choix
- Utilisez des migrations (EF Core, Flyway, Liquibase) — ne modifiez jamais un schéma de production à la main.
- Automatisez les sauvegardes et testez la restauration chaque trimestre.
- Chiffrez les données personnelles au repos et concevez la suppression dès le départ.
- Mesurez avec de vrais plans d'exécution avant d'ajouter des index ou des caches.
Besoin d'aide pour choisir ou migrer ? Nos consultants ont déplacé des systèmes entre toutes les bases ci-dessus — contactez-nous.