OWASP a publié un Top 10 pour les applications LLM. On a lu la liste avec la perspective d'une équipe TI.

La majorité du cadre s'adresse aux ingénieurs en IA qui construisent des modèles. Mais trois risques s'appliquent à toutes les organisations qui utilisent l'IA, que vous l'ayez construite ou non. Voici ce qu'on pense que vous devriez savoir.

C'est le risque principal. Données clients, information financière, code source, stratégies internes, tout ça circule dans les outils d'IA et ressort de l'autre côté.

Le danger, ce n'est pas la fuite évidente. C'est le goutte-à-goutte. Un employé colle un contrat dans ChatGPT pour le résumer. Le nom du fournisseur, le prix, les clauses de résiliation, tout se retrouve dans les journaux d'un tiers. Multipliez par des centaines d'employés qui font des choses similaires chaque jour. Vous n'avez pas une brèche. Vous avez une surface d'exposition continue que la plupart des organisations n'ont jamais mesurée.

Ce qu'il faut demander : Quelles données circulent vers les outils d'IA en ce moment ? Pas ce qu'on a approuvé. Ce qui bouge vraiment. Si la réponse est « il faudrait vérifier », c'est ça la réponse.

Celui-là s'installe tranquillement. L'agence excessive arrive quand les systèmes d'IA obtiennent plus de permissions qu'ils en ont besoin. Un agent d'IA qui lit votre CRM, écrit dans vos courriels et accède à vos partages de fichiers, c'est pratique. C'est aussi un point unique de compromission.

Le pattern : une équipe active Copilot, Salesforce Einstein ou un agent Slack. Chacun se connecte à des systèmes internes « pour être plus utile ». Six mois plus tard, personne n'a la vue complète. Les permissions se sont accumulées. Personne ne les a auditées.

Ce qu'il faut demander : À quoi vos intégrations d'IA ont-elles vraiment accès ? Si une injection de prompt ou un compte compromis en exploitait une, jusqu'où irait-elle ?

C'est celui auquel la plupart des équipes TI n'ont pas pensé. Et il porte les plus grandes implications en conformité.

Quand vous utilisez un outil d'IA, vous faites confiance à chaque modèle sur lequel il a été bâti, à chaque jeu de données sur lequel il a été entraîné, à chaque module avec lequel il s'intègre. L'outil d'IA est une boîte noire. La chaîne d'approvisionnement derrière est une boîte noire encore plus profonde.

On a déjà vu cette histoire. SolarWinds. Log4j. Un composant de confiance se révèle avoir des dépendances cachées qui introduisent des risques que vous ne saviez pas que vous portiez.

L'angle conformité : La Loi 25, le RGPD et des réglementations similaires exigent que vous sachiez où les données personnelles sont traitées. Si votre outil d'IA fonctionne sur un modèle entraîné avec des données que vous ne pouvez pas auditer, hébergé par un fournisseur avec des sous-traitants que vous ne pouvez pas tracer, vous avez une lacune de conformité dont la plupart des conseils n'ont pas été informés.

L'angle cybersécurité : Des modèles compromis et des modules vulnérables peuvent introduire des risques dans votre environnement en silence. Le rayon d'impact dépend de ce à quoi ces outils sont connectés.

Ce qu'il faut demander : Pour chaque outil d'IA que vous utilisez, savez-vous sur quel modèle il repose, où il est hébergé et à quelles données il touche ? Pourriez-vous répondre à ça pour un auditeur la semaine prochaine ?

Prenez du recul. Qu'est-ce que ça veut dire qu'OWASP, l'organisation qui a défini la sécurité applicative moderne, ait décidé que l'IA méritait son propre Top 10 ?

La sécurité de l'IA a franchi un seuil. Elle n'est plus émergente. Elle est opérationnelle. Le cadre existe parce que l'industrie avait besoin d'une façon commune de parler de ces risques.

