Comment les LLM choisissent des bases de données d'après les besoins produit — et où ils échouent

Pourquoi les gens utilisent des LLM pour choisir une base de données

Les équipes demandent aux LLM de recommander une base de données pour la même raison qu'elles leur demandent de rédiger des e‑mails ou de résumer des spécifications : c'est plus rapide que de partir de zéro. Quand vous devez choisir parmi une douzaine d'options — PostgreSQL, DynamoDB, MongoDB, Elasticsearch, Redis, ClickHouse, et d'autres — un LLM peut rapidement fournir une courte liste, exposer les compromis et donner un point de départ « suffisamment bon » pour une discussion d'équipe.

Bien utilisé, cela vous force aussi à expliciter des exigences que vous laisseriez peut‑être vagues autrement.

Ce que « déduire à partir des besoins produit » signifie vraiment

Concrètement, vous décrivez le produit (« une marketplace avec annonces et chat »), les données (« utilisateurs, commandes, messages ») et les contraintes (« doit scaler jusqu'à 1M d'utilisateurs, nécessite une recherche rapide, faible charge d'exploitation »). Le LLM mappe ensuite ces besoins sur des patterns architecturaux courants :

• données relationnelles → SQL
• documents flexibles → magasin documentaire
• analytique → entrepôt columnar
• mise en cache → magasin clé‑valeur
• recherche plein‑texte → moteur de recherche

Ce mapping peut être réellement utile en phase initiale, surtout quand l'alternative est une page blanche.

Conseil vs décision finale d'architecture

La recommandation d'un LLM est mieux traitée comme une hypothèse, pas comme un verdict d'architecture. Elle peut vous aider à :

• nommer les questions clés à résoudre
• identifier tôt les incompatibilités évidentes
• rédiger une note de décision que vous affinez avec l'équipe

Mais elle ne connaît pas la vraie forme de votre trafic, la croissance des données, les compétences de l'équipe, les contraintes fournisseurs ou la tolérance opérationnelle sans entrées précises — et même avec ces entrées, elle n'exécutera pas de tests en production.

Ce qui peut mal tourner (et comment réduire le risque)

Les LLM échouent de manière prévisible : ils s'appuient sur des règles empiriques populaires, devinent des détails manquants, négligent les besoins en transactions et cohérence, supposent des performances sans benchmark, et sous‑estiment le coût et la charge opérationnelle.

Le reste de cet article décompose ces modes d'échec et se termine par une checklist pratique pour valider toute recommandation de base de données issue d'un LLM avant de vous engager.

Comment les LLM convertissent les exigences en choix de base de données

Quand vous demandez à un LLM de « recommander une base de données », il n'évalue pas les bases comme le ferait un ingénieur. Il convertit votre prompt en exigences inférées, les met en correspondance avec des patterns vus précédemment, puis produit une réponse qui ressemble à une décision.

Ce qu'il considère comme entrées

Les entrées ne sont pas seulement les détails explicites que vous fournissez (trafic, taille des données, besoins de cohérence). Le modèle utilise aussi :

• la formulation et la structure de votre prompt (ce que vous mettez en avant, ce que vous omettez)
• la description produit (il mappe « chat », « analytics », « paiements », « IoT », etc. à des architectures typiques)
• les contraintes déclarées (cloud, budget, compétences de l'équipe, délais)
• les « patterns passés » appris lors de l'entraînement (stacks communs, conseils de blog populaires, appariements fréquents)

Comme beaucoup de prompts sont incomplets, le modèle complète souvent les lacunes par des hypothèses implicites — parfois correctes, parfois non.

Ce qu'il produit comme sorties

La plupart des réponses se situent sur trois couches :

1. un choix de catégorie (SQL vs NoSQL ; relationnel vs document vs clé‑valeur)
2. des moteurs spécifiques (PostgreSQL, MySQL, DynamoDB, MongoDB, BigQuery, Redis)
3. un ensemble de « bonnes pratiques » (index, cache, réplicas de lecture, sharding, event sourcing)

Le résultat peut avoir l'air d'une recommandation claire, mais c'est souvent un résumé structuré d'options conventionnelles.

Pourquoi ça peut paraître certain sans l'être

Les LLM généralisent à partir d'exemples ; ils n'exécutent pas votre charge, n'inspectent pas votre schéma ni ne benchmarquent vos requêtes. Si les données d'entraînement associent fortement « haute échelle » à « NoSQL », vous obtiendrez peut‑être cette réponse alors qu'un système SQL bien optimisé conviendrait mieux.

Un ton assuré est un style, pas une mesure. À moins que le modèle n'explicite ses hypothèses (« je suppose principalement des écritures en append‑only et que la cohérence éventuelle est acceptable »), la certitude peut masquer la vraie incertitude : des entrées manquantes et des performances non testées.

Ce que « besoins produit » inclut réellement

Quand on dit « choisir une base de données selon les besoins produit », cela signifie souvent bien plus que « on stocke utilisateurs et commandes ». Un bon choix de base reflète ce que le produit fait, comment il doit se comporter sous contrainte, et ce que votre équipe peut raisonnablement exploiter.

Besoins fonctionnels (ce que vous construisez)

Commencez par la forme du produit : les entités principales, leurs relations, et quelles requêtes alimentent les workflows réels.

Avez‑vous besoin de filtrage ad‑hoc et de reporting sur de nombreux attributs ? Comptez‑vous sur des jointures entre entités ? Faites‑vous surtout des lectures de l'enregistrement par ID ou des scans sur des plages temporelles ? Ces détails déterminent si des tables SQL, des modèles documentaires, des schémas wide‑column ou des index de recherche conviennent le mieux.

Besoins non fonctionnels (comment il doit se comporter)

Les bases sont choisies autant par des contraintes que par des fonctionnalités :

• objectifs de latence (p95/p99) pour les actions clés
• exigences de disponibilité et de reprise (quelle indisponibilité est acceptable ?)
• ratio lecture/écriture et pics de trafic
• taux de croissance des données et du trafic sur 6–24 mois

Un système tolérant quelques secondes de délai est très différent d'un système qui doit confirmer un paiement en moins de 200 ms.

Besoins opérationnels (ce que vous pouvez exploiter)

Même un modèle de données « parfait » échoue si l'exploitation ne suit pas :

• sauvegardes et tests de restauration
• migrations et évolution de schéma
• charge d'astreinte et staffing (expérience DBA vs généralistes)
• limites fournisseurs : quotas des services gérés, support de régions, fenêtres de maintenance

Besoins réglementaires (ce que vous devez prouver)

Les exigences de conformité peuvent rapidement restreindre les choix :

• garanties de suppression et de rétention des données
• pistes d'audit (qui a modifié quoi et quand)
• contrôle d'accès, chiffrement et séparation des tâches

Les LLM infèrent souvent ces besoins à partir d'un prompt vague — être explicite fait la différence entre une recommandation utile et une erreur confiante.

Où le raisonnement des LLM peut diverger de la réalité

Les LLM cartographient souvent quelques besoins énoncés (« temps réel », « scalable », « schéma flexible ») sur une étiquette familière (« utilisez NoSQL », « utilisez Postgres »). C'est utile pour le brainstorming, mais le raisonnement dérape quand le modèle confond fonctionnalités de base de données et exigences produit.

Fonctionnalités ≠ besoins produit

Une liste de fonctionnalités (transactions, support JSON, recherche plein‑texte, sharding) semble concrète, pourtant les besoins produit décrivent des résultats : latence acceptable, règles de correction, auditabilité, compétences de l'équipe, contraintes de migration et budget.

Un LLM peut « cocher » des fonctionnalités et manquer que le produit nécessite des workflows d'assistance prévisibles, un écosystème mature ou une option d'hébergement autorisée par votre entreprise.

Les checklists ne capturent pas la forme des données et des requêtes

De nombreuses recommandations partent du principe que si une base peut stocker un type de données, elle conviendra au produit. La difficulté est la relation entre les données et les requêtes : comment vous filtrerez, joindrez, trierez et agrégerez — à quels volumes et avec quels motifs de mise à jour.

Deux systèmes capables tous deux de « stocker des événements utilisateur » peuvent très bien se comporter différemment selon que vous avez besoin de :

• analytique ad‑hoc sur de nombreuses dimensions
• timelines par utilisateur avec ordonnancement strict
• contraintes inter‑entités (ex. : le stock ne peut pas passer sous zéro)

La performance est un détail d'implémentation, pas une promesse

Les LLM peuvent dire « la base X est rapide », mais la performance dépend du schéma, des index, du partitionnement, des requêtes et de la concurrence. De petits changements — comme ajouter un index composite ou éviter des scans non bornés — peuvent inverser le résultat. Sans données et requêtes représentatives, « rapide » n'est qu'une supposition.

L'adéquation opérationnelle peut primer sur la capacité brute

Même si deux bases peuvent techniquement répondre aux exigences, le meilleur choix peut être celui que votre équipe sait exploiter : temps de restauration, monitoring, charge d'astreinte, verrouillage fournisseur, prévisibilité des coûts et conformité.

Les LLM ont tendance à sous‑pondérer ces réalités sauf si vous les fournissez explicitement.

Mode d'échec 1 : Sur‑généraliser à partir de règles de poche populaires

Les LLM répondent souvent aux questions sur les bases de données en ressortant des « règles » largement répétées, comme « NoSQL scale mieux » ou « Postgres fait tout ». Ces raccourcis sonnent confiants, mais ils aplatisent la réalité complexe des produits : ce que vous stockez, comment vous le requêtez et ce que signifie une défaillance en situation réelle.

Le raccourci classique : « Utilisez NoSQL pour l'échelle »

Un pattern courant est de supposer que si vous mentionnez croissance, trafic élevé ou « big data », le choix le plus sûr est NoSQL. Le problème est que « scaler » est rarement le premier problème non résolu. Beaucoup d'apps atteignent des limites à cause de :

• index manquants ou requêtes inefficaces
• rétention de données non bornée
• mauvaise stratégie de cache
• ressources sous‑dimensionnées

Dans ces cas, changer de base de données ne règle pas la cause racine — ça change juste les outils.

Ce qu'on ignore : jointures, transactions et stricte correction

Les règles de poche gommant aussi des besoins qui influencent fortement l'adéquation d'une base. Un LLM peut recommander un magasin documentaire tout en négligeant que vous avez besoin de :

• mises à jour multi‑étapes qui doivent réussir ou échouer ensemble (transactions)
• stricte correction pour soldes, inventaire ou réservations (cohérence forte)
• requêtes de reporting qui assemblent des données cross‑entités (jointures complexes)

Ces besoins n'excluent pas automatiquement le NoSQL, mais ils élèvent le niveau : vous pourriez nécessiter un schéma soigné, une logique applicative supplémentaire ou des compromis différents de ceux suggérés par le LLM.

Pourquoi ce mode d'échec coûte cher

Quand une recommandation est construite sur un slogan plutôt que sur vos patterns d'accès réels, le risque n'est pas seulement un choix sous‑optimal — c'est une ré‑platformisation coûteuse plus tard. Migrer des données, réécrire des requêtes et requalifier l'équipe survient souvent quand vous pouvez le moins vous permettre des interruptions.

Traitez les « règles » comme des amorces de questions, pas comme des réponses. Demandez ce que vous mettez à l'échelle (lectures, écritures, analytique), ce qui doit être correct et quelles requêtes sont incontournables.

Mode d'échec 2 : Entrées manquantes ou ambiguës

Les LLM excellent à transformer une description courte en un choix confiant — mais ils ne peuvent pas inventer les contraintes manquantes qui déterminent réellement si un choix fonctionne. Quand les entrées sont vagues, la recommandation devient une supposition déguisée en réponse.

Le piège « temps réel » et « trafic élevé »

Des mots comme « temps réel », « trafic élevé », « scalable » ou « enterprise‑grade » ne mappent pas clairement à une base spécifique. « Temps réel » peut vouloir dire « mises à jour sous 5 secondes » pour un tableau de bord — ou « bout‑à‑bout < 50 ms » pour des alertes de trading. « Trafic élevé » peut être 200 requêtes/s ou 200 000.

Sans chiffres précis, un LLM peut basculer vers des heuristiques populaires (ex. « NoSQL pour l'échelle », « Postgres pour tout ») même quand les vrais besoins pointent ailleurs.

Les nombres manquants qui changent la réponse

Si vous ne fournissez pas :

• QPS lecture/écriture (pic vs moyenne)
• objectifs de latence p95/p99 (et s'ils s'appliquent aux lectures, écritures ou aux deux)
• taille actuelle du jeu de données, taux de croissance, politique de rétention
• taille des objets (lignes larges ? gros blobs ?) et cardinalité des index

le modèle les supposera silencieusement.

Patterns de requêtes oubliés

Les omissions les plus dommageables sont souvent en forme de requête :

• reporting et analytique (group‑by, buckets temporels)
• filtres/tris sur de nombreux champs
• requêtes ad‑hoc pour support et debugging
• backfills, reprocessing et recherches « montre‑moi tout pour l'utilisateur X »

Une base excellente pour l'accès clé‑valeur peut peiner si le produit exige soudainement des filtrages flexibles et un reporting fiable.

Astuce pratique : forcer la clarification avant de recommander

Traitez la « sélection de base » comme une interaction en deux étapes : collectez d'abord les contraintes, puis recommandez. Un bon prompt (ou une check‑list interne) devrait exiger des chiffres et des requêtes exemples avant de nommer un moteur.

Mode d'échec 3 : Mauvais appariement du modèle de données

Une erreur fréquente du LLM est de recommander une catégorie de base de données (SQL, document, graphe, wide‑column) sans valider si les données du produit s'adaptent réellement à ce modèle. Le résultat : choisir un magasin qui semble adapté mais qui se bat contre la structure de l'information à représenter.

Le décalage commence souvent avec les relations

Les LLM minimisent souvent la profondeur et la cardinalité des relations : un‑à‑plusieurs vs plusieurs‑à‑plusieurs, propriété imbriquée, entités partagées et la fréquence des traversées.

Une base documentaire peut sembler naturelle pour des « profils utilisateur », mais si votre produit exécute constamment des requêtes cross‑entités — « tous les projets où le rôle d'un membre a changé ces 7 derniers jours » ou « top 20 tags à travers toutes les équipes filtrés par statut de conformité » — vous ne récupérez plus simplement un document ; vous faites des jointures.

Quand ces jointures sont fréquentes, vous devez soit :

• simuler des jointures côté application (aller‑retour et complexité), soit
• fortement dénormaliser (dupliquer les données)

Le coût caché de la dénormalisation

La duplication n'est pas gratuite. Elle augmente l'amplification des écritures, rend les mises à jour plus difficiles à garder cohérentes, complique les audits et peut créer des bugs subtils (« quelle copie est la source de vérité ? »). Les LLM recommandent parfois la dénormalisation comme si c'était un choix unique, pas une charge opérationnelle continue.

Contrôle de cohérence : schéma candidat + requêtes clés

Avant d'accepter une recommandation LLM, imposez un test de réalité rapide :

1. Esquissez un schéma candidat (tables/collections/nœuds) avec clés primaires et relations critiques.
2. Rédigez 5–10 « requêtes clés » que le produit doit supporter (filtres, tris, agrégations, jointures inter‑entités).
3. Demandez : cette base exprime‑t‑elle ces requêtes naturellement et efficacement, sans dénormalisation héroïque ou jointures applicatives en plusieurs étapes ?

Si le modèle et les requêtes ne s'alignent pas, la recommandation est du bruit — même si elle semble confiante.

Mode d'échec 4 : Angles morts sur transactions et cohérence

Les LLM traitent souvent la « cohérence » comme une préférence plutôt que comme une contrainte produit. Cela conduit à des recommandations qui paraissent raisonnables sur le papier (« utilisez un magasin NoSQL scalable ») mais qui s'effondrent quand des actions réelles d'utilisateurs exigent des mises à jour atomiques multi‑étapes.

Le fossé d'atomicité : mises à jour multi‑étapes qui doivent réussir ensemble

Beaucoup de flux produit ne sont pas un seul write — ce sont plusieurs écritures qui doivent toutes réussir ou échouer ensemble.

Les paiements en sont l'exemple type : créer un prélèvement, marquer une facture comme payée, décrémenter un solde de compte et ajouter une entrée d'audit. Si une étape échoue après la première, vous créez une divergence que les utilisateurs et la comptabilité vont remarquer.

L'inventaire est similaire : réserver du stock, créer une commande et mettre à jour la disponibilité. Sans transactions, vous pouvez survendre pendant les pics ou laisser des états partiels.

La cohérence éventuelle n'est pas synonyme de « l'interface peut se rafraîchir plus tard »

Les LLM assimilent parfois la cohérence éventuelle à « l'interface utilisateur s'actualisera ». La vraie question est de savoir si l'action métier peut tolérer la divergence.

Les conflits de réservation montrent pourquoi c'est crucial : deux utilisateurs réservent le même créneau. Si le système accepte les deux et « résout plus tard », vous n'améliorez pas l'UX — vous créez des tickets support et des remboursements.

Sémantiques opérationnelles manquantes : idempotence, retries et exactly‑once

Même avec une base qui supporte les transactions, le workflow périphérique a besoin de sémantiques claires :

• clés d'idempotence pour que « payer » cliqué deux fois ne débite pas deux fois
• retries sûrs face à pannes partielles et timeouts
• effets exactly‑once (ou une alternative assumée comme « at‑least‑once + déduplication ») pour les événements, webhooks et jobs en arrière‑plan

Quand un LLM ignore ces points, il peut recommander des architectures requérant un travail distribués avancé juste pour atteindre une correction produit « normale ».

Mode d'échec 5 : Hypothèses de performance sans tests

Les LLM recommandent souvent une base « rapide » comme si la vitesse était une propriété intrinsèque du moteur. En pratique, la performance est l'interaction entre votre workload, schéma, formes de requêtes, index, matériel et réglages opérationnels.

« Rapide » sans contexte de workload

Si vous ne spécifiez pas quoi doit être rapide — latence p99 pour lectures single‑row, analytique batch, débit d'ingestion ou time‑to‑first‑byte — l'LLM peut par défaut choisir des options populaires.

Deux produits peuvent tous deux revendiquer « faible latence » et pourtant avoir des patterns d'accès opposés : l'un fait des lookups clé‑valeur ; l'autre combine recherche + filtrage + tri sur de nombreux champs.

Contraintes cachées : index, amplification et partitions chaudes

Les conseils de performance dérapent aussi quand les modèles ignorent :

• limites d'indexation et compromis : les index secondaires accélèrent les lectures mais ajoutent un coût en écriture et en stockage. Certains systèmes limitent les index composites, le temps de construction d'index ou les changements d'index en ligne.
• amplification d'écriture : les moteurs basés LSM peuvent transformer des écritures simples en beaucoup de travail de compaction en arrière‑plan, important sous ingestion soutenue.
• partitions chaudes : une conception sharded/partitionnée peut toujours être un goulot si le trafic se concentre sur une petite plage de clés (tenant récent, date du jour, un article populaire).

Comportement du cache et forme des requêtes

Un LLM peut supposer que le cache vous sauvera, mais les caches n'aident que pour des patterns d'accès prévisibles. Les requêtes scannant de larges plages, triant par champs non indexés ou utilisant des filtres ad‑hoc échappent au cache et sollicitent disque/CPU.

De petits changements dans la forme des requêtes (ex. pagination par OFFSET vs pagination par clé) peuvent inverser les performances.

Un petit plan de benchmark (mieux que des suppositions)

Plutôt que de faire confiance au générique « X est plus rapide que Y », lancez un test léger adapté au produit :

1. Choisissez 3–5 requêtes représentatives (y compris les pires filtres/tris) et 1–2 patterns d'écriture (continu + rafale).
2. Utilisez un volume de données réaliste (au moins suffisant pour dépasser la mémoire ; incluez skew et clefs chaudes).
3. Mesurez p50/p95/p99 et le débit séparément pour lectures et écritures.
4. Testez variantes d'index (aucun index, index minimal, index « idéal ») et notez le surcoût en écriture.
5. Exécutez avec une concurrence proche du pic attendu et surveillez CPU, disque, compaction et métriques de lock/transaction.

Les benchmarks ne prédisent pas tout, mais ils révèlent rapidement si les hypothèses de performance du LLM tiennent la route.

Mode d'échec 6 : Négligences opérationnelles et de coût

Les LLM optimisent souvent l'adéquation sur papier — modèle de données, patterns de requêtes, buzzwords de scalabilité — tout en éludant ce qui rend une base durable en production : opérations, reprise et la vraie facture mensuelle.

Le travail caché : sauvegardes, restauration et migration

Une recommandation n'est complète que si elle répond aux questions de base : comment prendre des sauvegardes cohérentes ? À quelle vitesse restaurer ? Quel est le plan de reprise multi‑régions ?

Les conseils LLM sautent fréquemment ces détails, ou supposent qu'ils sont « intégrés » sans lire les petites lignes.

La migration est un autre angle mort. Changer de base plus tard peut être coûteux et risqué (changements de schéma, écritures doubles, backfills, réécriture de requêtes). Si votre produit risque d'évoluer, « facile à démarrer » ne suffit pas — il faut un chemin réaliste de migration.

L'observabilité fait partie du produit

Les équipes n'ont pas seulement besoin d'une base — elles doivent l'exploiter.

Si la recommandation ignore les slow query logs, métriques, dashboards, hooks de tracing et alerting, vous risquez de ne remarquer les problèmes que quand les utilisateurs se plaignent. Les outils d'exploitation varient fortement entre offres managées et auto‑hébergées, et entre fournisseurs.

Le coût total n'est pas que le tarif horaire

Les LLM ont tendance à sous‑estimer le coût en se focalisant sur la taille d'instance et en oubliant les multiplicateurs :

• croissance du stockage et politique de rétention
• tarification IOPS/débit et limites de burst
• réplicas pour montée en lecture et haute disponibilité
• temps d'astreinte, réponse aux incidents et plans de support vendor

Faire correspondre la base à l'équipe

Une « meilleure » base que votre équipe ne sait pas exploiter est rarement la meilleure option. Les recommandations doivent s'aligner sur les compétences, les attentes de support et les besoins de conformité — sinon le risque opérationnel devient le coût dominant.

Mode d'échec 7 : Conceptions polyglottes trop compliquées

Les LLM proposent parfois de « tout résoudre d'un coup » en recommandant une stack : Postgres pour les transactions, Redis pour le cache, Elasticsearch pour la recherche, Kafka + ClickHouse pour l'analytique, plus une base graphe « au cas où ». Cela peut impressionner, mais c'est souvent une conception prématurée qui crée plus de travail que de valeur — surtout en phase initiale.

Pourquoi le conseil déraille

Les architectures multi‑base semblent être un filet de sécurité : chaque outil est « le meilleur » pour une tâche. Le coût caché, c'est que chaque datastore ajouté augmente le déploiement, le monitoring, les sauvegardes, les migrations, le contrôle d'accès, la réponse aux incidents et un nouveau panel de modes de défaillance.

Les équipes passent alors du temps à maintenir la plomberie plutôt qu'à livrer des fonctionnalités produit.

Quand la persistance polyglotte est justifiée

Ajouter une seconde (ou troisième) base est généralement justifié quand il existe un besoin clair et mesuré que la base principale ne peut satisfaire sans douleur inacceptable, par exemple :

• exigences de qualité/latence de recherche dépassant ce que peut fournir la BDD principale
• workloads analytiques qui dégradent significativement les performances transactionnelles
• patterns d'échelle nécessitant des modèles de stockage ou d'indexation différents

Si vous ne pouvez pas nommer la requête précise, l'objectif de latence, la contrainte de coût ou le risque opérationnel motivant la séparation, c'est probablement prématuré.

Pièges de cohérence et duplication cross‑store

Une fois les données réparties, les questions difficiles apparaissent : quel store est la source de vérité ? Comment garder les enregistrements cohérents lors de retries, pannes partielles et backfills ?

Les données dupliquées entraînent aussi des bugs dupliqués — résultats de recherche obsolètes, comptages utilisateurs discordants et réunions « ça dépend du dashboard que tu regardes ».

Règle pratique de décision

Commencez par une base générale couvrant transactions et reporting. Ajoutez un store spécialisé seulement après que vous ayez (1) montré que le système actuel échoue face à une exigence et (2) défini un modèle de responsabilité pour la synchronisation, la cohérence et la reprise.

Gardez la trappe de sortie, pas la complexité.

Une checklist pratique pour valider un conseil de LLM sur une base de données

Les LLM peuvent être utiles pour générer un premier jet de recommandation, mais traitez‑le comme une hypothèse. Utilisez la checklist ci‑dessous pour valider (ou rejeter) la suggestion avant de consacrer des ressources d'ingénierie.

1) Clarifier les entrées (écrivez‑les)

Transformez le prompt en exigences explicites. Si vous ne pouvez pas les formuler clairement, le modèle a probablement deviné.

• Quel est le workload principal du produit : OLTP, analytique, recherche, séries temporelles, messagerie ?
• Échelle attendue : utilisateurs, écritures/sec, lectures/sec, croissance stockage, pic vs moyenne.
• Besoins non fonctionnels : uptime, multi‑région, conformité, budget, compétences équipe.

2) Modéliser les données et les requêtes clés

Élaborez les entités et relations réelles (même un croquis). Puis listez vos principaux patterns d'accès.

• Quelles sont les 10 lectures/écritures principales ?
• Quelles requêtes doivent être rapides en pic ?
• Que doit être indexé, joint, agrégé ou recherché ?

3) Définir des tests d'acceptation (critères de succès)

