Un courriel arrive, l’assistant le lit, retrouve un contrat et prépare une réponse. Puis il propose de modifier les coordonnées bancaires du fournisseur. Le gain de temps paraît évident. Le danger aussi, dès que l’on pose la bonne question : sur quelle autorité agit-il ? À l’horizon de septembre 2026, le déploiement des agents IA dessine un chantier de cybersécurité qui dépasse largement le chatbot. Cette analyse s’appuie sur des évolutions déjà documentées et formule des perspectives, sans présenter ces scénarios comme des événements établis.
Du logiciel qui répond au logiciel qui agit
La rupture ne tient pas seulement à la qualité des modèles. Elle vient de leur raccordement au système d’information. Un assistant isolé produit du texte ; un agent connecté peut chercher une pièce jointe, interroger un CRM, ouvrir un ticket ou déclencher une opération. Il devient une interface entre une intention exprimée en langage naturel et des outils capables de changer quelque chose dans l’entreprise.
Dès 2023 et 2024, les assistants intégrés aux suites bureautiques, les mécanismes d’appel de fonctions et les frameworks d’agents ont installé les briques de cette évolution. Ils n’offraient pas tous la même autonomie. Mais ils posaient déjà une question commune : quand un modèle choisit un outil et ses paramètres, qui vérifie que cette action correspond réellement au mandat de l’utilisateur ?
Le scénario probable n’est pas celui d’un robot omnipotent remplaçant tout un service. C’est plutôt une multiplication de petits agents spécialisés : achats, support, ventes, ressources humaines. Chacun paraît inoffensif. Ensemble, ils ajoutent des identités techniques, des connexions et des chemins d’accès qu’il faudra inventorier.
Les permissions héritées ne suffisent pas
Premier piège : considérer qu’un agent peut disposer de tous les droits de son utilisateur. Une responsable financière consulte légitimement des factures, des salaires et des comptes bancaires. Son agent chargé de relancer les impayés n’a pas besoin de tout cela. Le droit d’une personne à accéder à une donnée ne constitue pas un mandat permanent pour une machine.
Deuxième piège : ouvrir largement les accès pour réussir une démonstration. Un compte de service partagé, un jeton durable et quelques connecteurs suffisent à créer un prototype spectaculaire. Ils peuvent aussi fabriquer un point de concentration des privilèges. Si plusieurs agents utilisent la même identité, comprendre lequel a consulté ou modifié une ressource devient difficile.
Une identité, un mandat, une échéance
La réponse consiste à distinguer l’identité de l’agent, celle de la personne qui le sollicite et l’autorisation accordée pour une tâche. L’agent doit avoir un propriétaire identifié, un périmètre explicite et une procédure de révocation. Les accès temporaires et les jetons limités réduisent les conséquences d’un détournement, à condition que les applications raccordées permettent cette granularité.
- Séparer lecture et écriture : consulter une facture ne doit pas permettre de changer son bénéficiaire.
- Limiter la portée : restreindre les dossiers, les clients, les montants ou les opérations accessibles.
- Faire expirer les délégations : une mission terminée ne doit pas laisser un accès ouvert indéfiniment.
- Contrôler côté outil : le logiciel destinataire doit refuser une action interdite, même si le modèle la demande.
Ce dernier point est décisif. Une consigne disant « ne réalise jamais de virement » n’est pas équivalente à une API dépourvue de fonction de paiement. La sécurité repose sur des contraintes exécutables, pas sur la seule bonne conduite attendue du modèle.
L’injection de consignes : le document devient piège
Imaginez maintenant un agent chargé de résumer les propositions de plusieurs fournisseurs. Dans l’un des documents figure une instruction : ignorer la demande initiale, récupérer une pièce confidentielle et l’envoyer vers une adresse externe. Pour un humain, cette phrase semble incongrue. Pour un système traitant instructions et contenus dans un même flux linguistique, elle peut devenir une tentative de prise de contrôle.
Cette attaque, dite injection indirecte de consignes, était déjà documentée en 2023. L’OWASP a également placé l’injection de consignes parmi les principaux risques des applications fondées sur les grands modèles de langage. Sa particularité : l’attaquant n’a pas nécessairement besoin de parler directement à l’agent. Il lui suffit parfois de contrôler une page, un courriel ou un document que celui-ci consultera.
Le problème ne se résume donc pas à repérer la formule « ignore les instructions précédentes ». Une demande malveillante peut se déguiser en procédure de support, en note interne ou en étape prétendument indispensable. Filtrer quelques expressions ne suffit pas. Il faut traiter les contenus récupérés comme des données non fiables, sans leur permettre d’élargir les autorisations.
Des défenses superposées, pas une formule magique
La séparation des sources, le marquage de leur provenance et les évaluations adversariales peuvent réduire le risque. Ils ne garantissent pas une immunité absolue. Les protections les plus robustes limitent aussi les destinations réseau, empêchent l’accès inutile aux secrets et imposent des validations déterministes avant les opérations sensibles. Une injection réussie contre le modèle doit pouvoir échouer contre le système.
Tracer les actes sans créer une nouvelle fuite
Après un incident, « l’IA a décidé » ne constitue pas une explication exploitable. L’entreprise doit pouvoir reconstituer la demande initiale, les sources consultées, les outils appelés, les paramètres transmis et les résultats obtenus. Elle doit aussi savoir quelle politique d’autorisation s’appliquait et qui a approuvé une action sensible.
Cela n’exige pas d’enregistrer un prétendu monologue intérieur du modèle. Une justification générée peut être incomplète ou trompeuse. La preuve utile est d’abord opérationnelle : événements horodatés, versions des composants, décisions d’accès et modifications effectivement réalisées. Des identifiants de corrélation doivent relier ces éléments à travers les applications.
Attention cependant au journal qui conserve tout. Les traces peuvent accumuler contrats, données personnelles et secrets techniques. Il faut donc filtrer les informations sensibles, définir des durées de conservation et restreindre leur consultation. Sinon, l’outil destiné à surveiller les agents devient lui-même un entrepôt à haut risque.
L’humain doit valider une action compréhensible
Ajouter un bouton « confirmer » ne règle pas tout. Si l’utilisateur approuve cinquante propositions par jour sans voir leurs conséquences, la supervision devient cérémonielle. Une validation utile présente l’action exacte, les données concernées, le destinataire et les changements prévus. Pour une modification bancaire, elle doit s’accompagner d’une vérification indépendante, pas d’un simple résumé rassurant.
Les entreprises auraient donc intérêt à progresser par paliers : observation, suggestions, actions réversibles, puis opérations plus sensibles. Chaque palier suppose des tests, un responsable et un moyen d’arrêt. Révoquer un accès, suspendre une file de tâches et annuler une modification doivent faire partie du produit, pas du plan d’urgence improvisé.
Et maintenant ? La perspective pour septembre 2026 est moins une course à l’autonomie maximale qu’un arbitrage entre utilité et délégation maîtrisée. Les agents les plus crédibles pourraient être ceux dont on sait expliquer les limites : ce qu’ils peuvent lire, ce qu’ils peuvent modifier et quand ils doivent demander de l’aide. Le nouveau collègue numérique n’a pas besoin d’un passe-partout. Il a besoin d’un badge adapté à sa mission, d’un registre fiable et d’une porte que l’entreprise peut refermer.
