NIS2 en interne ou avec un cabinet spécialisé ? Comparatif des coûts, des délais et des risques

Choisir entre une mise en œuvre de NIS2 en interne et l’accompagnement d’un cabinet spécialisé ne consiste pas simplement à comparer les honoraires d’un consultant au coût du temps consacré par les équipes. Le résultat dépend du périmètre des obligations, de la disponibilité des décideurs, de la fiabilité des données relatives aux processus et aux actifs, ainsi que de la capacité de l’organisation à maintenir durablement les dispositifs retenus. La solution qui paraît la moins chère peut finalement devenir la plus coûteuse si elle entraîne une qualification erronée, la reprise des analyses ou la production d’une documentation déconnectée du fonctionnement réel de l’entreprise. Il convient donc de commencer par déterminer le périmètre et les écarts, puis de comparer le coût complet, les délais et les risques associés aux trois modèles de réalisation, avant de sélectionner un prestataire et d’organiser les travaux.

Ne choisissez pas le prestataire avant d’avoir déterminé vos obligations

Comparer une mise en œuvre réalisée avec les seules ressources internes à un accompagnement externe n’a de sens qu’après avoir établi si l’organisation relève des obligations issues de NIS2 et des dispositions nationales qui les transposent. Si tel est le cas, il faut préciser les services, entités, sites et actifs concernés par l’analyse. Sans cette qualification préalable, il est impossible d’estimer sérieusement la charge de travail, le calendrier ou le budget. La direction doit également désigner un pilote de projet disposant de l’autorité nécessaire pour arbitrer entre les activités opérationnelles, la fonction juridique et l’informatique.

Le point de départ n’est ni l’achat d’un ensemble documentaire ni celui d’un outil informatique, mais la description du modèle opérationnel. Il faut identifier les services fournis, les processus qui les soutiennent, les systèmes et les données associés, ainsi que les fournisseurs et les dépendances dont dépend la continuité d’activité. Cette cartographie permet ensuite de déterminer si l’analyse doit couvrir l’ensemble de la société ou uniquement certains services et sites. La première étape doit aboutir à une qualification documentée de l’entité, à des limites de périmètre clairement définies et à une liste des domaines nécessitant une évaluation ou des actions correctives.

Il faut distinguer l’assujettissement réglementaire formel du besoin métier de renforcer la résilience. Une organisation peut se situer hors du champ des obligations légales tout en devant satisfaire les exigences de ses clients, de son groupe, de son assureur ou d’autres acteurs de la chaîne d’approvisionnement. Un tel projet ne doit pas être présenté comme l’exécution d’une obligation légale, mais comme une réponse à des exigences contractuelles précises et à des risques opérationnels identifiés.

Prenons l’exemple d’une entreprise industrielle qui dispose de pare-feu, de sauvegardes et d’une protection des postes de travail, mais qui ne sait pas désigner le propriétaire du processus de réponse aux incidents. Elle n’a pas non plus évalué les conséquences d’une indisponibilité du système de planification de la production sur l’ordonnancement, la disponibilité des matières et le respect des délais de livraison. Le problème ne tient alors pas uniquement au niveau des mesures techniques : il résulte également de responsabilités non attribuées et d’une analyse insuffisante des dépendances entre le système d’information et la fourniture du service.

Une fois l’activité décrite, une analyse juridique doit être menée selon les critères sectoriels, organisationnels et de taille applicables à la date de publication. La position formelle doit être validée par l’organe ou la personne habilitée à représenter l’organisation, avec la participation de la fonction juridique et des propriétaires de services et de processus. L’informatique fournit les données relatives aux systèmes, mais ne doit pas décider seule de la qualification. Ce sujet est approfondi dans l’article « Directive NIS2 : quelles organisations sont concernées et quelles entreprises doivent respecter les nouvelles exigences ? ».

Le coût de la mise en œuvre ne se limite pas à la facture du consultant

Le scénario interne n’est pas gratuit, tout comme les honoraires d’un cabinet ne représentent pas le coût complet d’un accompagnement externe. Le calcul doit intégrer le travail de la direction, des propriétaires de processus, des équipes informatiques, des achats, des ressources humaines, de la fonction juridique et du responsable du système de management. Le temps consacré par ces personnes doit être valorisé selon les coûts internes et les heures réellement mobilisées, en tenant compte des tâches opérationnelles qu’elles ne pourront pas accomplir pendant le projet. La charge dépend principalement du nombre de sites, de processus, de systèmes, de fournisseurs et de sociétés inclus dans le périmètre.

