🧠 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 :

Une séparation stricte des contextes d’usage.
Des permissions vérifiables à chaque étape du pipeline.
Des audits internes dès la phase de conception.
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