With PerfectScale™ for Commitments, we're bringing rate optimization to every cloud
Cloud Intelligence™Cloud Intelligence™

Cloud Intelligence™

FinOps as Code : piloter DoiT Cloud Intelligence avec Terraform

By Hannes HayashiJun 25, 202611 min read

Cette page est également disponible en English, Deutsch, Español, Italiano, 日本語 et Português.

Vous versionnez votre infrastructure. Vous relisez les pull requests de votre code applicatif. Mais qu'en est-il de votre configuration FinOps — budgets, allocations de coûts, alertes et rapports analytiques ?

Dans la plupart des équipes, tout cela se passe dans une UI. Quelqu'un clique dans un assistant, fixe un seuil, choisit un filtre, et espère que la personne qui devra le modifier ensuite comprendra l'intention initiale. Pas d'historique, pas de relecture par les pairs, aucun moyen de répliquer la configuration d'un environnement à l'autre. Quand vos pratiques FinOps sont aussi critiques que votre infrastructure, elles méritent la même rigueur.

C'est pourquoi nous avons créé le provider Terraform DoiT. Il fait entrer votre configuration DoiT Cloud Intelligence dans le workflow Infrastructure as Code que vous utilisez déjà pour vos ressources cloud — avec 17 ressources managées et 61 data sources couvrant aussi bien les budgets et les rapports que les requêtes vers l'assistant IA ou les diagrammes d'infrastructure cloud.

Premiers pas

Pour démarrer, un bloc provider et une clé API suffisent :

terraform {
  required_providers {
    doit = {
      source  = "doitintl/doit"
      version = "~> 1.0"
    }
  }
}


provider "doit" {}

Définissez DOIT_API_TOKEN dans votre environnement (les clés API se créent depuis la DoiT Console), et c'est parti. Aucune configuration supplémentaire n'est requise.

Le workflow FinOps de base

Passons en revue les ressources que la plupart des équipes adoptent en premier : allocations, budgets, alertes et rapports. Ensemble, elles forment un pipeline FinOps complet — et les gérer as code permet de versionner, relire et répliquer l'ensemble de la configuration.

Allocations de coûts

Les allocations permettent de découper vos dépenses cloud en catégories pertinentes. Le provider prend en charge un moteur de formules booléennes pour combiner des critères de filtrage, des allocations groupées qui répartissent les coûts dans des compartiments nommés, et même des allocations imbriquées qui en référencent d'autres par ID.

Voici une allocation groupée qui répartit les coûts par région, avec un fourre-tout pour ce qui ne correspond à aucun critère :

resource "doit_allocation" "by_region" {
  name              = "By Region"
  description       = "Group costs by geographic region"
  unallocated_costs = "Other Regions"
  rules = [
    {
      action  = "create"
      name    = "US"
      formula = "A"
      components = [{
        key = "country", mode = "is", type = "fixed", values = ["US"]
      }]
    },
    {
      action  = "create"
      name    = "Europe"
      formula = "A"
      components = [{
        key = "country", mode = "is", type = "fixed", values = ["DE", "FR", "GB", "NL"]
      }]
    }
  ]
}

Besoin d'une granularité plus fine ? Utilisez type = "allocation_rule" dans un composant pour référencer une allocation existante — vous composez ainsi des allocations à partir d'autres, jusqu'à 3 niveaux de profondeur. Plutôt que de coder en dur des valeurs de dimension comme "US" ou "DE", la data source doit_dimension vous permet de découvrir dynamiquement les valeurs valides depuis l'API.

Budgets

Les budgets sont vos garde-fous. Le provider permet de définir des alertes multi-seuils, de cadrer les budgets sur des allocations ou dimensions précises et — voici un schéma utile — de filtrer les collaborateurs par fonction plutôt que d'ajouter tous les utilisateurs de l'organisation :

data "doit_users" "all" {}


locals {
  engineers = [
    for u in data.doit_users.all.users : u
    if u.job_title == "Software / Ops Engineer"
  ]
}


resource "doit_budget" "eng_budget" {
  name          = "Engineering Budget"
  currency      = "USD"
  type          = "recurring"
  amount        = 10000
  time_interval = "month"
  start_period  = provider::time::rfc3339_parse("2026-01-01T00:00:00Z") * 1000


  alerts = [
    { percentage = 50 },
    { percentage = 80 },
    { percentage = 100 }
  ]


  collaborators = concat(
    [{ email = data.doit_current_user.me.email, role = "owner" }],
    [for u in local.engineers : { email = u.email, role = "viewer" }]
  )


  recipients = [for u in local.engineers : u.email]


  scopes = [{
    type   = "allocation_rule"
    id     = "allocation_rule"
    mode   = "is"
    values = [doit_allocation.by_region.id]
  }]
}

