TLDR
Le détournement d’une notification push via la plateforme de communication tierce d’ASOS révèle une faille de test commune à la plupart des équipes d’ingénierie. Voici comment la combler.
Mardi, vers 10 h (heure britannique), des clients d’ASOS ont ouvert l’application du distributeur et découvert une notification qu’ils n’auraient jamais dû voir. Intitulée « ASOS HACKED », elle s’adressait au DPO et à l’équipe IT de l’entreprise, et affirmait que des attaquants avaient compromis une plateforme de données utilisée par le distributeur. Elle renvoyait vers un canal Telegram.
En milieu d’après-midi, ASOS a confirmé l’incident : l’entreprise enquête sur une « activité non autorisée impliquant des plateformes tierces que nous utilisons pour communiquer avec nos clients », a restreint l’accès aux plateformes de notification et travaille avec ses conseils et les autorités. ASOS précise que des informations personnelles de base ont pu être consultées, mais ne pense pas que les données de carte bancaire ou les mots de passe des comptes aient été touchés. Son site et son application ont fonctionné normalement pendant tout l’incident.
Charlotte Wilson, de Check Point, a résumé ce qui rendait l’attaque inhabituelle : les pirates avaient « transformé l’application d’ASOS en demande de rançon ». Le message visait les équipes internes d’ASOS, mais ce sont les clients qui l’ont lu sur leur écran de verrouillage.
Ce canal de diffusion, l’intégration tierce qu’utilise ASOS pour joindre ses clients, est précisément l’endroit où la plupart des suites de tests s’arrêtent. Tester les intégrations tierces de bout en bout : voilà la faille que cet incident rend visible.
Votre suite de tests s’arrête là où l’expérience de vos clients continue
La plupart des suites automatisées vérifient le code écrit par votre équipe. C’est le bon point de départ. Mais vos clients ne vivent pas votre code : ils vivent votre code plus chaque intégration qu’il appelle (fournisseur de notifications push, e-mails transactionnels, plateformes SMS, messagerie in-app, deep links).
Aucune de ces intégrations ne fait généralement l’objet d’assertions.
L’approche classique mocke la frontière de l’intégration : un test déclenche une requête, un stub renvoie une réponse de succès, le test passe. Ce que le client reçoit réellement sur son écran de verrouillage n’est jamais vérifié. Le test des notifications push en est un exemple parlant. Dans les communautés de développeurs, le débat porte sur la place de ces flux : dans les suites automatisées, ou laissés au monitoring. La réponse par défaut est souvent ni l’un ni l’autre. C’est pour cette raison que des incidents comme celui de mardi parviennent aux équipes d’ingénierie sous forme de captures d’écran envoyées par les clients.
Le cadre de test d’intégration en quatre couches de Prismatic explique clairement pourquoi : les environnements sandbox sont rarement représentatifs de la production. Volumes, limites de débit, configurations d’authentification et versions d’API des fournisseurs diffèrent. La quatrième couche, le monitoring permanent de la production, détecte la catégorie de défaillances que les tests unitaires, les tests de contrat et même les tests E2E laissent passer.
Les flux de notifications push se testent de bout en bout. Une approche documentée avec Firebase Cloud Messaging fait du test instrumenté le backend de l’application : il récupère le token push, déclenche la notification via l’API du fournisseur, puis attend que l’application confirme la réception et vérifie le message. Le flux est automatisable. La plupart des équipes ne l’ont simplement pas encore fait.
Les agents de test IA de Thunders exécutent des parcours utilisateur complets décrits en langage naturel, y compris des étapes qui franchissent la frontière d’un service tiers, au lieu de s’arrêter à une réponse mockée. Un flux qui déclenche une notification puis vérifie ce que fait l’application à sa réception constitue un parcours end-to-end que vous pouvez exécuter dans votre CI.
Tester en staging ne suffit pas : surveillez la production
Même une suite de pré-production exhaustive ne peut pas détecter ce qui change en production après la mise en ligne.
Les API des fournisseurs évoluent sans préavis. Les configurations d’authentification dérivent. Une rotation des identifiants touche les systèmes les uns après les autres. Le service de notifications qui fonctionnait en staging tourne en production avec une autre configuration : d’autres limites de débit, une autre chaîne d’authentification, parfois un environnement fournisseur entièrement différent.
Merge.dev tire la conséquence sans détour : « aucune suite de tests ne peut reproduire toutes les configurations du monde réel. C’est pourquoi le monitoring est aussi essentiel que le test. » Leur approche repose sur un monitoring continu en production (santé des synchronisations, schémas d’erreur, changements de comportement des API tierces) afin que les anomalies remontent avant que les clients ne les signalent.
Pour les flux de notifications, la version concrète est un test planifié sur la production : un compte de test préconfiguré reçoit une notification de test selon un planning défini, avec des assertions sur l’identité de l’expéditeur, le contenu du template et les éventuels liens. Si le résultat change de façon inattendue, une alerte part vers Slack ou votre système d’astreinte. C’est de la détection, pas de la prévention. Aucun dispositif de monitoring n’arrête un attaquant qui possède déjà des identifiants. Mais il réduit l’écart entre « c’est arrivé » et « nous le savons » de plusieurs heures à quelques minutes.
Thunders permet de planifier l’exécution de Test Sets : configurés une seule fois, ils tournent à intervalle régulier sur n’importe quel environnement, production comprise. L’Inbox vous prévient lorsqu’une exécution échoue. Un flux simple exécuté selon un planning, c’est ce qui fait passer le monitoring de production du principe à la pratique.
Le second incident : livrer des correctifs sous pression
Dès qu’ASOS a confirmé la faille, la réponse s’est enclenchée : rotation des identifiants, revue des accès fournisseurs, changements de configuration, correctifs d’urgence. Chacune de ces actions touche des parcours clients (connexion, paiement, opt-in aux notifications, réinitialisation du mot de passe) et chacune part en production sous contrainte de temps.
C’est à ce moment que les régressions s’infiltrent. Pas par négligence, mais parce qu’on n’a pas le temps de déboguer un sélecteur cassé pendant une rotation d’identifiants en plein incident. Si votre suite de régression échoue sur un changement d’interface pendant cette fenêtre, les équipes ignorent les échecs ou cessent de lancer la suite. Dans les deux cas, le correctif suivant part sans quality gate de régression vérifié.
Les 72 heures qui suivent un incident de sécurité impliquent généralement des changements d’identifiants et de tokens, des mises à jour de configuration chez les fournisseurs, des ajustements de feature flags et parfois un changement de fournisseur de notifications. Chacun de ces changements peut casser silencieusement un parcours client.
Une checklist concrète pour les équipes qui livrent sous pression :
- Relancez les parcours de connexion et d’authentification immédiatement après tout changement d’identifiants
- Vérifiez que les parcours de commande et de paiement ne sont pas affectés par la reconfiguration des fournisseurs
- Testez l’opt-in et l’opt-out aux notifications sur la plateforme de notifications mise à jour
- Exécutez la réinitialisation du mot de passe avec les nouveaux identifiants
- Contrôlez les deep links : ils cassent sans bruit lorsque la configuration du fournisseur push change
Les tests auto-réparants de Thunders absorbent les changements de sélecteurs et de configuration qui casseraient une suite traditionnelle pendant une réponse à incident rapide : lorsqu’un élément change, Thunders répare le sélecteur pendant l’exécution et journalise la correction. Grâce à l’intégration CI/CD, chaque hotfix passe automatiquement par le même quality gate de régression, à chaque commit.
Lancez votre premier test gratuitement, ou cartographiez en 15 minutes les intégrations que vos tests ignorent aujourd’hui.
.png)
