Le scénario qui pique (et qui arrive vraiment)
Vendredi 18h12. Ton dev pousse un correctif “vite fait” sur un repo. Dans le lot, une clé API OpenAI ou Claude traîne dans un fichier de config. Le repo est public 20 minutes. Ça suffit.
Samedi matin, alerte carte bleue. Lundi, ta facture tokens a explosé. Et là tu comprends le deuxième problème: ce n’est pas juste financier. Si cette clé donnait accès à un projet qui manipule des prompts internes, des fichiers, des assistants, des logs, tu as potentiellement une fuite de données ChatGPT entreprise (ou Claude, ou Azure OpenAI). Confidentialité, responsabilité, et parfois obligations de notification selon ce qui est touché.
Ce cas est devenu industriel: GitHub a des patterns de “secret scanning” dédiés aux clés IA (Anthropic, Azure OpenAI, etc.). Traduction: l’exposition accidentelle est fréquente et détectée à l’échelle. Tu ne gagneras pas en disant “chez nous ça n’arrivera pas”. Tu gagnes en posant un cadre.
Objectif: sécuriser en 60 minutes, sans casser la prod
Tu ne vas pas “tout blinder” en 1 heure. Par contre tu peux réduire fort le risque, tout de suite, avec 6 étapes. Tu ressors avec:
- un inventaire clair des accès (qui a des clés, où, pour quoi faire),
- des règles simples de stockage et de rotation,
- des clés à privilèges minimaux (scopes),
- un filet anti-explosion de facture (budgets, alertes),
- une procédure d’incident courte que tout le monde sait appliquer.
On parle de gouvernance outils IA, pas de paranoia. Et oui, tu peux tracer sans espionner.
Les 2 dégâts immédiats à garder en tête
1) Facturation tokens incident: ça monte tant que la clé vit
Une clé compromise, c’est un robinet ouvert. L’attaquant consomme ton quota. Les fournisseurs eux-mêmes le disent: clé compromise = risque de “charges non autorisées” (côté Claude notamment).
2) Fuite de données: la clé est un passe-partout
Si ta clé permet d’accéder à un projet qui touche des données internes, le sujet devient: quels prompts, quels fichiers, quels résultats ont transité? Même si l’attaquant ne “vole” rien volontairement, il peut provoquer des traitements non autorisés.
Plan en 6 étapes (60 minutes chrono)
Étape 1 (10 min): inventaire express des accès
Tu veux une photo, pas un audit ISO. Prends 10 minutes et produis une liste “assez vraie”:
- Quels fournisseurs: OpenAI API, Anthropic Claude API, Azure OpenAI, Google (Gemini), etc.
- Quels comptes: compte perso d’un dev, compte “company”, compte agence, compte d’un prestataire.
- Où sont les clés: .env local, variables CI/CD, outil d’automatisation, serveur, proxy LLM, CRM, Airtable, Make, n8n, etc.
- Quels usages: POC, prod, reporting, support, enrichissement CRM, génération docs.
- Qui paie: carte perso, carte boîte, facture centralisée, refacturation interne.
Décision dirigeant: tu imposes un owner par “projet API”. Un seul responsable nommé. Pas “l’équipe”. Un nom.
Piège à éviter: le “gateway/proxy LLM” (ex: un service qui centralise les appels et stocke les secrets) peut devenir un point unique de compromission. Même si tes devs sont propres, un coffre à clés mal maîtrisé recrée le risque.
Étape 2 (10 min): règles de stockage (le minimum non négociable)
Tu n’as pas besoin d’un roman. Tu poses 5 règles, applicables aujourd’hui:
- Interdit: clés dans Git, Notion, Google Docs, tickets, Slack/Teams, email.
- Obligatoire: clés dans un secrets manager ou, a minima, dans les variables d’environnement du CI/CD et de l’hébergement.
- Une clé = un usage: pas une clé partagée pour 5 applis “parce que c’est pratique”.
- Pas de clés sur les postes si tu peux éviter. Sinon, durée courte + rotation.
- Accès par rôle: qui peut créer une clé, qui peut la lire, qui peut la révoquer.
Résultat attendu: si une clé fuit, tu sais où elle a pu fuiter. Et tu peux la tuer sans casser 10 produits.
Étape 3 (10 min): rotation immédiate + expiration
Tu fais simple:
- Tu révoques les clés dont tu n’es pas sûr à 100% de l’emplacement.
- Tu recrées des clés propres, par projet, et tu documentes “où c’est stocké”.
Côté Claude, tu peux configurer une expiration à la création (3h, 1 jour, 7 jours, 30 jours, custom, ou “Never” si et seulement si tu gères ça via un secrets manager et rotation).
Décision dirigeant: tu arbitres entre confort et risque. Pour un POC: expiration courte. Pour de la prod: “Never” peut se défendre uniquement si rotation maîtrisée et stockage propre.
Étape 4 (10 min): scopes et permissions (le contrôle le plus rentable)
Le fantasme, c’est “on ne peut pas limiter”. Si, tu peux limiter, et c’est là que tu gagnes gros.
Côté OpenAI API, tu peux définir des permissions de clé (full access, restricted, read-only), y compris par endpoint. Tu peux aussi gérer des scopes plus fins via l’API d’admin (du type lecture de fichiers, etc.).
Ta règle en 3 lignes:
- Dev/test: clés avec droits minimaux, budgets bas.
- Prod: une clé par service, permissions minimales, et idéalement isolation par projet.
- Jamais: une clé “full access” qui traîne dans 4 environnements.
Bonus anti-vol concret: si tu utilises OpenAI API, active une IP allowlist. Même si la clé est volée, les requêtes hors IP autorisées sont rejetées. C’est bête, mais c’est très efficace quand tes workloads sortent d’IP stables (serveurs, CI runners fixes, VPN egress).
Étape 5 (10 min): alerting coûts et garde-fous “facture”
Tu veux détecter en minutes, pas en fin de mois.
- Budgets par projet: fixe des plafonds et des alertes. OpenAI permet des contrôles de budgets/limites/alertes au niveau projet.
- Alertes financières: seuil journalier et seuil horaire si possible (ou via ton monitoring interne).
- Signal simple: “consommation x5 vs moyenne 7 jours” = alerte.
- Kill switch: qui a le droit de désactiver une clé/projet immédiatement.
Si tu veux cadrer plus large la discipline coûts (tokens, licences, dépassements) sans bloquer les équipes, tu peux t’appuyer sur cet article du site: https://jimmymanin.com/blog/budgets-ia-qui-derapent-piloter-tokens-licences-et-depassements-sans-bloquer-tes-equipes.
Étape 6 (10 min): procédure incident (courte, exécutable)
Tu écris une procédure 1 page. Pas un PDF de 40 pages. Objectif: agir vite quand ça arrive.
Déclencheurs:
- augmentation brutale des coûts (facturation tokens incident),
- détection de clé exposée (GitHub secret scanning, alerte interne),
- activité anormale (logs, IP, volumes).
Actions en 15 minutes:
- Révoquer la clé suspecte (et couper les clés liées si doute).
- Bloquer au niveau réseau si possible (IP allowlist, egress).
- Créer une nouvelle clé propre, déployer via secrets manager/CI.
- Geler les déploiements qui pourraient réintroduire la clé (hotfix non contrôlé).
Actions en 24h:
- identifier la source de fuite (commit, log, outil, poste),
- lister les ressources potentiellement exposées (projets, assistants, fichiers, logs),
- ouvrir un ticket “post-mortem” avec 3 correctifs max (pas 25).
Décision dirigeant: qui est “incident commander” (même dans une PME). Sans ça, tout le monde s’agite et personne ne décide.
Checklist dirigeant: API ou interfaces Enterprise? (et comment tracer sans espionner)
Ton arbitrage doit être clair: tout le monde n’a pas besoin d’API. Les API, c’est puissant, mais ça ajoute de la surface d’attaque (secrets, scopes, réseau, budgets, SIEM).
Qui a le droit d’utiliser des API
- Oui si: intégration applicative, automatisation back-office, produit qui appelle un modèle, besoin d’industrialiser.
- Non si: usage individuel “je veux rédiger / résumer / brainstormer”. Dans ce cas, tu privilégies une interface Business/Enterprise.
- Non si: prestataire externe qui veut “ta clé” pour bosser. Les clés ne se prêtent pas. Et côté OpenAI, l’achat/vente/transfert de clés est explicitement interdit contractuellement. Tu fournis un accès propre, traçable, révocable.
Quand privilégier une interface Enterprise
Exemple concret: Microsoft 365 Copilot. Tu gagnes des contrôles “suite” plutôt que de réinventer la roue:
- Purview: labels, DLP.
- Audit logs sur les événements Copilot (prompts/réponses et contenus référencés), utile pour enquêter sans transformer l’entreprise en open-space policier.
Tu traces des événements (qui, quand, quel outil, quel connecteur, quel document référencé), pas “la vie” des gens.
Tracer sans espionner: ta règle de gouvernance
- Tu journalises: utilisateur, appli, horodatage, volume, modèle, coût, source de données (connecteur), statut (succès/erreur).
- Tu évites de stocker le contenu brut des prompts par défaut, sauf besoin légal/qualité clairement justifié.
- Tu actives l’audit là où il existe nativement (ex: écosystème M365) et tu relies ça à ton processus incident.
Si tu veux cadrer plus largement les risques internes (droits, logs, sandbox) autour des agents et usages avancés, ce plan est utile: https://jimmymanin.com/blog/agents-ia-en-entreprise-ton-plan-insider-threat-droits-logs-sandbox-en-90-minutes.
La version “1 heure, pas plus”: ton déroulé minute par minute
- 0:00 à 0:10 Inventaire express: fournisseurs, comptes, clés, usages, payeur, owner.
- 0:10 à 0:20 Règles de stockage: où c’est autorisé, où c’est interdit, et “une clé = un usage”.
- 0:20 à 0:30 Rotation: révocation des clés douteuses + recréation propre + expiration si pertinent.
- 0:30 à 0:40 Scopes/permissions: droits minimaux + séparation dev/prod + IP allowlist si possible.
- 0:40 à 0:50 Budgets/alertes: plafond par projet + alerte sur dérive + kill switch.
- 0:50 à 1:00 Procédure incident: 15 minutes (stopper) + 24h (analyser) + owner incident.
Ce que tu ne feras pas en 60 minutes (et c’est normal)
- Tu ne vas pas “résoudre” la classification data, le RGPD, et l’AI Act en une heure.
- Tu ne vas pas supprimer tout Shadow AI d’un coup. Tu vas réduire le risque, puis itérer.
- Tu ne vas pas obtenir une sécurité parfaite. Tu vises une sécurité rentable: moins de risque, moins de surprise, sans bloquer les équipes.
Pour reprendre la main sur les usages non déclarés sans faire la police, tu peux t’appuyer sur: https://jimmymanin.com/blog/shadow-ai-en-entreprise-7-controles-simples-pour-reprendre-la-main-sans-bloquer-tes-equipes.
Le kit prêt à copier-coller: règles internes “clés API IA”
Règle 1. Toute clé API IA appartient à un projet identifié, avec un owner nommé.
Règle 2. Stockage uniquement dans un secrets manager ou variables chiffrées CI/CD. Jamais dans un repo, doc, ticket, chat.
Règle 3. Une clé par application et par environnement (dev, staging, prod).
Règle 4. Permissions minimales (scopes) et séparation stricte dev/prod.
Règle 5. Budgets et alertes activés par défaut. Seuil de dérive = alerte + droit de coupure.
Règle 6. Incident: révocation immédiate, rotation, analyse cause racine, 3 actions correctives max.
Ta prochaine action (aujourd’hui)
Ouvre un doc interne “Gouvernance outils IA”. Une page. Mets:
- la liste des projets API + owner,
- les 5 règles de stockage,
- les règles de permissions (scopes) et de rotation,
- les alertes coûts et le kill switch,
- la procédure incident en 10 lignes.
Puis fais 20 minutes de revue avec ton responsable IT/dev. Si tu ne peux pas nommer qui détient quelles clés et où elles sont, tu as déjà ton premier chantier. Et tu viens d’éviter, très concrètement, la prochaine fuite et la prochaine facture surprise.
