Fin août 2026, un groupe se présentant comme un collectif de hackers a remis le Maroc au centre de l’actualité internationale des fuites de données. Une fuite de données Maroc revendiquée par un groupe se faisant appeler « Jabaroot » affirmait exposer les données personnelles d’environ 70 000 personnes présentées comme des agents de la police (DGSN) et de la surveillance du territoire (DGST).
Quelques jours plus tard, les autorités concernées publiaient un démenti formel et catégorique, et des journalistes marocains indépendants commençaient à relever des failles dans la revendication elle-même.
Pour une entreprise marocaine, le titre du jour n’est pas ce qui compte. Ce qui compte, c’est le mécanisme derrière lui : le nom d’une organisation peut se retrouver au cœur d’une revendication de fuite sans qu’aucun de ses propres systèmes n’ait jamais été compromis, parce que l’exposition réelle se trouve souvent chez un prestataire, un assureur ou un fournisseur de services qui détient les mêmes données.
Cet article récapitule ce qui est confirmé au sujet de cette fuite de données Maroc, puis vous donne la méthode pour vérifier une revendication de fuite, en retracer l’origine probable et réagir dans les 48 premières heures.
Fuite de données Maroc : que dit vraiment le groupe Jabaroot ?
Le 24 août 2026, un groupe se faisant appeler « Jabaroot » a publié sur Telegram des fichiers prétendant exposer les données personnelles d’environ 70 000 personnes décrites comme des agents de la police nationale (DGSN) et de la direction générale de la surveillance du territoire (DGST). Ces fichiers contenaient, selon les informations rapportées, des noms, dates de naissance, numéros de carte d’identité nationale, matricules, dates de recrutement et, pour certains enregistrements, des grades et des coordonnées bancaires.
Selon ses propres messages, le groupe se présente comme pro-algérien et présente cette publication comme une réponse aux événements migratoires de Ceuta de fin juillet 2026. Il s’agit là des affirmations des attaquants eux-mêmes sur leur identité et leurs motivations, non de faits vérifiés de façon indépendante.
Trois jours plus tard, le 27 août 2026, le pôle DGSN-DGST a publié un communiqué officiel démentant catégoriquement toute intrusion dans ses systèmes d’information ou ses bases de données sécurisées, affirmant que ces systèmes répondent aux « normes de cybersécurité les plus strictes » et sont « déconnectés des réseaux ouverts sur internet ».
Les autorités affirment que les données en circulation proviennent d’anciens fichiers issus de compagnies d’assurance et d’organismes de couverture sociale ou de santé, et non de leurs propres systèmes.
Elles ont mis en avant des éléments précis attestant du caractère daté et falsifié des données : des dates de recrutement qui ne dépassent pas 2020, la présence de personnes décédées, des grades et des descriptions d’uniformes « qui n’existent pas » au Maroc, des photos incorrectes et des fautes de grammaire. Une enquête a été ouverte sous la supervision du parquet.
Des enquêtes indépendantes viennent renforcer certains éléments de ce récit sans le confirmer entièrement. Jeune Afrique et Le Courrier de l’Atlas ont, chacun de leur côté, identifié la présence d’Abdelhak Khiame, ancien directeur du BCIJ décédé en 2022, parmi les enregistrements, une découverte faite par des journalistes et non uniquement affirmée par les autorités.
Medias24 a publié le 25 août sa propre analyse, concluant que la prétendue « liste de 70 000 espions » « fait pschiitt » une fois examinée de près. Rien de tout cela ne prouve que l’ensemble du fichier est fabriqué, et aucune confirmation forensique indépendante de son origine n’est disponible publiquement, mais les éléments cités pointent vers un fichier ancien et gonflé plutôt que vers une intrusion récente.
Ce n’est pas la première revendication de Jabaroot contre une cible marocaine : le groupe avait déjà été associé à un précédent incident, récapitulé dans le dossier de SecureWeb sur la fuite de données CNSS.
Pourquoi une fuite de données Maroc peut survenir sans que vos systèmes soient piratés
L’affaire DGSN-DGST illustre bien une réalité que toute organisation marocaine doit comprendre : un démenti ferme d’intrusion dans ses propres systèmes et une fuite réelle des données personnelles de son personnel ne sont pas contradictoires. Les deux peuvent être vrais en même temps.
Voici le mécanisme. Votre organisation est rarement le seul endroit où résident les données de vos employés. Au cours d’une carrière, le nom, le numéro de carte d’identité et d’autres informations d’un employé transitent par un assureur santé, un prestataire de paie, un gestionnaire d’avantages sociaux, une agence de recrutement ou une plateforme SaaS utilisée par votre service RH.
Chacun de ces tiers détient une copie des mêmes données que vos propres systèmes, et chacun constitue une cible distincte, avec son propre niveau de sécurité, que vous ne contrôlez pas et que vous n’auditez souvent pas.
Lorsque l’un d’eux subit une violation ou laisse simplement circuler un ancien export, les données qui fuitent concernent bien votre personnel, et le nom de votre organisation se retrouve associé à l’affaire alors même que l’incident n’a jamais touché votre réseau.
C’est exactement le schéma décrit par les autorités dans cette affaire : la DGSN et la DGST démentent toute intrusion dans leurs propres systèmes, tout en affirmant que les données proviennent d’organismes d’assurance et de couverture santé ou sociale. Que ce récit soit entièrement exact ne peut être confirmé de façon indépendante depuis l’extérieur, mais il décrit un scénario réel et fréquent.
La leçon pratique pour toute organisation marocaine confrontée à une revendication de fuite : ne considérez pas que « nous avons vérifié nos serveurs et n’avons rien trouvé » clôt l’enquête, et ne considérez pas non plus qu’une revendication spectaculaire est automatiquement vraie.
Comment distinguer une fuite récente d’un fichier recyclé ou gonflé
Tout fichier publié avec un titre choc n’est pas forcément une fuite récente. Les attaquants, et parfois de simples opportunistes qui recyclent d’anciens fichiers, ont intérêt à présenter une revendication comme la plus actuelle et la plus volumineuse possible, car la taille et la fraîcheur attirent l’attention. Apprendre à lire les données elles-mêmes est le cœur de la vérification d’une fuite. Cinq signaux méritent d’être vérifiés systématiquement :
- Un plafond net sur les dates récentes. Si toutes les dates d’embauche ou d’activité « récentes » d’une base censément à jour s’arrêtent la même année, 2020 dans ce cas précis, l’export sous-jacent a très probablement été réalisé à cette époque, et non la semaine dernière. Une organisation qui recrute en continu présenterait des dates réparties jusqu’à une période proche de la fuite, et non un mur net situé des années en arrière. Ce plafond fonctionne comme une date d’expédition tamponnée sur un colis : il indique quand les données sont sorties, pas ce qu’elles reflètent aujourd’hui.
- Identités dupliquées ou décédées. Un enregistrement concernant une personne connue pour être décédée, comme des journalistes l’ont identifié de façon indépendante dans ce dossier, est l’un des signes les plus clairs qu’un fichier n’est pas tenu à jour. Un système RH correctement maintenu reflète l’effectif actuel ; un enregistrement qui maintient une personne décédée « active » indique que le fichier a été copié dans le passé et jamais mis à jour depuis.
- Grades, titres ou formats qui ne correspondent pas à la réalité. Lorsqu’une fuite assemble des champs provenant de plusieurs sources, elle peut se retrouver avec un grade ou une description d’uniforme qui n’existe pas dans l’institution qu’elle prétend représenter. Cette incohérence suggère que l’enregistrement n’a pas été extrait du système RH de cette organisation, mais provient d’une base sans rapport, ré-étiquetée pour correspondre au récit.
- Métadonnées incohérentes. Photos incorrectes et fautes de grammaire sont la signature d’un fichier assemblé rapidement pour maximiser l’impact médiatique. Une véritable violation d’un système bien géré préserve généralement une cohérence interne, car les données ont été extraites d’un seul bloc.
- Affirmations qui ne peuvent pas être vérifiées de façon indépendante. Lorsque l’origine réelle des données ne peut être confirmée par personne en dehors du groupe qui revendique la fuite ou de l’organisation qui la dément, considérez la revendication comme non tranchée : ne la rejetez pas d’emblée, mais ne la prenez pas non plus pour argent comptant.
Plusieurs éléments avancés par les autorités correspondent directement à ces signaux : le plafond des dates de recrutement en 2020, la présence d’un ancien responsable décédé, des grades inexistants et des erreurs de formatage. Cette combinaison explique pourquoi des médias indépendants comme Medias24 sont arrivés à une conclusion sceptique, non pas parce qu’un démenti a été publié, mais parce que les données elles-mêmes présentaient les marques d’un fichier ancien et recyclé.
La chaîne d’approvisionnement : la source la plus probable d’une fuite de données Maroc
Si une revendication de fuite concernant votre organisation s’avère contenir de véritables données personnelles, la chaîne d’approvisionnement, et non vos systèmes centraux, est statistiquement l’origine la plus probable. Cela vaut pour toute entreprise marocaine, pas seulement pour les agences de sécurité.
Songez au nombre d’acteurs qui détiennent légitimement une copie des données d’un seul employé : un assureur santé ou vie, un organisme national de couverture sociale, un fournisseur de logiciel de paie ou RH, un gestionnaire d’avantages sociaux, une agence de recrutement, un prestataire informatique disposant d’un accès administrateur.
Chacun est une organisation distincte, avec son propre budget de sécurité et son propre historique de mise à jour. On ne peut pas sécuriser ce que l’on ne contrôle pas, et la plupart des entreprises n’ont jamais cartographié qui détient des copies des données de leur personnel en dehors de leurs murs.
Le calcul joue en faveur du prestataire : si dix d’entre eux détiennent chacun une partie des données de vos employés, et que chacun présente ne serait-ce qu’une faible probabilité annuelle d’incident, la probabilité qu’au moins l’un soit compromis dans l’année est bien plus élevée que celle qui pèse sur vos propres systèmes, mieux dotés.
Une fois qu’une donnée a fuité, quelle que soit son origine, elle reste rarement à un seul endroit. Les fichiers publiés sur un canal comme Telegram se retrouvent généralement aussi sur des places de marché du dark web, où ils peuvent être revendus, réempaquetés et remis en circulation des mois ou des années plus tard sous une nouvelle revendication, comme SecureWeb l’explique dans son article sur la manière dont les données volées circulent et sont monétisées sur le dark web.
Une partie de cette circulation est opportuniste ; une autre sert délibérément à faire pression sur l’organisation dont le nom est associé aux données, ou à l’extorquer, un schéma détaillé dans le guide de SecureWeb sur le fonctionnement de la cyberextorsion.
Le point pratique à retenir : cartographiez chaque tiers détenant des données personnelles sur vos employés ou vos clients, et exigez de chacun qu’il démontre des pratiques de sécurité minimales, comme une exigence permanente et non une simple case à cocher au moment de l’achat.
Les 48 premières heures lorsque le nom de votre entreprise apparaît dans une fuite de données
Lorsque le nom de votre organisation apparaît dans une revendication de fuite, les deux premiers jours donnent le ton à tout ce qui suit. Un démenti précipité et un aveu précipité peuvent tous deux causer des dommages plus durables que la revendication initiale. Suivez cette séquence :
- Vérifiez avant de paniquer ou de démentir. Faites examiner un échantillon des données revendiquées par votre équipe de sécurité, et non par du personnel non formé, via des canaux contrôlés, et confrontez-le aux cinq signaux vus plus haut. N’interagissez jamais directement avec un canal de fuite et ne téléchargez jamais le fichier complet.
- Déterminez l’ampleur et l’origine probables. Les données vous appartiennent-elles réellement, proviennent-elles d’un prestataire de votre chaîne d’approvisionnement, ou présentent-elles des signes clairs de gonflage ? Cette évaluation détermine tout ce qui suit, y compris qui d’autre doit être impliqué.
- Informez les personnes concernées et le régulateur compétent dès que vous disposez d’une évaluation crédible de l’ampleur. La loi marocaine 09-08 relative à la protection des données à caractère personnel fixe des obligations de notification ; l’aperçu de SecureWeb sur les lois marocaines de cybersécurité et les obligations de notification détaille ce qui s’applique et quand. Une communication honnête et progressive est plus sûre que le silence.
- Coordonnez un seul message interne. Mettez-vous d’accord sur un récit unique et factuel, que chaque porte-parole répète, afin que l’organisation ne se contredise pas publiquement pendant que l’enquête se poursuit.
- Faites appel à un partenaire spécialisé en investigation forensique. Une équipe expérimentée peut confirmer l’origine et l’ampleur des faits sur la base de preuves, ce qui vous évite les deux écueils habituels : affirmer trop vite que rien ne s’est passé avant la fin de l’enquête, ou se taire pendant que les preuves continuent de circuler.
Une fuite de données Maroc peut se révéler totalement infondée quant aux systèmes propres d’une organisation, et mériter malgré tout d’être prise au sérieux, car le risque pesant sur les données de votre personnel ne commence ni ne s’arrête à l’intérieur de votre propre réseau.
Questions fréquentes
La DGSN ou la DGST ont-elles réellement été piratées dans cette fuite de données Maroc ?
La DGSN et la DGST ont publié le 27 août 2026 un communiqué officiel démentant catégoriquement toute intrusion, affirmant que ces systèmes ne sont pas connectés à internet. Les autorités affirment que les données en circulation proviennent d’anciens fichiers d’assurance et de couverture santé ou sociale, et non de leurs propres bases. Des enquêtes indépendantes, dont le fact-check de Medias24, ont conclu que la revendication ne résistait pas à l’examen.
Que contenait la revendication de fuite attribuée à Jabaroot ?
Des fichiers publiés sur Telegram le 24 août 2026 prétendaient contenir des données personnelles sur environ 70 000 personnes présentées comme du personnel de la DGSN et de la DGST : noms, dates de naissance, numéros de carte d’identité nationale, matricules, dates de recrutement, et pour certains enregistrements, grades et coordonnées bancaires.
Comment vérifier si mes données ont fuité dans l’affaire Jabaroot ?
SecureWeb ne renvoie vers aucun fichier de données divulguées et n’en reproduit aucun ; les particuliers ne doivent pas chercher à consulter directement les fichiers publiés sur Telegram. Si vous pensez que vos informations pourraient être concernées, suivez les communiqués officiels de la DGSN et de la DGST et envisagez un service professionnel de surveillance du dark web, capable de signaler vos données sans que vous ayez à rechercher vous-même ces canaux.
Que doit faire une entreprise marocaine si son nom apparaît dans une revendication de fuite ?
Vérifiez les données avant de réagir, déterminez l’ampleur et l’origine probables y compris au sein de votre chaîne de prestataires, informez les personnes concernées et le régulateur conformément à la loi 09-08, diffusez un message unique et coordonné, et faites appel à un partenaire spécialisé en investigation forensique pour confirmer les constats.
Sources
- Le Desk, 27 août 2026 : Fuite Jabaroot : la DGSN et la DGST démentent tout piratage de leurs systèmes
- La Vie Eco, 27 août 2026 : Fuite de données : la DGSN-DGST dément toute intrusion
- Barlamane FR, 27-28 août 2026 : La fuite de données sur des agents de sécurité marocains mêle fichiers anciens et renseignements administratifs
- Le Courrier de l’Atlas : Jabaroot, fausse liste de 70 000 agents marocains
- Jeune Afrique : Maroc : ce que l’on sait de la dernière fuite sécuritaire de Jabaroot
- Medias24, 25 août 2026 : Une fuite attribuée à Jabaroot « fait pschiitt »
- Maroc Hebdo : Fuite Jabaroot : le pôle DGSN-DGST dément toute intrusion
- Yabiladi : Maroc : DGSN-DGST dément piratage