Les organisations à qui on pose les questions les plus difficiles en ce moment, par les régulateurs, les conseils et les clients, sont celles qui mènent des initiatives d'IA sans réponse claire à « où sont vos contrôles ? » OWASP vous donne la structure. Il n'écrit pas les réponses.

Sources :

• OWASP. (2025). OWASP Top 10 for Large Language Model Applications.
• Government of Quebec. (2021). Act to modernize legislative provisions as regards the protection of personal information (Law 25).
• Gartner. (2024). Predicts 2025: Shadow AI Security Breaches Will Affect 40% of Enterprises by 2030.

Vous avez probablement déjà essayé. Politiques rédigées, sessions de formation, peut-être même quelques outils bloqués au firewall. Et pourtant, vos employés continuent d'utiliser de l'IA non autorisée.

Voici pourquoi cette approche échoue, et ce qui fonctionne vraiment.

Forrester appelle ça la « shadow pandemic ». Soixante pour cent des travailleurs utilisent leurs propres outils d'IA pour faire leur travail, en contournant délibérément les politiques de sécurité de leur organisation.

Pas parce qu'ils sont imprudents, mais parce qu'ils trouvent que c'est la façon la plus efficace de livrer.

En parallèle, 38 % des employés admettent avoir partagé de l'information sensible avec des outils d'IA sans la permission de leur employeur. Et 69 % des entreprises soupçonnent ou ont vu des employés utiliser des outils d'IA générative interdits.

Voici la vérité inconfortable. La formation et les politiques seules n'arrêteront pas le Shadow AI.

La formation est nécessaire mais pas suffisante. Vous pouvez dire aux employés de ne pas coller de données confidentielles dans ChatGPT. Ils vont hocher la tête, dire qu'ils comprennent, et le faire quand même quand ils auront une livraison serrée et un outil qui marche.

Les interdictions, c'est encore pire. Elles n'éliminent pas le problème, elles le cachent. Les employés passent dans la clandestinité. Ils utilisent leurs appareils personnels, leur réseau maison, ou des outils dont vous ne connaissez pas l'existence. Vous perdez la visibilité, donc la capacité de protéger les données.

Le vrai problème, ce n'est pas l'intention des employés. C'est l'alignement des incitatifs. Vos employés sont mesurés sur leurs résultats. L'outil d'IA les rend plus rapides. Donc ils l'utilisent, peu importe ce que dit la politique.

Voici ce qui fonctionne vraiment. Ne bloquez pas l'outil. Bloquez les données qui ne devraient pas y passer.

Les solutions de sécurité modernes font quelque chose que les approches traditionnelles ratent. Elles agissent au niveau du prompt, le moment précis où un employé tape de l'information dans un outil d'IA.

Voici les capacités déployées aujourd'hui :

Détection en temps réel

Identifier quand des données sensibles sont sur le point d'être envoyées à un outil d'IA, avant qu'elles ne quittent votre réseau. Renseignements personnels, code propriétaire, dossiers clients, données financières. Saisir l'information sur le moment.

Masquage intelligent

Au lieu de bloquer le prompt au complet, masquer ou caviarder les morceaux sensibles. Laisser l'employé utiliser l'outil, mais retirer ce qui ne devrait pas y aller. On préserve la productivité tout en protégeant l'information.

Politiques contextuelles

Chaque équipe a son profil de risque. Le marketing peut partager des types de données que les finances ne peuvent pas. Les solutions modernes permettent de définir des politiques granulaires par département, par rôle, par type de donnée.

Visibilité sans surveillance

Documenter ce qui se passe sans installer une culture de surveillance. Vous ne cherchez pas à prendre les gens en défaut. Vous cherchez à comprendre le risque et à protéger les données.

Application active

Pas seulement alerter. Bloquer les prompts à risque, les rerouter, ou exiger une approbation supplémentaire avant que les données sensibles ne sortent. Comme un système DLP, mais conçu pour l'ère de l'IA.

