Imaginez qu’un nouveau collaborateur arrive dans votre entreprise. Avant même de lui expliquer ce qu’il peut décider, vous lui confiez les clés du bureau, la base clients et l’accès à la messagerie. Un accueil généreux. Peut-être un peu trop pour un premier matin.

C’est pourtant ce qui peut se produire lorsqu’un assistant IA devient un agent. Hier, il préparait des réponses. Aujourd’hui, il peut les envoyer, modifier une fiche client ou déclencher un autre outil. La démonstration est convaincante. La question de savoir qui a autorisé quoi arrive parfois après.

Le 26 octobre, IBM a annoncé la disponibilité générale d’Agent Identity, un service consacré à l’identité des agents, à la délégation des droits et à la traçabilité de leurs actions. C’est une annonce commerciale, pas une preuve indépendante d’efficacité. Mais le problème posé concerne aussi les petites équipes : quand un logiciel commence à agir à votre place, que lui avez-vous exactement délégué ?

Une bonne réponse ne donne pas tous les droits

Prenons une petite boutique en ligne marocaine. Un assistant lit les demandes des clients et prépare des réponses sur les livraisons. Jusque-là, une personne vérifie et envoie. L’équipe souhaite maintenant lui laisser traiter seul les demandes courantes.

Présenté ainsi, c’est une amélioration. Dans les faits, plusieurs décisions se cachent derrière. L’agent peut-il consulter toutes les commandes, ou seulement celle du client concerné ? Changer une adresse ? Effectuer un remboursement ? Accorder une remise ? Transmettre une pièce jointe à un autre service ?

Ce cas est fictif. Il permet de voir ce qu’une consigne comme « gère le service client » laisse dans le flou. Elle désigne un métier. Elle ne définit pas les pouvoirs accordés.

Un agent qui explique correctement une politique de remboursement a montré une compétence. Un agent qui peut rembourser un paiement dispose d’un pouvoir supplémentaire. La première ne justifie pas automatiquement le second.

La limite doit aussi exister dans les outils

Écrire « n’envoie jamais rien sans validation » est utile. Donner en parallèle à l’agent un accès libre à l’envoi, c’est lui confier une capacité qu’on lui demande ensuite de ne pas utiliser.

Lorsque le service connecté le permet, mieux vaut un compte ou un identifiant limité au travail confié. L’agent chargé de préparer des messages doit pouvoir enregistrer des brouillons. Celui qui établit un rapport peut avoir besoin de consulter des données, sans pouvoir les modifier. Si le connecteur ne permet pas de séparer ces opérations, cette limite compte dans le choix du dispositif.

Les recommandations publiées le 1er mai 2026 par la CISA et ses partenaires internationaux vont dans ce sens : limiter l’autonomie, éviter les accès trop larges aux systèmes sensibles et maintenir des contrôles d’identité et une supervision. Elles donnent un cadre de sécurité ; elles ne certifient aucun produit et ne définissent pas les obligations juridiques marocaines.

Pour une petite équipe, la question est très concrète : cette limite tient-elle vraiment ? Si personne ne sait quels identifiants l’agent utilise, ni comment lui retirer l’accès sans changer le mot de passe de tout le monde, il reste quelque chose à régler avant de lui confier davantage.

Valider, oui. Mais valider quoi ?

On peut aussi ajouter un bouton de validation et considérer que le travail est supervisé.

Seulement, que voit la personne avant de cliquer ? Une mention « mettre à jour le client » ? Ou l’adresse actuelle, la nouvelle adresse proposée et le message à l’origine de la demande ?

Dans le second cas, elle peut prendre une décision. Dans le premier, on lui demande surtout de faire confiance.

Pour notre boutique fictive, un premier périmètre pourrait autoriser les réponses de suivi fondées sur les données vérifiées de la commande, soumettre les changements d’adresse à une relecture et laisser les remboursements hors du champ de l’agent pendant l’essai. Ce découpage dépend du métier et des outils. Rien n’interdit de commencer plus prudemment.

La relecture humaine est utile lorsqu’elle porte sur une action importante ou ambiguë. Faire approuver chaque consultation sans conséquence risque de transformer la supervision en réflexe de clic. Demander l’accord après l’envoi du message, en revanche, c’est avoir raté le moment.

Une petite équipe doit pouvoir comprendre la trace laissée

Une agence, un commerçant ou une société de services au Maroc n’a pas besoin de reproduire toute l’architecture informatique d’un grand groupe pour tester un agent. Il faut cependant que quelqu’un puisse répondre à quelques questions ordinaires.

Quel travail lui a-t-on confié ? Quelles données a-t-il utilisées ? Qu’a-t-il proposé ou modifié ? Qui a donné son accord, si une validation était nécessaire ? Comment l’arrête-t-on ?

Un historique court et lisible peut rendre davantage service qu’un journal technique impressionnant que personne ne consulte. Il doit aider à comprendre un incident sans devenir une copie supplémentaire et incontrôlée des messages et données personnelles des clients. Conserver ce qui permet d’expliquer une action, puis décider ce qu’on garde et qui peut le lire : cela mérite un choix explicite.

L’initiative du NIST lancée en février sur les standards des agents IA comporte justement des travaux sur la sécurité, l’identité et l’interopérabilité. Il s’agit d’une initiative, pas d’un label universel de conformité. Pour un acheteur, c’est une raison de plus de regarder les connexions, les droits et les traces laissées, au-delà de la qualité de la conversation.

Commençons par un travail dont on peut rattraper les erreurs

Une première mission utile possède un résultat identifiable et des erreurs supportables : classer des demandes entrantes, préparer un rapport hebdomadaire ou rédiger des réponses à relire. Un périmètre assez précis pour que l’on puisse examiner ce qui a été fait.

Ensuite, il faut lui présenter les cas un peu pénibles. Deux commandes portent le même nom. Un client demande une exception. Un message contient une instruction contraire à la procédure. Un outil cesse de répondre après avoir reçu une demande. L’agent s’arrête-t-il ? Demande-t-il de l’aide ? Relance-t-il une opération qui a peut-être déjà abouti ?

Le temps gagné se mesure après la relecture et les corrections. Un agent qui génère dix minutes de nettoyage pour cinq minutes économisées a accéléré quelque chose, certes. Pas forcément ce qui nous arrange.

Comme pour les autres choix d’infrastructure, la facilité d’utilisation mérite d’être mise en regard de la maîtrise opérationnelle. On élargit ensuite les accès lorsque les résultats de l’essai le justifient, responsabilité par responsabilité.

Lors de la prochaine démonstration, demandez à voir trois choses : les droits réels de l’agent, la validation d’une action importante et la manière de lui retirer l’accès. Une réponse bien tournée peut impressionner une salle. Ces trois éléments vous en diront beaucoup plus sur la capacité du système à travailler chez vous.