Le choix entre une stack observabilité auto-hébergée et une plateforme SaaS se discute souvent comme une question de principe (contrôle contre confort), ce qui masque le vrai calcul : un coût total de possession, où chaque option déplace la dépense vers un poste différent.
Ce que le SaaS facture réellement
Les plateformes SaaS d’observabilité (Datadog, New Relic, et d’autres) facturent presque toujours à l’ingestion : par hôte surveillé, par volume de métriques, par giga-octet de logs indexés, ou une combinaison des trois. Ce modèle a une conséquence directe et souvent sous-estimée : le coût croît avec le volume de données observées, indépendamment du volume de trafic métier ou du nombre de développeurs qui l’utilisent. Ajouter une dimension à une métrique (une nouvelle valeur de label, un service supplémentaire instrumenté) augmente la facture du mois suivant, ce qui crée une pression discrète mais réelle à sous-instrumenter pour contenir les coûts.
Ce que l’auto-hébergé facture réellement
Une stack Prometheus/Grafana auto-hébergée déplace ce coût vers deux postes différents : l’infrastructure qui fait tourner Prometheus, Grafana et le stockage long terme (Thanos, Mimir, ou une simple rétention étendue), et le temps d’exploitation, qui n’est jamais nul. Quelqu’un doit dimensionner le stockage, gérer les montées de version, arbitrer la cardinalité des métriques avant qu’elle n’explose la consommation mémoire, et répondre quand la stack de monitoring elle-même tombe en panne, un incident d’un genre particulier : celui qui empêche de voir les autres incidents.
Le calcul qui tranche
Le SaaS gagne presque toujours en dessous d’un certain volume : pour une infrastructure de quelques dizaines de services, le temps d’ingénieur nécessaire pour opérer correctement une stack auto-hébergée dépasse largement ce qu’une facture SaaS proportionnée coûterait. L’auto-hébergé gagne à mesure que le volume grandit, parce que son coût marginal par métrique supplémentaire tend vers zéro (de la capacité de calcul et de stockage déjà provisionnée) là où le coût marginal SaaS reste linéaire, voire s’aggrave sur les paliers de tarification élevés. Le point de bascule dépend moins du nombre de serveurs que du temps d’ingénieur déjà disponible en interne pour l’exploitation : une équipe qui a déjà la compétence Kubernetes/Prometheus paie un coût marginal d’exploitation bien plus faible qu’une équipe qui devrait l’acquérir spécifiquement pour ce projet.
Le coût caché du SaaS que le tableau de prix ne montre pas
Une dépendance à un fournisseur SaaS pour l’observabilité crée un risque spécifique : si la facture devient un sujet de négociation budgétaire, l’option la plus simple à court terme est de réduire la rétention ou la granularité des métriques, ce qui dégrade silencieusement la capacité à diagnostiquer un incident, précisément au moment où l’organisation cherche à réduire les coûts (souvent un signe de tension plus large). L’auto-hébergé n’élimine pas ce risque, mais le déplace : réduire un budget d’infrastructure de monitoring est une décision plus visible, généralement arbitrée en connaissance de cause plutôt que par ajustement automatique d’un plan tarifaire.
Une troisième voie : hybride par criticité
Peu d’organisations tranchent entièrement d’un côté. Une approche pragmatique fréquente : auto-hébergé pour les métriques à fort volume et faible valeur unitaire (métriques d’infrastructure, logs applicatifs verbeux), SaaS pour un périmètre restreint à très haute valeur (surveillance externe, alerting critique avec garantie de disponibilité contractuelle que l’équipe ne veut pas porter elle-même). Cette segmentation demande de connaître le coût réel de chaque option sur son propre volume, pas une préférence générale pour l’un ou l’autre modèle.
À retenir
Le choix entre observabilité auto-hébergée et SaaS se tranche sur un coût total de possession, pas sur une préférence idéologique. Le SaaS facture l’ingestion et croît linéairement avec le volume ; l’auto-hébergé facture l’infrastructure et le temps d’exploitation, avec un coût marginal qui tend vers zéro à volume élevé si la compétence est déjà en place. Le bon calibrage de ce calcul, avant de s’engager sur l’un ou l’autre, fait partie de ce qui se pose dès le diagnostic d’une mission de fiabilité et observabilité.