Ce budget est cadré sur l'allocation par région que nous venons de créer, et ne notifie que les utilisateurs dont l'intitulé de poste est Software / Ops Engineer. Les budgets prennent aussi en charge seasonal_amounts pour les mois où vos objectifs de dépenses varient, et des champs calculés comme current_utilization et forecasted_utilization sont exposés en lecture seule.

Alertes

Les alertes déclenchent des notifications dès qu'un coût ou un usage franchit un seuil. Toute leur puissance tient au cadrage : vous pouvez restreindre une alerte à un fournisseur cloud, un service, une région ou n'importe quelle dimension. L'exemple ci-dessous utilise la data source doit_products pour rechercher dynamiquement l'ID du service Compute Engine plutôt que de le coder en dur :

data "doit_products" "gcp" {
  platform = "google_cloud_platform"
}


resource "doit_alert" "compute_cost" {
  name = "GCP Compute Cost Alert"
  config = {
    metric        = { type = "basic", value = "cost" }
    time_interval = "day"
    value         = 500
    currency      = "USD"
    condition     = "value"
    operator      = "gt"
    scopes = [{
      type   = "fixed"
      id     = "service_description"
      mode   = "is"
      values = [
        for p in data.doit_products.gcp.products : p.id
        if p.display_name == "Compute Engine"
      ]
    }]
  }
  recipients = [data.doit_current_user.me.email]
}

Rapports

Les rapports Cloud Analytics sont la ressource la plus riche du provider. Vous pouvez configurer jusqu'à 4 métriques, ajouter des comparaisons d'une année sur l'autre avec secondary_time_range, appliquer des filtres et des dimensions de regroupement, et organiser les rapports en dossiers.

resource "doit_report" "monthly_costs" {
  name        = "Monthly Cost Report"
  description = "Tracks monthly costs across cloud providers with YoY comparison"
  config = {
    metrics = [
      { type = "basic", value = "cost" },
      { type = "basic", value = "usage" }
    ]
    aggregation   = "total"
    time_interval = "month"
    data_source   = "billing"
    time_range = {
      mode            = "last"
      amount          = 3
      include_current = true
      unit            = "month"
    }
    secondary_time_range = {
      amount = 1, unit = "year", include_current = false
    }
    filters = [{
      id = "cloud_provider", type = "fixed", mode = "is"
      values = ["amazon-web-services", "google-cloud"]
    }]
    group = [{ id = "cloud_provider", type = "fixed" }]
    layout         = "table"
    display_values = "actuals_only"
    currency       = "USD"
  }
}

Pour découvrir les IDs et types de dimensions valides pour vos filtres et regroupements, la data source doit_dimensions fournit un catalogue complet — fini les approximations.

Au-delà du FinOps

Les ressources FinOps de base sont le point de départ de la plupart des équipes, mais le provider couvre une part bien plus large de la plateforme DoiT. Certaines fonctionnalités, vous ignorez peut-être même qu'elles existent dans la console — et les gérer as code est un excellent moyen de les découvrir.

Interroger Ava depuis Terraform

Oui, vous pouvez interroger Ava — l'assistant IA de DoiT — directement depuis votre configuration Terraform. Particulièrement pratique : vous pouvez référencer dans votre prompt des IDs de rapports issus d'autres ressources Terraform :

data "doit_ava" "report_summary" {
  question = "Can you summarize report ${doit_report.monthly_costs.id} for me?"
}


output "report_summary" {
  value = data.doit_ava.report_summary.answer
}

Créez un rapport, puis demandez immédiatement à Ava de l'expliquer — le tout dans le même terraform apply. Vous pouvez aussi l'utiliser pour des recherches rapides du type Quels sont mes 3 principaux services cloud par coût ce mois-ci ? et rediriger la réponse vers des outputs Terraform.

Requêtes analytiques ad hoc

Parfois, vous n'avez pas besoin d'un rapport persistant — vous voulez juste répondre à une question. La data source doit_report_query exécute des requêtes Cloud Analytics à la volée et renvoie du JSON structuré que vous pouvez parser, transformer ou exporter :

data "doit_report_query" "cost_by_provider" {
  config = {
    metrics       = [{ type = "basic", value = "cost" }]
    aggregation   = "total"
    time_interval = "month"
    currency      = "USD"
    time_range = {
      mode = "last", amount = 3, include_current = true, unit = "month"
    }
    group = [{ id = "cloud_provider", type = "fixed" }]
  }
}


