« On le mettra en conformité après » : le vrai coût de la négligence

« On le mettra en conformité après. » En seize ans de sécurité offensive, nous avons entendu cette phrase des dizaines de fois, dans la banque, le nucléaire, le spatial, la défense ou au sein de grands groupes du CAC 40. Et presque à chaque fois, le « après » est arrivé sous la même forme : un incident.

Un outil d'IA à déployer avant la concurrence. Un client stratégique à signer cette semaine. Une mesure de sécurité repoussée au prochain trimestre, puis au suivant. Pris isolément, aucun de ces arbitrages n'est absurde. C'est leur accumulation qui finit par coûter cher.

Cet article n'est pas un procès des directions. Il part d'un constat de terrain : le conflit entre business et sécurité n'est presque jamais un problème de mauvaise volonté. C'est un problème de visibilité, de langage et de gouvernance. Et chacun de ces trois points se traite.

L'urgence business passe toujours devant

Pour une direction, faire du chiffre est primordial. C'est légitime : une entreprise qui ne vend pas ne survit pas, et la sécurité ne génère pas de revenu directement.

Le problème commence quand chaque sujet de sécurité, de conformité ou de protection des données est arbitré contre un contexte business urgent. Dans ce cas, la sécurité perd presque toujours. Non pas parce qu'elle a tort, mais parce que la comparaison est déséquilibrée dès le départ.

D'un côté, le gain business est certain, immédiat et chiffré : un contrat, un délai tenu, une fonctionnalité livrée. De l'autre, le risque cyber est probable, différé et rarement chiffré : « une attaque pourrait exploiter cette faiblesse ». Face à cette asymétrie, l'arbitrage penche naturellement du côté du concret. Et tant qu'aucun incident ne survient, chaque report semble donner raison à celui qui l'a décidé.

Nous avons vu ce schéma se répéter dans des secteurs très différents :

• Un outil d'IA mis en production avant toute validation de sécurité, parce que « les équipes l'attendent »
• Une application connectée à la messagerie ou aux documents de l'entreprise sans revue des droits qu'elle obtient
• Un changement d'architecture ou de droits d'accès réalisé dans l'urgence, sans revue
• Une mise en conformité RGPD ou réglementaire repoussée faute de budget
• Un correctif critique décalé pour ne pas perturber une période commerciale
• Un compte à privilèges créé « temporairement » pour un prestataire, et jamais supprimé

Aucun de ces exemples n'est spectaculaire. C'est justement ce qui les rend dangereux : ils s'accumulent en silence, jusqu'au jour où un attaquant les enchaîne.

Le cas de l'IA : l'urgence à l'état pur

L'IA générative illustre parfaitement ce mécanisme. La pression est forte : les équipes veulent l'utiliser, la direction veut montrer que l'entreprise avance, et les outils sont faciles à brancher en quelques minutes.

Résultat, des assistants IA se retrouvent connectés à des messageries, des espaces documentaires ou des applications métier sans que personne ait vérifié ce qu'ils peuvent lire, où partent les données, ni qui y a accès. Un connecteur mal configuré peut exposer en une seule fois ce que des années de cloisonnement avaient protégé.

Mettre un outil d'IA en conformité après coup est particulièrement difficile : les usages sont déjà installés, les données déjà transmises, et revenir en arrière est perçu comme une régression. Une revue de quelques jours en amont aurait souvent suffi.

Des collaborateurs qui ne voient pas ce que voit la DSI

Il y a un second frein, moins visible que le budget : l'écart d'information entre les équipes métier et la DSI.

Un collaborateur qui installe un outil gratuit, connecte une application à sa messagerie ou partage un fichier sensible avec un prestataire ne pense pas mal faire. Il cherche à aller plus vite, avec les informations dont il dispose. Ce qu'il ne voit pas, c'est tout ce que la DSI et le RSSI voient chaque jour :