Traduisiez « rapide et fiable » en tests mesurables.

• Objectifs de latence et débit (p95/p99) pour les requêtes cruciales
• Exigences de cohérence et de transaction (ce qui doit être atomique)
• Cas de défaillance : perte de nœud, partitions réseau, basculement régional, durée de backup/restore

4) Lancer un proof‑of‑concept léger

Utilisez des formes de données et des mixes de requêtes réalistes, pas des exemples jouets. Chargez un jeu de données représentatif, exécutez des requêtes sous charge et mesurez.

Si le LLM a proposé plusieurs bases, testez d'abord l'option la plus simple mono‑base, puis prouvez en quoi la séparation est nécessaire.

Si vous voulez accélérer cette étape, une approche pratique consiste à prototyper la portion produit qui motive le choix de base (quelques entités clés + endpoints principaux + requêtes importantes). Des plateformes comme Koder peuvent aider ici : décrivez le workflow en chat, générez une app web/backend fonctionnelle (souvent React + Go + PostgreSQL) et itérez rapidement en affinant schéma, indexes et formes de requêtes. Des fonctions comme le mode planning, les snapshots et le rollback sont particulièrement utiles quand vous expérimentez des modèles de données et des migrations.

5) Documenter la décision — et les « triggers » de changement

Rédigez une courte rationale : pourquoi cette base convient au workload, quels compromis vous acceptez, et quels métriques forceraient une réévaluation plus tard (ex. : croissance d'écriture soutenue, nouveaux types de requêtes, besoin multi‑région, seuils de coût).