locals {
  result  = jsondecode(data.doit_report_query.cost_by_provider.result_json)
  columns = [for s in local.result.schema : s.name]
}


resource "local_file" "query_csv" {
  filename = "cost_by_provider.csv"
  content = join("\n", concat(
    [join(",", local.columns)],
    [for row in local.result.rows :
      join(",", [for cell in row : cell == null ? "" : tostring(cell)])]
  ))
}

C'est particulièrement utile pour des gates de coûts en CI/CD : lancez une requête pendant votre pipeline, vérifiez si la dépense dépasse un seuil et faites échouer le build le cas échéant. La data source doit_report_result permet aussi de récupérer les résultats de rapports déjà enregistrés.

Cloud Diagrams en flowcharts Mermaid

Le provider inclut 12 data sources pour la fonctionnalité Cloud Diagrams, couvrant la recherche, l'export, les relations, les snapshots et les statistiques. Un cas d'usage créatif : générer des flowcharts Mermaid à partir de la topologie de votre infrastructure cloud, à intégrer directement dans des READMEs, des pages Confluence ou des rapports d'incident.

data "doit_cloud_diagrams_search" "project" {
  query = "my-gcp-project"
}


data "doit_cloud_diagrams_schemes" "diagram" {
  layer_ids  = [data.doit_cloud_diagrams_search.project.scheme[0].ss_id]
  components = true
  link       = true
}


locals {
  ss = data.doit_cloud_diagrams_schemes.diagram.statussheet[
    data.doit_cloud_diagrams_search.project.scheme[0].ss_id
  ]


  node_lines = [
    for id, n in local.ss.node :
    "  ${id}[\"${replace(coalesce(n.name, id), "\"", "#quot;")}\"]"
  ]


  edge_lines = [
    for id, l in local.ss.link :
    l.connection_type != null
    ? "  ${l.origin._id} -->|${l.connection_type}| ${l.destination._id}"
    : "  ${l.origin._id} --> ${l.destination._id}"
  ]


  mermaid = join("\n", concat(["flowchart LR"], local.node_lines, local.edge_lines))
}


output "mermaid" {
  value = local.mermaid
}

Collez la sortie dans mermaid.live ou dans n'importe quel rendu Markdown pour obtenir une représentation visuelle des relations de votre infrastructure : diffs de topologie dans le temps, snapshots de conformité, ou simplement un aperçu rapide de ce qui est connecté à quoi.

Partage et contrôle d'accès

Gérer qui peut voir vos ressources FinOps passe souvent au second plan — jusqu'au jour où cela devient un problème. La ressource doit_sharing permet de définir les permissions sur les rapports, budgets, alertes et allocations :

locals {
  permissions = [
    { user = data.doit_current_user.me.email, role = "owner" },
    { user = "[email protected]",               role = "editor" },
    { user = "[email protected]",             role = "viewer" },
  ]
}


resource "doit_sharing" "report" {
  resource_type = "reports"
  resource_id   = doit_report.monthly_costs.id
  permissions   = local.permissions
  public        = "viewer"  # Grant org-wide read access
}

Définissez vos ensembles de permissions une seule fois dans locals et appliquez-les uniformément à chaque ressource partagée. Associez cela à doit_user pour intégrer de nouveaux membres et à doit_roles pour découvrir les rôles disponibles — le tout depuis votre configuration Terraform.

Annotations et labels

Vous est-il déjà arrivé d'observer un pic de coûts datant de six mois en vous demandant ce qui s'était passé ? Les annotations permettent de documenter les événements de coût — déploiements, migrations, incidents — directement sur vos données de coût :

resource "doit_label" "infrastructure" {
  name  = "infrastructure"
  color = "blue"
}


resource "doit_annotation" "black_friday" {
  content   = "AWS cost spike due to Black Friday traffic"
  timestamp = "2024-11-29T00:00:00Z"
  reports   = [doit_report.monthly_costs.id]
  labels    = [doit_label.infrastructure.id]
}

Les labels et leurs assignations offrent un étiquetage transversal : catégorisez rapports, alertes et annotations par équipe, projet ou toute taxonomie qui a du sens pour votre organisation.

Organiser à grande échelle avec les dossiers

À mesure que votre configuration FinOps gérée par Terraform grandit, les dossiers gardent l'ordre. Ils acceptent l'imbrication et fonctionnent aussi bien avec les rapports qu'avec les allocations :

resource "doit_folder" "analytics" {
  name        = "Analytics"
  description = "Cloud Analytics reports and dashboards"
}


