Un courriel arrive au service achats. L’assistant IA le résume, retrouve la commande, vérifie la facture et prépare une réponse. Jusque-là, il fait gagner du temps. Mais s’il peut aussi modifier un fournisseur ou déclencher un paiement, le même scénario change de nature. Le vrai sujet n’est plus seulement ce que l’IA sait, mais ce qu’elle a le droit de faire. À l’horizon de septembre 2026, cette frontière devrait structurer le déploiement des agents. Les exemples qui suivent reposent sur des évolutions publiques antérieures à 2026 ; les développements envisagés restent prospectifs.
Du chatbot qui conseille au logiciel qui agit
Un agent IA combine un modèle, des instructions et des outils : recherche documentaire, navigateur, requêtes dans une base, création de tickets, envoi de messages. Il peut enchaîner plusieurs opérations pour atteindre un objectif. La différence avec un chatbot classique est moins spectaculaire qu’il n’y paraît, mais décisive : sa réponse peut devenir une action dans le système d’information.
Cette transition était déjà visible en 2024. Microsoft présentait des agents autonomes dans Copilot Studio ; Salesforce lançait Agentforce. Anthropic expérimentait la manipulation d’un ordinateur par Claude, puis publiait le Model Context Protocol, ou MCP, destiné à faciliter les connexions entre applications d’IA, données et outils. Ces annonces indiquaient une direction commune : sortir de la fenêtre de conversation pour intervenir dans les processus métiers.
La promesse est concrète. Au lieu d’expliquer comment traiter un retour client, l’agent retrouve l’achat, applique la politique commerciale et prépare le remboursement. Mais chaque branchement ajoute une capacité, donc un risque. Un modèle qui se trompe dans un résumé produit une erreur de texte. Le même modèle connecté à un logiciel comptable peut produire une erreur comptable.
Les connecteurs deviennent des frontières de sécurité
Les protocoles de connexion réduisent le travail nécessaire pour rendre un outil accessible. Ils ne règlent pas, à eux seuls, la question de l’autorisation. Standardiser le branchement ne signifie pas sécuriser chaque usage. Il faut encore déterminer l’identité utilisée, les ressources accessibles et les opérations permises. Lire une fiche client n’équivaut pas à exporter tout le fichier commercial.
Le piège classique consiste à donner à l’agent les droits d’un salarié, voire un compte technique très privilégié, pour éviter les blocages. Cela simplifie la démonstration et fragilise la production. Un agent chargé de planifier une réunion n’a pas besoin d’accéder aux archives des ressources humaines. Celui qui vérifie une facture n’a pas nécessairement besoin de pouvoir la payer.
La bonne granularité dépasse donc le simple bouton « autoriser ». Elle distingue lecture, création, modification et suppression, mais aussi périmètre, durée et montant. Un accès temporaire à un dossier précis vaut mieux qu’un jeton permanent couvrant toute une application. Les autorisations doivent être vérifiées par les systèmes qui exécutent l’action, pas seulement rappelées au modèle dans une consigne.
Quand un document tente de donner des ordres
Avec les agents, une menace connue prend une portée opérationnelle : l’injection de prompt indirecte. Une page web, un courriel ou un document consulté contient des instructions malveillantes. Le texte cherche à faire dévier l’agent de sa mission, par exemple en lui demandant de récupérer des informations confidentielles puis de les transmettre à une adresse extérieure.
Ce n’est pas une attaque informatique classique contre un mot de passe. Elle exploite la difficulté du modèle à séparer les instructions légitimes des contenus qu’il doit seulement analyser. Un message peut se présenter comme une note interne urgente ou une procédure de sécurité. L’agent doit pourtant le traiter comme une donnée non fiable, pas comme une nouvelle autorité.
Aucun filtre de texte ne suffit à garantir cette séparation. La défense doit aussi limiter les conséquences : destinations d’envoi autorisées, secrets inaccessibles au modèle, environnements isolés pour certaines tâches et contrôles indépendants avant exécution. Un agent manipulé mais privé du droit d’exporter une base fera moins de dégâts qu’un agent supposé prudent doté d’un accès universel.
La validation humaine, utile mais pas magique
« Un humain validera » semble une réponse rassurante. Encore faut-il lui montrer ce qu’il valide. Une fenêtre affichant « Continuer ? » n’aide guère à repérer un changement de coordonnées bancaires. La confirmation doit présenter l’action exacte, sa cible, les données transmises et les conséquences attendues. Pour une opération sensible, elle devrait aussi signaler les éléments inhabituels.
Tout soumettre à approbation serait cependant contre-productif. À force de confirmer des actions banales, les utilisateurs finissent par cliquer mécaniquement. Mieux vaut organiser une autonomie graduée : laisser l’agent classer des tickets, encadrer ses réponses commerciales et exiger une validation renforcée pour un paiement, une suppression massive ou une modification de droits.
- Faible impact : automatisation avec journalisation et contrôles a posteriori.
- Impact intermédiaire : limites de volume, de périmètre et possibilité d’annulation.
- Impact élevé : approbation explicite, voire double contrôle, avant exécution.
Tracer des actes, pas prétendre lire une pensée
Lorsqu’une erreur survient, conserver la conversation ne suffit pas. Il faut savoir quel outil a été appelé, avec quels paramètres, sous quelle identité et avec quelle autorisation. Le résultat, l’heure, la version du système et les éventuelles validations doivent permettre de reconstituer l’opération. Cette piste d’audit relie la demande initiale aux effets réellement produits.
La traçabilité utile n’est pas une prétendue transcription exhaustive du raisonnement interne du modèle. Elle porte sur des faits observables. Elle doit également respecter la confidentialité : enregistrer systématiquement tous les documents consultés pourrait créer un second stock de données sensibles. Les journaux exigent donc leurs propres règles d’accès, de conservation et de protection.
La responsabilité ne se délègue pas au modèle
Si un agent accorde une remise interdite, qui répond de l’incident ? L’équipe qui l’a configuré, le responsable du processus, le fournisseur du logiciel ? La réponse dépendra notamment des contrats, des obligations applicables et des circonstances. Mais une entreprise ne peut pas organiser ses opérations autour d’une entité présentée comme autonome sans désigner de responsables humains.
Le RGPD reste pertinent dès que des données personnelles sont traitées. Le règlement européen sur l’IA, adopté en 2024 avec un calendrier d’application échelonné, ajoute des obligations selon les usages et les rôles des acteurs ; il ne classe pas automatiquement tout agent comme système à haut risque. La conformité doit examiner le contexte réel, pas simplement l’étiquette « agent ».
Sur le terrain, cela impose un propriétaire du service, une procédure d’incident et un moyen de couper rapidement les accès. Révoquer un jeton, suspendre un connecteur ou revenir à un traitement manuel compte autant que choisir le modèle. Avant le déploiement, les tests doivent inclure des documents piégés, des permissions expirées et des opérations partiellement exécutées.
Et maintenant ? À l’horizon de septembre 2026, la différenciation pourrait se déplacer vers cette infrastructure discrète : identités dédiées, permissions temporaires, validations lisibles et preuves d’exécution. Les agents les plus utiles ne seront pas nécessairement ceux auxquels on laisse tout faire, mais ceux dont on peut élargir l’autonomie sans perdre le contrôle. Pour les entreprises, le bon premier projet n’est donc pas un assistant omnipotent : c’est une tâche bornée, mesurable et réversible.
