Un agent IA consulte des documents, interroge une application par API, puis déclenche une opération dans le cloud. Ce scénario résume le grand défi de l’année 2026. Des composants protégés chacun de leur côté peuvent, en effet, une fois assemblés, ouvrir un chemin d’attaque. Les modèles existants restent utiles, à condition de couvrir ces relations au-delà des frontières entre équipes. 

L’attaque se glisse entre les couches 

Un compte compromis peut ouvrir plusieurs applications et un secret technique exposé, donner accès à une API. Une défaillance du service d’identité peut par ailleurs rendre indisponibles des outils pourtant intacts. La sécurité doit ainsi couvrir les délégations de droits, les connecteurs et les dépendances communes. 

D’autant qu’avec l’IA générative, le contenu traité peut devenir un vecteur d’attaque. Des instructions malveillantes dans un document peuvent détourner un LLM de sa tâche initiale. S’il pilote un agent aux droits étendus, cette manipulation peut provoquer une fuite de données ou une action indésirable. L’OWASP identifie précisément ce risque d’autonomie, de fonctionnalités et de permissions excessives. 

Les abus d’API rappellent, eux, qu’un accès authentifié n’est pas nécessairement autorisé à tout faire. Une application peut, en effet, reconnaître correctement l’appelant tout en lui laissant consulter des données auxquelles il ne devrait pas accéder. Le contrôle doit donc porter sur chaque ressource et chaque opération. 

Sauf qu’une défense en silos risque de ne pas détecter ce type d’enchaînements. Car si un accès cloud, une lecture documentaire et un appel d’API peuvent sembler ordinaires, leur succession, en revanche, peut révéler une attaque. Les équipes doivent donc pouvoir rapprocher leurs observations. 

L’identité devient centrale, sans suffire à elle seule 

Qui agit, pour le compte de qui, avec quels droits et sur quelles données ? La question concerne aujourd’hui tout le monde, aussi bien les salariés, que les comptes de service, les applications et les agents IA. Chaque identité non humaine doit désormais avoir un responsable, des permissions limitées et des accès révocables. Un agent chargé de lire des factures n’a, en effet, aucune raison de pouvoir modifier les coordonnées bancaires d’un fournisseur. 

Le Zero Trust apporte d’ailleurs un cadre à cette discipline. Il consiste à ne pas accorder une confiance implicite à un utilisateur ou à un équipement en raison de sa présence dans le réseau. L’accès doit être justifié par l’identité, la ressource demandée et le contexte. L’authentification ne délivre pas un blanc-seing. 

Cette logique relie accès, données, applications, segmentation et surveillance. Et pour les agents IA, la grande évolution IT de l’année 2026, les autorisations doivent être imposées par les systèmes qui exécutent les actions. Un modèle peut ainsi proposer une opération, mais il ne doit pas décider seul qu’il a le droit de l’accomplir. Les actions sensibles exigent des validations adaptées à leur impact. 

Reste à rendre ces contrôles supportables. La priorité consiste donc à harmoniser les politiques, à automatiser le cycle de vie des accès et à exploiter ensemble les journaux disponibles. Notez toutefois que l’authentification unique et les contrôles ajustés au risque peuvent réduire les sollicitations inutiles. Ajouter un outil se justifie s’il comble un manque identifié, mais un tableau de bord supplémentaire ne compense pas une responsabilité floue. 

Quant à la consolidation sur une plateforme unique, elle peut créer un point de défaillance commun. Les accès de secours et les procédures de crise devant évidemment fonctionner même si cette plateforme devient indisponible. 

NIS2 place la continuité au niveau de la direction 

NIS2 donne à cette évolution une portée organisationnelle. Pour les entités concernées, la directive prévoit que les organes de direction approuvent les mesures de gestion des risques cyber, supervisent leur mise en œuvre et puissent être tenus responsables de manquements à ces obligations. Elle couvre notamment la gestion des incidents, la continuité d’activité, les sauvegardes, la reprise et la sécurité de la chaîne d’approvisionnement. 

Quels services maintenir ? Quelle dégradation accepter ? Qui peut suspendre un agent ou interrompre un flux ? Ces arbitrages impliquent les métiers, les achats, la DSI et la direction, avant l’incident. 

Ils doivent aussi être éprouvés. Car l’action de restaurer une sauvegarde ne prouve pas, à elle seule, que l’activité peut reprendre. Il faut, en effet, vérifier l’intégrité des données, la disponibilité des dépendances et la capacité des équipes à travailler en mode dégradé. Les exercices doivent mesurer le temps nécessaire pour comprendre l’incident, contenir sa propagation et rétablir un service digne de confiance. 

In fine, la cyber-résilience ne dispense jamais de prévenir les compromissions. Elle ajoute une exigence, celle de conserver visibilité, contrôle et capacité d’action lorsqu’une protection cède. Anticiper, résister, récupérer et s’adapter, c’est justement le cadre posé par le NIST.