L'adoption de la sécurité commence au conseil d'administration, pas au service d'assistance

Le secteur des MSP a enfin commencé à parler d’adoption. On y évoque les licences Copilot, les scores de sensibilisation et les structures Teams, tout cela concernant les utilisateurs finaux. La conversation la plus difficile, celle qui compte le plus, n’a pas encore véritablement commencé : les personnes personnellement responsables du cyberrisque comprennent-elles réellement les tableaux de bord que leur MSP leur présente ?

Cette question est revenue à plusieurs reprises lors de récentes conversations avec des clients, dans diverses sessions partenaires, et une nouvelle fois lors d’un récent épisode de MSP Late Night, où l’adoption était enfin le sujet central. Les intervenants autour de la table étaient incisifs sur Copilot, sur la formation à la sensibilisation et sur l’écart entre vendre une licence et changer les comportements. Mais la discussion est restée presque entièrement centrée sur l’utilisateur final. Or, en sécurité de l’information et en conformité, où la NIS2 a désormais rendu les administrateurs personnellement responsables, l’angle mort le plus important se situe un étage plus haut.

L’adoption n’est pas seulement un problème d’utilisateur final

Lorsque les MSP parlent d’adoption, ils entendent généralement la même chose que les éditeurs de solutions de productivité. Les collaborateurs utilisent-ils l’outil ? Sollicitent-ils Copilot ? Terminent-ils le module de sensibilisation ? Cliquent-ils sur les bons boutons dans le bon système ?

Ces questions comptent. Mais en sécurité et en conformité, il existe une seconde question d’adoption qui n’est presque jamais posée. Le dirigeant qui a signé le contrat comprend-il ce que l’outil lui indique ? L’administrateur personnellement responsable du résultat lit-il le tableau de bord ? Le comité de direction propriétaire du risque d’entreprise pilote-t-il l’organisation à partir des chiffres qu’il produit ?

Si ce n’est pas le cas, le tableau de bord n’est pas adopté. Il est simplement payé. Ce sont deux choses différentes.

Comment un administrateur sait-il si son MSP le protège réellement ?

C’est la question que les propriétaires, les administrateurs et les membres de conseils d’administration tapent dans les moteurs de recherche et posent à leurs conseillers de confiance. C’est également la question à laquelle les MSP sont le moins bien équipés pour répondre dans un langage compréhensible pour un conseil d’administration.

Le Global Cybersecurity Outlook 2026 du Forum économique mondial, publié en janvier 2026 avec Accenture et fondé sur les réponses de 804 dirigeants seniors dans 92 pays, illustre cet écart à travers deux chiffres. Parmi les organisations que le Forum économique mondial classe comme hautement résilientes, quatre-vingt-dix-neuf pour cent déclarent une implication du conseil d’administration dans la cybersécurité. Encourageant en apparence. En poursuivant la lecture du même rapport, seulement cinquante-deux pour cent de ces mêmes organisations affirment que les membres de leur conseil d’administration reçoivent réellement des mises à jour régulières sur la cybersécurité. « L’implication sans information n’équivaut pas à la supervision. »

La même enquête est catégorique sur un second point : ce qui préoccupe le PDG et ce qui préoccupe le RSSI ne coïncident plus. Les PDG placent la fraude et le phishing facilités par la cybercriminalité en tête de leurs préoccupations ; les RSSI classent toujours le rançongiciel en première position. Ils observent le même paysage de menaces mais en tirent des conclusions différentes, car ils lisent des tableaux de bord différents, dans des vocabulaires différents.

Pour un administrateur, la question « suis-je protégé » ne peut pas trouver de réponse en pointant un Secure Score, un pourcentage de conformité ou une carte thermique colorée. Elle ne peut trouver de réponse que grâce à quelqu’un disposé à traduire ce score en conséquences pour l’entreprise : chiffre d’affaires à risque, contrats à risque, responsabilité personnelle à risque.

Un tableau de bord n’est pas une stratégie

