Bases de données
PostgreSQL, MongoDB, Redis, ClickHouse, Pinecone. Modélisation rigoureuse, indexation intelligente, query optimisation, réplication, sharding quand nécessaire. Du schéma initial à la maintenance opérationnelle.
Le contexte
En 2026, le SQL est plus vivant que jamais. PostgreSQL 17 supporte vectoriel natif (pgvector), partitioning automatique, logical replication mature. Mais 80 % des startups que nous auditons ont les mêmes problèmes : schémas non normalisés, index manquants sur des colonnes filtrées à 10M de requêtes/jour, foreign keys cassés, migrations sans rollback, requêtes N+1 qui mangent 60 % du CPU.
Le piège : démarrer avec « on verra plus tard ». À 100 lignes, tout marche. À 1M de lignes, une requête mettre 8 secondes. À 100M, le service tombe sous charge. Le coût de re-modéliser à ce stade : 3-6 mois de freeze produit, 50-200k€ d'effort, et des risques de migration en production.
Notre conviction : un schéma bien pensé dès le départ vaut deux ans de refactoring évités. On modélise selon les invariants métier (pas selon les écrans), on indexe selon les patterns de lecture réels, on choisit entre normalisé et dénormalisé en connaissant le trade-off. Et on prépare l'évolution : sharding, partitioning, read replicas — connus dès le jour 1, activés quand pertinent.
< 50ms
Latence p99
Sur les requêtes critiques après tuning et indexation
100×
Vitesse de lecture
Gain typique après ajout d'index appropriés
0
Migration cassée
Toutes nos migrations passent le test rollback avant déploiement
1M+
QPS soutenu
Architecture testée — read replicas + cache + partitioning
Ce qu'on construit
De la DB relationnelle classique au search vectoriel pour RAG, on choisit le bon moteur pour le bon problème — jamais le contraire.
Le cœur de 80 % de nos projets.
Schéma relationnel rigoureux, normalisation 3NF ajustée selon les besoins, contraintes FK + checks, indexation B-tree + partial + GIN selon les patterns. Migrations versionnées (Prisma, Drizzle, Knex, Alembic). Partitioning quand pertinent.
Quand le schéma est flexible.
Apps avec des objets riches et hiérarchiques (commerce produits, content management). MongoDB 8 avec time series collections, change streams, lookup. Stratégie d'indexation compound + multikey, sharding planifié dès le départ.
Performance et asynchrone.
Redis pour le cache applicatif (objets de session, requêtes coûteuses), pub/sub temps réel, BullMQ pour les jobs en file. Stratégies d'éviction (LRU, LFU), TTL fins, replica avec sentinel pour HA.
Quand 10M de lignes ne suffisent plus.
Pour dashboards analytiques, events tracking, logs structurés. ClickHouse columnar + materialized views + ReplacingMergeTree. Requêtes p99 < 100ms sur des milliards de lignes. Coût stockage 10× moins que PG sur ce cas.
L'IA a besoin de retrouver.
Indexation vectorielle pour assistants conversationnels et recherche sémantique. Pinecone (managé), Qdrant (self-hosted), pgvector (intégré PG). Embeddings, hybrid search (semantic + BM25), reranking pour la précision finale.
Diagnostic d'une DB qui souffre.
Audit complet : EXPLAIN ANALYZE sur les requêtes lentes, identification d'index manquants, détection de N+1, dead tuples accumulés. Rapport actionnable : top 20 wins par ratio gain/effort, mis en œuvre si tu veux.
Notre approche
On démarre par comprendre ton domaine, pas par dessiner des tables. La structure suit le besoin — pas l'inverse.
Atelier produit pour comprendre les invariants métier. Identification des entités (utilisateurs, ressources, événements), des relations (1-1, 1-N, N-N), des règles de cohérence. Choix relationnel vs document selon la nature des données.
Schéma DB final avec contraintes, types stricts, FK, checks. Stratégie d'indexation argumentée selon les patterns de lecture anticipés. Migrations versionnées avec rollback testé. Stratégie évolution (sharding, partitioning, read replicas) documentée.
Mise en œuvre du schéma sur PostgreSQL/MongoDB. Génération de données réalistes (Faker) pour les tests. Repository pattern avec ORM (Prisma, Drizzle, SQLAlchemy) ou SQL natif si critique. Tests d'intégration sur la couche data.
Stratégie backup (full + WAL streaming pour PG, snapshot quotidien). Tests de restauration sur copie. Monitoring : pg_stat_statements, slow query log, dashboards Grafana (latence, throughput, locks). Alerting Slack sur seuils critiques.
Stack technique
Pas de mode. Chaque moteur a son sweet spot. Voici comment on choisit selon le problème réel.
Relationnel
PostgreSQL 17 · MySQL 8 · CockroachDB · TiDB
PostgreSQL par défaut (mature, JSON, vector, extensions). MySQL si déjà en place. CockroachDB pour multi-region serializable. TiDB pour HTAP.
Document & NoSQL
MongoDB · Firestore · DynamoDB
MongoDB quand le schéma est flexible et évolutif. Firestore pour real-time mobile/web. DynamoDB quand on est full AWS et qu'on accepte les contraintes.
Cache & queues
Redis · Memcached · BullMQ · KeyDB
Redis pour cache + queue + pub/sub. Memcached pour pur cache distribué. BullMQ pour orchestration jobs Node. KeyDB pour drop-in Redis avec multi-thread.
Analytique columnar
ClickHouse · DuckDB · BigQuery · Snowflake
ClickHouse pour real-time analytics self-hosted. DuckDB embarqué dans l'app. BigQuery quand on est GCP. Snowflake pour les besoins enterprise massifs.
Vector DB (RAG)
Pinecone · Qdrant · Weaviate · pgvector · Turbopuffer
pgvector quand on est déjà PG (intégration native). Pinecone (managé) pour démarrer vite. Qdrant self-hosted pour la souveraineté. Turbopuffer pour le coût massif.
Migration & ORM
Prisma · Drizzle · Knex · TypeORM · Alembic · SQLAlchemy
Prisma ou Drizzle pour TS (DX excellent). Alembic + SQLAlchemy pour Python. Knex en SQL builder pur. TypeORM seulement sur projets legacy.
Garanties chiffrées
p99 < 50ms
Latence requête
Sur les requêtes critiques. Mesurée après tuning et indexation, validée en charge réelle.
0
Migration cassée
Chaque migration testée avec rollback avant déploiement. Pas de surprise dimanche soir.
RPO < 1h
Backup automatisé
Recovery Point Objective : tu ne perds jamais plus d'1h de données. Backups testés mensuellement.
100%
Index documentés
Chaque index documenté avec son cas d'usage. Pas d'index « pour voir » qui ralentit les writes.
Tarification
Plutôt que des forfaits abstraits, on cadre selon ton contexte : périmètre, complexité, délais, contraintes. Tu nous écris en 3 phrases ce que tu veux faire — on te revient avec un devis ferme sous 48h ouvrées.
Réponse sous 48 h ouvrées Demander un devis →Ton mail est prêt 🚀
On a ouvert ton client mail avec toutes les infos pré-remplies. Appuie sur Envoyer et l'équipe te répond sous 24h ouvrées.