Voici ce que vos employés savent et que vous ignorez peut-être. L'IA est déjà intégrée dans les outils que vous avez approuvés. Slack, Microsoft 365, Salesforce, Google Workspace. Ils ont tous de l'IA intégrée. Votre équipe utilise ces fonctionnalités tous les jours, souvent sans s'en rendre compte.

La question n'est donc pas « va-t-on utiliser l'IA ? » C'est « va-t-on l'utiliser sécuritairement, ou en cachette ? »

Les contrôles actifs au niveau du prompt offrent une troisième option. Vous n'avez pas à choisir entre interdire l'IA et ignorer le risque. Vous pouvez l'activer et la protéger en même temps.

C'est ici que la vraie stratégie commence. Il vous faut :

1. De la visibilité. Quelles données circulent où ? Quels outils sont utilisés ? Par qui ?

2. Des politiques claires. Montrez aux gens comment utiliser l'IA de façon sécuritaire.

3. Des garde-fous actifs. De la technologie qui applique ces politiques au moment du risque.

4. Un changement de culture. De « l'IA est interdite » à « l'IA est permise, mais on protège nos données ».

Rien de ça n'est théorique. Des organisations déploient ces capacités en ce moment. Et celles qui agissent en premier auront un avantage marqué sur celles qui essaient encore de bloquer leur chemin vers la sécurité.

Sources :

• Forrester. (2023). Predictions 2024: Generative AI Transitions From Hype To Intent.
• Forrester. (2023). Predictions 2024: Cybersecurity, Risk, And Privacy.
• IBM. (2024). What Is Shadow AI?
• Gartner. (2024). Predicts 2025: Shadow AI Security Breaches Will Affect 40% of Enterprises by 2030.
• McKinsey & Company. (2025). The State of AI in 2025: Agents, Innovation, and Transformation.

Gartner est direct sur la trajectoire. D'ici fin 2026, 75 % des organisations qui mènent des initiatives d'IA générative vont réorienter leurs efforts de sécurité,en transférant leurs dépenses de la sécurité des données structurées vers la sécurité des données non structurées.

Ce n'est pas une prédiction. C'est un avertissement.

On le voit sur le terrain. Que ce soit une municipalité, une clinique de santé ou une entreprise manufacturière, le motif se répète. Les équipes découvrent constamment de nouveaux outils LLM utilisés par leurs employés. Les TI en bloquent un dans le firewall. Un autre apparaît deux semaines plus tard. C'est un jeu de tape-taupe, et c'est partout.

Et voici ce qui aggrave la situation. Selon le rapport Verizon Data Breach Investigations 2025, près de 50 % des fuites de données viennent d'employés qui envoient de l'information sensible au mauvais destinataire, pas d'attaquants externes. Imaginez maintenant ça à travers des outils que vos équipes TI ne savent même pas sont utilisés.

Voici la prise de conscience qu'il faut avoir. Vous ne pouvez pas écrire de politique pour des outils que vous ne savez pas qu'ils existent. Vous ne pouvez pas protéger des données qui circulent dans des systèmes que vous ne surveillez pas. Vous ne pouvez pas auditer ce qui est invisible.

Arrêtez de vouloir bannir l'IA. Cette bataille est déjà perdue. La vraie bataille, c'est la visibilité.

Et c'est ici que ça devient concret. Quand ça va casser, et ça va casser, la pression ne viendra pas de votre équipe TI. Elle viendra du :

• Département juridique. Où sont vos contrôles ? Quelles données sont allées où ?
• La conformité. A-t-on enfreint des règlements ? Quelle est notre exposition ?
• Des finances. Combien coûte une fuite ? Quelle est notre responsabilité ?
• Du conseil. Comment c'est arrivé sous votre garde ?

Quand un régulateur demande où étaient vos garde-fous, dire « on ne savait pas que les employés utilisaient ça » n'est pas une défense. C'est de la négligence.

Si vous êtes CIO,vous voyez le risque opérationnel. Comment gouverner quelque chose qui va plus vite que vos processus ?

