DP-900 : Ne confondez pas relationnel, NoSQL et analytique

Parmi les candidats qui échouent à la certification Microsoft DP-900 Azure Data Fundamentals, une proportion significative trébuche sur la différence SQL NoSQL analytique DP-900 Azure : l’incapacité à distinguer clairement les bases de données relationnelles, les bases NoSQL et les entrepôts analytiques dans l’écosystème Azure. Ce piège est particulièrement redoutable parce qu’il ne ressemble pas à une erreur évidente. Les services Microsoft partagent des noms proches, des logos similaires et des descriptions qui semblent se recouper. Résultat : des candidats pourtant préparés perdent des points précieux sur des questions qui auraient dû être acquises.

1. Le piège identifié : comprendre la confusion

Le problème central est que Microsoft Azure propose un catalogue de services de données extrêmement riche, et que plusieurs d’entre eux semblent, en surface, répondre aux mêmes besoins. Un candidat qui survole sa préparation va naturellement ranger Azure SQL Database et SQL Server dans une case « base de données classique », puis considérer Cosmos DB comme « juste une autre base de données », et enfin percevoir Azure Synapse Analytics comme « un SQL un peu plus grand ». Cette simplification est exactement ce que l’examen cherche à piéger.

La confusion naît de plusieurs mécanismes cognitifs. D’abord, le mot « SQL » apparaît dans Azure SQL, SQL Server, mais aussi dans l’interface de Synapse Analytics — ce qui brouille la frontière entre stockage transactionnel et analyse massive. Ensuite, Cosmos DB supporte plusieurs API dont une API SQL, ce qui amène des candidats à le classer par erreur parmi les bases relationnelles. Enfin, Azure Data Lake et Azure Blob Storage sont deux services de stockage de fichiers dont les rôles semblent interchangeables au premier abord, mais qui s’inscrivent dans des architectures fondamentalement différentes. Les bases relationnelles (Azure SQL Database, Azure SQL Managed Instance, SQL Server sur machine virtuelle) sont conçues pour des données structurées, des transactions ACID et des relations entre tables. Les bases NoSQL (Cosmos DB, Azure Table Storage) gèrent des données semi-structurées ou non structurées, avec une scalabilité horizontale et des modèles de données flexibles : documents JSON, paires clé-valeur, graphes ou colonnes larges. Les entrepôts analytiques (Azure Synapse Analytics, Azure Data Lake Storage) ne sont pas faits pour des transactions en temps réel : ils sont optimisés pour l’analyse de grandes volumétries, les requêtes OLAP et les pipelines de données.

2. La règle pour ne plus se tromper

Pour ne plus confondre ces trois familles de services, il faut se poser une seule question décisive face à chaque scénario : quel est le type d’opération principale décrite ? Voici la grille de lecture à mémoriser :

• Transactions quotidiennes, données structurées, relations entre tables → Relationnel : Azure SQL Database, SQL Managed Instance, SQL Server. Pensez à une application e-commerce qui enregistre des commandes.
• Données flexibles, forte scalabilité, faible latence mondiale, schéma variable → NoSQL : Cosmos DB (documents, graphes, clé-valeur), Azure Table Storage. Pensez à un catalogue de produits avec des attributs différents selon les catégories.
• Analyse de masse, reporting, Big Data, requêtes sur des millions de lignes → Analytique : Azure Synapse Analytics, Azure Data Lake Storage. Pensez à un dashboard de ventes agrégées sur cinq ans.

Cette logique est au cœur de ce que le Microsoft DP-900 Study Guide officiel appelle la distinction entre les charges de travail OLTP (Online Transaction Processing) et OLAP (Online Analytical Processing). Savoir associer chaque service à l’un de ces deux mondes suffit à résoudre la grande majorité des questions pièges. Pour aller plus loin dans votre méthode de préparation, pensez à analyser vos résultats d’examen blanc pour progresser et identifier précisément vos zones de confusion.