Les postes les plus souvent sous-estimés sont la collecte des données, l’attribution des responsabilités, l’inventaire des actifs et des fournisseurs, la constitution des preuves, les tests, la formation et la correction de règles incohérentes. Un cabinet spécialisé ne réduira cette charge que s’il sait traduire les exigences dans les processus, les rôles et les outils existants. Fournir des politiques types sans comprendre l’activité ne supprime pas le coût : cela le reporte sur les phases de validation, de déploiement et de mise à jour ultérieure.

Une procédure de gestion des incidents peut être rédigée rapidement, mais elle restera théorique si les astreintes, le circuit d’escalade, la préservation des éléments de preuve et les suppléances n’ont pas été définis. Le coût réel apparaîtra lors d’un exercice ou d’un incident, lorsqu’il faudra reconstruire la procédure. Le budget doit donc distinguer les dépenses ponctuelles des coûts récurrents et inclure les honoraires de conseil, les investissements techniques, les indisponibilités liées au projet, les corrections et le maintien annuel : revues, tests, formations, actualisation documentaire, évaluation des fournisseurs et traitement des incidents.

Un système de management de la sécurité de l’information opérationnel ou une certification peut réduire les travaux d’inventaire, d’appréciation des risques, de maîtrise documentaire et d’audit, à condition que les dispositions concernées fonctionnent effectivement dans le périmètre analysé. Cela ne remplace cependant ni l’évaluation des obligations précises résultant des textes applicables ni la vérification de l’adéquation des mesures existantes aux services concernés. Cette articulation est expliquée dans l’article NIS2 et NF EN ISO 27001 : ce qu’apporte la certification et ce qui reste nécessaire pour répondre aux exigences du KSC.

Le calendrier dépend avant tout de la capacité à prendre des décisions

Le délai nécessaire pour se préparer aux exigences de NIS2 dépend rarement de la vitesse de rédaction des procédures. Les principaux facteurs limitants sont la disponibilité de données fiables, des propriétaires de processus et des personnes habilitées à valider les changements. Le planning doit tenir compte de leur disponibilité réelle, de la fréquence des réunions du comité de pilotage et du temps nécessaire aux arbitrages interfonctionnels. Une date annoncée pour la remise de la documentation ne constitue pas un indicateur d’avancement si l’organisation n’a pas validé le périmètre, les responsabilités et les priorités.

Les travaux doivent être ordonnés selon leurs dépendances. Il faut d’abord définir le périmètre, les rôles, les processus et les actifs, puis réaliser l’appréciation des risques, adopter le plan de traitement des risques, mettre en œuvre les mesures, effectuer les tests et constituer les preuves de fonctionnement. Certaines tâches reposant sur des hypothèses déjà validées peuvent être conduites en parallèle, par exemple l’inventaire des contrats et la revue des mesures existantes. En revanche, une analyse détaillée des risques ne doit pas commencer avant que les services, processus, systèmes, informations et dépendances fournisseurs inclus dans l’évaluation aient été identifiés.

Pour ordonnancer les actions, il convient de distinguer les écarts nécessitant des achats, des modifications contractuelles, des intégrations techniques ou des tests. Chacune de ces catégories suit son propre circuit de validation et son propre calendrier. Un appui externe peut accélérer le diagnostic, rendre les ateliers plus efficaces et structurer leurs résultats. En revanche, le consultant ne peut pas décider à la place de la direction de l’acceptation d’un risque, de l’ordre des investissements ou de la durée d’interruption de service jugée tolérable. Lorsque ces arbitrages sont reportés à la fin du projet, la documentation prend de l’avance sur les solutions opérationnelles et certaines analyses doivent être reprises.

L’avancement doit donc être mesuré au regard du nombre de décisions validées, de dépendances traitées et de mesures dont l’efficacité a été vérifiée, et non au nombre de documents rédigés. Même un calendrier de quelques semaines devient irréaliste si l’organisation ne possède ni liste à jour de ses systèmes, ni registre de ses contrats fournisseurs, ni propriétaires de processus désignés. L’équipe pourra alors décrire un état déclaratif, sans être en mesure d’attribuer clairement la responsabilité de la continuité d’activité, du rétablissement du service ou de la surveillance du fournisseur.

La cartographie des processus doit soutenir ces décisions, et non alourdir la documentation. Le comparatif « BPMN ou logigramme : quel outil choisir pour cartographier les processus qualité ? » aide à sélectionner le bon niveau de détail. Dans ce contexte, l’outil pertinent est celui qui fait apparaître clairement les rôles, les transferts de responsabilité, les dépendances informationnelles ainsi que les domaines nécessitant des mesures de protection ou de suppléance.

