🧠 Asana, MCP et l’art du partage involontaire : un chef-d’œuvre de l’anti-« Privacy by Design »

Asana, MCP et l’art du partage involontaire : quand une fonctionnalité IA mal ficelée transforme une plateforme de gestion de projet en distributeur automatique de données inter-clients. Retour sur un fiasco technique où le Model Context Protocol d’Asana a démontré tout ce qu’il ne faut pas faire en matière de sécurité, d’isolation de données, et de respect du sacro-saint principe de Privacy by Design.

Imaginez une startup bien huilĂ©e, leader dans la gestion de projet, qui veut surfer sur la vague de l’IA. Elle lance une nouvelle fonctionnalitĂ© brillante, nommĂ©e MCP pour Model Context Protocol â€” un nom ronflant qui fleure bon la disruption. L’idĂ©e ? Injecter de l’IA dans vos projets Asana pour vous aider Ă  rĂ©diger, rĂ©sumer, automatiser, bref, faire le taf Ă  votre place. Pratique.

Sauf que voilĂ . Le 4 juin 2025, Asana rĂ©alise que son joujou intelligent partage un peu trop bien. En fait, il partage… trop. Comme un stagiaire IA un peu trop zĂ©lĂ© qui aurait dĂ©cidĂ© que l’open-space s’appliquait aussi aux donnĂ©es clients. RĂ©sultat : pendant plus d’un mois, des utilisateurs d’organisations diffĂ©rentes ont eu potentiellement accès Ă  des donnĂ©es d’autres clients, le tout sans piratage, sans malware, sans ransomware. Non. Juste grâce Ă  une excellente mauvaise conception.


🎯 L’incident MCP : Multi-Client Problématique

Le bug ne vient pas d’un groupe cybercriminel russe ou d’un pentester vĂ©reux. Non, cette faille est made in Silicon Valley. Elle rĂ©side dans la manière dont le Model Context Protocol est codĂ©. Le protocole Ă©tait censĂ© gĂ©nĂ©rer dynamiquement du contexte Ă  partir des donnĂ©es du client pour nourrir un LLM (Large Language Model). Sauf que la frontière entre “vos donnĂ©es” et “les donnĂ©es des autres” Ă©tait… disons, poreuse.

Isolation des tenants ? Absente. Cloisonnement logique ? Flou. Contrôle d’accès contextuel ? Trop conceptuel.
En clair : un magnifique exemple d’un système multi-tenant mal conçu, oĂą les pipelines de donnĂ©es ont fait fi des barrières entre organisations.


đź§» Privacy by Design ? Pas ce jour-lĂ .

Depuis des annĂ©es, on vous le rĂ©pète : la Privacy by Design, c’est LE socle. Un principe de base. Une Ă©vidence. IntĂ©grer la protection des donnĂ©es personnelles dès la conception des systèmes.

Mais ici, Asana semble avoir interprĂ©tĂ© cela comme Â«Â on concevra la protection des donnĂ©es… plus tard. »
Ou pire : Â«Â C’est l’IA qui s’en chargera, non ? Elle est censĂ©e ĂŞtre smart, après tout. »

Résultat :

  • Des utilisateurs qui reçoivent des suggestions IA contenant des donnĂ©es d’autres entreprises ;
  • Des projets, commentaires, voire fichiers rendus accessibles via les contextes de prompts gĂ©nĂ©rĂ©s automatiquement ;
  • Et Asana qui reconnaĂ®t une exposition de donnĂ©es inter-clients pendant un mois, sur une fonctionnalitĂ© toute neuve. Clap de fin.

đź“… Retour sur les faits

  • 🗓️ 1er mai 2025 : dĂ©ploiement du MCP, tambours et trompettes inclus.
  • 🚨 4 juin 2025 : Asana dĂ©tecte l’incident et Ă©teint les lumières.
  • 📣 18 juin 2025 : communication officielle sur BleepingComputer. Environ 1 000 clients concernĂ©s.

Et comme toujours dans ce genre de fiasco, l’entreprise précise qu’aucune preuve d’abus des données n’a été trouvée. On connaît la chanson.


💡 Ce que ça révèle

Ce type d’erreur est bien plus grave qu’un simple “bug”. Il s’agit d’un dĂ©faut fondamental de conception dans un système censĂ© ĂŞtre intelligent et sĂ»r :

  • ❌ Pas de sandbox client : les contextes sont construits Ă  partir de pools de donnĂ©es sans restriction stricte par organisation.
  • ❌ Pas de contrĂ´les d’accès dynamiques au moment du traitement IA.
  • ❌ Pas de revue de sĂ©curitĂ© solide avant la mise en production.
  • ❌ Et surtout : aucune vĂ©rification d’isolation tenant – LE B.A.-BA du SaaS multi-organisation.

Ă€ ce niveau-lĂ , ce n’est plus une erreur, c’est une faille culturelle dans le cycle de dĂ©veloppement.


🦺 Rappels utiles pour les autres (et pour Asana)

🎓 Le “Privacy by Design”, ce n’est pas :

  • Un joli sticker RGPD collĂ© Ă  la fin du sprint.
  • Un audit annuel en mode check-list ISO.
  • Ou une promesse floue sur la page de login.

C’est :

  1. Une séparation stricte des contextes d’usage.
  2. Des permissions vérifiables à chaque étape du pipeline.
  3. Des audits internes dès la phase de conception.
  4. Un système qui échoue de manière sûre, pas de manière bavarde.

🤖 Morale de l’histoire : l’IA ne corrige pas un code merdique

IntĂ©grer de l’intelligence artificielle dans une appli sans maĂ®trise des bases techniques, c’est comme rajouter un turbo sur une voiture sans freins. Ça va vite, ça impressionne… et ça finit dans le mur.

Ce que montre l’affaire MCP d’Asana, c’est que :

  • MĂŞme sans hacker, vos donnĂ©es peuvent fuir.
  • L’erreur humaine (ou organisationnelle) est toujours le maillon faible.
  • Et les LLM ne pardonnent pas les backend conçus Ă  la truelle.

đź§ľ Conclusion

Asana aurait pu briller avec son IA MCP. Ă€ la place, elle offre au monde un cas d’école de fail en matière de sĂ©curitĂ© des donnĂ©es.
Alors, la prochaine fois que vous lisez “intĂ©gration AI avancĂ©e dans notre solution SaaS”, pensez Ă  une chose : la sĂ©curitĂ© ne se sous-traite pas Ă  un modèle de langage.

🧠 Asana, MCP et l’art du partage involontaire : un chef-d’œuvre de l’anti-« Privacy by Design »
Partager cet article : Twitter LinkedIn WhatsApp

🖋️ Publié sur SecuSlice.com

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Retour en haut