• la cartographie des données sensibles et de leurs flux ;
• les exigences de sécurité imposées par les contrats clients ;
• les obligations réglementaires (RGPD, NIS2, exigences sectorielles) ;
• les tentatives d'intrusion, d'hameçonnage et les alertes traitées en continu ;
• l'historique des incidents, dans l'entreprise et chez ses pairs.

Pour lui, une règle de sécurité ressemble à une contrainte arbitraire. Pour la DSI, la même règle est la conséquence directe de risques bien réels. Chacun a raison avec ses propres informations, et personne ne parle de la même chose.

Cet écart produit des situations que nous retrouvons partout :

• La règle contournée : un outil interdit sans explication est remplacé par un compte personnel ou un téléphone privé. L'usage ne disparaît pas, il devient invisible.
• La demande perçue comme un blocage : le métier vit la revue de sécurité comme une perte de temps, la sécurité vit la demande tardive comme une mise devant le fait accompli.
• Le signalement qui n'arrive pas : un collaborateur qui ne comprend pas les enjeux ne remonte pas un comportement suspect, ou le fait trop tard.

La responsabilité est partagée. Les équipes de sécurité expliquent trop rarement le « pourquoi » de leurs règles. Les métiers associent trop tard la sécurité à leurs projets. Tant que cet écart n'est pas comblé, chaque projet urgent rejoue le même conflit.

Le RSSI entre deux réalités

C'est le quotidien de beaucoup de RSSI : faire plus avec moins, et remonter des risques que personne ne veut entendre tant qu'ils restent théoriques.

Le RSSI doit tenir compte de la réalité du business, sans quoi il devient l'interlocuteur que l'on contourne et que l'on informe en dernier. Il doit aussi défendre la réalité du contexte cyber, sans quoi il valide des risques qu'il sait dangereux. Trouver la juste mesure entre les deux est l'un des exercices les plus difficiles du métier.

Deux pièges guettent. Le premier est de tout bloquer : chaque demande devient un refus, et la sécurité perd sa légitimité auprès des métiers. Le second est de tout laisser passer pour préserver la relation : les risques s'accumulent, et le RSSI en porte la responsabilité au moment de l'incident.

Le rôle du RSSI n'est pas de dire oui ou non. C'est d'éclairer une décision qui appartient à la direction, en lui donnant les éléments pour la prendre en connaissance de cause.

Ce qui se passe le jour où l'incident arrive

Quand l'incident survient, la tension qui avait été évitée au moment de l'arbitrage revient d'un coup, et dans les pires conditions.

Les décisions doivent être prises dans l'urgence, souvent sans visibilité complète. Les équipes techniques travaillent sous pression pour contenir l'attaque et restaurer les services. La direction découvre des risques qu'elle pensait maîtrisés. Les obligations de notification s'imposent, auprès des autorités et parfois des personnes concernées. Les clients et partenaires demandent des comptes.

Et très vite, une question revient : « qui avait validé ça ? ». C'est souvent à ce moment que l'on découvre que personne ne l'avait formellement validé. Le risque avait simplement été repoussé, sans que quiconque l'ait explicitement accepté.

Une mesure de sécurité a un coût visible : du temps, un budget, parfois un projet décalé de quelques jours. La négligence a un coût différé, et presque toujours plus élevé : gestion de crise, interruption d'activité, remédiation en urgence, atteinte à la réputation. Le premier coût se discute en comité. Le second s'impose à vous au pire moment.

Un sujet de direction, pas seulement de technique

Le cadre réglementaire va dans le même sens. La directive européenne NIS2 prévoit que les organes de direction des entités concernées approuvent les mesures de gestion des risques cyber, en supervisent la mise en œuvre et puissent être tenus responsables de leurs manquements. Elle prévoit aussi qu'ils se forment à ces sujets.

Autrement dit, la cybersécurité n'est plus un sujet que l'on peut déléguer entièrement à la DSI. La décision de reporter une mesure de sécurité est une décision de direction, et elle doit être assumée comme telle.