Le risque provient avant tout d’hypothèses erronées

La réussite d’une préparation à NIS2 dépend souvent davantage de la pertinence des hypothèses que du nombre de tâches réalisées. Dans un modèle entièrement interne, les principaux risques sont une interprétation incorrecte du périmètre, l’omission de dépendances métier et la réduction de la cybersécurité à une responsabilité purement informatique. L’organisation peut alors négliger les processus industriels, la logistique, la maintenance, la continuité des approvisionnements ou ses engagements envers les clients. Elle se prive également d’un regard indépendant sur des pratiques considérées comme suffisantes uniquement parce qu’elles n’ont encore provoqué aucune perturbation visible.

L’accompagnement externe ne supprime pas automatiquement ces risques. Ils augmentent lorsque le prestataire fournit un ensemble documentaire standard sans analyser les services, les processus et les dépendances de l’organisation, lorsqu’il n’associe pas les propriétaires de processus ou lorsqu’il ne transmet pas les connaissances nécessaires au maintien des dispositions retenues. Le système dépend alors de l’auteur de la documentation plutôt que des personnes responsables des opérations quotidiennes.

Il est donc utile de séparer la réalisation des travaux de l’évaluation finale indépendante, notamment lorsque le même prestataire a défini le périmètre, apprécié les risques et sélectionné les mesures. La décision d’accepter le risque résiduel doit rester de la responsabilité du niveau de management compétent.

Une conformité de façade se révèle par l’écart entre les documents et les pratiques : la politique décrit un fonctionnement différent de la réalité, le registre des risques n’oriente ni les priorités ni les investissements, et la procédure de gestion des incidents n’a jamais été testée. Un écart documentaire correspond à l’absence ou à l’incohérence d’un document ou d’un enregistrement nécessaire. Un écart opérationnel existe lorsque l’organisation n’est pas capable d’exécuter une action, d’en attribuer la responsabilité ou de produire une preuve de son efficacité. Compléter un formulaire peut corriger le premier écart, mais ne remplace ni un test, ni une décision, ni une évolution des pratiques.

On peut citer le cas d’un site industriel disposant d’une procédure approuvée de signalement des incidents, alors que les opérateurs de production ne savent pas comment déclarer l’indisponibilité d’un système de contrôle ou de planification. Parallèlement, aucun circuit d’escalade, contact désigné ou mode de fonctionnement hors heures ouvrées n’a été convenu avec le prestataire. Le document existe, mais les premières minutes de la perturbation sont perdues à rechercher qui doit agir. Seul un exercice associant l’utilisateur, le propriétaire du processus, l’informatique, la direction et le fournisseur permet de détecter cet écart.

Un audit de préparation doit évaluer la capacité à agir et à présenter des preuves fiables, et non la seule complétude documentaire. Les indicateurs utiles peuvent inclure le nombre d’actions non réalisées à la suite d’audits et de tests antérieurs, les résultats des essais de restauration, les enseignements tirés des incidents et des perturbations, ainsi que la proportion de fournisseurs critiques évalués et soumis à des exigences convenues — toujours à partir des données propres à l’organisation. La méthode de vérification est approfondie dans l’article « Audit NIS2 dans une entreprise industrielle : comment vérifier si l’organisation est prête à répondre aux nouvelles obligations ».

Le modèle hybride offre généralement la meilleure maîtrise

Le choix du mode de mise en œuvre doit découler de la capacité réelle de l’organisation à réaliser les travaux, et non de la seule comparaison des tarifs de conseil. Une réalisation interne est pertinente lorsque le projet dispose d’un pilote compétent, que les processus de management des risques sont suffisamment matures, que les inventaires d’actifs et de dépendances sont à jour, et que les personnes clés ont le temps et les compétences nécessaires pour interpréter les exigences. Un accompagnement externe plus complet est justifié en cas de déficit important de compétences, de structure dispersée, de fortes dépendances technologiques, de délai court ou d’absence de système de management structuré.

Dans la plupart des cas, le modèle hybride offre la meilleure maîtrise des coûts, des délais et des risques. L’organisation reste responsable des décisions, des données sources, de la propriété des risques et de l’exécution des actions opérationnelles. Le consultant prend en charge le diagnostic, la méthodologie, l’animation des ateliers, les analyses nécessitant une expertise spécialisée et le contrôle qualité des résultats.

Les responsabilités suivantes doivent au minimum rester dans l’organisation :

• déterminer la criticité des processus et des services ;
• désigner les propriétaires des risques ;
• accepter les risques résiduels ;
• définir les priorités d’investissement ;
• confirmer l’efficacité opérationnelle des mesures.

