Le 15 mai 2026, le CERT-FR a publié une alerte sur une vulnérabilité touchant Microsoft Exchange Server. L’alerte a été mise à jour le 11 juin 2026 après la publication de versions correctives par Microsoft. Pour une entreprise, le sujet n’est pas seulement technique : si un serveur de messagerie a été exposé, si des courriels ont été compromis ou si une attaque a été facilitée par un retard de correction, il faut très vite organiser la preuve, vérifier les obligations de notification et examiner la responsabilité éventuelle du prestataire informatique.
La situation typique est simple : l’entreprise paie un infogérant, un mainteneur ou un prestataire sécurité pour surveiller ses serveurs, appliquer les correctifs, gérer la sauvegarde et alerter en cas d’incident. Une faille critique est annoncée, puis l’entreprise découvre plusieurs jours ou semaines plus tard que le correctif n’a pas été appliqué, que le contournement provisoire n’a pas été activé ou que les journaux utiles ont disparu. À ce stade, il ne faut pas seulement demander « qui a fait l’erreur ». Il faut d’abord sécuriser les traces, limiter le dommage et éviter de perdre les recours.
Pourquoi l’alerte Exchange change la réaction de l’entreprise
L’alerte CERT-FR CERTFR-2026-ALE-005 vise une vulnérabilité Microsoft Exchange Server affectant notamment Exchange Server 2016, Exchange Server 2019 et Exchange Server Subscription Edition. Le CERT-FR indique que la vulnérabilité permet une injection de code indirecte à distance et un contournement de politique de sécurité lorsqu’un utilisateur ouvre un courriel piégé dans Outlook Web Access. L’alerte précise aussi que Microsoft a indiqué une exploitation active de la vulnérabilité.
Cela change la manière de gérer le dossier. Lorsqu’une vulnérabilité est officiellement signalée, que des correctifs existent et que l’exposition concerne la messagerie de l’entreprise, le débat avec le prestataire ne se limite pas à une appréciation vague de « bonnes pratiques ». Il faut reconstituer une chronologie précise :
- date de publication de l’alerte ;
- date de réception éventuelle d’une information par le prestataire ;
- date à laquelle le prestataire a informé l’entreprise ;
- date d’application du correctif ou du contournement provisoire ;
- période d’exposition du serveur ;
- signes d’intrusion, d’accès non autorisé ou de fuite de données ;
- pertes opérationnelles, financières ou commerciales subies.
Plus cette chronologie est documentée tôt, plus l’entreprise peut discuter utilement avec son prestataire, son assureur, la CNIL, un expert informatique ou le juge.
Les premières mesures à prendre dans les heures qui suivent
La première erreur consiste à modifier le système dans l’urgence sans conserver les éléments de preuve. Il faut évidemment contenir l’incident, mais il faut aussi préserver ce qui permettra ensuite de comprendre ce qui s’est passé.
Le CERT-FR recommande, en cas d’intrusion sur un système d’information, de qualifier l’incident, d’identifier le périmètre concerné, d’estimer les impacts, de préserver les journaux et de mobiliser les équipes internes ou les prestataires. En pratique, l’entreprise doit demander immédiatement :
- une copie horodatée des journaux Exchange, IIS, antivirus, EDR, pare-feu et VPN ;
- la liste des versions installées et des correctifs appliqués ;
- les tickets ouverts par le prestataire ;
- les mails d’alerte, comptes rendus d’exploitation et rapports de supervision ;
- le contrat de maintenance, le périmètre exact de la mission et les SLA ;
- la preuve des sauvegardes disponibles avant et après l’incident ;
- les éventuelles alertes de compromission, connexions anormales ou créations de règles de messagerie suspectes.
Il faut éviter de se contenter d’un simple mail du prestataire indiquant que « tout est rentré dans l’ordre ». Cette phrase ne prouve ni l’absence d’intrusion, ni l’absence de fuite, ni l’exécution correcte de ses obligations contractuelles.
Le prestataire informatique peut-il être responsable ?
Oui, mais la responsabilité dépend du contrat, du périmètre confié et de la preuve du manquement. Un prestataire chargé uniquement de fournir une licence n’a pas le même niveau d’obligation qu’un infogérant chargé de maintenir le serveur, surveiller les alertes, appliquer les mises à jour, gérer les sauvegardes et assister l’entreprise en cas d’incident.
La base juridique principale est l’article 1231-1 du code civil : le débiteur peut être condamné à des dommages et intérêts en cas d’inexécution ou de retard d’exécution, sauf force majeure. Si le contrat prévoyait une obligation de maintenance, de veille de sécurité, de correction des vulnérabilités ou d’alerte, le retard peut devenir un manquement contractuel.
Les points à vérifier sont les suivants :
- le contrat inclut-il la maintenance corrective et de sécurité ;
- le prestataire devait-il appliquer automatiquement les correctifs critiques ;
- l’entreprise devait-elle valider les mises à jour avant intervention ;
- un délai d’intervention était-il prévu pour les failles critiques ;
- le prestataire avait-il accès au serveur et aux droits nécessaires ;
- l’entreprise a-t-elle refusé ou retardé une opération recommandée ;
- le prestataire a-t-il conservé les journaux et rapports d’intervention ;
- le dommage est-il directement lié au retard ou à l’absence de correction.
Si aucun contrat écrit n’est complet, il faut exploiter les devis, bons de commande, factures, échanges de mails, tickets de support, comptes rendus de réunion et pratiques habituelles. Une mission réellement exécutée pendant des mois peut être prouvée même si le contrat est imprécis.
Quels préjudices réclamer après une cyberattaque ?
Une entreprise peut subir plusieurs types de préjudices après une faille non corrigée. Il ne faut pas les mélanger. Le dossier doit distinguer les pertes certaines, les coûts de crise et les pertes plus discutables.
Les postes les plus fréquents sont :
- coût de l’expert en réponse à incident ;
- coût de restauration, durcissement, changement de mots de passe et reprise d’activité ;
- interruption d’exploitation ;
- perte de chiffre d’affaires liée à l’indisponibilité ;
- surcoût interne lié à la mobilisation des équipes ;
- frais de communication de crise ;
- frais de notification CNIL et d’accompagnement RGPD ;
- éventuelles demandes de clients, pénalités contractuelles ou résiliations ;
- franchise ou refus partiel de l’assurance cyber ;
- atteinte à l’image lorsque l’incident est rendu public.
Le lien de causalité est souvent le point le plus difficile. L’entreprise doit montrer que le dommage n’aurait pas eu lieu, ou aurait été moins grave, si le prestataire avait exécuté correctement sa mission. D’où l’importance de la chronologie technique et des journaux.
Faut-il notifier la CNIL ?
Si l’incident touche ou peut toucher des données personnelles, il faut analyser immédiatement le risque RGPD. La CNIL rappelle qu’une violation de données personnelles doit être documentée en interne. Lorsque la violation présente un risque pour les droits et libertés des personnes, elle doit être notifiée à la CNIL dans un délai maximal de 72 heures. Si le risque est élevé, les personnes concernées peuvent aussi devoir être informées.
Dans un incident Exchange, les données personnelles peuvent être nombreuses : courriels clients, pièces jointes, devis, factures, contrats, bulletins de salaire, données bancaires, échanges RH, litiges, données de santé ou informations confidentielles. Même si l’entreprise ne sait pas encore tout, elle peut procéder à une notification initiale, puis la compléter lorsque l’enquête progresse.
Le prestataire informatique peut être sous-traitant RGPD lorsqu’il traite des données pour le compte de l’entreprise. Dans ce cas, il doit alerter le responsable de traitement sans délai après avoir connaissance d’une violation. Si le prestataire tarde à signaler l’incident, ce retard peut aggraver le dossier, notamment si l’entreprise dépasse le délai de notification ou perd la possibilité de prévenir les personnes concernées à temps.
Assurance cyber : attention aux déclarations tardives et aux exclusions
L’assurance cyber doit être notifiée très tôt. Le CERT-FR recommande de penser à l’assureur du système d’information pour démarrer la prise en compte de la couverture, identifier les prestataires pouvant être recommandés ou mandatés et établir le périmètre couvert.
Il faut relire la police avant d’envoyer une déclaration trop vague. Certains contrats prévoient :
- un délai de déclaration strict ;
- une obligation de ne pas reconnaître de responsabilité sans accord ;
- une liste de prestataires agréés ;
- une exclusion en cas d’absence de mises à jour critiques ;
- une condition de sauvegarde régulière ;
- une exclusion si l’entreprise n’a pas respecté ses mesures minimales de sécurité.
Si l’assureur refuse sa garantie en invoquant l’absence de correctif, cela peut renforcer l’intérêt d’un recours contre le prestataire qui avait précisément la charge de la maintenance. Mais il faut éviter les contradictions : ce qui est écrit à l’assureur, à la CNIL, au client et au prestataire doit rester cohérent.
Mise en demeure du prestataire : que demander ?
Une mise en demeure utile ne doit pas se limiter à demander une indemnisation globale. Elle doit organiser la conservation des preuves et forcer le prestataire à prendre position sur son rôle.
Elle peut demander :
- la communication du contrat, des annexes techniques et des SLA ;
- l’historique des interventions sur le serveur Exchange ;
- la date exacte d’application des correctifs ;
- les raisons du retard ou de l’absence de correction ;
- les alertes reçues par le prestataire ;
- les rapports de supervision ;
- la conservation de tous les journaux et tickets ;
- la confirmation des mesures d’endiguement ;
- une position sur la prise en charge financière des frais de crise ;
- les coordonnées de son assureur responsabilité civile professionnelle.
Si le prestataire refuse de communiquer les pièces, l’entreprise peut envisager une procédure de référé pour obtenir la conservation ou la production de preuves, selon l’urgence et les éléments disponibles. L’objectif n’est pas seulement d’obtenir un document : il s’agit d’éviter que les journaux disparaissent par rotation automatique ou que les tickets soient modifiés sans traçabilité.
Paris et Île-de-France : quel réflexe pratique pour les entreprises ?
Pour une entreprise située à Paris ou en Île-de-France, le dossier mêle souvent plusieurs interlocuteurs : prestataire local, assureur, expert cyber, DPO, clients professionnels, commissariat ou gendarmerie, CNIL, éventuellement tribunal de commerce si le litige est commercial.
Le bon réflexe consiste à centraliser rapidement un dossier de crise :
- un tableau de chronologie ;
- les contrats informatiques ;
- les factures du prestataire ;
- les preuves d’alerte et de correction ;
- les journaux techniques conservés ;
- les preuves de pertes d’exploitation ;
- les notifications et déclarations effectuées ;
- les courriers clients et assureur ;
- les décisions prises par la direction.
Ce dossier servira à la fois pour discuter avec le prestataire, déclarer le sinistre, répondre à un client, préparer une mise en demeure ou saisir le juge.
Lorsque le litige prend une dimension contractuelle ou commerciale, l’entreprise peut aussi se faire assister en droit des affaires pour articuler la mise en demeure, l’expertise technique, les discussions d’assurance et l’éventuelle action contre le prestataire.
Ce qu’il ne faut pas faire
Plusieurs erreurs affaiblissent fortement le recours :
- supprimer ou écraser les journaux en voulant nettoyer trop vite ;
- laisser le prestataire rédiger seul le récit de l’incident ;
- déclarer à l’assureur que l’incident est mineur sans analyse ;
- attendre la fin de l’enquête technique pour se poser la question CNIL ;
- oublier les clauses de limitation de responsabilité du contrat ;
- accepter un avoir commercial en échange d’une renonciation générale ;
- publier une communication externe avant d’avoir vérifié les faits ;
- accuser le prestataire sans pouvoir décrire précisément son manquement.
Une cyberattaque est un dossier technique, mais le contentieux se gagne souvent sur des éléments très concrets : dates, tickets, logs, clauses, délais, mails d’alerte et preuves de perte.
Sources utiles
- Alerte CERT-FR : vulnérabilité dans Microsoft Exchange Server.
- Fiche CERT-FR : bons réflexes en cas d’intrusion sur un système d’information.
- CNIL : règles à suivre en cas de violation de données personnelles.
- Code civil : article 1231-1 sur la responsabilité contractuelle et article 1240 sur la responsabilité délictuelle.
- À lire aussi : cyberattaque en entreprise : que faire dans les 72 heures après une fuite de données ?.
Besoin d’un avis rapide sur votre dossier.
Le cabinet peut vous aider à analyser la responsabilité du prestataire, organiser les preuves, déclarer le sinistre et préparer une mise en demeure.
Consultation téléphonique en 48 heures avec un avocat du cabinet.
Appelez le cabinet au 06 46 60 58 22 ou utilisez le formulaire de contact du cabinet Kohen Avocats.
Le cabinet intervient notamment pour les entreprises situées à Paris et en Île-de-France confrontées à une cyberattaque, un prestataire informatique défaillant, une difficulté d’assurance cyber ou un litige commercial lié à une interruption d’activité.
Transmettez les pièces de votre dossier au cabinet. Maître Reda KOHEN vous répond personnellement sous 24 heures avec une première analyse stratégique.