C'est aussi le principe de la norme ISO 27001 : chaque risque identifié a un propriétaire, et un risque que l'on choisit de ne pas traiter doit être explicitement accepté par la personne qui en a l'autorité.

Trouver la juste mesure : notre méthode

Il ne s'agit pas de choisir entre business et sécurité, mais de les faire avancer ensemble. Voici les principes que nous appliquons sur le terrain.

1. Traduire le risque en langage business

Une direction arbitre mieux un scénario concret qu'une alerte technique. Pour chaque risque important, nous formulons quatre éléments :

• le scénario : ce qu'un attaquant pourrait faire, concrètement ;
• l'impact : sur l'activité, les clients, les obligations réglementaires ;
• la probabilité : au regard de l'exposition réelle et des menaces observées ;
• le coût de traitement : en jours, en budget, et ce que l'on peut faire tout de suite.

Ce format transforme « il faudrait corriger cette faille » en une décision que la direction peut réellement prendre.

2. Rendre chaque report explicite

Reporter une mesure n'est pas un problème en soi. Ce qui pose problème, c'est le report implicite, que personne ne porte. Nous recommandons que chaque risque non traité fasse l'objet d'une acceptation formelle, avec un propriétaire, une justification et une date de réexamen.

Ce simple geste change la dynamique : quand il faut signer l'acceptation d'un risque, on regarde le risque autrement.

3. Intégrer la sécurité dès le début des projets

Une revue de sécurité en amont coûte toujours moins cher qu'une remise en conformité après la mise en production. Pour les projets sensibles, en particulier les outils d'IA et les services exposés sur internet, un point de contrôle léger avant la mise en service suffit souvent : quelles données, quels accès, quelle exposition, quel test.

4. Expliquer avant d'imposer

Une règle comprise est appliquée, une règle subie est contournée. Partager avec les collaborateurs une partie de ce que voit la DSI (des exemples d'attaques réelles, les exigences de vos clients, les conséquences concrètes d'une fuite) réduit fortement l'écart de perception.

5. Proposer des alternatives plutôt que des interdictions

Si un besoin métier est réel, l'interdire ne le fait pas disparaître. Proposer une solution validée, aussi simple à utiliser que l'outil non autorisé, est presque toujours plus efficace.

6. Prioriser selon le risque réel

Tout ne peut pas être traité en même temps. C'est là qu'un regard offensif fait la différence : tester comme un attaquant permet de distinguer ce qui est réellement exploitable de ce qui ne l'est pas, et de concentrer les efforts là où ils comptent.

Quelques questions pour faire le point

Si vous êtes dirigeant, posez-vous ces questions :

1. Savez-vous quels risques cyber ont été repoussés au cours des douze derniers mois, et par qui ?
2. Ces reports ont-ils été formellement acceptés, avec une date de réexamen ?
3. Vos projets d'IA et vos nouveaux outils passent-ils par une revue de sécurité avant leur mise en service ?
4. Vos collaborateurs comprennent-ils pourquoi les règles de sécurité existent ?
5. Votre RSSI a-t-il un accès régulier à la direction, en dehors des périodes de crise ?

Si plusieurs réponses restent floues, c'est le bon moment pour agir, avant qu'un incident ne le fasse à votre place.

Être entendu avant l'incident

La sécurité n'est pas un frein à l'activité : c'est ce qui lui permet de durer. La sécurité a un prix. La négligence aussi. Elle se paie simplement plus tard, et plus cher.

Notre rôle est d'aider les directions et les RSSI à trouver ce juste équilibre : un regard d'attaquant pour identifier les risques réels, une approche structurée selon les normes reconnues pour les gouverner, et un discours que les métiers comprennent.

Vous avez un projet urgent qui touche à la sécurité, à la conformité ou à l'IA, et vous voulez l'avancer sans le payer plus tard ? Parlons-en : écrivez-nous via le formulaire de contact.