La mauvaise surprise sur la facture cloud suit toujours le même scénario : le mois se termine, la facture arrive, le montant est plus élevé que prévu et l'enquête commence. À ce moment-là, la ressource qui s'est emballée facture depuis des semaines. Les alertes servent à réduire ce délai, mais elles ne fonctionnent que si elles préviennent tôt, la bonne personne, avec quelque chose de concret à faire. Dans cet article, nous montrons comment les mettre en place avec AAA Sentinel et avec les budgets natifs de chaque cloud, qui se complètent.
Le problème : une seule alerte, et trop tard
Beaucoup d'équipes ont, au mieux, une notification quand les dépenses du mois atteignent le budget. Quand elle arrive, le mois est dépensé et il ne reste qu'à expliquer ce qui s'est passé. D'autres reçoivent des alertes dans une boîte que personne ne lit, ou tellement d'alertes que l'équipe a appris à les ignorer.
Une seule alerte à 100 % du budget, c'est une alarme qui ne sonne qu'une fois le cambriolage terminé.
Ce que vous y gagnez
Avec des alertes réparties en couches :
- Vous voyez un pic de dépenses au scan suivant, pas sur la facture.
- Chaque alerte arrive là où l'équipe travaille : e-mail, Slack ou votre propre système.
- Ce qui doit être corrigé finit en ticket Jira ou Linear, avec un responsable et une priorité.
- Ceux qui n'ont pas besoin du détail reçoivent un résumé quotidien ou hebdomadaire au lieu de chaque alerte.
D'abord : AAA Sentinel ne remplace pas les budgets de votre cloud
Soyons clairs : AAA Sentinel n'a pas de budgets cloud. Il ne fixe pas de plafond mensuel par compte et ne prévient pas à 80 % d'un montant. Les budgets qu'il gère sont ceux de l'IA, ce qui est une autre histoire. Pour le plafond mensuel, utilisez le budget natif de chaque fournisseur, qui dispose des données de facturation de première main. AAA Sentinel apporte ce que le budget ne voit pas : les hausses entre deux scans, les nouveaux constats qui expliquent la hausse, les anomalies par service et un seul endroit pour alerter sur les trois clouds.
La stratégie en trois couches
Voici la combinaison que nous recommandons :
- Couche 1 · Le plafond du mois : un budget natif dans chaque cloud, avec des alertes sur les dépenses prévues et réelles (par exemple à 80 % prévu et à 100 % réel). Il vous dit si le mois est en passe de déraper.
- Couche 2 · Les écarts : l'alerte de pics de dépenses d'AAA Sentinel, qui compare chaque scan au précédent, et le rapport d'anomalies, qui descend au niveau de chaque service.
- Couche 3 · Les causes : les alertes de nouveaux constats critiques ou à priorité élevée, qui arrivent avec la ressource concernée et peuvent ouvrir un ticket toutes seules.
Couche 1 : les budgets natifs de chaque cloud
Les trois fournisseurs procèdent de façon similaire :
- AWS : AWS Budgets, dans Billing and Cost Management. Des budgets de coût par compte, service ou tag, avec des alertes sur les dépenses réelles ou prévues par e-mail ou Amazon SNS. Pour les pics inattendus, AWS Cost Anomaly Detection s'appuie sur l'apprentissage automatique et prévient par les mêmes moyens.
- Azure : Cost Management → Budgets. Par abonnement ou groupe de ressources, avec des conditions d'alerte sur le coût réel ou prévu, qui envoient un e-mail ou déclenchent un groupe d'actions. Cost Management propose aussi des alertes d'anomalies par abonnement.
- Google Cloud : Facturation → Budgets et alertes. Des règles de seuil sur les dépenses réelles ou prévues (50, 90 et 100 % par défaut), avec un e-mail aux administrateurs de facturation et Pub/Sub si vous voulez automatiser quelque chose.
Un budget prévient, il n'arrête pas la dépense. Pour une réaction automatique, AWS Budgets propose des actions de budget, Azure peut déclencher un groupe d'actions et, sur Google Cloud, on la programme à partir du message Pub/Sub.
Comment fonctionnent les alertes d'AAA Sentinel
Les alertes sont générées dans les plans Pro et Business, à la fin de chaque scan de chaque compte. Dans ces plans, le scan est automatique et quotidien : en pratique, la plateforme vérifie chaque compte une fois par jour. Voici ce qui peut déclencher une alerte :
AAA Sentinel · ce qui déclenche chaque alerte
- Pics de dépenses
- Le coût relevé par le scan augmente par rapport au scan précédent d'au moins le seuil fixé, et dépasse la dépense minimale. Sévérité élevée, ou critique si la hausse atteint 50 %
- Nouvelles détections critiques
- Le scan apporte au moins un nouveau constat (ou c'est le premier du compte) : une alerte avec les constats critiques
- Nouvelles détections à priorité élevée
- Même principe, avec les constats à priorité élevée et les économies qu'ils représentent
- Hausse du coût unitaire
- Alerte mensuelle si le coût par unité métier augmente (plan Business, nécessite des métriques métier)
- Nouveaux constats de sécurité et Baisse du Security Score
- Alertes du scan de posture de sécurité
- Chaque alerte est conservée dans Alertes pendant 90 jours, qu'elle ait été envoyée à un canal ou non.
- Les connexions IA utilisent les mêmes interrupteurs : un pic de dépenses IA ou un budget IA presque épuisé arrive aussi sous forme d'alerte.
Cas pratique : ACME
ACME, une entreprise fictive au plan Pro, a trois comptes connectés : sa boutique sur AWS, un abonnement Azure et un projet Google Cloud. Elle veut être prévenue dans la journée de toute hausse sérieuse et que ce qui est actionnable finisse dans Jira. Voici sa configuration :
ACME · configuration des alertes
- Activé : arrive à l'adresse de la personne qui enregistre la configuration
- Slack
- Webhook du canal #finops-alertes
- Seuil de pic de dépenses
- 25 %
- Dépenses minimales pour alerter
- 100 USD/mois
- Résumé périodique
- Hebdomadaire, le lundi à 07:00 UTC
- Jira
- Projet FINOPS, alertes de sévérité Élevé ou supérieur
- AWS Budgets (dans AWS)
- 6 000 USD/mois, alerte à 80 % prévu et à 100 % réel
Étape 1 : connecter les canaux
Tout se configure dans Alertes → Canaux d'alerte, que seuls le propriétaire et les administrateurs peuvent modifier. Chaque canal a son bouton de test : utilisez-le avant de considérer quoi que ce soit comme acquis.
- E-mail : il s'active d'un interrupteur et envoie à l'adresse avec laquelle la personne qui enregistre la configuration se connecte à AAA Sentinel.
- Slack : sur api.slack.com/apps, créez une app, activez Incoming Webhooks, cliquez sur « Add New Webhook to Workspace », choisissez le canal et copiez l'URL, qui commence par hooks.slack.com. Collez-la dans « URL Webhook Slack » et cliquez sur « Tester le webhook ».
- Microsoft Teams : dans le canal, ouvrez Plus d'options → Workflows, choisissez le modèle « Envoyer des alertes de webhook à un canal », confirmez l'équipe et le canal, enregistrez et copiez l'URL. Elle contient une signature : traitez-la comme un mot de passe. Les URL des anciens connecteurs Office 365 (webhook.office.com) sont refusées, car Microsoft les a désactivés en mai 2026.
- Webhook générique : une URL HTTPS publique (les adresses de réseau interne sont refusées) qui reçoit un POST JSON avec le type, la sévérité, le titre, le message, le compte et le scan. S'il vous faut une signature, les webhooks de Developer → Applications OAuth2 émettent l'événement alert.triggered avec l'en-tête X-Sentinel-Signature.
Étape 2 : régler les seuils de détection
Sur la même page, le bloc Seuils de détection décide quand une alerte vaut la peine :
- Seuil de pic de dépenses : entre 5 et 100 %, par pas de 5 ; 20 % par défaut.
- Dépenses minimales pour alerter : de 0 à 1 000 USD/mois ; 5 par défaut. Évite les alertes sur des comptes presque vides.
- Hausse du coût unitaire : entre 5 et 100 % ; 20 % par défaut. Ne s'applique que si vous utilisez le coût unitaire.
- Notifier lors de la détection : un interrupteur par type (Nouvelles détections critiques, Nouvelles détections à priorité élevée, Pics de dépenses, Nouveaux constats de sécurité, Baisse du Security Score et Hausse du coût unitaire). Tous sont activés par défaut.
Sur AWS, sur Azure et sur Google Cloud avec l'export de facturation, le coût que lit chaque scan est le cumul du mois en cours. Pour que cette croissance naturelle ne ressemble pas à un pic, AAA Sentinel compare le rythme quotidien de dépense de chaque scan, projeté sur le mois complet, ce qui évite aussi qu'un changement de mois ressemble à une baisse. Pendant les trois premiers jours du mois, la base est insuffisante et les pics ne sont pas évalués, de même que lorsqu'un des deux scans utilise des coûts estimés et l'autre des coûts réels.
Étape 3 : le résumé périodique
Tout le monde n'a pas besoin de chaque alerte. Le Résumé périodique est un e-mail quotidien ou hebdomadaire (vous choisissez le jour de la semaine et l'heure d'envoi, en UTC) avec le coût du dernier scan, les constats, les économies potentielles et le nombre d'alertes critiques et élevées de la période. Il est envoyé par compte, et seulement si au moins un scan s'est terminé sur la période. ACME le programme le lundi à 07:00 UTC pour la direction, et garde les alertes en temps réel pour l'équipe plateforme.
Étape 4 : de l'alerte au ticket
Le 14, le scan du compte AWS d'ACME relève 3 100 USD contre 2 400 USD au scan précédent : une hausse de 29 %. Comme elle dépasse 25 % et le minimum de 100 USD, un pic de dépenses de sévérité élevée se déclenche. Voici la suite :
- L'alerte arrive par e-mail et dans #finops-alertes, avec un lien vers la plateforme.
- Comme Jira est configuré pour la sévérité Élevé ou supérieur, un ticket est créé dans le projet FINOPS avec la priorité correspondante et le label finops-sentinel. Linear fonctionne de la même façon. Les deux se configurent dans Alertes → Intégrations, chacun avec son bouton « Tester la connexion ».
- Sur la page Alertes, l'équipe la voit avec les autres, peut filtrer par sévérité ou par compte et la marque comme lue une fois examinée.
- Depuis un constat précis, vous pouvez aussi ouvrir le ticket à la main, sans attendre d'alerte.
Étape 5 : Anomalies, pour savoir quel service est en cause
Une hausse de 29 % dit que quelque chose a changé, pas quoi. Avec le plan Business, Rapports → Anomalies compare les deux derniers scans de chaque compte, service par service, et détecte quatre types d'anomalie :
- Pic ou chute de dépenses du compte : plus de 15 % et plus de 5 USD d'écart.
- Nouveau service : un service absent jusque-là qui apparaît avec plus de 10 USD.
- Pic sur un service existant : plus de 25 % et plus de 5 USD de hausse.
- Chaque anomalie peut être marquée comme examinée, écartée ou rouverte. Les anomalies écartées ne comptent pas dans l'Impact total.
Ce sont des règles fixes appliquées à la comparaison entre scans, pas un modèle d'apprentissage automatique, et le rapport est calculé à l'ouverture : il n'envoie pas d'alertes. Pour ACME, il aurait montré que la hausse venait presque entièrement d'Amazon EC2.
Ce qu'il ne fait pas encore
Pour que vous sachiez où sont les limites :
- Il n'a pas de budgets cloud ni d'alertes en pourcentage d'un budget : c'est le rôle d'AWS Budgets, des budgets d'Azure Cost Management et de ceux de Google Cloud.
- Il ne détecte pas les pics au cours de la journée : il compare un scan au précédent, normalement une fois par jour.
- La configuration des canaux et des seuils est commune à toute l'organisation ; si vous gérez des clients avec le plan Business, chaque client peut avoir la sienne.
- Les seuils du rapport d'anomalies sont fixes ; ceux des Seuils de détection ne concernent que les alertes.
Checklist pour démarrer
Avec ces éléments en place, la facture de fin de mois n'est plus le premier avertissement.
- Un budget natif dans chaque cloud, avec une alerte sur les dépenses prévues et une sur les dépenses réelles.
- Plan Pro ou Business, avec les comptes connectés et scannés chaque jour.
- Au moins un canal testé dans Canaux d'alerte : e-mail, Slack ou webhook.
- Un seuil de pic et une dépense minimale adaptés à vos dépenses, pour que chaque alerte ait un sens.
- Le résumé périodique pour ceux qui n'ont pas besoin de chaque alerte.
- Jira ou Linear connecté dans Intégrations pour que l'important finisse en ticket.
- Avec Business, le rapport Anomalies consulté après chaque pic.