La direction ne peut pas transférer au prestataire sa responsabilité en matière de résilience de l’organisation.

Une entreprise possédant plusieurs sites peut collecter elle-même les informations relatives à ses services, actifs, fournisseurs et impacts des perturbations, car leur évaluation fiable nécessite une connaissance opérationnelle. Un spécialiste externe peut ensuite structurer la méthode d’évaluation, remettre en question les incohérences, animer des ateliers transversaux et vérifier la complétude des preuves. La pertinence économique de cette répartition dépend du nombre et des compétences des personnes pouvant réellement être affectées au projet, et non de la composition formelle de l’équipe projet.

Les offres doivent être comparées à partir d’un périmètre de livrables et de critères de réception identiques. Les références du prestataire doivent être appréciées selon la proximité du secteur, de la taille, des processus et de l’environnement technologique, et non d’après le seul nombre de missions réalisées. Le contrat doit préciser clairement les livrables, les critères de réception, l’obligation d’adapter les solutions aux processus réels, le transfert de connaissances, les règles de confidentialité et d’accès aux données sensibles, la responsabilité relative aux corrections et le niveau d’assistance après la mise en œuvre. Le modèle de rémunération ne doit pas récompenser le volume de documents, mais l’obtention de résultats convenus et vérifiables.

La répartition opérationnelle des responsabilités entre la direction, les propriétaires de processus et les fonctions support est approfondie dans l’article NIS2 dans la pratique managériale : traduire les exigences en décisions, en responsabilités et en résilience réelle.

Fondez la décision sur les preuves et sur la capacité à maintenir le dispositif

Le choix du modèle de mise en œuvre doit être précédé d’un diagnostic organisationnel concis. Il faut confirmer le périmètre du projet, désigner son pilote, évaluer les compétences disponibles, inventorier les preuves de fonctionnement existantes et estimer les principaux écarts. Ce n’est qu’ensuite qu’il devient possible de décider quels travaux seront réalisés en interne et dans quels domaines l’intervention d’un spécialiste réduira le risque d’erreur d’interprétation, d’omission ou de reprise.

La décision de la direction doit comparer trois scénarios : la réalisation en interne, le modèle hybride et un accompagnement externe plus complet. Les mêmes critères doivent être appliqués à chacun :

• le coût complet, incluant le temps du personnel, les corrections et le maintien du dispositif ;
• le délai nécessaire pour atteindre une capacité opérationnelle réelle ;
• le risque d’erreur et de reprise des travaux ;
• la disponibilité effective des compétences ;
• la capacité de l’organisation à maintenir les solutions de manière autonome.

La résolution ou la décision de la direction doit préciser le scénario retenu, la répartition des responsabilités, le pilote du projet, les ressources, les modalités de reporting, les critères de réception et les indicateurs d’efficacité issus des processus de l’organisation, plutôt que de seuils universels dépourvus de contexte.

La réception de la mise en œuvre ne doit pas reposer sur le nombre de politiques produites. Le résultat attendu est un fonctionnement reproductible : rôles attribués, décisions relatives aux risques documentées, mesures effectivement appliquées, réponses aux perturbations et aux incidents testées, fournisseurs maîtrisés et enregistrements fiables. Une procédure de réponse approuvée ne démontre pas la préparation si un test révèle des coordonnées obsolètes, un circuit d’escalade ambigu ou l’absence d’une personne habilitée à décider.

Les critères de réception doivent couvrir la cohérence entre les documents et les pratiques, la clôture des écarts convenus, les résultats des tests, le transfert des connaissances et un plan clair d’amélioration continue, comprenant notamment le programme d’audits internes. Les preuves de réception peuvent inclure les validations, les registres, les résultats d’essais, les comptes rendus de formation, les décisions relatives aux risques et les confirmations de réalisation des actions. La préparation et le maintien de ces preuves sont développés dans l’article Documentation NIS2 et KSC avant un contrôle : quelles politiques, quels registres et quelles preuves faut-il réellement détenir ?.

La pérennité du dispositif ne peut être évaluée qu’après la réduction de l’intervention du consultant. Les propriétaires de processus doivent alors être capables de mettre à jour les registres, de prendre les décisions relatives aux risques, d’analyser les résultats des tests et de lancer les actions correctives de manière autonome. Si le système ne fonctionne que grâce aux connaissances du prestataire, le projet n’est pas achevé : l’organisation a reçu de la documentation, mais n’a pas développé la capacité nécessaire pour la maintenir.