Début juillet, un acteur malveillant connu sous le pseudonyme « 888 » a mis en vente sur un forum cybercriminel ce qu'il présente comme un peu plus de 35 Go de données volées chez Accenture : code source, clés RSA et SSH, jetons d'accès personnels Azure, clés de stockage Azure et fichiers de configuration. Accenture a confirmé un incident dans une déclaration aux médias : « un dossier isolé », dont la source a été « remédiée », sans impact sur ses opérations ni sur la prestation de services.
Il faut lire cette déclaration pour ce qu'elle dit, et surtout pour ce qu'elle ne dit pas. Elle parle des opérations d'Accenture. Elle ne dit rien des clients. Pour quiconque confie à un grand cabinet son intégration cloud, son développement applicatif ou ses accès privilégiés, c'est là que commence la vraie question.
Ce qui est confirmé, ce qui est revendiqué
La rigueur impose de séparer les deux, car à ce jour personne n'a validé publiquement le contenu du lot mis en vente.
- Confirmé par Accenture : un incident a eu lieu, sa source a été corrigée, et l'entreprise affirme qu'il n'y a pas d'impact sur ses opérations ni sur ses livraisons de services.
- Revendiqué par le pirate, non vérifié : le volume de 35 Go, la présence de code source, de clés RSA et SSH, de jetons Azure et de fichiers de configuration. Comme preuve, une capture d'écran semblant montrer le clonage d'un dépôt Azure DevOps privé associé à un hôte de production accenture.com.
L'acteur « 888 » n'en est pas à son premier coup : il avait déjà revendiqué en 2024 une fuite de données d'employés d'Accenture via un tiers. Et Accenture elle-même a connu un rançongiciel LockBit en 2021 et une exposition de données via un compartiment S3 mal configuré en 2017. Trois incidents connus en dix ans, pour l'un des prestataires les plus matures au monde en cybersécurité.
Pourquoi c'est votre problème, même si vous n'êtes pas client
Le point n'est pas de juger Accenture. Le point est structurel : les grands cabinets de conseil et intégrateurs sont des points de concentration de risque. Ils détiennent du code livré à leurs clients, des identifiants d'accès aux environnements de leurs clients, des schémas d'architecture et des fichiers de configuration qui décrivent les défenses de leurs clients.
Si les revendications du pirate sont exactes, trois conséquences en découlent.
- Des clés sont des accès, pas des données. Un jeton Azure ou une clé SSH volé n'est pas une fuite d'information : c'est un vecteur d'intrusion actif, utilisable tant qu'il n'est pas révoqué. La question opérationnelle immédiate est la rotation, pas la notification.
- Le code source est une carte des vulnérabilités. Des chercheurs cités dans la presse spécialisée le rappellent : le code et les fichiers de configuration permettent de comprendre la logique interne des applications, d'y repérer les implémentations fragiles et d'y chercher des secrets codés en dur. Si du code livré à des clients figure dans le lot, l'exposition se propage en cascade.
- La déclaration du fournisseur ne couvre pas votre exposition. « Pas d'impact sur nos opérations » ne signifie pas « pas d'impact sur vos données ni sur vos accès ». C'est à vous, client, d'obtenir une confirmation écrite du périmètre.
C'est exactement le scénario pour lequel un programme de gestion des risques tiers existe : non pas cocher un questionnaire annuel, mais savoir en continu quels fournisseurs détiennent quoi, et pouvoir agir en heures quand l'un d'eux est touché.
Ce qu'un client devrait faire cette semaine
Si votre organisation travaille avec Accenture, ou avec n'importe quel prestataire de ce profil, l'incident fournit un exercice concret et borné.
- Inventoriez les accès du prestataire. Dépôts de code, locataires cloud, comptes de service, accès VPN et SSH, jetons d'intégration : qu'est-ce qui, chez vous, est accessible avec des identifiants détenus chez lui ?
- Faites tourner les secrets partagés. Toute clé, jeton ou identifiant que le prestataire détient ou a détenu devrait être considéré comme potentiellement exposé et remplacé. Le coût d'une rotation préventive est faible ; celui d'un jeton valide entre de mauvaises mains ne l'est pas.
- Demandez une confirmation écrite du périmètre. Vos données, votre code, vos identifiants figurent-ils dans le lot ? Une déclaration générique aux médias ne vaut pas une réponse contractuelle à votre question.
- Surveillez la suite. Un lot mis en vente peut réapparaître, être revendu ou publié. La surveillance de l'exfiltration de données et des places de marché criminelles fait partie de la réponse.
Et si l'exercice révèle que vous ne savez pas répondre à la première question, l'inventaire des accès, c'est le vrai constat de l'incident : votre dépendance au fournisseur n'est pas cartographiée.
La question pour le conseil
Au niveau de la gouvernance, cet incident pose une question simple : lesquels de nos fournisseurs sont des points de concentration, c'est-à-dire détiennent à la fois notre code, nos accès et notre connaissance d'architecture ? Ces fournisseurs-là ne relèvent pas du même traitement que la moyenne du parc. Ils justifient un classement critique, des clauses de notification d'incident avec délais, des obligations de rotation de clés, et une réévaluation continue plutôt qu'un questionnaire annuel.
La leçon n'est pas qu'il faut se méfier des grands cabinets. C'est que la taille et la maturité d'un fournisseur ne remplacent pas votre propre visibilité sur ce que vous lui avez confié.
Où FortaRisks intervient
Le module Risque des tiers de FortaRisks cartographie vos fournisseurs, leur criticité et leur exposition réelle, en continu plutôt qu'au rythme des questionnaires, pour que la question « qu'est-ce que ce prestataire détient chez nous » ait une réponse avant l'incident, pas après. Pour évaluer la maturité de votre programme en dix minutes, notre diagnostic de gestion des risques tiers est gratuit et donne une feuille de route priorisée.