# Prometheus vs Grafana vs Datadog en 2026 : comparatif monitoring et questions d'entretien DevOps

> Comparatif détaillé de Prometheus, Grafana et Datadog en 2026. Architecture, PromQL, alerting, intégration Kubernetes, analyse du TCO et questions d'entretien typiques sur l'observabilité.

- Published: 2026-06-20
- Updated: 2026-07-01
- Author: Anthony Fillion-Maillet
- Tags: devops, monitoring, prometheus, grafana, datadog, observability
- Reading time: 12 min

---

Dans presque tous les entretiens DevOps ou SRE, la question de la différence entre Prometheus, Grafana et Datadog finit par surgir. Un candidat capable non seulement de citer ces trois outils, mais aussi d'expliquer leur architecture, leurs points forts et leurs compromis se démarque nettement des autres. Cet article confronte les distinctions essentielles, analyse les langages de requête et les approches d'alerting respectifs, et prépare aux [questions d'entretien les plus fréquentes sur le monitoring](/technologies/devops/interview-questions/monitoring-prometheus).

> **Distinction fondamentale pour les entretiens**
>
> Prometheus est un moteur de collecte et de stockage de métriques. Grafana est une couche de visualisation et de dashboarding. Datadog est une plateforme SaaS d'observabilité entièrement managée. Ces outils résolvent des problèmes différents et, dans la pratique, se complètent souvent plutôt que de se concurrencer directement.

## Architecture et modèle de données comparés

Les fondations architecturales de ces trois outils diffèrent fondamentalement. Les recruteurs exploitent délibérément ce sujet pour évaluer la profondeur de la compréhension technique du candidat.

**Prometheus** repose sur un modèle pull-based. Le serveur interroge des endpoints HTTP (généralement `/metrics`) à des intervalles configurables et stocke les données de séries temporelles dans une base de données temporelle locale (TSDB) qui lui est propre. Chaque série temporelle est identifiée par un nom de métrique et un ensemble de labels clé-valeur. Prometheus 3.0, publié en novembre 2024, a apporté avec la version 3.8 des [histogrammes natifs](https://prometheus.io/docs/concepts/native_histograms/) stables, l'ingestion OTLP nativement intégrée et Remote Write 2.0 pour une meilleure fédération entre clusters.

**Grafana** ne collecte ni ne stocke lui-même de métriques. Il se connecte plutôt à des sources de données -- parmi lesquelles Prometheus, Loki, Tempo, InfluxDB, Elasticsearch et [plus de 100 autres](https://grafana.com/docs/grafana/latest/datasources/) -- puis génère des dashboards à partir de leurs données. Grafana Labs développe en outre Mimir (stockage de métriques à long terme), Loki (agrégation de logs) et Tempo (tracing distribué). Ensemble, ces composants forment ce que l'on appelle la stack LGTM, une plateforme d'observabilité open-source complète. La version 13, parue en mai 2026, a introduit des outils d'observability-as-code, Git Sync pour les dashboards et les SQL Expressions pour les requêtes multi-sources.

**Datadog** fonctionne comme un service SaaS push-based. Des agents installés sur les hôtes envoient métriques, logs et traces vers le backend cloud. L'ensemble des fonctions -- ingestion, stockage, requêtage, alerting et dashboarding -- réside au sein d'une plateforme managée unique. Le moteur de ML Watchdog effectue une détection d'anomalies automatique, sans qu'il soit nécessaire de définir manuellement des seuils.

La configuration Prometheus suivante illustre le modèle pull à travers une intégration Kubernetes :

```yaml
# prometheus.yml - Pull-based scrape configuration
global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: 'api-server'
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
        action: keep
        regex: true
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_port]
        action: replace
        target_label: __address__
        regex: (.+)
        replacement: ${1}:${2}
```

Cette configuration YAML met en évidence le modèle pull : les pods Kubernetes sont automatiquement découverts via le service discovery et leurs endpoints `/metrics` sont scrapés toutes les 15 secondes. Les `relabel_configs` déterminent quels pods sont scrapés et sur quel port les métriques sont disponibles. À l'inverse, Datadog ne nécessite que l'installation d'un agent en tant que DaemonSet -- la configuration s'effectue de manière centralisée depuis l'interface web.

## PromQL vs. langage de requête Datadog

Les langages de requête comptent parmi les sujets techniques les plus fréquents en entretien sur le thème du monitoring. On attend d'un candidat qu'il maîtrise couramment au moins l'un d'eux et qu'il sache expliquer les compromis respectifs.

**PromQL** (Prometheus Query Language) est le standard dans tout l'écosystème Prometheus et Grafana. Le langage prend en charge les instant vectors, les range vectors, les opérateurs d'agrégation et les recording rules. Sa puissance d'expression permet des analyses ad-hoc complexes, mais exige un temps d'apprentissage non négligeable.

```promql
# Request rate per service over 5 minutes
rate(http_requests_total{job="api-server"}[5m])

# 99th percentile latency using native histograms
histogram_quantile(0.99, rate(http_request_duration_seconds[5m]))

# Error rate as percentage
sum(rate(http_requests_total{status=~"5.."}[5m]))
  / sum(rate(http_requests_total[5m])) * 100

# Predict disk full in 4 hours using linear regression
predict_linear(node_filesystem_avail_bytes[1h], 4 * 3600) < 0
```

La fonction `rate()` calcule le taux de variation moyen d'un compteur sur une fenêtre temporelle. En entretien, la question de la différence entre `rate()` (taux lissé sur toute la fenêtre) et `irate()` (taux instantané basé sur les deux derniers points de données) revient régulièrement. La fonction `predict_linear()` permet, à partir d'une régression linéaire, de prédire le moment où une ressource sera épuisée -- un scénario typique de capacity planning.

**Le langage de requête de Datadog** adopte une autre approche, construite autour d'appels de fonctions et de scoping :

```text
# Equivalent request rate in Datadog
sum:http.requests{service:api-server}.as_rate()

# Anomaly detection (Watchdog ML - no equivalent in PromQL)
anomaly(avg:system.cpu.user{service:api-server}, 'agile', 3)

# Forecast query
forecast(avg:system.disk.free{host:web-01}, 'linear', 1)
```

La différence centrale tient au périmètre fonctionnel : PromQL offre une puissance d'expression supérieure pour les opérations mathématiques et les analyses ad-hoc. Le langage de Datadog échange une partie de cette flexibilité contre des fonctions de ML intégrées comme `anomaly()` et `forecast()`. Ces fonctions nécessiteraient un tooling externe supplémentaire dans une stack Prometheus. Pour les entretiens, la règle est la suivante : celui qui sait expliquer avec précision la sémantique de `rate()` en PromQL tout en connaissant les limites des deux langages démontre une véritable expérience pratique.

## Stratégies d'alerting : basé sur des règles vs. assisté par ML

La philosophie d'alerting diffère profondément d'un outil à l'autre. Comprendre ces différences signale, en entretien, une maturité opérationnelle.

**Prometheus Alertmanager** évalue les règles à intervalles fixes et achemine les alertes via un pipeline configurable avec grouping, silencing et inhibition :

```yaml
# alert-rules.yml - Prometheus alerting rules
groups:
  - name: api-server-alerts
    rules:
      - alert: HighErrorRate
        expr: |
          sum(rate(http_requests_total{status=~"5..",job="api-server"}[5m]))
          / sum(rate(http_requests_total{job="api-server"}[5m])) > 0.05
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "API error rate above 5% for 5 minutes"
          runbook: "https://wiki.internal/runbooks/high-error-rate"

      - alert: PodMemoryPressure
        expr: |
          container_memory_working_set_bytes{namespace="production"}
          / container_spec_memory_limit_bytes{namespace="production"} > 0.9
        for: 10m
        labels:
          severity: warning
```

Cette approche exige la définition explicite de seuils. L'avantage réside dans une transparence totale : chaque alerte possède une expression vérifiable, que l'on peut retracer lors de code reviews et d'audits. L'inconvénient est ce que l'on nomme la threshold fatigue -- les seuils statiques doivent être ajustés régulièrement aux motifs saisonniers et à la croissance de l'infrastructure, ce qui devient de plus en plus fastidieux avec des centaines de services.

**Grafana Alerting**, unifié depuis Grafana 12+, évalue des requêtes sur n'importe quelle source de données connectée et prend en charge des alertes multidimensionnelles avec des notification policies. Depuis la version 13, les définitions d'alertes peuvent être versionnées sous forme de code et gérées via Git Sync, ce qui simplifie considérablement les workflows d'infrastructure-as-code.

**Les Monitors de Datadog** combinent des seuils statiques avec des monitors d'anomalie, d'outlier et de forecast assistés par ML. Watchdog détecte automatiquement les anomalies de performance, sans qu'il soit nécessaire de créer des règles manuelles. Cela réduit sensiblement l'effort de configuration, mais au prix d'une moindre transparence sur la logique de détection. Dans les secteurs régulés comme la finance ou la santé, cela peut poser problème, car les auditeurs attendent des règles d'alerting traçables et documentées.

## Coûts et coût total de possession (TCO)

La tarification est, dans la pratique, un facteur décisif dans le choix d'un outil et revient régulièrement dans les entretiens de system design. Les candidats capables de comprendre et d'articuler les structures de coûts démontrent une conscience business.

| Dimension | Prometheus + Grafana | Datadog |
|-----------|---------------------|--------|
| **Licence** | Gratuit (AGPL / Apache 2.0) | 15-31 USD/hôte/mois (annuel) |
| **Stockage des métriques** | Auto-géré (Mimir/Thanos) | Inclus, tarification selon la rétention |
| **Gestion des logs** | Loki (self-hosted) | 0,10 USD/Go ingéré + indexation |
| **APM / Traces** | Tempo (self-hosted) | 31 USD/hôte/mois |
| **Coûts d'infrastructure** | Compute + stockage pour la stack | Aucun (SaaS) |
| **Effort opérationnel** | Élevé (upgrades, scaling, HA) | Minimal |
| **Coût annuel typique (50 hôtes)** | 20 000-60 000 USD (infra + ingénierie) | 50 000-150 000 USD |
| **Risque de vendor lock-in** | Faible (OpenTelemetry, PromQL) | Plus élevé (langage de requête propriétaire) |

Sur le papier, la stack open-source paraît moins chère, mais elle exige du temps d'ingénierie dédié pour la maintenance, les upgrades, la planification de capacité et la configuration de haute disponibilité. Le modèle managé de Datadog transfère cet effort vers l'éditeur. L'expérience montre que, pour des équipes de moins de cinq ingénieurs d'infrastructure, les solutions managées ont souvent un coût total inférieur dès lors que l'on intègre le temps d'ingénierie.

Un aspect fréquemment négligé est la facturation high-watermark de Datadog : le nombre d'hôtes est mesuré chaque heure, le 1 % supérieur des heures est écarté, et le pic au 99e percentile sert de base de facturation. Des pics d'auto-scaling temporaires -- par exemple pendant le trafic du Black Friday -- gonflent la facture mensuelle, même une fois les instances déjà terminées.

## Monitoring Kubernetes : profondeur d'intégration comparée

Plus de 80 % des clusters Kubernetes utilisent Prometheus pour la collecte de métriques. Ce sujet est donc pratiquement inévitable dans les entretiens portant sur l'orchestration de conteneurs.

**Prometheus + Grafana** s'intègre nativement via le Helm Chart [kube-prometheus-stack](https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack). Ce chart déploie Prometheus Operator, Alertmanager, node-exporter, kube-state-metrics et des dashboards Grafana préconfigurés en une seule installation :

```bash
# Deploy full monitoring stack on Kubernetes
helm repo add prometheus-community \
  https://prometheus-community.github.io/helm-charts
helm install monitoring prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --create-namespace \
  --set prometheus.prometheusSpec.retention=30d \
  --set prometheus.prometheusSpec.storageSpec.volumeClaimTemplate.spec.resources.requests.storage=50Gi
```

Cette commande déploie une stack de monitoring prête pour la production, avec un stockage persistant et 30 jours de rétention des données. Le [Prometheus Operator](https://prometheus-operator.dev/) utilise des Custom Resource Definitions (ServiceMonitor, PodMonitor) pour configurer les scrape targets de manière déclarative. Les équipes peuvent créer de façon autonome des configurations de monitoring pour leurs services, sans avoir besoin d'accéder à la configuration Prometheus centrale -- un avantage organisationnel considérable dans les grandes entreprises.

**Datadog** déploie un DaemonSet d'agents et un Cluster Agent. Le Cluster Agent prend en charge de manière centralisée la communication avec l'API server de Kubernetes et réduit ainsi la charge sur l'API. La vue Live Containers offre une visibilité en temps réel sur l'état des pods, et l'Orchestrator Explorer visualise les relations entre deployments, services et pods. L'effort d'installation est moindre, mais une dépendance à un service SaaS externe apparaît.

Pour les équipes déjà profondément ancrées dans l'[écosystème Kubernetes](/technologies/devops/interview-questions/kubernetes-basics), l'approche Prometheus-native évite d'introduire une dépendance externe. Les équipes qui privilégient une mise en place rapide avec un effort opérationnel réduit penchent plutôt vers Datadog ou Grafana Cloud.

## OpenTelemetry et neutralité vis-à-vis des éditeurs

[OpenTelemetry](https://opentelemetry.io/docs/) (OTel) s'est imposé comme le standard industriel pour l'instrumentation des applications. En entretien, la question du rôle d'OTel dans le contexte des comparatifs de monitoring est de plus en plus posée.

Prometheus 3.0+ accepte nativement les métriques OTLP, sans qu'un Collector distinct soit nécessaire comme couche intermédiaire. Grafana Alloy, le successeur de Grafana Agent, fait office à la fois d'OTel Collector et de scraper Prometheus. Datadog prend en charge l'ingestion OTLP, mais recommande ses agents propriétaires pour bénéficier de « toutes les fonctionnalités » -- une forme de vendor lock-in soft.

L'importance stratégique d'OTel réside dans le découplage entre l'instrumentation et le choix du backend. Un code applicatif instrumenté avec les SDK OTel peut envoyer des données de télémétrie vers Prometheus, Grafana Cloud, Datadog ou tout autre backend compatible, sans modification de code. Cette flexibilité constitue un argument de poids dans les entretiens de system design, en particulier lorsqu'il est question de stratégies d'observabilité à long terme. Celui qui sait expliquer pourquoi OTLP est préférable aux intégrations propriétaires démontre une vision architecturale.

## Questions d'entretien DevOps fréquentes sur le monitoring et l'observabilité

Les questions suivantes reviennent régulièrement dans les entretiens DevOps et SRE. Chaque réponse met en évidence les concepts que les recruteurs cherchent précisément à évaluer.

**Q : Quelle est la différence entre monitoring, observabilité et alerting ?**

Le monitoring suit des métriques prédéfinies et vérifie des modes de défaillance connus. L'observabilité permet d'investiguer des modes de défaillance inconnus à travers les métriques, les logs et les traces -- les fameux « trois piliers ». L'alerting déclenche des notifications lorsque des conditions franchissent des seuils définis ou des baselines d'anomalie. Le monitoring répond à la question « le système est-il en bonne santé ? », tandis que l'observabilité répond à la question « pourquoi le système n'est-il pas en bonne santé ? ».

**Q : Dans quels scénarios Prometheus est-il un mauvais choix ?**

Prometheus est optimisé pour la fiabilité plutôt que pour la durabilité -- la disponibilité du système de monitoring lui-même est prioritaire. Les scénarios où Prometheus atteint ses limites : le stockage à long terme au-delà de 30 jours (nécessite Thanos, Mimir ou Cortex), les données liées à la facturation exigeant une précision de 100 % (Prometheus peut abandonner des samples sous charge) et les systèmes basés sur des événements qui requièrent une collecte push-based (bien que le Pushgateway existe comme contournement).

**Q : Comment la philosophie « Big Tent » de Grafana influence-t-elle l'architecture d'observabilité ?**

Grafana se connecte à n'importe quelle source de données sans exiger de migration des données. Les équipes peuvent réunir Prometheus, Elasticsearch, CloudWatch et Datadog dans un dashboard unique. Le compromis réside dans la complexité opérationnelle : maintenir plusieurs backends demande davantage d'expertise infrastructure qu'une approche single-vendor. Les recruteurs vérifient si les candidats savent formuler clairement ce trade-off.

**Q : Comment l'alerting basé sur les SLO diffère-t-il entre Prometheus et Datadog ?**

Dans Prometheus, l'alerting basé sur les SLO utilise des recording rules pour précalculer les error budgets et les burn-rate alerts -- l'approche multi-window, multi-burn-rate issue du SRE Book de Google. Datadog propose des widgets SLO et des monitors intégrés qui suivent automatiquement le burn rate. Les deux approches implémentent le même concept, mais Prometheus exige davantage de configuration manuelle, tandis que Datadog fournit un workflow managé. Dans une bonne réponse d'entretien, les fenêtres de burn rate (1h, 6h, 3j) et les taux de consommation de l'error budget devraient être explicitement nommés.

**Q : Quel rôle joue la cardinalité dans le contexte de Prometheus et pourquoi est-elle problématique ?**

La cardinalité désigne le nombre de séries temporelles uniques dans Prometheus. Chaque combinaison d'un nom de métrique et de valeurs de labels génère une série temporelle distincte. Des labels à forte cardinalité -- comme des identifiants utilisateur ou des request IDs -- peuvent faire croître le nombre de séries temporelles de manière exponentielle et dégrader massivement à la fois la mémoire et la performance des requêtes. Les bonnes pratiques incluent la limitation des valeurs de labels, le recours aux recording rules pour la préagrégation et le monitoring de sa propre TSDB Prometheus via `prometheus_tsdb_head_series`.

Pour une préparation approfondie aux thèmes de monitoring, le [module d'entretien Prometheus et monitoring](/technologies/devops/interview-questions/monitoring-prometheus) propose des scénarios supplémentaires accompagnés d'explications détaillées.

## Framework de décision : choisir la bonne stack

| Scénario | Stack recommandée | Justification |
|----------|------------------|------------|
| Startup, moins de 10 ingénieurs | Datadog ou Grafana Cloud | Minimiser l'effort opérationnel |
| Grande organisation avec équipe plateforme | Prometheus + Grafana + Loki | Contrôle total, coût unitaire plus faible à l'échelle |
| Multi-cloud / hybride | Prometheus + Grafana | Neutre vis-à-vis des éditeurs, cohérent entre environnements |
| Secteur à forte contrainte de conformité | Prometheus + Grafana self-hosted | Les données restent dans le datacenter interne |
| Croissance rapide et imprévisible | Grafana Cloud (Mimir managé) | Scale sans gestion d'infrastructure |
| Détection d'anomalies assistée par ML requise | Datadog | Watchdog ne nécessite aucune configuration manuelle |

Le bon choix dépend de trois variables : la taille de l'équipe, la maturité opérationnelle et les contraintes budgétaires. Il n'existe pas de réponse universellement correcte. Les recruteurs attendent des candidats qu'ils raisonnent systématiquement sur les trade-offs, plutôt que de proclamer un unique gagnant.

## Conclusion

- Prometheus est le standard de facto pour la collecte de métriques dans les environnements Kubernetes ; la version 3.x apporte en 2026 le support OTLP natif et des histogrammes natifs stables
- Grafana est une couche de visualisation et non une base de données de métriques -- la stack LGTM (Loki, Grafana, Tempo, Mimir) forme une plateforme d'observabilité open-source complète avec plus de 100 intégrations de sources de données
- Datadog offre la voie la plus rapide vers une observabilité full-stack avec un alerting assisté par ML, mais au prix de coûts plus élevés et d'un vendor lock-in plus marqué
- OpenTelemetry découple l'instrumentation du choix du backend et rend la décision pour un outil donné moins définitive
- La gestion de la cardinalité est un aspect opérationnel critique dans les environnements Prometheus et un sujet d'entretien fréquent
- En entretien, il s'agit de démontrer la capacité à peser systématiquement les trade-offs entre coût, contrôle et complexité, plutôt que de présenter un unique outil comme une solution miracle
- Pour une préparation pratique, le [module de questions d'entretien DevOps](/blog/devops/essential-devops-interview-questions) est recommandé, ainsi que l'approfondissement de thèmes connexes comme les [concepts de pipeline CI/CD](/blog/devops/ci-cd-pipeline-interview-questions-github-actions-gitlab-ci-jenkins)

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/fr/blog/devops/prometheus-vs-grafana-vs-datadog-monitoring-devops-interview