Guardian360
Démarrer l’essai gratuitDevenir partenaire
← Tous les articles

Opinion

MSP, NIS2 a renforce le devoir de diligence de votre client. Il a aussi renforce le votre.

Par Jan Martijn Broekhof ·

En preparant un webinaire sur la Cyberbeveiligingswet, la transposition neerlandaise de NIS2, j’ai echange avec Henk Bijsterbosch, de Samen Digitaal Veilig. Il a evoque une chose qui m’est restee en tete : le double devoir de diligence revient dans presque chaque conversation qu’il a avec des MSP. Non pas comme un risque hypothetique auquel ils pourraient un jour etre confrontes, mais comme quelque chose qui faconne deja, en silence, la maniere dont les clients et les MSP se disputent la question de savoir qui etait responsable de quoi.

Cette conversation merite d’etre menee serieusement, car il ne s’agit pas d’un probleme neerlandais. La Cyberbeveiligingswet est en vigueur aux Pays-Bas depuis le 15 aout 2026. La Belgique a transpose NIS2 dans son droit national des le mois d’octobre 2024. Le NIS2UmsuCG allemand est entre en vigueur le 6 decembre 2025. La France, au moment ou j’ecris ces lignes, n’a toujours pas acheve sa transposition et a ete renvoyee devant la Cour de justice de l’Union europeenne pour ce retard. Quatre marches, quatre calendriers differents, et une chose qui n’attend aucun d’entre eux : le devoir de diligence civil qui s’applique depuis des decennies aux prestataires professionnels d’informatique et de securite, bien avant que quiconque ait entendu parler de NIS2.

En quoi consiste exactement le double devoir de diligence ?

Il existe deux niveaux, et les MSP ont tendance a remarquer le premier tout en passant a cote du second. Le premier est l’obligation legale du client. NIS2, et ses transpositions nationales, font peser la responsabilite de la gestion des risques, de l’enregistrement et de la notification des incidents directement sur l’organisation elle-meme. Le guide technique de mise en oeuvre de l’ENISA est explicite : les fournisseurs de services geres et les fournisseurs de services de securite geres relevent eux aussi du champ de ces exigences, ce qui rappelle utilement que l’histoire ne se joue pas uniquement du cote du client.

Le second niveau est plus ancien et facile a negliger, precisement parce qu’il precede la reglementation. Aux Pays-Bas, l’article 7:401 du Code civil neerlandais oblige un prestataire de services professionnel a agir avec le soin d’un praticien competent, et la jurisprudence neerlandaise a maintes fois soumis les fournisseurs informatiques a un devoir renforce d’information et de mise en garde, en raison de l’ecart d’expertise qui les separe de leurs clients, comme l’expose la synthese des decisions pertinentes realisee par Dirkzwager. La Belgique dispose de sa propre version de cette doctrine : le Hof van Cassatie a juge des 2006 qu’un fournisseur informatique a un devoir d’informer, de conseiller et de mettre en garde son client, un principe encore cite aujourd’hui dans la doctrine juridique belge. L’Allemagne parvient a une conclusion similaire par le biais de sa propre jurisprudence. Lorsque l’OLG Schleswig a retenu la responsabilite d’un prestataire de services informatiques pour ne pas avoir correctement conseille un client avant la conclusion du contrat, et que le Bundesgerichtshof a refuse d’examiner un pourvoi ulterieur, cela a confirme un devoir precontractuel complet d’information et de conseil. La Cour de cassation francaise a juge de meme, a savoir qu’un fournisseur de produits informatiques complexes est tenu d’un devoir de conseil envers son client, et ce depuis au moins 2006, et la Cour d’appel de Rennes a applique ce principe directement a un litige de cybersecurite en novembre 2024.

Quatre pays, quatre systemes juridiques, la meme idee sous-jacente : NIS2 n’a pas invente ce devoir. Il a simplement releve l’enjeu de son ignorance.

Pourquoi la responsabilite du client ne peut-elle pas simplement devenir le probleme du client ?

C’est ici que reside le paradoxe, et il vaut la peine de s’y attarder plutot que de le survoler. NIS2 place le client aux commandes. Le client decide du risque qu’il accepte, de ce dans quoi il investit et de la maniere dont il etablit ses priorites. Un MSP peut conseiller, mais il ne peut pas contraindre un client a suivre ce conseil. A premiere vue, cela semble devoir mettre le MSP a l’abri.

Il n’en est rien, et la raison est constante dans chaque juridiction que j’ai examinee : la partie la plus experte supporte le devoir le plus lourd, quelle que soit la personne qui signe les documents de conformite. Une cour d’appel neerlandaise, statuant dans une affaire commentee par Elferink & Kortier Advocaten, est allee encore plus loin en jugeant qu’un fournisseur informatique professionnel doit rechercher activement si les propres choix du client sont reellement justifies, et non se contenter d’emettre un avertissement pour passer a autre chose. Avoir raison sur le fait que la decision appartenait au client ne signifie pas automatiquement que le MSP en a fait assez.

