Comment on a brûlé 50 USD en 24h sur l'API Anthropic — et ce qu'on a appris
Comment on a brûlé 50 USD en 24h sur l'API Anthropic — et ce qu'on a appris
SecuAAS | Transparence technique | Avril 2026
Chez SecuAAS, on construit des outils de cybersécurité avec un principe fondateur : la souveraineté des données. Toute notre infrastructure tourne sur OVH Beauharnois, hors juridiction américaine, pour respecter la Loi 25 et éviter le CLOUD Act. On contrôle notre stack. On sait ce qui tourne, où, et combien ça coûte.
Ou du moins, c'est ce qu'on croyait.
Le 8 avril 2026, notre clé API Anthropic a consommé ~50 USD en moins de 24 heures. Ce billet, c'est notre postmortem public — pas pour se flageller, mais parce qu'on pense que les incidents bien documentés font avancer tout le monde.
Ce qui s'est passé
SecuAAS opère une gateway AI interne appelée SecuTools : un service centralisé qui route les requêtes d'inférence vers notre GPU V100S sur OVH, avec Claude comme fallback quand le GPU est indisponible. L'idée est bonne. L'exécution avait trois failles critiques.
Faille #1 : un service avait sa propre clé Claude
Notre plateforme vCISO — un outil d'analyse de posture de sécurité actuellement en développement, non déployé en production — contenait un client HTTP Go qui appelait api.anthropic.com directement, avec sa propre clé API. Ce client existait comme "fallback de secours" si SecuTools était lent ou indisponible.
Important : vCISO n'étant pas en production, aucune donnée client réelle n'a transité vers l'API Anthropic. Les requêtes impliquaient uniquement des données synthétiques de développement. Il n'y a eu aucun impact sur la confidentialité des données.
Résultat côté finances : ~41 CAD de consommation complètement invisible dans nos métriques SecuTools. Et accessoirement, la clé était stockée en clair dans un fichier YAML commité dans Git.
Faille #2 : le fallback silencieux
Trois cron jobs dans vCISO (06h, 07h, 08h EST) analysaient toutes les organisations actives en soumettant des prompts de ~28 000 tokens à SecuTools. Notre GPU gère 16 000 tokens max. Résultat : 98,5% des jobs vCISO routaient vers Claude via fallback automatique — sans alerte, sans limite, sans tracking adéquat.
Faille #3 : une restriction qui ne s'appliquait pas partout
On avait prévu un mécanisme exclude_providers pour bloquer Claude sur certaines clés API. Sauf que ce mécanisme n'était enforced que dans buildChainWithHints() — pas dans buildChain(), le chemin de routing standard. Les jobs avec preferred_ai: claude-sonnet dans leurs métadonnées contournaient la restriction.
Ce qu'on a changé
Architecture : un seul point de sortie vers Anthropic
Avant : 10 namespaces Kubernetes avaient chacun leur propre clé Anthropic.
Après : Zéro. Seul SecuTools conserve une clé. Chaque service passe obligatoirement par la gateway.
C'est la leçon la plus importante. Un service partagé avec accès external doit avoir un seul point d'entrée contrôlé. Pas dix. Un.
Budgets par source avec alertes progressives
On a déployé un système de budget quotidien par source de trafic :
- 50% → log interne
- 80% → notification email
- 90% → header d'avertissement dans les réponses API
- 100% → rejet 429, plus aucune requête
Chaque source (SecuScan, vCISO, SecuEndpoint, etc.) a son propre plafond. Un bug dans une feature n'impacte pas le budget des autres.
Détection d'anomalies proactive
Toutes les 15 minutes, un système vérifie quatre patterns :
- Spike : consommation > 3× la moyenne historique à la même heure
- Drop : une source habituellement active tombe à 0
- Trend : projection linéaire vers le dépassement de budget
- Volume : nombre de jobs anormalement élevé
Tracking des coûts même en cas d'échec
Anthropic facture les tokens d'input même quand la réponse est vide ou erronée. Notre code retournait une erreur avant de comptabiliser le coût dans ces cas. Corrigé : chaque appel retourne maintenant son coût réel, succès ou non.
Fixes ciblés dans vCISO
- Suppression du client Claude direct
PreferredAI: "auto"→"gpu"sur les trois cron jobs- Rate limit sur l'endpoint de trigger manuel (1 par organisation par heure)
- Backoff exponentiel sur le polling (2s → 30s)
Les chiffres finaux
| Métrique | Valeur |
|---|---|
| Coût incident (24h) | ~50 USD (~68 CAD) |
| Coût cumulé SecuTools (44 jours) | 154 CAD |
| Jobs vCISO routés vers Claude | 534 / 542 (98,5%) |
| Clés Anthropic supprimées | 10 namespaces K8s |
| Fichiers modifiés en correctif | 30+ |
Ce qu'on retient pour la suite
La centralisation n'est pas optionnelle. Dès qu'un service externe a un coût à l'usage, un seul chemin d'accès contrôlé doit exister. Pas de "raccourcis" locaux, pas de clés de secours dans les configs.
Le fallback silencieux est un anti-pattern. Quand le GPU échoue et que Claude prend le relais, c'est une décision qui doit être explicite, loggée, et limitée. Un fallback automatique non encadré transforme un problème technique en problème financier.
Les métriques doivent compter les échecs coûteux. Si un provider externe facture même les tentatives ratées, vos métriques de coût doivent le refléter. Un angle mort financier reste un angle mort, même quand tout semble fonctionner.
Budgets par sous-système, pas globaux. Un plafond global sur une clé API ne protège pas contre le scénario où une seule feature consomme tout le budget des autres. La granularité sauve des insomnies.
Pourquoi publier ça ?
SecuAAS est une entreprise de cybersécurité. Notre crédibilité repose sur la rigueur, pas sur la perfection. Les incidents arrivent — ce qui compte, c'est la réponse : détection rapide, analyse des causes racines, mesures structurelles (pas de rustines), et transparence.
On a détecté l'anomalie en moins de 24 heures, identifié 6 causes racines, déployé 10 mesures correctives, et rédigé ce postmortem complet. C'est ça, une culture de la fiabilité.
Si vous construisez une plateforme qui consomme des APIs d'IA générative, on espère que ce billet vous évite quelques surprises sur votre facture.
SecuAAS — Sécurité souveraine, hébergée au Québec
secuaas.com | Scanyze | ConformVault | SecuTools