resource "doit_folder" "cost_reports" {
  name             = "Cost Reports"
  description      = "Monthly and quarterly cost breakdowns"
  parent_folder_id = doit_folder.analytics.id
}


resource "doit_report" "monthly_costs" {
  name      = "Monthly Cost Overview"
  folder_id = doit_folder.cost_reports.id
  # ... report config ...
}

Vous pouvez aussi habiller vos analyses aux couleurs de votre marque grâce aux thèmes personnalisés : définissez des palettes en mode clair et sombre qui s'appliquent aux graphiques des rapports Cloud Analytics, pour des dashboards soignés et alignés sur votre identité.

Onboarding AWS CloudConnect

Connecter des comptes AWS à DoiT se fait en général en plusieurs étapes : créer un rôle IAM, configurer un bucket S3, enregistrer le compte. Nous avons publié un module Terraform dédié qui orchestre toute la stack en un seul terraform apply :

module "doit_cloudconnect" {
  source  = "doitintl/doit-cloudconnect/aws"
  version = "~> 1.0"
}

Le module crée le rôle IAM, le bucket S3 et l'enregistrement CloudConnect d'un seul coup. Pour les entreprises qui intègrent des dizaines de comptes, utilisez-le avec for_each sur une liste de comptes. Si vous avez besoin de plus de contrôle, la ressource sous-jacente doit_cloudconnect_aws_account reste disponible pour un usage direct.

Insights personnalisés

Si vous exécutez vos propres vérifications d'optimisation — recherche de ressources inutilisées, identification d'opportunités de right-sizing, signalement de problèmes de sécurité — vous pouvez publier vos résultats directement dans la console DoiT :

resource "doit_insight" "unused_instances" {
  key               = "unused-ec2-instances"
  title             = "Unused EC2 Instances"
  short_description = "EC2 instances with consistently low CPU utilization"
  cloud_provider    = "aws"
  categories        = ["FinOps"]
}

Associez cela à doit_insight_resource_results pour attacher des résultats par ressource, et votre moteur d'optimisation personnalisé fait remonter ses constats aux côtés des insights natifs de DoiT.

Le modèle de composabilité

À travers tous ces exemples, un fil rouge se dégage : les data sources sont le ciment. Au lieu de coder en dur des IDs de dimension, des noms de service ou des emails d'utilisateurs, vous les découvrez au moment du plan :

data "doit_dimensions" "all" {}


locals {
  dimension_types = { for id, types in {
    for d in data.doit_dimensions.all.dimensions : d.id => d.type...
  } : id => types[0] }
}

Cette table de correspondance des dimensions est réutilisable dans les rapports, budgets, alertes et allocations — écrivez-la une fois, puis référencez local.dimension_types["region"] partout. Dans le même esprit, doit_current_user élimine les emails codés en dur, doit_products repère les valeurs valides pour les filtres de service et doit_platforms liste les fournisseurs cloud disponibles pour votre organisation.

Activement développé et open source

Le provider a connu 5 versions mineures durant les quatre mois qui ont suivi le lancement de la v1.0 en février 2026, chacune apportant son lot de nouvelles ressources et data sources. Parmi les ajouts récents : la prise en charge de Cloud Diagrams, les thèmes de console personnalisés, la gestion des dossiers, le partage et le contrôle d'accès, l'onboarding AWS CloudConnect et la data source Ava AI.

Si vous êtes encore sur une release v0.x, c'est le moment idéal pour migrer. Les versions v0.x étaient une preview technique — la branche v1.x est la ligne stable et prête pour la production, avec une migration d'état automatique pour une transition en douceur. Consultez le guide de mise à niveau v1.0.0 pour les instructions de migration.

Le provider est open source sur github.com/doitintl/terraform-provider-doit. Issues, demandes de fonctionnalités et contributions sont les bienvenues. Chaque ressource dispose de tests d'acceptation exécutés contre la véritable API DoiT, et le module CloudConnect AWS est le premier d'une série de modules de plus haut niveau qui composeront les ressources du provider en patterns prêts à l'emploi.

Lancez-vous

  1. Installez le provider depuis le Terraform Registry
  2. Créez une clé API
  3. Parcourez la documentation complète pour les détails de schéma et d'autres exemples
  4. Mettez une étoile au dépôt GitHub et dites-nous ce que vous aimeriez voir ensuite

Vos pratiques FinOps méritent le même versionnage, la même relecture par les pairs et la même reproductibilité que votre infrastructure. Essayez le provider et faites passer votre cloud intelligence sous code.