Si vous êtes CISO,vous voyez l'exposition à la conformité. La responsabilité est réelle.

Si vous êtes responsable TI,vous voyez la pression sur vos ressources. Vous êtes déjà étiré, et voilà une autre couche invisible à gérer.

Même problème. Pressions différentes.

Avant de pouvoir corriger la visibilité, il faut savoir avec quoi on travaille. Posez les questions à votre équipe :

1. Quels outils d'IA utilise-t-on vraiment, en ce moment ? Pas ce que vous avez approuvé. Ce qui est vraiment utilisé. Intégrations Slack ? Extensions de navigateur ? Applications autonomes ? Si vous ne pouvez pas répondre avec confiance, vous avez un angle mort.

2. Quelles données alimentent ces outils ? Données clients ? Votre propre code ? Stratégies internes ? Soyez précis. Ça vous donne la vraie surface de risque.

3. Quels outils ont accès à vos systèmes ou à vos données ? Certains outils d'IA se connectent à votre Microsoft 365, Google Workspace ou CRM. Ils ont des permissions que vous avez probablement oubliées. Trouvez-les.

Ces trois questions ne règlent pas le problème. Mais elles vous diront si vous en avez un, et de quelle ampleur.

Sources :

• Gartner. (2024). Security Leaders’ Guide to Data Security in the Age of GenAI.
• Verizon. (2025). 2025 Data Breach Investigations Report.

Voici un scénario qui se produit plus souvent que la plupart des équipes TI ne sont à l'aise de l'admettre. Un employé quitte l'organisation. Son compte Active Directory est désactivé. Mais les comptes locaux qu'il avait sur trois systèmes internes, l'identifiant fournisseur partagé qu'il utilisait pour l'accès à distance, et le compte applicatif lié à son courriel ? Eux, ils restent actifs. Discrètement. Pendant des mois, parfois des années.

Ce n'est pas de la négligence. C'est le résultat prévisible d'une gestion des identités système par système, application par application, sans vue centralisée de ce qui existe et de qui a accès à quoi. Et selon les recommandations de la NSA et de la CISA, c'est l'une des lacunes les plus exploitables dans la GIA d'entreprise aujourd'hui.

Les comptes locaux semblent gérables quand on a une poignée de systèmes. À grande échelle, ils deviennent autre chose. Chaque plateforme avec sa propre base d'utilisateurs, ses propres politiques de mots de passe et ses propres règles de session ajoute une couche de complexité qu'aucune équipe ne peut raisonnablement surveiller dans son ensemble.

La NSA et la CISA sont directes là-dessus : les volumes massifs de comptes locaux à travers les systèmes d'entreprise ne peuvent tout simplement pas être maintenus à un niveau de sécurité qui correspond au risque qu'ils représentent. Les problèmes s'accumulent rapidement. La surveillance des événements de sécurité devient inefficace parce qu'il n'y a pas de vue unifiée de l'activité d'authentification.

Les comptes partagés rendent l'attribution forensique pratiquement impossible après un incident. Et les attaquants qui obtiennent un point d'appui via un système géré localement peuvent utiliser cet accès pour sonder d'autres systèmes sans générer les alertes inter-systèmes qui signaleraient autrement le comportement.

La fédération d'identités et le SSO sont souvent présentés comme des améliorations de l'expérience utilisateur. Une seule connexion pour toutes les applications. Moins de friction, moins de mots de passe à retenir. C'est réel, mais ça sous-estime ce que ces technologies font du point de vue de la sécurité.

Quand l'authentification est centralisée via une solution SSO liée à un fournisseur d'identités, les administrateurs obtiennent quelque chose qu'ils n'ont pas dans un environnement de comptes locaux fragmenté : une vue unique et fiable de qui accède à quoi, d'où, et à quel moment.

Les comportements anormaux deviennent visibles parce qu'il existe une base de référence pour comparer. L'application des politiques devient cohérente parce qu'elle se fait à un seul endroit, et non à travers des dizaines de systèmes configurés indépendamment.