Lorsqu’un client refuse votre conseil

C’est le schema que la plupart des MSP reconnaissent d’instinct, et il se deroule a peu pres de la meme facon partout. Vous recommandez une mesure, EDR, gestion des correctifs, authentification multifacteur, quelque chose que vous considereriez comme une hygiene de base. Le client la refuse, pour des raisons de cout, de commodite, ou simplement parce que “nous n’avons jamais eu de probleme”. Des mois plus tard, une autorite de controle effectue une verification ou, pire, un incident survient. Le client, desormais confronte a sa propre exposition legale au titre de NIS2, cherche quelqu’un avec qui partager la responsabilite, et le MSP qui a donne le conseil est le candidat evident. Comme le souligne Critical.Matters, cette dynamique est deja visible aux Pays-Bas, avant meme que les obligations de la Cyberbeveiligingswet ne soient pleinement ancrees : les clients repercutent les exigences de securite le long de la chaine vers leurs fournisseurs, bien avant toute mesure d’application.

Lorsqu’un client refuse d’investir dans une certification

Le second schema est legerement different, mais aboutit au meme point. Un client refuse de rechercher une certification de securite reconnue, qu’il s’agisse d’un referentiel de chaine d’approvisionnement aligne sur NIS2, d’ISO 27001, ou d’une norme sectorielle. Soyons clairs : la certification n’est pas une obligation legale pour demontrer que vous maitrisez votre propre securite ; de nombreuses organisations peuvent le prouver au moyen de politiques documentees, d’audits et d’un processus credible de gestion des risques. Mais un certificat est un moyen rapide et externe de le prouver, a une autorite de controle, a un assureur, ou a l’un de vos propres clients inquiets. Sans lui, et sans une alternative tout aussi convaincante, une organisation est plus exposee lorsqu’un grand client se retire ou qu’un contrat tombe a l’eau apres un audit de securite. La encore, le MSP qui a signale la lacune peut se retrouver accuse de ne pas avoir insiste suffisamment.

Le point de vue sceptique, et pourquoi il ne tient pas

Il serait legitime de se demander s’il ne s’agit la que de peur deguisee en leadership eclaire, un moyen commode de vendre des services de certification ou du conseil en conformite. Je comprends ce scepticisme. Mais le schema decrit ci-dessus n’est pas de la speculation ; il est documente dans des decisions de justice issues de quatre systemes juridiques differents, sur pres de deux decennies. Ce que la jurisprudence montre aussi, de maniere constante, c’est que les MSP capables de produire une trace ecrite, des conseils documentes, des decisions de clients consignees, un compte rendu clair de ce qui a ete recommande et de ce qui a ete refuse, sortent de ces litiges dans une position bien plus solide que ceux qui ne le peuvent pas. Le risque est reel. Il est aussi, dans la plupart des cas, maitrisable.

Qu’est-ce qui reduit reellement le risque ?

C’est la partie rassurante, et elle merite autant d’attention que la mise en garde. Trois choses font systematiquement la difference.

Documentez vos conseils, et documentez la decision du client lorsqu’il les refuse. Non pas une note vague dans un CRM, mais quelque chose d’assez precis pour resister au temps, des mois ou des annees plus tard : ce que vous avez recommande, pourquoi, et ce que le client a choisi de faire a la place.

Fixez des exigences minimales de securite avant de prendre en charge un client, ou avant de renouveler, plutot que de decouvrir les lacunes une fois que quelque chose a mal tourne. Il ne s’agit pas de se montrer difficile ; il s’agit d’etre honnete, tot, tant que la relation autorise encore une conversation franche.

Ne laissez pas “le client n’en voulait pas” sans trace ecrite. C’est la phrase, a elle seule, qui determine si un litige devient une conversation partagee sur le risque ou une querelle unilaterale sur la responsabilite.

Rien de tout cela n’exige d’un MSP qu’il se transforme en service juridique. Cela exige de traiter la documentation comme une composante du service, et non comme une paperasse que l’on expedie s’il reste du temps.

Si vous souhaitez approfondir le sujet, le 8 octobre j’anime un webinaire destine au marche neerlandais sur la Cyberbeveiligingswet, qui couvre ce qu’elle exige reellement et, tout aussi important, comment demontrer que vos mesures de securite fonctionnent en pratique et pas seulement sur le papier. Vous pouvez vous inscrire ici.

Voici donc la question qu’il vaut la peine de se poser cette semaine : si un client vous interpellait demain sur un conseil que vous lui avez donne il y a dix-huit mois, seriez-vous reellement en mesure de le produire ?

Sources