Entrez dans une organisation moyenne du marché intermédiaire qui recourt à un MSP pour la sécurité et la conformité, et vous y trouverez des tableaux de bord. Un Microsoft Secure Score. Un décompte de vulnérabilités issu d’un scanner. Un pourcentage de préparation ISO 27001. Une autoévaluation NIS2. Une console Defender ou EDR. Parfois une vue personnalisée fournie par le MSP lui-même.

Ce que vous ne trouverez généralement pas, c’est une réponse courte à la question : « Que signifie tout cela pour notre entreprise ce trimestre ? »

L’enquête Defenders 2025 de Trend Micro, menée auprès de plus de trois mille professionnels de la cybersécurité, l’a démontré clairement. Seuls environ trente pour cent des répondants ont indiqué que leur organisation disposait d’« un modèle structuré et continu de communication sur les événements de sécurité avec les parties prenantes ». Le rapport concluait que la gestion du cyberrisque au niveau exécutif « exige une traduction : exprimer les risques en termes commerciaux plutôt qu’en termes techniques ».

Les tableaux de bord existent, les données existent, les outils fonctionnent. Le goulot d’étranglement se situe dans la couche de traduction. Et cette couche de traduction est, presque par définition, le rôle de celui qui se trouve entre la technologie et le conseil d’administration. Pour la plupart des organisations du marché intermédiaire, il s’agit du MSP.

Hans ten Hove, un habitué de la table de MSP Late Night, l’a résumé sans détour dans une publication LinkedIn en néerlandais : « une solution non adoptée, a-t-il écrit, n’est jamais qu’une facture coûteuse assortie d’un tableau de bord. » C’est la phrase à garder en tête chaque fois qu’un nouveau tableau de bord de conformité est déployé.

Qu’a discrètement changé la NIS2 concernant la responsabilité du conseil d’administration ?

Cette discussion resterait théorique s’il n’y avait le changement juridique désormais fermement en place.

En vertu de l’article 20 de la directive NIS2, l’organe de direction d’une entité essentielle ou importante doit approuver les mesures de gestion du cyberrisque de l’organisation, superviser leur mise en œuvre et suivre une formation obligatoire afin de pouvoir évaluer les cyberrisques. Comme l’a exposé DLA Piper dans une analyse de novembre 2025 de la directive, cette responsabilité ne peut être déléguée au service informatique ni externalisée à un prestataire externe. Les États membres se sont vu accorder le pouvoir d’imposer une responsabilité personnelle aux administrateurs individuels et, dans les cas graves, de suspendre un directeur général ou un représentant légal de ses fonctions.

Le BSI-Gesetz allemand révisé, entré en vigueur le 6 décembre 2025, va encore plus loin. Il rend les organes de direction personnellement responsables de la mise en œuvre effective des mesures de cyberrisque, et non plus seulement de leur approbation. Le régulateur allemand a confirmé que, la date limite d’enregistrement du 6 mars 2026 étant désormais passée, il est entré en phase d’application active.

Pour un MSP, l’implication est plus marquée qu’il n’y paraît de prime abord. Un administrateur personnellement responsable du cyberrisque et qui ne peut pas, en termes simples, expliquer ce que signifie son tableau de bord de conformité, est exposé. Non pas parce que le MSP a échoué techniquement, mais parce que l’écart d’adoption entre l’outil et la personne légalement responsable du résultat n’a jamais été comblé.

La NIS2 ne dit pas que les MSP doivent devenir des interprètes commerciaux. Mais elle rend impossible, pour tout membre sérieux d’un conseil d’administration, de rester un destinataire passif d’un Secure Score qu’il ne lit pas.

Du fournisseur informatique à l’interprète commercial

C’est là que le rôle du MSP doit évoluer, et c’est précisément là que beaucoup de MSP se sentent le plus mal à l’aise, honnêtement. La mise en œuvre est un terrain bien connu. Cycles de correctifs, référentiels de configuration, surveillance, réponse aux incidents, SLA de tickets. Le savoir-faire technique nécessaire pour gérer un parc informatique est véritablement exigeant, et ceux qui le maîtrisent méritent davantage de reconnaissance qu’ils n’en reçoivent.

