Un commercial demande à son assistant de « nettoyer le dossier client avant la réunion ». Le logiciel corrige une fiche, déplace des documents, puis prépare une remise dans l’outil de vente. À quel moment l’aide devient-elle une décision ? Quand l’IA peut agir, la question n’est plus seulement de savoir si sa réponse est juste, mais qui lui a donné le droit de changer quelque chose. À l’horizon de septembre 2026, ce basculement impose un autre regard sur la sécurité informatique. Cette analyse s’appuie sur des évolutions documentées, notamment depuis 2024 ; les prolongements envisagés restent prospectifs.
Du copilote qui suggère à l’agent qui exécute
Le premier assistant bureautique produisait surtout du texte : compte rendu, synthèse, brouillon de courriel. Un humain récupérait le résultat et décidait de son usage. L’agent ajoute une boucle : il observe une situation, choisit un outil, exécute une opération, examine le retour et poursuit. Il peut ainsi transformer une consigne générale en plusieurs actions techniques, sans que l’utilisateur ait décrit chaque étape.
Cette évolution ne relève pas uniquement du discours commercial. En 2024, Microsoft a présenté des fonctions d’agents autonomes dans Copilot Studio ; Salesforce a lancé Agentforce ; Anthropic a dévoilé une capacité expérimentale de pilotage d’interface, baptisée « computer use ». Ces annonces dessinent une direction commune : rapprocher les modèles des logiciels où le travail se fait réellement. Elles ne prouvent toutefois ni une fiabilité universelle ni une autonomie sans surveillance.
Pour une direction informatique, la rupture est concrète. Un texte erroné peut tromper son lecteur. Une action erronée peut écraser un fichier, exposer un document confidentiel ou modifier une commande. Et plusieurs actions individuellement autorisées peuvent, une fois enchaînées, produire un résultat que personne n’avait souhaité.
Le piège des droits hérités
Le raccourci le plus tentant consiste à donner à l’agent les accès de son utilisateur. Après tout, pourquoi l’assistant ne pourrait-il pas faire ce que son propriétaire peut faire ? Parce qu’un salarié dispose souvent de droits étendus, accumulés au fil des missions, et qu’une consigne ambiguë ne vaut pas autorisation générale d’exercer tous ces droits.
Imaginons une responsable administrative autorisée à consulter les factures et à modifier les coordonnées des fournisseurs. Pour rapprocher un paiement, son agent a seulement besoin de lire certaines pièces. Lui transmettre une session complète ouvre inutilement la possibilité de changer un compte bancaire. Le périmètre pertinent n’est pas celui du métier de l’utilisateur, mais celui de la tâche confiée.
Le principe du moindre privilège reste donc valable, avec une granularité nouvelle : quel outil, quelle opération, quelles données, pendant combien de temps ? Une autorisation temporaire de lecture sur dix dossiers vaut mieux qu’un accès permanent au répertoire entier. Une identité technique distincte permet également de reconnaître les actions de l’agent, sans les confondre avec celles du salarié.
Le modèle propose, une autre couche autorise
Il faut surtout éviter de demander au modèle de faire lui-même respecter toutes les règles. Une instruction comme « ne supprime jamais de document important » n’est pas un contrôle d’accès. Une passerelle d’exécution doit vérifier les appels aux outils : opérations permises, paramètres acceptables, destinataires autorisés, plafonds éventuels. Le modèle peut proposer ; un composant déterministe doit pouvoir refuser.
Quand un document devient une fausse consigne
Un agent lit des contenus qui ne sont pas nécessairement dignes de confiance : courriels reçus, pages web, pièces jointes, tickets de support. L’injection indirecte de prompt exploite précisément cette situation. Un texte consulté peut contenir des instructions destinées à détourner le comportement du modèle, par exemple lui demander d’envoyer des informations vers une adresse extérieure.
Le problème dépasse le filtrage de quelques formulations suspectes. Un document est censé constituer une donnée, pas une autorité. Or le modèle traite dans un même contexte la demande légitime et les contenus rencontrés. Avec des outils connectés, une confusion entre ces deux niveaux peut devenir une fuite de données ou une opération indésirable.
Les protections doivent donc se cumuler : limiter les sources accessibles, séparer autant que possible les contenus externes des instructions, contrôler les sorties et restreindre les destinations réseau. Les connecteurs et protocoles d’intégration facilitent le branchement des outils ; ils ne garantissent pas, à eux seuls, la légitimité des actions. Chaque connexion supplémentaire mérite une analyse de risque.
La validation humaine n’est pas un bouton magique
« Un humain reste dans la boucle » rassure, mais ne décrit pas un dispositif de sécurité. Si l’agent affiche quinze demandes de confirmation opaques, l’utilisateur finira probablement par cliquer sans lire. À l’inverse, imposer une approbation pour chaque consultation rend l’automatisation inutilisable. L’enjeu consiste à réserver l’attention humaine aux changements qui le méritent.
Une politique praticable distingue les conséquences :
- Lecture limitée : autonomie possible sur des données autorisées, avec journalisation.
- Modification réversible : aperçu des changements, historique de versions et retour arrière.
- Action sensible : validation explicite, voire double approbation pour un paiement ou un changement de droits.
La confirmation doit montrer ce qui va réellement se passer : fichiers concernés, valeurs avant et après, destinataires, effets attendus. « Autorisez-vous la poursuite ? » ne suffit pas. L’autorisation doit aussi porter sur une opération précise : si l’agent en modifie ensuite les paramètres, une nouvelle validation peut être nécessaire.
Des traces pour comprendre, pas seulement pour stocker
Après un incident, savoir que « l’assistant a exécuté une tâche » ne sert guère. Il faut pouvoir reconstituer la chaîne : demande initiale, identité utilisée, outils sollicités, paramètres transmis, décisions du contrôle d’accès, validations obtenues et résultats observés. Cette traçabilité doit relier l’intention exprimée à la modification effective dans l’application.
Il n’est pas nécessaire de prétendre enregistrer les pensées internes du modèle. L’important est de conserver les éléments vérifiables de l’exécution. Ces journaux contiennent eux-mêmes des informations sensibles : leur accès, leur durée de conservation et leur intégrité doivent être encadrés. Tout enregistrer sans discernement créerait un nouveau gisement de risques.
La réversibilité compte autant que l’audit. Versions de fichiers, transactions contrôlées, environnement de test et mécanismes empêchant de répéter une opération offrent des garde-fous concrets. Un agent interrompu puis relancé ne doit pas expédier deux fois la même commande. Et un arrêt d’urgence doit couper ses accès effectifs, pas simplement fermer sa fenêtre de conversation.
La responsabilité ne se délègue pas au logiciel
Le déploiement exige enfin un propriétaire identifié pour chaque agent : qui définit sa mission, approuve ses permissions et répond en cas d’incident ? La DSI ne peut pas décider seule de la portée d’une remise commerciale ; un service métier ne peut pas ouvrir seul une base sensible. Sécurité, métiers et conformité doivent fixer ensemble des limites testables.
Et maintenant ? Le scénario le plus crédible pour la prochaine étape n’est pas une entreprise peuplée d’agents libres de tout faire, mais une autonomie graduée, accordée après des essais et réévaluée sur des résultats observables. Les organisations les mieux préparées seront probablement celles qui sauront répondre simplement à trois questions : que peut faire cet agent, comment le prouver, et comment l’arrêter ?