La fédération permet aussi une amélioration opérationnelle essentielle dans la gestion du cycle de vie des accès. Quand un employé quitte l'organisation, désactiver l'identité centralisée désactive l'accès partout. Plus de listes de systèmes à mettre à jour manuellement, plus de comptes locaux oubliés encore ouverts.

Le SSO crée également la bonne base pour un déploiement d'AMF plus robuste. Intégrer l'AMF au niveau de la couche d'authentification centralisée signifie qu'on sécurise un seul système et qu'on couvre toutes les applications qu'il connecte, plutôt que de tenter de configurer et maintenir l'AMF dans chaque application indépendamment.

La surface d'attaque se réduit. La surveillance devient plus efficace. Et l'expérience utilisateur reste gérable.

Le point de départ honnête est une question d'inventaire. La plupart des équipes TI ont une image raisonnable de leur répertoire principal et de leurs applications cloud majeures. Ce qui tend à être moins clair, c'est la longue traîne : les systèmes hérités avec des comptes administrateurs locaux, les plateformes gérées par des fournisseurs avec des identifiants partagés, les applications qui précèdent l'architecture GIA actuelle et qui n'ont jamais été intégrées à la fédération.

Ce sont ces comptes qui n'apparaissent pas dans les rapports standard et qui ne génèrent pas d'alertes quand ils sont utilisés en dehors des heures normales ou depuis des emplacements inattendus. Ce sont exactement les types de comptes que les acteurs malveillants ciblent parce qu'ils existent en dehors de la visibilité centralisée.

La voie de remédiation n'est pas compliquée en principe. Elle commence par un inventaire complet des comptes locaux sur tous les systèmes. À partir de là, la question est directe : lesquels peuvent être éliminés en étendant le SSO à la plateforme ? Lesquels nécessitent un compte local pour des raisons opérationnelles et ont donc besoin de politiques de mots de passe explicites et d'une surveillance dédiée ? Et lesquels sont simplement des comptes hérités qui auraient dû être révoqués depuis longtemps ?

Il y a un argument de ressources qui mérite d'être présenté en parallèle de l'argument sécurité. Gérer plusieurs infrastructures d'identités à travers une organisation coûte cher. Chaque système avec sa propre logique d'authentification représente du travail de configuration continu, de la gestion de correctifs et une charge pour le service d'assistance.

L'authentification centralisée via la fédération et le SSO réduit considérablement ces coûts et facilite le maintien des standards de sécurité dans le temps, sans augmenter proportionnellement l'équipe nécessaire pour le gérer.

C'est en partie pourquoi la NSA et la CISA positionnent la fédération d'identités non pas comme une capacité avancée, mais comme une capacité fondamentale. Les organisations qui fonctionnent encore principalement avec des comptes locaux ne sont pas en mesure de gérer efficacement les risques d'identité qui existent dans les environnements hybrides et multi-cloud modernes.

Si votre organisation n'a pas fait un inventaire complet de ses comptes locaux récemment, c'est le bon point de départ. Non pas parce que le résultat sera nécessairement alarmant, mais parce qu'on ne peut pas prendre de bonnes décisions sur la stratégie de fédération et de SSO sans savoir avec quoi on travaille réellement.

Ensuite, évaluer quelles applications dans votre environnement prennent déjà en charge la fédération SSO et lesquelles ne le font pas est la deuxième étape. La plupart des plateformes modernes le supportent. Les lacunes se trouvent généralement dans les systèmes hérités et les applications gérées par des fournisseurs. Savoir où se trouvent ces lacunes, c'est ce qui rend possible une feuille de route de remédiation réaliste.

Sources :

• Identity and Access Management Recommended Best Practices for Administrators

Le périmètre réseau a disparu. L'identité est maintenant votre première ligne de défense.

Mais déployer des outils ne suffit pas. C'est la façon dont vous les gérez qui définit votre posture de sécurité.

