Un assistant qui invente une réponse fait perdre du temps. Le même assistant, connecté au logiciel de facturation, peut envoyer une relance injustifiée à un client stratégique. Branché aux achats, il peut transformer une mauvaise interprétation en commande ferme. Le changement décisif n’est pas seulement l’intelligence du modèle : c’est son droit d’agir. À l’horizon de septembre 2026, le véritable chantier des agents IA se dessine donc moins dans les fenêtres de conversation que dans les règles d’accès aux systèmes d’entreprise.
Du conseil à l’exécution, un changement de nature
La trajectoire est déjà visible dans les annonces et produits apparus en 2024 et début 2025. Salesforce a présenté Agentforce, Microsoft a développé les capacités d’agents de Copilot Studio et OpenAI a dévoilé Operator, capable d’interagir avec des interfaces web. Ces jalons documentés ne prouvent pas une autonomie généralisée. Ils montrent cependant une direction commune : passer d’un outil qui suggère une action à un logiciel qui tente de l’accomplir.
La suite relève ici de l’analyse prospective, et non d’un bilan vérifié de septembre 2026. Dans les entreprises, cette évolution pourrait déplacer la question centrale. Au lieu de demander seulement si l’IA répond correctement, il faudra établir ce qu’elle peut modifier, pour le compte de qui et dans quelles limites. Un résumé erroné reste rectifiable. Une suppression de données ou un paiement engagé appelle d’autres protections.
Prenons un cas fictif, mais banal : « Régularise les factures en retard de ce fournisseur. » Faut-il retrouver les pièces manquantes, corriger une référence, préparer un règlement ou l’exécuter ? Pour un salarié, le contexte et les procédures délimitent généralement la mission. Pour un agent, cette phrase peut devenir une succession d’appels logiciels. Chaque étape exige une autorisation distincte, que la fluidité de la conversation tend à masquer.
Un compte de service n’est pas un mandat illimité
Le raccourci serait de donner à l’agent les identifiants d’un collaborateur, puis de le laisser travailler. Ce serait confondre deux choses : les droits dont une personne dispose pour exercer son métier et ceux nécessaires à une tâche précise. Une responsable financière peut avoir accès à tous les fournisseurs. L’agent chargé de vérifier une facture n’a pas besoin de pouvoir changer leurs coordonnées bancaires.
Le principe du moindre privilège, classique en cybersécurité, prend donc une dimension nouvelle. Les permissions devraient être limitées par opération, par ressource et, lorsque c’est possible, dans le temps. Lire un dossier, proposer une modification et valider cette modification constituent trois pouvoirs différents. Les réunir derrière un bouton « connecter mon entreprise » rend la démonstration séduisante, mais le risque difficile à maîtriser.
Il faut aussi distinguer l’identité de l’agent, celle de son utilisateur et celle du service technique exécutant l’action. Sans cette séparation, une opération apparaît simplement comme réalisée par un compte partagé. Impossible alors de comprendre facilement qui l’a demandée et sous quelle délégation. L’agent doit recevoir un mandat borné, pas hériter silencieusement de toute l’autorité de son utilisateur.
Le document consulté peut devenir un piège
Les agents cumulent deux propriétés délicates : ils lisent des contenus extérieurs et disposent parfois d’outils puissants. Un courriel, une page web ou un document partagé peut contenir des instructions malveillantes destinées au modèle. C’est le problème de l’injection indirecte de prompt : un texte censé servir d’information tente de devenir un ordre.
Imaginons une pièce jointe demandant discrètement à l’assistant de transmettre un export client vers une adresse externe, sous prétexte de contrôle comptable. Le danger n’est pas que le document possède lui-même une permission informatique. C’est que l’agent mobilise ses propres droits pour suivre une instruction provenant d’une source non autorisée. Une frontière entre données et commandes a alors disparu.
La réponse ne peut pas reposer uniquement sur une consigne au modèle : « Ignore les instructions suspectes. » Les contrôles doivent aussi exister hors de lui : destinations autorisées, filtrage des sorties, restrictions d’accès et vérification des paramètres avant exécution. Un composant déterministe peut refuser un transfert interdit même si l’agent le juge utile. La sécurité ne doit pas dépendre de sa seule capacité à reconnaître une ruse.
Connecter plus facilement ne signifie pas autoriser correctement
Présenté par Anthropic en novembre 2024, le Model Context Protocol, ou MCP, illustre la recherche d’une interface commune entre assistants, données et outils. Ce type de standard peut réduire le travail nécessaire pour raccorder un modèle à un environnement métier. Mais la compatibilité technique ne résout pas, à elle seule, la gouvernance des actions.
Un connecteur indique comment appeler une fonction. Il ne détermine pas nécessairement si cette fonction doit être accessible dans une situation donnée. Une entreprise devra toujours examiner les permissions demandées, la provenance des composants et les informations transmises. Le catalogue d’outils mérite la même attention qu’un catalogue d’applications : chaque nouvelle connexion élargit potentiellement la surface d’attaque.
La validation humaine doit avoir un contenu
« Un humain reste dans la boucle » peut devenir une formule creuse. Si une personne approuve cinquante propositions opaques à la suite, elle risque de cliquer par habitude. Une validation utile doit présenter l’action exacte, les données concernées, ses conséquences et les éléments justifiant la demande. Pour un virement, afficher seulement « opération conforme » ne permet pas un contrôle sérieux.
Le niveau de contrôle devrait suivre le risque. Classer un ticket interne peut rester automatique. Préparer une réponse commerciale peut demander une relecture. Modifier un bénéficiaire bancaire ou supprimer des archives peut exiger une double validation. Surtout, l’accord doit porter sur les paramètres effectivement exécutés : si le montant ou le destinataire change après approbation, celle-ci ne vaut plus.
Tracer les actes, prévoir les réparations
La conversation ne suffit pas comme journal d’audit. Il faut conserver les outils appelés, les paramètres transmis, les réponses reçues, les permissions utilisées et les validations obtenues. L’objectif n’est pas de collecter un hypothétique raisonnement intérieur du modèle, mais de reconstruire les faits observables. Cette journalisation doit elle-même protéger les données personnelles et éviter d’enregistrer inutilement des secrets.
Il faut également préparer l’échec. Certaines actions peuvent être annulées ; d’autres demandent une opération compensatoire, et un courriel envoyé ne se récupère pas vraiment. Des plafonds d’activité, un arrêt d’urgence et des tests sur des scénarios adverses deviennent indispensables. Les équipes devront mesurer non seulement les tâches réussies, mais aussi les actions indésirables, les refus justifiés et le temps nécessaire pour remettre la situation en ordre.
Et maintenant ? Pour septembre 2026 et au-delà, le scénario le plus crédible n’est pas nécessairement celui d’agents libres de tout faire. C’est celui d’une autonomie graduée, gagnée tâche par tâche grâce à des résultats vérifiables. Commencer par un périmètre réversible, séparer proposition et exécution, puis élargir les droits après évaluation paraît moins spectaculaire qu’une démonstration sans surveillance. Mais l’avantage durable pourrait précisément venir de là : savoir confier une action à l’IA sans abandonner la maîtrise de ses conséquences.