3. Deux exemples de questions types avec analyse

Question 1 : Une entreprise doit stocker les données d’un réseau social mondial avec des profils utilisateurs aux attributs variables et doit garantir une latence inférieure à 10 ms dans toutes les régions du monde. Quel service Azure est le plus adapté ?
A) Azure SQL Database
B) Azure Synapse Analytics
C) Azure Cosmos DB
D) Azure Data Lake Storage Gen2

Réponse : C) Azure Cosmos DB — Le scénario décrit trois indices clés : données à schéma variable (NoSQL), distribution mondiale (multi-région) et faible latence. Cosmos DB est le seul service conçu pour répondre simultanément à ces trois contraintes. Le distracteur A (Azure SQL Database) est convaincant car on parle de profils utilisateurs, ce qui évoque une base de données classique — mais la contrainte de schéma variable élimine le relationnel. Le distracteur B (Synapse) est éliminé dès que l’on voit « latence inférieure à 10 ms » : Synapse est analytique, pas transactionnel. Le distracteur D piège les candidats qui confondent scalabilité et stockage de fichiers.

Question 2 : Une équipe data souhaite effectuer des requêtes d’agrégation sur cinq années d’historique de ventes représentant plusieurs téraoctets de données pour alimenter des rapports mensuels. Quel service Azure correspond à ce besoin ?
A) Azure Cosmos DB
B) Azure SQL Managed Instance
C) Azure Table Storage
D) Azure Synapse Analytics

Réponse : D) Azure Synapse Analytics — Le mot-clé ici est « agrégation sur plusieurs téraoctets » pour des « rapports » : c’est une charge de travail OLAP pure. Azure Synapse Analytics est la réponse évidente dès qu’on applique la règle T-N-A. Le distracteur B (SQL Managed Instance) est le plus dangereux : les candidats voient « SQL » et « requêtes » et choisissent par réflexe une solution relationnelle. Mais SQL Managed Instance n’est pas conçu pour des analyses massives sur des téraoctets — ses performances et son architecture ne sont pas optimisés pour ce cas d’usage. Les distracteurs A et C sont éliminés rapidement car ils appartiennent à la famille NoSQL, inadaptée aux requêtes analytiques complexes. Si vous préparez d’autres certifications cloud en parallèle, les stratégies utilisées pour préparer l’AWS Cloud Practitioner CLF-C02 partagent cette même logique de distinction par cas d’usage.

4. Ce qu’il faut retenir pour le jour J

Quatre réflexes concrets à avoir pendant l’examen :

• Identifier le cas d’usage avant le service : lisez toujours le scénario en cherchant d’abord si l’opération est transactionnelle, flexible/scalable ou analytique. Le service découlera naturellement de cette classification.
• Méfiance avec le mot « SQL » : Azure SQL, SQL Server, SQL Managed Instance sont relationnels. Mais Synapse Analytics intègre aussi du SQL — ce n’est pas la même chose. Le contexte (transaction vs analyse) tranche.
• Cosmos DB ≠ base relationnelle : même si Cosmos DB supporte une API SQL, il reste fondamentalement un service NoSQL. Sa valeur ajoutée est la flexibilité du schéma et la distribution mondiale, pas les relations entre tables.
• Data Lake = stockage de fichiers analytiques : Azure Data Lake Storage n’est pas une base de données. C’est un espace de stockage optimisé pour les grands volumes de fichiers bruts, souvent utilisé en amont de Synapse. Ne le confondez pas avec une solution de requêtage directe.

Ces quatre points couvrent l’essentiel de ce que le domaine « Données non relationnelles dans Azure » — soit jusqu’à 30% de votre score — teste réellement. Contrairement à d’autres certifications comme celles de l’univers Scrum où la distinction est conceptuelle (voir par exemple PSPO vs PSM : quelle certification Scrum choisir), ici la confusion est technique et se résout par une grille de lecture claire appliquée systématiquement.