Voici quatre pièges courants qui laissent les organisations vulnérables.

Quand on pense identité, on pense humain. Erreur.

Les identités non-humaines (NHI) (bots, comptes de service, clés API) dépassent maintenant les identités humaines dans un ratio de huit pour un. Ces comptes sont souvent sur-privilégiés et sous-surveillés. Ils deviennent des cibles de choix pour les attaquants cherchant à persister ou se déplacer latéralement.

Si votre stratégie de gouvernance n'audite pas les machines aussi rigoureusement que les humains, vous ignorez la majorité de votre surface d'attaque.

La gouvernance des identités ne peut pas être statique. Une erreur courante : Ne pas automatiser la révocation des accès quand les employés partent ou changent de rôle.

Le risque : L'accumulation de privilèges. Les utilisateurs conservent leurs anciens droits tout en accumulant de nouveaux. L'exposition grandit inutilement.

La solution : La NSA le confirme, la mesure préventive la plus efficace est la capacité de révoquer immédiatement les accès lors de la détection d'événements à haut risque ou de départs.

Toutes les MFA n'offrent pas la même protection. Les simples notifications push ou SMS deviennent un handicap. Le "prompt bombing" (submerger l'utilisateur jusqu'à ce qu'il approuve) et le vol de jetons explosent.

Les données : Le 2025 Data Breach Investigations Report note que le prompt bombing est apparu dans 14 % des brèches d'ingénierie sociale.

La solution : Passez à une MFA résistante au phishing (comme les clés matérielles FIDO2/WebAuthn) qui empêchent les attaquants de rejouer les identifiants ou d'intercepter les codes.

Le DBIR 2025 révèle un changement massif : 30 % des brèches impliquent maintenant un tiers. Ce chiffre a doublé en un an.

L'erreur : Supposer que vos politiques d'identité internes protègent automatiquement les données hébergées chez vos fournisseurs. Les campagnes ciblant les comptes clients Snowflake ont réussi parce que ces environnements tiers manquaient souvent de MFA obligatoire ou de SSO fédéré. Les attaquants ont simplement utilisé des identifiants volés pour se connecter directement.

Le Shadow IT : De plus, 15 % des employés accèdent régulièrement à des systèmes GenAI sur des appareils corporatifs, souvent avec des comptes personnels non intégrés qui contournent entièrement la surveillance de sécurité corporative.

Un mot de passe ne suffit plus. Vous avez besoin d'une stratégie holistique qui gouverne les identités humaines et machines, impose une authentification résistante au phishing et étend rigoureusement vos standards de sécurité aux fournisseurs tiers.

En évitant ces quatre erreurs, vous fermez les "portes d'entrée" que les adversaires trouvent actuellement grandes ouvertes.

Sources :

• Identity Defined Security Alliance (IDSA). (2025). 2025 Trends in Identity Security: A Survey of IT Security and Identity Professionals.

• National Security Agency (NSA) & Cybersecurity and Infrastructure Security Agency (CISA). (2023). Identity and Access Management Recommended Best Practices for Administrators.

• Verizon. (2025). 2025 Data Breach Investigations Report.

• World Economic Forum. (2023, June). Reimagining Digital ID: Insight Report.

Les défenses périmétriques traditionnelles ne suffisent plus à protéger un paysage hybride moderne, où les menaces contournent souvent la barrière et se déplacent sans être détectées de l’intérieur.

Pour atteindre une véritable cyber-résilience, il faut passer d’une approche de prévention à une approche où l’on suppose qu’une violation finira par se produire.

La micro-segmentation est un outil puissant de sécurité réseau qui garantit la continuité des activités, même en cas de cyberattaques.

De nombreuses entreprises utilisent des réseaux plats, ce qui les rend vulnérables aux attaquants. Une fois à l’intérieur, ces derniers peuvent se déplacer librement dans le réseau avec peu de résistance.