Ce que ce savoir-faire technique ne produit pas automatiquement, c’est une conversation où un administrateur comprend, en cinq minutes, contre quoi il est protégé, contre quoi il ne l’est pas, ce qu’il en coûterait de combler l’écart, et ce qui arriverait à l’entreprise si cet écart était exploité.

Cette conversation relève d’une compétence différente. Elle nécessite quelqu’un capable de se placer entre une console Microsoft Defender et un compte de résultat, et d’expliquer pourquoi l’un influe sur l’autre. Elle nécessite quelqu’un à l’aise pour dire : « Votre score de conformité est de soixante-dix-huit pour cent, voici les trois contrôles manquants, et voici le contrat que vous pourriez perdre si un audit client les détecte. » Elle nécessite que le MSP cesse de vendre des outils et commence à vendre de la clarté.

Quelques MSP des marchés néerlandais, belge et allemand développent discrètement cette capacité au sein de leurs propres équipes. La plupart ne le font pas encore. Ceux qui le font constateront que leurs conversations de renouvellement se raccourcissent et que leurs marges s’améliorent, car la valeur qu’ils livrent devient visible pour la personne qui signe le chèque. Ceux qui ne le font pas resteront dans les mémoires comme le fournisseur dont personne ne lisait les tableaux de bord.

La place de Guardian360 dans cette équation

Je dirige un éditeur de logiciels qui conçoit l’un de ces tableaux de bord, il serait donc malhonnête d’écrire ce texte sans aborder ce que nous faisons et ne faisons pas.

La plateforme Lighthouse produit les résultats techniques habituels que tout outil de sécurité sérieux produit : résultats de scans sur les réseaux, adresses IP et applications web, informations de sécurité Microsoft 365 via l’API Graph, constats de vulnérabilités et recommandations de conformité au regard de plus de quarante normes et réglementations. Rien de tout cela n’est unique en soi. Ce que nous avons passé les dernières années à construire, et ce qui compte le plus, selon nous, pour la conversation évoquée dans ce billet, c’est un score de risque commercial qui vient s’ajouter aux scores de risque techniques. L’objectif est simple : donner au conseil d’administration un chiffre qui se rattache à l’entreprise, et pas seulement à l’actif.

Une plateforme peut soutenir la conversation de traduction. Elle ne peut pas mener cette conversation. C’est le travail du partenaire, et c’est là que nous dépendons, chaque jour, des MSP, intégrateurs et conseillers qui travaillent avec nous. L’outillage comble une partie de l’écart d’adoption. La relation comble le reste.

Une question différente à poser lors de votre prochaine revue MSP

Si vous êtes administrateur, propriétaire ou membre d’un conseil d’administration, vous n’avez pas besoin de lire les articles de la NIS2 pour agir en fonction de leurs implications. Lors de votre prochaine revue avec votre partenaire informatique, ne demandez pas ce qu’il a mis en œuvre ce trimestre. Demandez si vous, votre comité de direction et, idéalement, votre conseil d’administration comprenez ce que ces mises en œuvre signifient pour l’entreprise.

Si la réponse prend plus de temps que le résumé de la mise en œuvre lui-même, vous avez votre constat.

L’adoption de la sécurité commence au conseil d’administration, pas au service d’assistance. Le secteur des MSP, le secteur informatique dans son ensemble et les régulateurs ont tous commencé, chacun à leur manière, à pousser dans la même direction. Les billets et podcasts sur l’adoption par les utilisateurs finaux constituent un début sain. La prochaine conversation, la plus difficile, concerne les personnes dont le nom figure en haut de l’organigramme et dont la signature finit sur la lettre du régulateur.

Si cette conversation n’a pas encore eu lieu dans votre organisation, c’est la plus utile à programmer.