Le 7 septembre 2026, Adobe a publié le bulletin de sécurité APSB26-146. Le lendemain, le CERT-FR a repris l’alerte sous la référence CERTFR-2026-AVI-1130. Le 10 septembre, la page française d’instructions d’Adobe, destinée aux exploitants d’Adobe Commerce et de Magento Open Source, a précisé qu’Adobe sait que CVE-2026-75650 a été exploité dans le ciblage sauvage des commerçants Adobe Commerce. La faille permet, selon le même document, à un attaquant non authentifié d’exécuter du code arbitraire. Adobe demande d’appliquer un correctif et de faire pivoter les clés de chiffrement. Le CERT-FR ajoute, dans les mêmes termes, qu’Adobe indique que la vulnérabilité est activement exploitée.
La carte des décisions n’est pas celle d’un acheteur isolé. Elle concerne le commerçant dont le catalogue, les commandes et, souvent, les comptes clients professionnels tournent sur Magento ou Adobe Commerce, l’agence ou l’intégrateur qui administre la boutique, l’hébergeur, parfois Adobe elle-même lorsque la boutique est en cloud, et les partenaires de paiement, de logistique ou de place de marché qui s’y branchent. Chacun doit savoir qui applique le correctif, qui conserve les journaux, qui notifie, et ce que le contrat permet encore. Les réserves sont nettes : Adobe ne publie pas de liste de boutiques françaises compromises ; le CERT-FR ne dit pas que toutes les installations Magento en France sont atteintes ; poser le correctif ne prouve pas l’absence d’intrusion antérieure ; les contrats particuliers n’ont pas été lus. Nul ne peut, à partir des seuls avis publics, conclure à la faute d’une enseigne, d’une agence ou d’un hébergeur nommé.
I. La crise vue d’en haut : l’éditeur, la boutique et l’agence
A. Ce que les documents officiels permettent d’établir, et ce qu’ils ne permettent pas
Le premier document utile n’est pas un forum de cybercriminalité. C’est le bulletin Adobe APSB26-146 du 7 septembre 2026, que le CERT-FR cite comme source de l’avis CERTFR-2026-AVI-1130 du 8 septembre. Adobe y classe la mise à jour en priorité 1. Le résumé français, mis à jour le 10 septembre 2026, décrit une vulnérabilité jour zéro : un attaquant non authentifié peut exécuter du code arbitraire sur une installation affectée, identifiée CVE-2026-75650. Le bulletin anglais précise que la catégorie est une mauvaise neutralisation d’éléments spéciaux utilisés dans un moteur de templates (CWE-1336), que l’impact est une exécution de code arbitraire, que la sévérité est critique, qu’aucune authentification n’est requise et que le score CVSS de base est 10,0. Ces éléments techniques viennent de l’éditeur. Ils ne valent pas constat d’intrusion dans une boutique française déterminée.
Les systèmes visés, tels que les énumère le CERT-FR, sont Adobe Commerce B2B, Adobe Commerce et Magento Open Source, dès lors qu’ils n’ont pas reçu le correctif de sécurité pour CVE-2026-75650. La page française détaille les branches : Adobe Commerce de 2.4.4-2026-août à 2.4.9-2026-août et versions antérieures, le module B2B d’Adobe Commerce de 1.3.3-2026-août à 1.5.3-2026-août et versions antérieures, Magento Open Source de 2.4.6-2026-août à 2.4.9-2026-août et versions antérieures. La présence d’une ligne « Adobe Commerce B2B » a une conséquence pratique : la boutique n’est pas seulement une vitrine grand public. Elle peut porter des comptes d’acheteurs professionnels, des grilles de prix, des commandes récurrentes, des données d’entreprises clientes. C’est précisément le terrain de la propagation : un incident sur la plateforme du marchand se lit ensuite dans les contrats qu’il a avec ses propres clients professionnels et avec ses prestataires.
Adobe ne se contente pas d’un correctif. La page française indique qu’il faut, pour les produits et versions concernés, appliquer le correctif selon la version et faire pivoter les clés de chiffrement. La rotation des clés n’est pas un détail d’administration. Si un attaquant a pu exécuter du code, la question n’est plus seulement de fermer la porte. C’est de savoir si des secrets déjà extraits permettent encore de lire ce que le commerçant croit chiffré : données de configuration, éventuellement des informations de paiement tokenisées, des intégrations, des sauvegardes. Adobe ne dit pas, dans les documents lus, que toutes les clés de toutes les boutiques ont fuité. Elle dit que la mesure à prendre, pour les versions concernées, est double : correctif et rotation.
Trois architectures doivent être distinguées, faute de quoi on attribue à la mauvaise personne le pouvoir de patcher. Sur une installation Magento Open Source ou Adobe Commerce « on site », le commerçant, ou l’agence à qui il a délégué l’exploitation, dispose des serveurs, des accès SSH ou du dépôt, et de la responsabilité opérationnelle d’appliquer le hotfix. Sur Adobe Commerce on Cloud, l’éditeur intervient dans l’hébergement de la plateforme ; le commerçant et son intégrateur restent toutefois tenus de suivre les instructions de l’annonce, notamment la rotation des clés. Dans tous les cas, l’hébergeur d’infrastructure, s’il est distinct d’Adobe, n’est pas l’éditeur du logiciel. Il peut n’avoir ni le droit ni le devoir de modifier le code Magento sans ordre. Inversement, une agence qui a un contrat de maintenance « run » et qui conserve les accès d’administration ne peut pas se réfugier derrière le seul silence du commerçant pour ne rien faire : le contrat, s’il existe, dit qui a le droit de poser un correctif et dans quel délai.
Ce que les sources ne permettent pas d’écrire doit rester hors du texte. Aucun document officiel lu ne donne le nombre de boutiques françaises touchées. Aucun ne désigne une enseigne, une agence ou un hébergeur nommé comme victime ou comme fautif. Le CERT-FR ne transforme pas un avis de vulnérabilité en constat d’incident. Adobe parle d’exploitation dans la nature et de ciblage des commerçants ; cela décrit une menace active, pas le dossier d’une société particulière. Les captures de forums, les listes de « shops hacked » et les revendications anonymes, si elles apparaissent demain, resteront des allégations jusqu’à confrontation avec les journaux de la boutique, le dépôt de code et, le cas échéant, une analyse forensique. Enfin, le fait qu’une boutique soit encore en version « 2026-aug or earlier » au 11 septembre 2026 n’établit pas, à lui seul, une faute : encore faut-il savoir qui, dans le contrat, avait la charge de la veille sécurité, dans quel délai, et si le commerçant a fourni les accès.
La chaîne professionnelle se lit alors ainsi. L’éditeur Adobe a publié un correctif et une procédure. Le commerçant reste, vis-à-vis de ses clients personnes physiques et, souvent, vis-à-vis de ses clients professionnels, celui qui détermine les finalités du traitement des commandes. L’agence qui administre le back-office, déploie les modules et conserve les clés n’est pas un spectateur. L’hébergeur qui fournit la machine, le WAF ou le CDN détient une autre partie des preuves : journaux réseau, snapshots, tickets d’incident. Les partenaires de paiement, de logistique ou d’affiliation, branchés par API, peuvent recevoir des appels anormaux, des commandes fictives ou des demandes de changement d’IBAN. Chacun de ces acteurs a un intérêt distinct. Les confondre, c’est écrire au mauvais destinataire et perdre du temps.
B. Qui est responsable de traitement, qui applique le correctif, et qui notifie
Le règlement (UE) 2016/679 ne se déclenche pas parce qu’Adobe a publié un bulletin. Il se déclenche si des données à caractère personnel ont été, ou sont susceptibles d’avoir été, traitées de manière non autorisée. L’article 4 définit les données à caractère personnel comme toute information se rapportant à une personne physique identifiée ou identifiable. Un fichier de commandes Magento, des comptes clients, des adresses de livraison, des tickets, des factures nominatives, des journaux d’administration nominatifs, tombent dans ce champ. Les données d’entreprises clientes, pures personnes morales, ne sont pas des données personnelles ; les noms des interlocuteurs, leurs courriels et leurs téléphones le sont. Sur une boutique Adobe Commerce B2B, les deux strates coexistent souvent dans la même base.
Le commerçant qui détermine les finalités et les moyens du traitement des commandes est, en principe, responsable de traitement. L’agence qui n’intervient que pour le compte du commerçant, selon ses instructions, est un sous-traitant au sens de l’article 28. Lorsqu’un traitement est effectué pour le compte d’un responsable, celui-ci ne doit faire appel qu’à des sous-traitants présentant des garanties suffisantes. Le même article ajoute que le sous-traitant ne recrute pas un autre sous-traitant sans autorisation écrite préalable, spécifique ou générale, du responsable du traitement. Une agence qui place la boutique chez un hébergeur, un infogérant ou un prestataire de WAF sans cette autorisation sort de son rôle. Inversement, un commerçant qui a laissé son agence choisir seule l’hébergeur depuis des années ne peut pas découvrir cette architecture le jour de l’avis CERT-FR et s’en laver les mains : l’article 28 pèse d’abord sur le responsable.
L’article 32 du règlement impose au responsable et au sous-traitant de mettre en œuvre les mesures techniques et organisationnelles appropriées afin de garantir un niveau de sécurité adapté au risque. Il vise notamment le chiffrement, des moyens de confidentialité, d’intégrité, de disponibilité et de résilience, et la capacité de rétablir l’accès aux données dans des délais appropriés en cas d’incident. La rotation des clés demandée par Adobe s’inscrit dans cette logique de chiffrement. Elle n’épuise pas l’article 32. Un commerçant qui pose le hotfix sans journaliser, sans vérifier les comptes administrateurs, sans regarder les cron et les modules tiers, n’a pas nécessairement « sécurisé » au sens du règlement. À l’inverse, un intégrateur qui a proposé le correctif dès le 7 ou le 8 septembre, par un ticket daté, et s’est heurté à un refus d’accès, n’est pas dans la même situation que celui qui n’a rien écrit.
La notification n’est pas automatique. L’article 33 impose au responsable de notifier la violation à l’autorité de contrôle dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance, sauf si la violation n’est pas susceptible d’engendrer un risque pour les droits et libertés des personnes physiques. Le paragraphe 2 ajoute que le sous-traitant notifie au responsable toute violation dans les meilleurs délais après en avoir pris connaissance. La distinction est pratique. L’agence ou l’hébergeur qui constate des accès anormaux, un webshell, une modification de templates, un export massif, un compte administrateur inconnu, doit alerter le commerçant sans attendre d’avoir « fini l’enquête ». Le commerçant, lui, n’a pas 72 heures à compter du bulletin Adobe du 7 septembre. Il a 72 heures à compter de la connaissance d’une violation le concernant, c’est-à-dire d’un incident réel ou suffisamment caractérisé sur son instance, pas à compter de la publication d’une CVE. Confondre les deux dates, c’est notifier trop tôt, trop tard, ou à la place d’un autre.
L’article 34 n’impose la communication aux personnes concernées que lorsqu’une violation est susceptible d’engendrer un risque élevé pour les droits et libertés d’une personne physique. Un correctif posé à temps, sans indice d’exfiltration, ne déclenche pas, à lui seul, un mailing à toute la base clients. Une exécution de code avérée, avec accès au fichier clients, aux commandes ou aux pièces d’identité éventuellement stockées pour le B2B, change la qualification. Entre les deux, il faut des faits : journaux, indicateurs de compromission, périmètre des tables lues. Ni Adobe ni le CERT-FR ne font cette analyse à la place du commerçant.
Le droit des affaires entre professionnels n’est pas un accessoire de cette qualification. C’est le contrat de maintenance, le contrat d’hébergement, le contrat de paiement et, le cas échéant, les conditions générales de vente B2B du marchand qui disent qui doit informer qui, dans quel délai, et qui paie l’expertise. L’article 1103 du code civil rappelle que « Les contrats légalement formés tiennent lieu de loi à ceux qui les ont faits. » L’article 1104 ajoute que « Les contrats doivent être négociés, formés et exécutés de bonne foi. Cette disposition est d’ordre public. » Un commerçant qui cache une compromission à l’agence chargée du run, une agence qui minimise un webshell pour ne pas perdre le client, un hébergeur qui refuse les journaux en invoquant un silence contractuel mal lu, se placent d’abord sur ce terrain de la bonne foi, avant même le débat sur le RGPD.
Adobe, dans cette répartition, n’est pas le responsable de traitement des commandes du commerçant du seul fait qu’elle a écrit Magento. Sur une instance on site, elle est l’éditeur d’un logiciel. Sur le cloud Adobe Commerce, elle peut être à la fois éditeur et hébergeur de plateforme ; encore faut-il lire le contrat cloud, que le présent article n’a pas. Dans tous les cas, le bulletin APSB26-146 est une information de sécurité, pas une notification au sens de l’article 33. Il ne dispense personne de regarder sa propre instance.
II. La crise vue d’en bas : preuves, clauses et recours
A. Ce que chaque professionnel doit figer avant de parler, et pourquoi un correctif ne suffit pas
L’article 1353 du code civil pose la règle de preuve : « Celui qui réclame l’exécution d’une obligation doit la prouver. Réciproquement, celui qui se prétend libéré doit justifier le paiement ou le fait qui a produit l’extinction de son obligation. » L’article 9 du code de procédure civile ajoute : « Il incombe à chaque partie de prouver conformément à la loi les faits nécessaires au succès de sa prétention. » Dans une faille Magento, celui qui dira « j’ai patché le 8 septembre » devra le montrer. Celui qui dira « l’agence n’avait pas les accès » devra produire les refus, les tickets, les mails. Celui qui dira « il n’y a pas eu d’exfiltration » devra expliquer comment il le sait. Les communiqués généraux d’Adobe ne tiennent lieu ni de journal d’administration, ni de constat.
L’article 1366 du code civil donne à l’écrit électronique « la même force probante que l’écrit sur support papier, sous réserve que puisse être dûment identifiée la personne dont il émane et qu’il soit établi et conservé dans des conditions de nature à en garantir l’intégrité ». Un ticket d’agence exporté en PDF le jour J, un e-mail d’Adobe conservé avec ses en-têtes, un export de composer.lock et de la version Magento, un hash des fichiers app/code et vendor avant et après correctif, un dump de la table des administrateurs, des journaux nginx ou Fastly datés, un enregistrement de la rotation des clés : autant de traces qui, si elles sont identifiables et intègres, serviront. Un capture d’écran anonyme, un Slack recopié sans horodatage, un « on a patché » oral, ne tiendront pas longtemps.
La cour d’appel de Versailles, le 19 mai 2022, n° 20/05106, a rappelé, dans un litige d’hébergement distinct, qu’un prestataire ne peut se fonder sur le seul compte-rendu qu’il a lui-même rédigé : « Elle ne produit en effet que le compte-rendu qu’elle a personnellement rédigé, alors même que nul ne peut se fournir de preuve à lui-même. » L’espèce n’est pas Magento. C’était un incident du 28 juin 2017 sur des serveurs Claranet hébergeant, en sous-traitance, les données comptables d’Amnesty International pour le compte d’un intégrateur, Apogea. La leçon de preuve, elle, se transpose : l’agence ou l’hébergeur qui écrit, le 11 septembre 2026, « nous n’avons rien vu » sans joindre les journaux bruts, se place dans la même fragilité. Le commerçant qui se contente du mail de l’agence sans demander les artefacts fait de même.
Avant tout procès, l’article 145 du code de procédure civile permet, « S’il existe un motif légitime de conserver ou d’établir avant tout procès la preuve de faits dont pourrait dépendre la solution d’un litige », d’obtenir des mesures d’instruction « à la demande de tout intéressé, sur requête ou en référé ». Le tribunal des activités économiques de Paris, le 3 juillet 2026, n° 2026013898, a ainsi désigné un expert en cybermalveillance dans un litige entre un établissement de santé et son prestataire informatique, sur ce fondement. Les faits ne sont pas ceux d’une boutique Magento. La voie procédurale, si les journaux risquent de disparaître, de tourner ou d’être écrasés par le correctif lui-même, est la même : figer d’abord, qualifier ensuite. Un hotfix appliqué en écrasant les fichiers sans copie de l’état antérieur peut être la bonne mesure de confinement et, en même temps, la mauvaise mesure de preuve. D’où l’intérêt, lorsque c’est possible, d’un snapshot, d’une image disque, d’une copie du pub/media, des templates compilés et des modules communautaires avant écriture.
La liste minimale, pour chaque acteur, n’est pas un audit de luxe. Pour le commerçant : contrat d’agence, contrat d’hébergement, conditions Adobe ou Magento, dernière facture de maintenance, liste des administrateurs, historique des modules, copies des commandes B2B sensibles, contacts du DPO s’il existe, police cyber s’il en a une. Pour l’agence : tickets de veille du 7 au 11 septembre 2026, preuve de la version avant correctif, preuve de la pose du hotfix, preuve de la rotation des clés, journaux d’accès, liste des sous-traitants, mail d’alerte au client. Pour l’hébergeur : journaux réseau, WAF, authentifications, snapshots, plage de conservation. Pour le partenaire de paiement ou de logistique : appels API anormaux, webhooks, demandes de modification de coordonnées bancaires, commandes incohérentes. Personne n’a besoin du dossier entier des autres pour commencer le sien.
Deux erreurs fréquentes méritent d’être écartées. La première est de croire que le correctif Adobe « lave » le passé. Adobe demande le correctif et la rotation des clés précisément parce que l’exploitation a pu précéder la publication. Une boutique patchée le 10 septembre peut avoir été visitée le 8. La seconde est de prévenir tous les clients B2B avec une formule vague, « nos systèmes ont pu être ciblés », qui crée un trouble commercial sans satisfaire l’article 34, lequel exige des « termes clairs et simples » sur la nature de la violation lorsqu’il y a lieu de communiquer. Mieux vaut un silence provisoire documenté, le temps d’établir le périmètre, qu’une alerte inexacte. Mieux vaut aussi, si le risque élevé est caractérisé, une information précise, datée, limitée aux personnes concernées.
B. Obligation contractuelle, clause limitative et force majeure : ce que le contrat permet encore
L’article 1231-1 du code civil dit le régime de l’inexécution : « Le débiteur est condamné, s’il y a lieu, au paiement de dommages et intérêts soit à raison de l’inexécution de l’obligation, soit à raison du retard dans l’exécution, s’il ne justifie pas que l’exécution a été empêchée par la force majeure. » L’agence qui s’est engagée à maintenir la boutique « en conditions opérationnelles de sécurité », l’hébergeur qui a promis un rétablissement en quelques heures, le commerçant qui a promis à ses clients B2B une disponibilité, se rencontrent sur ce texte. Encore faut-il lire l’obligation réelle, pas le slogan commercial.
La cour d’appel de Versailles, dans l’arrêt du 19 mai 2022 déjà cité, a retenu un manquement de l’hébergeur à une obligation chiffrée. L’avenant du 29 janvier 2010 prévoyait un engagement de disponibilité 24/7 à 99,5 % mensuelle et une garantie de temps de rétablissement de 4 heures. Après un disque défectueux et des sauvegardes illisibles, la cour a jugé : « Il résulte de ce compte-rendu que la société Claranet n’a pas été en mesure de résoudre l’incident qui s’est produit le 28 juin 2017, ce qui caractérise un manquement à son obligation contractuelle de ‘garantie de temps de rétablissement de 4 heures en 24/7″. » Elle a confirmé le jugement en ce qu’il avait « déclaré la société Claranet responsable de l’incident survenu le 28 juin 2017 quant à l’hébergement des données de l’association Amnesty International ». Les faits sont un incident matériel de 2017, pas CVE-2026-75650. Ils montrent néanmoins qu’une obligation de rétablissement écrite se prouve par le résultat, et qu’un prestataire ne s’exonère pas par un récit unilatéral d’obsolescence logicielle dont il ne démontre pas le lien causal.
Le même arrêt a toutefois donné effet à la clause limitative. Les conditions générales limitaient la responsabilité « le montant égal aux sommes payées par le client à Aspaway pour la période de 3 mois précédant le ou les événements ». La cour a jugé que l’obligation essentielle était « de rendre disponible les données et applications hébergées, avec un taux de disponibilité de 99,5% », qu’un incident de 0,5 % était contractuellement envisagé, et qu’il n’y avait « pas lieu de réputer non-écrite la clause limitative de responsabilité ». L’indemnisation a été calée sur trois mois de prestations, soit 8 497,20 euros. Un commerçant Magento qui ouvre un recours contre son hébergeur ou son agence doit donc lire la clause avant de chiffrer la perte d’exploitation. Inversement, l’article 1231-3 du code civil rappelle que le débiteur « n’est tenu que des dommages et intérêts qui ont été prévus ou qui pouvaient être prévus lors de la conclusion du contrat, sauf lorsque l’inexécution est due à une faute lourde ou dolosive ». Une clause qui vide l’obligation de maintenance de sécurité de toute substance, ou une inexécution dolosive, ne se discute pas comme une simple franchise de trois mois. Cela se juge sur pièces, pas sur le seul avis CERT-FR.
La cour d’appel de Reims, le 28 avril 2026, n° 24/01502, offre l’autre versant, côté intégrateur. Après une refonte informatique inachevée, la société MISA a subi un rançongiciel le 18 avril 2020. L’expert a relevé que « les recommandations formulées par l’ANSSI n’ont pas été appliquées lors du déploiement du système d’information de la société MISA ». La cour a aussi retenu que l’absence de cahier des charges et des informations insuffisantes du client avaient concouru au dommage. Elle a dit que le prestataire était « responsable à hauteur de 50 % des dommages subis » et l’a condamné à 12 097,59 euros. L’espèce n’est pas une boutique Magento. Elle est utile précisément parce qu’elle refuse le tout ou rien : un commerçant qui n’a jamais validé un cahier des charges de sécurité, jamais payé la supervision, jamais donné les accès à temps, n’obtient pas automatiquement l’intégralité de sa perte d’exploitation. Un intégrateur qui n’a pas suivi les recommandations de sécurité documentées au moment du déploiement n’obtient pas non plus l’exonération.
La force majeure, souvent invoquée le jour d’une CVE, a un texte précis. L’article 1218 du code civil dispose : « Il y a force majeure en matière contractuelle lorsqu’un événement échappant au contrôle du débiteur, qui ne pouvait être raisonnablement prévu lors de la conclusion du contrat et dont les effets ne peuvent être évités par des mesures appropriées, empêche l’exécution de son obligation par le débiteur. » Un zero-day publié le 7 septembre, accompagné d’un correctif le jour même et d’un avis CERT-FR le 8, laisse peu de place, à compter de ces dates, à la thèse de l’imprévisible et de l’inévitable, dès lors que le débiteur avait le pouvoir d’appliquer le hotfix. Avant la publication, la discussion est autre : l’état de l’art, la veille, le WAF, le cloisonnement. Après la publication, attendre sans motif, c’est exposer l’inexécution. Adobe ayant écrit que la faille est exploitée dans le ciblage des commerçants, le débiteur d’une obligation de sécurité ne peut plus dire qu’il s’agissait d’une hypothèse théorique.
Les partenaires qui n’ont pas de contrat avec l’agence, mais avec le commerçant, ou qui n’ont de lien qu’au titre d’une API, ne sont pas absents. L’article 1240 du code civil reste le droit commun délictuel : « Tout fait quelconque de l’homme, qui cause à autrui un dommage, oblige celui par la faute duquel il est arrivé à le réparer. » Un logisticien qui reçoit des commandes fictives, un établissement de paiement qui voit des appels anormaux, un client professionnel B2B dont le compte a été utilisé, peuvent avoir un intérêt à agir. Encore faut-il une faute, un préjudice et un lien. L’article 82 du règlement complète, pour les personnes physiques : toute personne ayant subi un dommage matériel ou moral du fait d’une violation du règlement a le droit d’obtenir du responsable ou du sous-traitant réparation du préjudice subi. Le même article précise qu’un sous-traitant n’est tenu que s’il n’a pas respecté les obligations qui incombent spécifiquement aux sous-traitants ou s’il a agi en dehors des instructions licites du responsable, ou contrairement à celles-ci. L’agence n’est donc pas le débiteur universel des clients du commerçant. Le commerçant n’est pas exonéré parce qu’il a « un prestataire ».
Que faire, concrètement, dans les quarante-huit heures, sans promettre un résultat. Identifier qui a les accès d’administration et le dépôt. Consigner la version exacte, le numéro de correctif, l’heure de pose, l’heure de rotation des clés. Recenser les modules tiers, souvent plus exposés que le cœur. Révoquer les comptes inutiles. Demander à l’hébergeur les journaux et un snapshot. Écrire à l’agence, ou au client, un fait daté, pas une opinion. Vérifier les flux de paiement et les IBAN. Décider, sur des indices et non sur la seule CVE, si une notification CNIL s’impose. Lire la clause d’assurance cyber, souvent plus étroite qu’on ne le croit, et le délai de déclaration. Rien de tout cela n’établit la faute d’autrui. Tout cela évite de se retrouver, dans six mois, avec une boutique recollée et aucun dossier.
Conclusion
CVE-2026-75650 n’est pas une actualité d’éditeur destinée aux seuls administrateurs systèmes. C’est un incident de chaîne : Adobe publie, le CERT-FR relaie, le commerçant reste responsable de ses traitements, l’agence et l’hébergeur tiennent les accès et une partie des preuves, les partenaires B2B subissent les commandes et les appels anormaux. Les documents du 7, 8 et 10 septembre 2026 permettent d’agir. Ils ne permettent pas de désigner un coupable français. La bonne décision n’est ni le silence, ni l’alerte universelle. C’est de figer la version, les journaux et les clés, de patcher, de qualifier le rôle de chacun dans le contrat, puis seulement de notifier et, s’il y a lieu, de recourir. Les arrêts d’hébergement et d’intégration cités ne jugent pas Magento. Ils rappellent que l’obligation écrite se prouve, que la clause limitative se lit, et que la responsabilité se partage parfois. Le reste est affaire de pièces.
Besoin d’un avis rapide sur votre dossier
Maître Reda KOHEN, avocat au Barreau de Paris, reçoit en consultation téléphonique les commerçants, agences et hébergeurs qui doivent qualifier leur rôle, figer les preuves et décider d’une notification ou d’un recours après l’exploitation active de la faille Adobe Commerce et Magento. Appelez le 06 46 60 58 22 ou écrivez via la page contact du cabinet en joignant le contrat de maintenance ou d’hébergement, la chronologie du correctif et les journaux déjà conservés.