Durant ce temps, les attaquants explorent votre réseau, escaladent leurs privilèges et recherchent vos données les plus sensibles.

Un réseau plat propage les virus comme un bureau à aire ouverte propage un rhume, tandis qu’une segmentation les contient comme des salles de quarantaine.

La segmentation traditionnelle divise un réseau en zones larges. La micro-segmentation va plus loin.

Elle applique des politiques de sécurité à des charges de travail, applications et appareils individuels, qu’ils soient sur site ou dans le cloud.

• Comment ? Les outils modernes de micro-segmentation offrent une cartographie des dépendances des applications. Cela visualise les flux de trafic en temps réel à travers toute votre infrastructure.

• Avant d’appliquer une règle, votre équipe voit exactement quels processus dépendent d’une connexion serveur spécifique. Cela évite la crainte de "casser l’application" en renforçant la sécurité.

• Pourquoi ? Vous ne pouvez pas protéger ce que vous ne voyez pas. Dans des réseaux hybrides complexes, les équipes informatiques ont souvent du mal à comprendre quelles applications communiquent entre elles.

En 2026, une violation est presque inévitable. Un désastre, non. La micro-segmentation transforme votre réseau fragile en un système résilient. Vous absorbez les impacts et continuez d’avancer.

La sécurité informatique reposait autrefois sur des défenses périmétriques telles que les pare-feu et les VPN, mais aujourd'hui cette frontière a disparu.

Les données sont claires : Le nouveau champ de bataille n’est plus à la périphérie du réseau, mais au niveau de l’identité.

Les systèmes d’authentification sont désormais les portes d’entrée des réseaux, applications et données d’entreprise. Cela en fait la cible privilégiée des adversaires modernes.

Pour les responsables TI, sécuriser la couche identité est devenu l’élément le plus critique pour protéger l’organisation.

Les cybercriminels les plus redoutables aujourd’hui ne piratent pas. Ils se connectent. Selon le Verizon 2025 Data Breach Investigations Report (DBIR), l’exploitation des identifiants reste le principal vecteur d’accès initial, représentant 22 % des violations.

Les acteurs malveillants exploitent activement les vulnérabilités des systèmes Identity and Access Management (IAM). En compromettant des identifiants, ils imitent des activités légitimes et contournent les outils classiques de détection d’anomalies.

Une fois infiltrés, ils escaladent les privilèges et se déplacent latéralement dans le réseau. Ils sont souvent impossibles à distinguer d’un utilisateur légitime... jusqu’à ce qu’il soit trop tard.

Quand on parle de gestion des identités, on pense d’abord aux utilisateurs humains. Pourtant, dans les environnements TI actuels, les identités non humaines (Non-Human Identities, NHI) dominent de plus en plus. Cela inclut les comptes de service, bots, clés API et workloads cloud.

Les recherches montrent que les NHIs surpassent désormais les identités humaines sur Internet dans une proportion de huit pour un.Ces identités machine sont souvent surdimensionnées en termes de privilèges et insuffisamment surveillées, créant une immense surface d’attaque silencieuse.

Sécuriser ces identités automatisées est désormais une priorité. Une stratégie axée uniquement sur les utilisateurs humains laisse la majorité des identités exposées.

Dans un modèle centré sur le réseau, on gérait les règles des pare-feux. Dans un modèle centré sur l’identité, il faut gérer le cycle de vie des identités.La gouvernance des identités, et plus particulièrement les processus Join, Move, Leave (JML), est indispensable pour arrêter les accès non autorisés.

• Join : Automatiser l’attribution des accès en fonction des rôles pour éviter une surprovisionnement.
• Move : Révoquer les droits d’accès lors des changements de rôle pour éviter l’accumulation de privilèges.
• Leave : Supprimer immédiatement les accès lors du départ de l’utilisateur.

Sans gouvernance rigoureuse, les organisations accumulent des comptes orphelins que les attaquants exploitent pour rester indétectés.

