Le système d’information ne s’arrête plus aux frontièresde l’entreprise. Une identité ouvre plusieurs environnements, un prestataire dispose d’un accès distant, une application dépend d’API et de bibliothèques tierces, un service SaaS héberge des données critiques, un équipement industriel reste connecté pendant 15 ans et des certificats ou des clés cryptographiques circulent dans des couches techniques parfois mal inventoriées.
La sécurité ne consiste plus seulement à défendre un périmètre, elle suppose de comprendre précisément de quoi l’entreprise dépend, qui peut y accéder et jusqu’où une
compromission peut se propager.
Cette évolution change la nature des angles morts. Une organisation peut connaître ses applications les plus stratégiques sans disposer d’une vision aussi nette des identités, composants, accès prestataires ou objets cryptographiques qui leur sont associés. Le problème ne réside plus uniquement dans l’absence de protection mais dans l’écart entre le système d’information tel qu’il est représenté et celui qui fonctionne réellement.
Ces dépendances sont en outre de plus en plus mouvantes. Les comptes peuvent devenir temporaires, les agents IA introduisent de nouvelles identités non humaines, les conteneurs apparaissent et disparaissent, tandis que les entreprises restent tributaires de leurs fournisseurs pour corriger une vulnérabilité, faire évoluer un logiciel ou préparer une migration cryptographique.
La stratégie centrale pour 2026 n’est donc pas de tout surveiller avec la même intensité mais de retrouver suffisamment de visibilité pour hiérarchiser. Quels sont les actifs réellement critiques ? Quels accès doivent être temporaires ou strictement contrôlés ? Quelles dépendances extérieures peuvent produire un effet domino ? Et parmi des milliers de signaux, lesquels justifient réellement une action immédiate ?
Identités, supply chain, environnements IT et OT, cryptographie, threat intelligence ou SOC
répondent ainsi à un même défi : reprendre le contrôle d’un système d’information dont une part croissante de la sécurité dépend désormais d’acteurs, de composants et de mécanismes que l’entreprise ne maîtrise jamais totalement.
Voir ce dont on dépend : identités, actifs, cryptographie
Avant de protéger, encore faut-il savoir ce qui existe réellement dans le système d’information. Or, cette connaissance devient plus difficile à maintenir à mesure que les environnements se fragmentent entre cloud, SaaS, applications internes, conteneurs, équipements industriels, comptes utilisateurs, identités machines et services tiers.
Jérôme Renoux et Fabio Costa, respectivement vice-président France et ingénieur solutions senior chez Akamai Technologies, insistent notamment sur l’extension continue de la surface d’attaque et sur la nécessité de disposer d’une vision globale des actifs et applications exposés. Le premier défi n’est plus seulement de poser des contrôles de sécurité mais de conserver une représentation suffisamment fidèle du SI pour savoir où ils doivent s’appliquer.
Le déplacement est particulièrement visible du côté des identités. La sécurité périmétrique a longtemps permis de présumer qu’une connexion provenant du réseau interne présentait déjà un certain niveau de confiance. Ce raisonnement tient beaucoup moins dans un environnement où les collaborateurs travaillent à distance et accèdent directement à des services SaaS. « Le focus va vers l’identité », résume Marc Balasko, Solutions Engineering Manager chez Wallix. Une identité compromise peut désormais donner accès à plusieurs ressources sans jamais traverser les frontières traditionnelles de l’entreprise. Le MFA devient dès lors moins une protection supplémentaire qu’un prérequis, tandis que les comptes à privilèges concentrent toujours davantage le risque.
Cette visibilité ne concerne plus uniquement les utilisateurs humains. Les échanges machine to machine existent depuis longtemps mais l’essor des agents IA ajoute des identités potentiellement beaucoup plus nombreuses et plus éphémères. Marc Balasko pose une question qui reste encore largement ouverte : un agent doit-il conserver sa propre identité, hériter de celle de l’utilisateur qui l’a lancé ou en obtenir une nouvelle à chaque action ? Dans des environnements aussi fluctuants, la gestion ne pourra pas reposer sur des validations humaines systématiques. Elle devra elle-même devenir largement automatisée.
Le même problème de connaissance se retrouve du côté des actifs. Pour un SOC, un inventaire n’a de valeur que s’il fournit suffisamment de contexte pour distinguer les ressources. Serge Carpentier, directeur des opérations de SysDream, prend l’exemple d’une entreprise capable de fournir la liste de ses machines mais qui ne peut pas préciser lesquelles relèvent de la production, de la préproduction ou de la recette, lesquelles sont exposées sur Internet ou contiennent des données personnelles. Dans ce cas-là, les alertes risquent d’être traitées avec le même niveau de priorité. Une faiblesse sur une machine de recette peut alors mobiliser les équipes pendant qu’un incident plus grave touche l’environnement de production.
La cryptographie ajoute encore une couche moins visible. Certificats, clés, secrets, tokens, protocoles ou bibliothèques sont disséminés dans les serveurs, applications, conteneurs, microservices et équipements. Pour Pierre Codis, AVP of Sales Nordics & Southern Europe chez Keyfactor, le problème du passage au post-quantique commence précisément là : « Si vous ne savez pas ce que vous avez, c’est difficile de migrer vers quelque chose de plus robuste. » L’inventaire cryptographique ne peut donc pas se limiter à une photographie ponctuelle, il doit être continu et replacer chaque objet dans son contexte métier : qui l’utilise, pour quoi faire et sur quelle application critique.
Cette exigence de visibilité devient ainsi le préalable commun à plusieurs chantiers qui pourraient sembler éloignés. Impossible de réduire les privilèges sans identifier les identités concernées, de prioriser une alerte sans connaître la criticité de l’actif ou de préparer une migration cryptographique sans savoir quels algorithmes sont utilisés et où. Avant même de parler de protection, les entreprises doivent donc réduire l’écart entre le système d’information qu’elles pensent administrer et celui qui fonctionne réellement.
Tiers et supply chain : sécuriser ce que l’on ne maîtrise pas
Une part croissante du risque cyber se joue désormais hors des murs de l’entreprise. Prestataires, fournisseurs cloud, éditeurs, partenaires techniques ou composants logiciels interviennent directement dans le fonctionnement du système d’information sans appartenir pour autant à l’organisation qui en dépend. La difficulté n’est donc plus seulement de protéger ses propres actifs mais d’évaluer jusqu’où la compromission d’un tiers peut atteindre les ressources internes.
Pour Serge Carpentier, directeur des opérations de SysDream, ce déplacement est déjà visible dans les modes d’attaque : « Les attaquants ne vont plus frapper par la porte d’entrée principale de l’organisation. Ils entrent par le prestataire. » Le problème ne réside pas uniquement dans l’existence de cet accès extérieur mais dans la capacité de l’entreprise à avoir correctement mesuré le risque qu’il introduit dans son propre SI. Un fournisseur peut ainsi devenir le point de départ d’une compromission sans que le client dispose d’une visibilité suffisante sur les droits accordés, les données accessibles ou les conséquences possibles d’un incident.
La sécurisation des accès tiers illustre particulièrement cette difficulté. Les grandes entreprises peuvent multiplier les validations avant d’autoriser un nouveau prestataire à intervenir mais cette rigueur a un coût opérationnel. Marc Balasko, Solutions Engineering Manager chez Wallix, décrit des processus dans lesquels plusieurs jours, voire une semaine, peuvent s’écouler entre la demande d’un métier et l’autorisation effective d’un partenaire. Or, l’intervention peut être urgente. « Il y a une vraie tension » entre besoins métiers et besoins de sécurité, souligne-t-il, avec un risque très concret : que les équipes finissent par contourner les procédures lorsqu’elles deviennent trop contraignantes.
L’enjeu n’est donc pas d’accumuler les barrières mais de rapprocher l’autorisation de ceux qui connaissent réellement le besoin. Wallix observe ainsi une demande pour des mécanismes permettant aux métiers de déléguer un accès sur un périmètre très précis, pour une intervention déterminée sans attendre systématiquement une validation centrale. Cette logique rejoint celle des privilèges temporaires : donner l’accès au moment où il est nécessaire, puis le retirer. La réduction du risque passe autant par la précision des droits accordés que par leur durée de vie.
La dépendance ne se limite cependant pas aux comptes des prestataires, elle peut être enfouie plusieurs niveaux plus bas dans la chaîne logicielle. La threat intelligence met régulièrement en évidence le rôle de composants ou de bibliothèques utilisés par de nombreux produits : la compromission d’une brique maintenue par une petite équipe peut se propager à l’ensemble des logiciels et services qui l’intègrent. Le risque prend alors la forme d’un effet domino, où l’organisation touchée n’a ni choisi directement le composant vulnérable ni nécessairement connaissance de son existence.
Cette profondeur de dépendance complique aussi la réponse. Identifier le fournisseur directement contracté ne suffit plus : il faut pouvoir comprendre ses propres dépendances, celles de ses logiciels, les accès qu’elles utilisent et les données qu’elles peuvent atteindre. La supply chain devient ainsi moins une liste de fournisseurs à contrôler qu’une cartographie de relations techniques et opérationnelles à maintenir.
Pour les entreprises, la priorité est donc de réduire la confiance implicite. Un tiers ne doit pas disposer d’un accès durable simplement parce qu’il est connu, pas plus qu’un composant ne doit être considéré comme sûr parce qu’il est intégré depuis longtemps. Chaque dépendance doit être reliée à un périmètre, une criticité, des droits et une capacité de révocation. La maîtrise de la supply chain commence précisément à cet endroit : savoir jusqu’où s’étend la confiance accordée et pouvoir la retirer avant qu’une compromission ne se transforme en propagation.
IT/OT : tous les actifs ne se valent pas
Cartographier ne suffit pas, encore faut-il savoir ce qui mérite d’être protégé en priorité. Dans un système d’information mêlant applications métiers, infrastructures cloud, équipements industriels et environnements anciens, la criticité ne peut pas être définie de manière uniforme. Une fuite de données, l’arrêt d’une chaîne de production ou la compromission d’un poste d’administration n’ont ni les mêmes conséquences ni les mêmes délais acceptables de réaction.
« C’est un peu le job de l’entreprise », résume Marc Balasko, Solutions Engineering Manager chez Wallix, lorsqu’il s’agit de définir ce qui est réellement critique. La question doit d’abord être posée en termes d’impact : perte de confidentialité, interruption d’activité, conséquences financières ou atteinte à un système industriel. Cette hiérarchisation conditionne ensuite les niveaux de protection, les accès autorisés et l’ordre dans lequel les équipes doivent intervenir.
L’industriel rend cette démarche particulièrement difficile. Les équipements récents sont généralement mieux inventoriés mais une partie du parc reste constituée de systèmes installés depuis 10 ou 15 ans. Les équipes locales savent souvent qu’ils existent, sans que l’information soit toujours consolidée au niveau du groupe. Marc Balasko évoque ainsi des environnements où les machines industrielles anciennes ou les PLC sont connus sur site mais beaucoup moins visibles depuis les fonctions centrales.
Cette situation crée une différence importante entre connaissance locale et visibilité globale. Un équipement peut être parfaitement identifié par l’équipe qui l’exploite quotidiennement tout en restant absent d’un inventaire central ou insuffisamment documenté du point de vue de la sécurité. Les « trous » dans la cartographie viennent alors moins d’une absence totale d’information que de son éclatement entre plusieurs équipes, plusieurs outils et plusieurs niveaux de l’organisation.
Le problème dépasse d’ailleurs l’OT. Dans l’IT aussi, la nature des actifs évolue rapidement. Il y a 10 ou 15 ans, la cartographie reposait encore largement sur des serveurs physiques. Les machines virtuelles ont ensuite complexifié cette vision, avant l’arrivée des conteneurs et d’environnements de plus en plus éphémères. À chaque étape, la durée de vie des ressources raccourcit tandis que leur nombre augmente. La représentation du SI doit donc évoluer avec lui, sous peine de devenir obsolète au moment même où elle est produite.
Le SOC rencontre directement les conséquences de ces lacunes. Serge Carpentier, directeur des opérations de SysDream, souligne que la qualité de la priorisation dépend du contexte disponible sur l’actif : environnement de production ou de recette, exposition sur Internet, présence de données sensibles, rôle dans le SI… Sans ces informations, les équipes risquent de traiter des alertes avec un niveau de priorité qui ne correspond pas à leur impact réel.
La maturité ne consiste donc pas à appliquer partout le même dispositif. Les principes restent communs : contrôler les accès, tracer les actions, limiter les privilèges et surveiller les ressources critiques. Mais leur mise en œuvre diffère profondément entre un environnement industriel ancien, un service cloud ou une infrastructure conteneurisée. « Ce n’est pas du tout le même paradigme technique », rappelle Marc Balasko.
Pour les entreprises, l’enjeu est de relier enfin trois informations qui restent encore trop souvent séparées : l’existence d’un actif, sa fonction métier et les conséquences de sa compromission. C’est cette combinaison qui permet de distinguer ce qui doit simplement être surveillé de ce qui ne peut pas se permettre de tomber.
Post-quantique : cartographier avant de migrer
La transition post-quantique peut donner l’impression d’un chantier lointain, réservé aux spécialistes de la cryptographie. Pourtant, son principal obstacle est beaucoup plus concret : les entreprises ne savent pas toujours précisément où la cryptographie est utilisée dans leur système d’information. Certificats, clés, secrets, tokens, protocoles ou bibliothèques sont disséminés dans les applications, serveurs, conteneurs, microservices et équipements. Avant même de choisir de nouveaux algorithmes, il faut donc retrouver ces dépendances.
L’ANSSI a fixé un premier jalon à partir de 2027 pour les produits de sécurité entrant dans son processus de qualification, avec l’intégration progressive de mécanismes résistants au quantique. Pour les entreprises, ce calendrier agit aussi sur le choix des fournisseurs : les produits capables d’évoluer vers la cryptographie post-quantique vont progressivement devenir un critère de sélection. Pierre Codis, de chez Keyfactor, y voit une conséquence très directe : les entreprises ne pourront pas mener leur propre migration indépendamment des éditeurs, fabricants et fournisseurs dont dépendent leurs systèmes.
Le premier chantier n’est donc pas le remplacement d’un algorithme. « Si vous ne savez pas ce que vous avez, c’est difficile de migrer vers quelque chose de plus robuste », souligne-t-il. Un inventaire cryptographique doit identifier les clés et certificats mais également les secrets, tokens, protocoles, librairies et autres objets qui utilisent de la cryptographie. Et cette cartographie ne peut pas rester une photographie figée : une application évolue, un certificat est renouvelé, un microservice apparaît, une bibliothèque change de version. L’inventaire doit donc être maintenu en continu et replacé dans son contexte métier.
Cette connaissance permet ensuite de hiérarchiser la migration. Toutes les données n’ont pas besoin d’être protégées pendant la même durée et toutes les applications n’ont pas la même criticité. Le risque dit harvest now, decrypt later ajoute ici une contrainte particulière : des données chiffrées interceptées aujourd’hui pourraient être conservées jusqu’au moment où des capacités quantiques permettraient de les déchiffrer. Une information qui doit rester confidentielle au-delà de la prochaine décennie peut donc être concernée bien avant l’arrivée d’un ordinateur quantique capable de casser les mécanismes actuels.
La migration elle-même ne se fera pas en une seule étape. Les approches hybrides combinent temporairement cryptographie classique et mécanismes post-quantiques afin de traverser une période où tous les équipements et logiciels ne seront pas compatibles au même rythme. Cette coexistence introduit néanmoins de nouvelles contraintes : davantage de clés à gérer, des impacts possibles sur les performances ou le stockage et surtout une dépendance aux feuilles de route des fournisseurs. « Tout ça ne se fait pas en un mois », insiste Pierre Codis, qui évoque des projets pouvant s’étaler sur deux, trois voire quatre ans.
C’est précisément pour éviter une nouvelle migration lourde à chaque évolution que l’agilité cryptographique devient un objectif en soi. Elle consiste à pouvoir changer plus facilement un algorithme, un certificat ou un mécanisme de chiffrement sans devoir reconstruire l’application qui l’utilise. À terme, un développeur pourrait simplement exprimer un besoin (chiffrer, signer, authentifier) tandis qu’une couche distincte appliquerait le mécanisme conforme à la politique de sécurité du moment. La cryptographie deviendrait ainsi moins figée dans les applications et plus facile à faire évoluer.
Le post-quantique révèle ainsi un problème plus large que la seule résistance aux futurs ordinateurs quantiques : la difficulté à modifier rapidement des mécanismes de confiance profondément enfouis dans le SI. Les organisations les mieux préparées ne seront pas nécessairement celles qui auront migré les premières partout mais celles qui sauront ce qu’elles utilisent, où, pour quelle durée et avec quelle capacité de remplacement.
Threat intelligence et SOC : du signal à la détection
Plus le système d’information se fragmente, moins les équipes peuvent se permettre de traiter toutes les menaces de la même manière. Une vulnérabilité critique sur le papier n’a pas la même urgence selon qu’elle touche un actif exposé, un serveur secondaire ou une application indispensable à la production. La threat intelligence prend alors son sens moins dans l’accumulation d’indicateurs que dans la capacité à replacer une menace dans le contexte réel de l’entreprise. C’était précisément l’objectif fixé pour cette partie du dossier : faire de la TI un outil de décision et non un flux supplémentaire à absorber.
Pour Vincenzo Ciancaglini, Senior Threat Researcher chez TrendAI Research, l’enjeu est présenté comme un travail de contextualisation. Une information sur une campagne, une vulnérabilité ou un groupe d’attaquants n’est utile que si elle permet de répondre à deux questions : la menace est-elle réellement intéressante pour l’attaquant et concerne-t-elle effectivement les actifs, usages ou secteurs de l’organisation ? Ce filtre évite de transformer chaque nouveauté technique ou chaque indicateur en urgence opérationnelle. Il permet au contraire de concentrer l’analyse sur les scénarios qui ont une chance réelle de se matérialiser.
Jérôme Renoux et Fabio Costa, chez Akamai Technologies, insistent de leur côté sur la nécessité de maintenir cette visibilité dans le temps. Il ne s’agit plus seulement de tester ponctuellement un environnement mais de suivre en continu ce qui est exposé, d’identifier ce qui est réellement critique et de réduire le délai entre l’apparition d’un risque et la réaction.
Cette logique devient particulièrement importante lorsque la menace touche une dépendance indirecte. Une bibliothèque open source, un composant logiciel ou une identité technique peuvent se situer plusieurs niveaux sous l’application visible par les métiers. Leur compromission peut pourtant créer un effet domino sur tous les services qui en dépendent. La threat intelligence doit donc être rapprochée de l’inventaire matériel et logiciel : savoir qu’une vulnérabilité est exploitée ne suffit pas, encore faut-il déterminer où elle existe réellement dans le SI et quel serait son rayon d’impact.
C’est précisément à cet endroit que la TI rejoint le SOC. Serge Carpentier, directeur des opérations de SysDream, insiste sur la nécessité de contextualiser les actifs pour prioriser les alertes. Si le SOC ignore qu’une machine appartient à la production plutôt qu’à la recette, qu’elle contient des données sensibles ou qu’elle est exposée sur Internet, la détection reste techniquement correcte mais opérationnellement incomplète. « L’inventaire est vraiment capital », résume-t-il.
L’automatisation et l’IA peuvent accélérer cette mise en relation mais elles ne remplacent pas le contexte. SysDream a testé l’intégration de l’intelligence artificielle dans ses opérations et en tire une limite claire : sans information suffisamment précise sur le client, l’automatisation peut générer des faux positifs ou proposer une réponse inadaptée. À l’inverse, quand les informations sur les actifs, les risques et les procédures sont disponibles, elle peut accélérer la collecte, rapprocher plusieurs signaux et réduire le temps nécessaire à l’analyse.
La dernière étape reste toutefois humaine et organisationnelle. Un SOC peut détecter et qualifier un incident mais la réponse suppose de savoir qui prévenir, quelles actions sont autorisées et jusqu’où le prestataire peut intervenir. Serge Carpentier évoque des entreprises incapables de répondre à une question pourtant élémentaire : si un incident survient à trois heures du matin, qui doit être notifié ? Le SOC devient alors moins un simple dispositif de surveillance qu’une extension opérationnelle de l’organisation, à condition que les responsabilités et les scénarios aient été définis avant la crise.
La maturité ne se mesure donc plus au nombre de flux de threat intelligence reçu, ni au volume d’alertes traitées, elle tient à la capacité de relier une menace à un actif, un actif à un impact métier, puis cet impact à une décision. Dans un SI trop vaste pour être surveillé uniformément, la valeur du renseignement et du SOC se joue désormais dans cette chaîne : comprendre, prioriser et agir.
Les priorités RSSI : six chantiers à engager maintenant
En 2026, la difficulté n’est pas de trouver de nouveaux sujets de cybersécurité, elle est de choisir par où commencer. Les chantiers liés aux identités, aux tiers, au post-quantique, à l’OT ou encore à la détection peuvent vite devenir trop larges pour être menés de front. L’enjeu pour le RSSI est donc de transformer ces sujets en actions vérifiables, avec un responsable, un périmètre et une échéance.
1. Confronter les inventaires à la réalité
Une CMDB, un annuaire ou une liste de fournisseurs ne suffisent pas s’ils ne permettent pas de savoir quels actifs sont exposés, qui les utilise et quelles dépendances les relient. Il faut donc vérifier en priorité les zones où les écarts sont les plus probables : comptes à privilèges, accès prestataires, environnements de développement, équipements industriels anciens, applications SaaS et composants cryptographiques. L’objectif n’est pas d’obtenir un inventaire « parfait » mais d’identifier les angles morts qui faussent déjà les décisions de sécurité.
2. Obliger les projets à documenter leurs dépendances
Une nouvelle application ne devrait plus être considérée uniquement sous l’angle de son architecture propre. Elle dépend de bibliothèques, d’API, d’identités techniques, de certificats, de fournisseurs cloud et parfois de sous-traitants. Ces dépendances doivent être identifiées dès le projet, avec au minimum leur propriétaire, leur criticité et les modalités de révocation ou de remplacement. Cette discipline évite de découvrir la dépendance au moment où elle devient un incident.
3. Revoir les accès permanents
Les comptes administrateurs ou prestataires encore ouverts en continu doivent être analysés un par un. L’accès est-il réellement nécessaire en permanence ? Peut-il être temporaire, limité à une ressource précise, soumis à une validation métier ou supprimé automatiquement après l’intervention ? C’est souvent un chantier moins spectaculaire que le développement d’un nouvel outil mais il réduit directement les chemins exploitables par un attaquant.
4. Commencer le post-quantique par un périmètre limité mais réel
Pour une entreprise qui n’a encore rien lancé, le premier objectif n’est pas de faire migrer toute la cryptographie, il est de choisir une application critique ou un ensemble de données sensibles, d’identifier les certificats, clés, secrets et protocoles qu’ils utilisent, puis de vérifier les possibilités de remplacement et les dépendances fournisseurs. Ce premier exercice donne rapidement une idée du niveau réel d’effort avant d’étendre le chantier.
5. Optimiser la threat intelligence
La TI, le SOC et l’automatisation doivent être évalués sur leur capacité à accélérer une décision, pas sur le volume d’informations qu’ils produisent. Une nouvelle source de threat intelligence ou un nouveau mécanisme automatisé n’apportent de valeur que s’ils aident à répondre plus vite à trois questions : sommes-nous concernés ; où sommes-nous exposés et quelle action faut-il engager ? Si ces réponses exigent encore plusieurs heures de recoupement manuel entre des outils différents, le problème reste largement organisationnel. Le chantier 2026 n’est donc pas de lancer six programmes supplémentaires, il est de choisir quelques dépendances critiques, les rendre réellement visibles, puis vérifier que l’entreprise sait retirer un accès, isoler un actif, remplacer une brique et prendre une décision lorsqu’elle devient vulnérable.
6. Relier chaque actif critique à un scénario d’incident
Pour un système de production, un service SaaS stratégique ou une application métier sensible, les équipes doivent savoir ce qu’il se passe concrètement en cas de compromission : qui est appelé, qui peut isoler l’actif, qui décide d’une coupure, quelles données doivent être préservées et quel délai de reprise est acceptable. Le test le plus simple reste brutalement efficace : si l’incident survient à trois heures du matin, la chaîne de décision fonctionne-t-elle réellement ?
Camille Suard
