Dernière révision : mai 2026
Une référence concise des modèles d'architecture évalués par l'examen CDL. Lisez de haut en bas ou sautez à une section.
Passer des dépenses informatiques liées à de gros achats de matériel initiaux à un modèle de paiement à l'usage.
Utiliser les services cloud pour convertir les dépenses d'investissement (CapEx) en dépenses d'exploitation (OpEx).
Pourquoi: Le cloud offre une flexibilité financière, réduit les barrières à l'entrée et aligne directement les coûts sur l'utilisation, évitant le surprovisionnement.
Clarifier la répartition des responsabilités en matière de sécurité entre le fournisseur cloud et le client.
Google sécurise l'infrastructure cloud (matériel, réseau). Le client sécurise ce qu'il place dans le cloud (données, IAM, code d'application).
Pourquoi: Le client est toujours responsable de ses données et de ses contrôles d'accès, quel que soit le modèle de service (IaaS, PaaS, SaaS).
Adopter le cloud tout en conservant la flexibilité d'utiliser d'autres plateformes ou technologies.
Privilégier les services basés sur des technologies open-source comme Kubernetes (GKE), TensorFlow et Apache Beam (Dataflow).
Pourquoi: Les standards open-source augmentent la portabilité des charges de travail, évitant le verrouillage à des API propriétaires et permettant des stratégies hybrides/multi-cloud.
Réduire l'empreinte carbone des opérations informatiques pour atteindre les objectifs de durabilité de l'entreprise.
Héberger les charges de travail sur Google Cloud, en tirant parti de son approvisionnement en énergie 100% renouvelable. Utiliser l'outil Carbon Footprint pour surveiller et sélectionner des régions à faible émission de carbone.
Pourquoi: Google Cloud exploite l'un des clouds les plus propres, permettant aux entreprises d'hériter de ses avantages en matière de durabilité.
Intégrer l'infrastructure sur site avec les services cloud en raison de réglementations ou de la souveraineté des données.
Utiliser Anthos pour une plateforme cohérente basée sur Kubernetes, à la fois sur site et sur Google Cloud.
Pourquoi: Anthos fournit un plan de gestion et de contrôle unifié pour les applications, quel que soit leur emplacement d'exécution, simplifiant les opérations hybrides.
Analyser des pétaoctets de données structurées avec des requêtes SQL complexes sans gérer l'infrastructure.
Utiliser BigQuery.
Pourquoi: BigQuery est un entrepôt de données entièrement géré et sans serveur, optimisé pour les requêtes analytiques à grande échelle.
Besoin d'une base de données relationnelle distribuée mondialement avec une forte cohérence et une scalabilité horizontale.
Utiliser Cloud Spanner.
Pourquoi: Spanner combine la sémantique relationnelle (ACID, SQL) avec une évolutivité non relationnelle, idéal pour les applications mondiales critiques comme la finance.
Stocker et récupérer de grands volumes de données clé-valeur simples (par exemple, IoT, profils utilisateur) avec une latence d'une seule milliseconde.
Utiliser Cloud Bigtable.
Pourquoi: Bigtable est une base de données NoSQL à colonnes larges optimisée pour les charges de travail opérationnelles et analytiques à haut débit et faible latence.
Développer une application mobile ou web nécessitant une synchronisation des données en temps réel et des fonctionnalités hors ligne.
Utiliser Firestore.
Pourquoi: Firestore est une base de données NoSQL orientée documents avec synchronisation en temps réel intégrée et persistance hors ligne, conçue pour le développement d'applications modernes.
Migrer une base de données MySQL, PostgreSQL ou SQL Server traditionnelle sur site vers un service cloud géré avec un minimum de modifications.
Utiliser Cloud SQL.
Pourquoi: Cloud SQL est un service de base de données relationnelle entièrement géré qui assure la compatibilité avec les moteurs de bases de données standards, automatisant les sauvegardes, les correctifs et la réplication.
Ingérer et traiter un flux de données en temps réel et à haut volume (par exemple, IoT, parcours de clics) pour une analyse immédiate.
Utiliser Pub/Sub pour l'ingestion, Dataflow pour le traitement des flux et BigQuery pour l'analyse.
Pourquoi: Ceci est le modèle sans serveur canonique pour l'analyse évolutive et en temps réel sur Google Cloud.
Stocker des données avec des schémas d'accès variés (fréquent, peu fréquent, archive) de manière rentable.
Utiliser Cloud Storage avec des politiques de cycle de vie pour faire passer automatiquement les données entre les classes Standard, Nearline, Coldline et Archive.
Pourquoi: Les politiques de cycle de vie automatisent la hiérarchisation des données, en adaptant le coût du stockage à la fréquence d'accès sans intervention manuelle.
Stocker de grandes quantités de données brutes, non structurées et semi-structurées pour un traitement et une analyse futurs.
Utiliser Cloud Storage comme référentiel central (lac de données).
Pourquoi: Cloud Storage offre un stockage d'objets durable et peu coûteux qui s'intègre à tous les services de traitement de données GCP (BigQuery, Dataproc, Dataflow).
Exécuter des tâches de traitement de données à grande échelle en utilisant des frameworks open-source comme Apache Spark et Hadoop.
Utiliser Dataproc.
Pourquoi: Dataproc fournit des clusters Spark et Hadoop entièrement gérés, automatisant la création et la gestion des clusters, permettant aux équipes de se concentrer sur leurs tâches.
Ajouter des capacités d'IA telles que la reconnaissance d'images, l'analyse des sentiments ou la transcription vocale à une application sans expertise en ML.
Utiliser des API pré-entraînées : Vision AI, Natural Language AI, Speech-to-Text API, Translation API.
Pourquoi: Ces API fournissent les modèles de pointe de Google pour les cas d'utilisation courants, ne nécessitant qu'un simple appel d'API REST.
Entraîner un modèle ML personnalisé en utilisant vos propres données étiquetées (par exemple, images de produits, texte client) mais sans expérience en codage ML.
Utiliser AutoML dans Vertex AI.
Pourquoi: AutoML automatise le processus de création de modèles, permettant aux équipes de créer des modèles personnalisés de haute qualité via une interface graphique simple.
Une équipe de science des données a besoin d'une plateforme unifiée pour construire, entraîner, déployer et gérer des modèles ML personnalisés tout au long de leur cycle de vie (MLOps).
Utiliser Vertex AI.
Pourquoi: Vertex AI est une plateforme MLOps complète qui fournit des outils pour chaque étape du workflow de machine learning dans un environnement unique.
Extraire automatiquement des informations structurées (par exemple, numéros de facture, postes) de documents numérisés ou de PDF.
Utiliser Document AI.
Pourquoi: Document AI est spécifiquement entraîné à comprendre les mises en page de documents et à extraire des données structurées, réduisant ainsi la saisie manuelle de données.
Construire un chatbot ou un agent virtuel vocal pour gérer les demandes de service client.
Utiliser Dialogflow.
Pourquoi: Dialogflow est une plateforme de compréhension du langage naturel conçue pour construire des interfaces conversationnelles, gérer les intentions, les entités et le flux de conversation.
Construire et exécuter des modèles prédictifs directement sur des données stockées dans un entrepôt de données en utilisant uniquement SQL.
Utiliser BigQuery ML.
Pourquoi: BigQuery ML démocratise le machine learning en permettant aux analystes de données de créer des modèles en utilisant une syntaxe SQL familière, évitant ainsi le déplacement des données.
Créer des applications capables de générer du nouveau contenu, tel que des résumés de texte, du code ou des images.
Utiliser la plateforme Vertex AI pour l'IA générative, en accédant à des modèles de fondation comme Gemini.
Pourquoi: Vertex AI offre un accès géré à de puissants modèles de fondation via des API, permettant le développement rapide de fonctionnalités d'IA générative.
Migrer une application héritée exécutée sur une VM vers le cloud avec des modifications minimales, nécessitant un contrôle total du système d'exploitation.
Utiliser Compute Engine.
Pourquoi: Compute Engine (IaaS) fournit des machines virtuelles, offrant un contrôle maximal et un chemin de migration direct pour les serveurs sur site.
Déployer une application web conteneurisée et sans état qui doit s'adapter automatiquement en fonction du trafic, y compris la mise à l'échelle à zéro.
Utiliser Cloud Run.
Pourquoi: Cloud Run est une plateforme sans serveur entièrement gérée pour les conteneurs qui abstrait toute l'infrastructure et ne facture que le temps de traitement des requêtes actives.
Exécuter une architecture de microservices complexe utilisant des conteneurs, nécessitant une orchestration et un contrôle précis.
Utiliser Google Kubernetes Engine (GKE).
Pourquoi: GKE fournit un environnement Kubernetes géré et prêt pour la production, offrant des capacités d'orchestration complètes tout en automatisant la gestion des clusters.
Exécuter un petit morceau de code en réponse à un événement, comme le téléchargement d'un fichier vers Cloud Storage ou un message Pub/Sub.
Utiliser Cloud Functions.
Pourquoi: Cloud Functions (FaaS) est un service de calcul sans serveur, piloté par les événements, idéal pour les fonctions de courte durée et à but unique sans gestion de serveurs.
Déployer une application web et se concentrer uniquement sur l'écriture de code, en laissant la plateforme gérer les serveurs, la mise à l'échelle et les correctifs.
Utiliser App Engine.
Pourquoi: App Engine (PaaS) est une plateforme entièrement gérée qui abstrait toute l'infrastructure, idéale pour les développeurs qui veulent le moyen le plus rapide de déployer une application.
Exécuter des tâches de traitement par lots volumineuses et tolérantes aux pannes ou des tâches de calcul haute performance au coût le plus bas possible.
Utiliser des VM Spot sur Compute Engine.
Pourquoi: Les VM Spot offrent des remises importantes (jusqu'à 91 %) pour les charges de travail qui peuvent être interrompues, les rendant très rentables pour les tâches par lots non critiques.
Établir une connexion privée à large bande passante et faible latence entre un centre de données sur site et Google Cloud.
Utiliser Cloud Interconnect.
Pourquoi: Cloud Interconnect fournit une connexion physique dédiée, offrant des performances plus fiables et cohérentes qu'un VPN sur l'Internet public.
Diffuser du contenu web ou vidéo à une base d'utilisateurs mondiale avec une faible latence.
Utiliser Cloud CDN.
Pourquoi: Cloud CDN met en cache le contenu aux emplacements périphériques mondialement distribués de Google, servant les utilisateurs à partir d'un point de présence proche d'eux.
Stocker et gérer des images de conteneurs, des paquets de système d'exploitation et des paquets de langage de manière sécurisée avec une analyse des vulnérabilités.
Utiliser Artifact Registry.
Pourquoi: Artifact Registry est un référentiel universel géré qui s'intègre avec CI/CD et GKE pour fournir une gestion sécurisée et centralisée des paquets.
Migrer les charges de travail VMware existantes vers Google Cloud sans réarchitecturer les applications ni changer les outils opérationnels.
Utiliser Google Cloud VMware Engine.
Pourquoi: Il fournit un centre de données défini par logiciel (SDDC) VMware dédié et entièrement géré exécuté sur Google Cloud, permettant un "lift and shift" transparent pour VMware.
Gérer l'accès des utilisateurs aux ressources cloud en fonction de leur fonction, en suivant le principe du moindre privilège.
Attribuer des rôles IAM prédéfinis ou personnalisés aux groupes Google, et non aux utilisateurs individuels.
Pourquoi: La gestion des autorisations via les groupes simplifie l'administration et garantit que les nouveaux utilisateurs héritent automatiquement des autorisations minimales correctes.
Obtenir une vue centralisée des vulnérabilités de sécurité, des menaces et des erreurs de configuration à travers toute l'organisation GCP.
Utiliser Security Command Center.
Pourquoi: Il agit comme un point de vue unique pour la sécurité, agrégeant les résultats de multiples sources et fournissant des informations exploitables.
Protéger les applications web exposées publiquement contre les attaques DDoS et les exploits web courants (par exemple, injection SQL).
Utiliser Cloud Armor.
Pourquoi: Cloud Armor est le pare-feu d'application web (WAF) et le service d'atténuation DDoS de Google qui s'intègre au répartiteur de charge global.
Chiffrer les données dans les services cloud tout en gardant un contrôle total sur les clés de chiffrement.
Utiliser Cloud Key Management Service (Cloud KMS) pour créer des clés de chiffrement gérées par le client (CMEK).
Pourquoi: CMEK vous permet de contrôler le cycle de vie des clés (rotation, destruction) pour des raisons de conformité ou de politique, tandis que Google gère l'infrastructure des clés.
Découvrir, classifier et masquer les données sensibles (par exemple, numéros de carte de crédit, PII) stockées dans Cloud Storage ou BigQuery.
Utiliser Cloud Data Loss Prevention (DLP).
Pourquoi: Cloud DLP fournit des outils pour scanner automatiquement et prendre des mesures sur les données sensibles afin d'éviter une exposition accidentelle.
Fournir un accès sécurisé aux applications web internes pour les employés sans utiliser de VPN traditionnel.
Utiliser Identity-Aware Proxy (IAP).
Pourquoi: IAP applique des politiques d'accès basées sur l'identité de l'utilisateur et le contexte, créant un modèle de sécurité "zero trust" pour les applications.
Empêcher l'exfiltration de données en créant un périmètre de sécurité autour des projets et services Google Cloud sensibles.
Utiliser VPC Service Controls.
Pourquoi: VPC Service Controls isole les services et les données, garantissant que les données ne peuvent pas être déplacées en dehors du périmètre défini, même par un utilisateur disposant d'autorisations IAM valides.
Stocker et gérer de manière sécurisée les secrets d'application tels que les clés API, les mots de passe et les certificats.
Utiliser Secret Manager.
Pourquoi: Secret Manager fournit un stockage centralisé, versionné et audité pour les secrets avec des autorisations IAM granulaires, ce qui est plus sécurisé que de les stocker dans du code ou des fichiers de configuration.
Obtenir une observabilité complète de la santé des applications et de l'infrastructure grâce aux métriques, aux logs et aux traces.
Utiliser la suite d'opérations Google Cloud : Cloud Monitoring (métriques/alertes), Cloud Logging (logs) et Cloud Trace (traçage).
Pourquoi: Cette suite intégrée offre une vue complète des performances du système pour une surveillance proactive et un dépannage plus rapide.
Gérer de manière proactive les dépenses cloud et recevoir des notifications avant que les coûts ne dépassent les montants prévus.
Configurer les alertes de budget de Cloud Billing.
Pourquoi: Les budgets fournissent des notifications programmatiques lorsque les dépenses atteignent certains seuils, évitant les dépassements de coûts.
Suivre et allouer les coûts cloud à des équipes, projets ou centres de coûts spécifiques pour la refacturation.
Appliquer des étiquettes (Labels) à toutes les ressources et utiliser les rapports de Cloud Billing pour filtrer et regrouper les coûts par étiquette.
Pourquoi: Les étiquettes sont le principal mécanisme pour organiser les ressources et attribuer les coûts pour la gouvernance financière.
Réduire les coûts pour les charges de travail prévisibles et stables qui s'exécutent en continu (par exemple, un serveur de base de données).
Acheter des remises sur engagement d'utilisation (CUDs) d'un ou trois ans pour Compute Engine ou d'autres services.
Pourquoi: Les CUDs offrent des économies significatives par rapport aux tarifs à la demande en échange d'un engagement à un niveau d'utilisation des ressources constant.
Organiser les ressources cloud pour refléter la structure de l'entreprise (par exemple, départements, environnements) et appliquer des politiques de manière hiérarchique.
Utiliser la hiérarchie des ressources Organisation > Dossiers > Projets.
Pourquoi: Cette structure permet un contrôle centralisé, car les politiques IAM et d'Organisation sont héritées le long de la hiérarchie, simplifiant la gouvernance à grande échelle.
Définir, déployer et gérer l'infrastructure cloud de manière répétable, versionnée et automatisée.
Utiliser un outil d'Infrastructure as Code (IaC) comme Terraform ou Cloud Deployment Manager.
Pourquoi: IaC réduit les erreurs manuelles, augmente la vitesse de déploiement et fournit un enregistrement auditable des modifications de l'infrastructure.
Équilibrer le besoin de fiabilité des services avec la nécessité d'innover et de publier de nouvelles fonctionnalités.
Mettre en œuvre les principes du Site Reliability Engineering (SRE) : définir les objectifs de niveau de service (SLOs) et utiliser le budget d'erreur (Error Budget) qui en résulte.
Pourquoi: Le budget d'erreur fournit un cadre basé sur les données pour décider quand prioriser le travail de fiabilité par rapport au développement de fonctionnalités, protégeant ainsi l'expérience utilisateur.