Selon l'Identity Defined Security Alliance (IDSA), 95 % des organisations adoptent le modèle Zero Trust pour sécuriser les frontières du réseau, où les exploits de vulnérabilités des VPN ont augmenté jusqu'à 22 %. Les attaquants utilisent désormais le bombardement de requêtes et le vol de jetons pour contourner les contrôles standards.

Cela a entraîné un passage vers une authentification résistante au phishing pour contrer ces menaces. Alors que le périmètre réseau s'étend aux shadow IT, les organisations s'adaptent.

Avec 15 % des employés utilisant des outils d'intelligence artificielle générative en dehors de la supervision de l'entreprise, beaucoup se tournent vers les portefeuilles numériques pour reprendre le contrôle des identifiants décentralisés.

Le périmètre d’identité définira le paysage opérationnel de 2026 et des années à venir. Pour protéger ce nouveau périmètre, pensez à :

1. Présumer la compromission : Mettre en place des défenses pour limiter l’impact d’identifiants piratés.

2. Auditer les identités machines : Inventorier et gouverner rigoureusement les comptes de service.

3. Automatiser la gouvernance : Appliquer le principe du moindre privilège tout au long du cycle de vie des employés.

En traitant l’identité comme le principal contrôle de sécurité, vous protégez le seul périmètre qui suit vos données où qu’elles aillent.

Sources :

• Identity Defined Security Alliance (IDSA). (2025). 2025 Trends in Identity Security: A Survey of IT Security and Identity Professionals.

• National Security Agency (NSA) & Cybersecurity and Infrastructure Security Agency (CISA). (2023). Identity and Access Management Recommended Best Practices for Administrators.

• Verizon. (2025). 2025 Data Breach Investigations Report.

• World Economic Forum. (2023, June). Reimagining Digital ID: Insight Report.

Dans le domaine de la cybersécurité La microsegmentation est une stratégie essentielle pour renforcer la résilience.

Pendant longtemps, les organisations se sont appuyées sur la sécurité périmétrique, supposant que tout ce qui se trouvait à l'intérieur du réseau était sûr. Mais aujourd'hui, les attaquants parviennent souvent à contourner ces défenses externes, accédant à un réseau plat où ils peuvent se déplacer librement pour atteindre vos données les plus critiques.

Voici un guide rapide pour comprendre pourquoi la Microsegmentation est désormais la norme en matière de résilience.

La Microsegmentation est une technique de sécurité qui divise votre réseau en zones très granulaires, jusqu’au niveau des charges de travail, des applications ou des appareils, afin de les sécuriser individuellement.

Contrairement à la segmentation traditionnelle, qui pourrait simplement séparer le "Wi-Fi invité" du "réseau d'entreprise",par exemple, la microsegmentation applique des politiques de sécurité strictes aux flux de trafic spécifiques entre serveurs et applications.

Elle repose sur l'identité, et non simplement sur l'emplacement physique dans le réseau. La question devient : "Le serveur web a-t-il besoin de communiquer avec la base de données maintenant ?" Si ce n'est pas le cas, l'accès est bloqué.

Pour comprendre la microsegmentation, il faut d'abord comprendre les directions du trafic réseau :

• Trafic Nord-Sud : Il s'agit des données qui entrent ou sortent de votre organisation. Les pare-feux traditionnels sont conçus pour gérer ce trafic.

• Trafic Est-Ouest : Il s'agit des données circulant à l'intérieur de votre réseau (par exemple, un serveur qui communique avec un autre serveur).
  

Le point à retenir ? Les pare-feux traditionnels ont du mal à surveiller et à contrôler ce trafic interne. La microsegmentation est spécifiquement conçue pour contrôler ce mouvement Est-Ouest.

La microsegmentation fait évoluer votre posture de sécurité, passant de "croiser les doigts pour ne pas être attaqué" à "être prêt à surmonter une attaque". En isolant vos actifs les plus critiques, vous vous assurez qu'une petite violation ne se transforme pas en catastrophe pour votre entreprise.