
Ce qui s’est passé
Plusieurs incidents survenus en novembre 2026 montrent une même tendance. Les clés d’API (codes secrets qui permettent à un logiciel d’utiliser un service payant en votre nom) liées aux services d’intelligence artificielle sont devenues une cible de choix. Une clé volée se transforme très vite en argent.
Railway : environ 740 000 $ de frais non autorisés
Railway, une plateforme d’hébergement infonuagique pour applications, rapporte que des clés d’IA appartenant à ses clients ont été volées. Selon l’entreprise, ces clés ont ensuite servi à consommer des services d’IA, pour des frais non autorisés estimés à environ 740 000 $ US. Le schéma est simple : l’attaquant ne paie rien et la facture arrive au titulaire légitime de la clé.
Fireworks AI : une brèche plus large que prévu
Fireworks AI, un fournisseur de plateforme d’exécution de modèles d’IA, a confirmé que sa brèche est plus étendue qu’annoncé au départ. Selon l’entreprise, elle touche des jeux de données de clients, des poids de modèles (les paramètres qui constituent un modèle d’IA entraîné) et des conversations de Notion AI. Ce n’est donc plus seulement une question de facturation : des données d’affaires sont exposées.
Des agents de codage qui publient des secrets sur GitHub
Des recherches publiées ce mois-ci montrent que les agents de codage par IA (assistants qui écrivent et soumettent du code de façon semi-autonome) ont exposé des milliers de secrets dans des dépôts GitHub. Il s’agit de mots de passe, de jetons et de clés d’API. Si un agent a accès à un fichier contenant des identifiants, il peut l’inclure dans le code qu’il publie, sans que personne ne s’en aperçoive.
Git : une faille dans les clones récursifs corrigée
Le projet Git a publié un correctif pour une vulnérabilité. Elle permet à un dépôt malveillant d’exécuter du code sur le poste d’un développeur lors d’un clonage récursif (commande qui télécharge un projet et tous les sous-projets qu’il référence). Pour un attaquant, c’est une porte d’entrée directe vers le poste de travail. Et ce poste contient souvent… des clés d’API.
Pourquoi ça compte pour une PME
Ces quatre événements forment une même chaîne d’attaque : trouver un secret, l’utiliser, monnayer. Les PME y sont particulièrement exposées pour plusieurs raisons :
- Un impact financier direct et rapide. Une clé d’IA sans plafond de dépenses peut générer des milliers de dollars de frais en quelques heures. Le cas Railway montre l’ordre de grandeur possible à l’échelle d’une plateforme.
- Un risque qui vient des fournisseurs. Votre sécurité interne peut être bonne et vos clés être volées quand même, chez votre hébergeur ou votre fournisseur d’IA. Il faut donc pouvoir réagir vite à leurs avis de brèche.
- Des outils d’IA adoptés sans encadrement. Dans beaucoup de PME, les développeurs, internes ou contractuels, utilisent des assistants de codage sans politique écrite. Les secrets traînent dans des fichiers
.env(fichiers texte de configuration qui contiennent souvent des mots de passe) que ces outils peuvent lire et publier. - Des obligations légales au Québec. Si les données exposées incluent des renseignements personnels (clients, employés), la Loi 25 s’applique, même si la brèche a eu lieu chez votre fournisseur. Vous restez responsable des renseignements que vous lui confiez.
| Scénario | Risque principal | Niveau pour une PME |
|---|---|---|
| Clé d’IA volée chez un fournisseur | Facturation frauduleuse | Élevé si aucun plafond |
| Secret publié par un agent de codage | Accès non autorisé, fraude | Élevé (exploitation souvent automatisée) |
| Brèche de données chez un fournisseur d’IA | Fuite de données, obligations Loi 25 | Moyen à élevé selon les données confiées |
| Git non mis à jour | Exécution de code sur un poste de développement | Moyen (exige le clonage d’un dépôt piégé) |
Comment se protéger
Priorité 1 : cette semaine (gestion des incidents et de la facturation)
- Faites l’inventaire de vos fournisseurs d’IA et d’hébergement. Listez chaque service (OpenAI, Anthropic, Fireworks AI, Railway, etc.), le compte associé, le responsable interne et les clés actives. Sans cet inventaire, on ne peut pas réagir vite à une brèche.
- Configurez des plafonds de dépenses et des alertes de facturation chez chaque fournisseur qui le permet. Fixez un plafond mensuel strict et une alerte à 50 % et à 80 % du budget habituel. Envoyez les alertes à une adresse partagée, pas à une seule personne.
- Si vous utilisez Railway ou Fireworks AI, faites tourner vos clés maintenant. La rotation consiste à générer une nouvelle clé, la déployer, puis révoquer l’ancienne. Vérifiez ensuite l’historique de consommation pour repérer tout usage anormal. Traitez la situation comme un incident (ITIL : gestion des incidents), avec un responsable et une trace écrite.
- Contestez rapidement les frais frauduleux auprès du fournisseur, avec vos journaux d’utilisation à l’appui.
Priorité 2 : sous 30 jours (correctifs et détection)
- Mettez Git à jour sur tous les postes et serveurs de build avec la version corrigée publiée par le projet Git. Consultez l’avis officiel pour connaître les versions concernées. Traitez cette mise à jour comme un changement standard (ITIL : gestion des changements). Vérifiez la version installée :
git --version
- En attendant le correctif, évitez les clones récursifs de dépôts non fiables. Désactivez la récursion automatique par défaut :
git config --global submodule.recurse false
# Cloner sans sous-modules, puis les inspecter avant de les récupérer
git clone https://exemple.com/projet.git
- Activez l’analyse des secrets (secret scanning) sur tous vos dépôts. Sur GitHub, activez le secret scanning et la push protection, qui bloque l’envoi d’un secret avant sa publication. Analysez aussi l’historique complet avec un outil libre :
# Analyse de l'historique complet d'un dépôt local
gitleaks detect --source . --verbose
# Alternative : TruffleHog sur un dépôt distant
trufflehog git https://github.com/votre-org/votre-depot.git
- Tout secret trouvé dans un dépôt doit être considéré comme compromis. Le supprimer du code ne suffit pas, car il reste dans l’historique. Il faut le révoquer et le remplacer.
Priorité 3 : sous 90 jours (mitigation durable)
- Adoptez un gestionnaire de secrets (coffre-fort centralisé pour les clés et mots de passe, par exemple Azure Key Vault, AWS Secrets Manager, HashiCorp Vault ou 1Password pour les équipes). Les clés ne doivent plus se trouver dans le code ni dans des fichiers
.envversionnés. Ajoutez au minimum.envau fichier.gitignore. - Limitez la portée de chaque clé : une clé par application et par environnement (test, production), avec les permissions minimales nécessaires. Une clé compromise doit avoir un impact limité.
- Planifiez une rotation régulière des clés (par exemple tous les 90 jours) et intégrez-la à votre processus de gestion des vulnérabilités.
- Rédigez une politique d’usage des assistants de codage par IA. Elle doit préciser :
- les outils autorisés et les comptes à utiliser (comptes d’entreprise, pas personnels) ;
- l’interdiction de donner aux agents l’accès aux fichiers de secrets ou aux identifiants de production ;
- la revue humaine obligatoire avant toute publication (commit ou push) produite par un agent ;
- l’application de la politique aux sous-traitants et pigistes.
Volet Loi 25 : votre fournisseur infonuagique vous avise d’une brèche
Au Québec, la Loi 25 qualifie ce type d’événement d’incident de confidentialité dès que des renseignements personnels peuvent avoir été consultés, utilisés ou communiqués sans autorisation. Voici la marche à suivre :
- 1. Alertez votre responsable de la protection des renseignements personnels (par défaut, la personne ayant la plus haute autorité dans l’entreprise, sauf délégation écrite).
- 2. Obtenez du fournisseur, par écrit, la nature des données touchées, la période d’exposition, les clients concernés et les mesures qu’il a prises.
- 3. Réduisez le risque immédiatement : rotation des clés, révocation des accès, suspension des intégrations touchées.
- 4. Évaluez le risque de préjudice sérieux en tenant compte de la sensibilité des renseignements, des conséquences possibles et de la probabilité d’une mauvaise utilisation.
- 5. Si ce risque est sérieux, avisez avec diligence la Commission d’accès à l’information (CAI) et les personnes concernées.
- 6. Inscrivez l’incident dans votre registre des incidents de confidentialité, que l’incident soit déclarable ou non. La CAI peut demander ce registre.
- 7. Revoyez votre contrat avec le fournisseur : délais de notification, obligations de sécurité, responsabilité financière. Ajustez-le au renouvellement si nécessaire.
À retenir : les clés d’API d’IA sont maintenant aussi précieuses qu’une carte de crédit pour les criminels. Plafonnez les dépenses, centralisez les secrets, analysez vos dépôts, encadrez vos agents de codage et préparez dès aujourd’hui votre réponse à la prochaine brèche d’un fournisseur.