Sécurité d’un agent IA dans le CRM : autoriser chaque action métier

La conversation donne une intention. L’application doit ensuite vérifier qui demande quoi, sur quel dossier, avec quelles limites. Une réponse convaincante de l’agent ne constitue pas une permission. Cette distinction devient concrète dès que le dossier change entre la demande du vendeur et l’exécution.

Prenons un distributeur fictif qui veut accélérer la préparation des renouvellements. L’agent rassemble les informations utiles et propose un message au représentant. Il n’a pas besoin d’accéder à tous les comptes, à l’historique complet des employés ou aux coordonnées bancaires. Le périmètre utile correspond aux dossiers attribués au représentant et aux champs nécessaires au renouvellement.

Écrivez un verbe par permission : consulter la fiche, créer un brouillon, proposer une remise, modifier une condition commerciale, envoyer un courriel, supprimer une donnée. Pour chaque verbe, précisez l’identité utilisée, les objets admissibles et le résultat autorisé. Une permission de lecture ne devrait pas se transformer en accès d’exportation massif par simple répétition des appels.

Ce travail se prépare avec l’équipe qui gère votre CRM et ERP sur mesure. Le responsable des ventes connaît les exceptions commerciales. L’équipe technique doit traduire ces exceptions en règles vérifiables côté serveur, y compris lorsque l’agent appelle directement un outil sans passer par les écrans habituels.

La fiche OWASP sur la sécurité des agents recommande des outils limités et une validation indépendante de l’exécution. Un texte récupéré dans un courriel ou une note CRM reste une donnée non fiable : il ne doit jamais pouvoir étendre les droits de l’agent.

Une demande d’approbation devrait montrer le client, le document concerné et les changements proposés. Pour une remise, affichez l’ancienne valeur, la nouvelle valeur, la base de calcul et la période. Pour un envoi, montrez les destinataires et le texte final. Le gestionnaire doit savoir quelle conséquence son clic autorise.

Définissez ensuite les conditions de validité : auteur de l’approbation, action précise, version du dossier et expiration. La durée relève de votre fonctionnement; une approbation vieille de plusieurs jours peut être inadaptée à une offre dont les quantités changent chaque heure. Documentez la règle choisie plutôt que de laisser chaque équipe l’interpréter.

Pour une automatisation du CRM et de l’ERP, un service d’exécution devrait revérifier l’autorisation au dernier moment. L’agent peut préparer la proposition. Le composant qui applique la modification doit vérifier les droits actuels et l’état de l’approbation, puis empêcher sa réutilisation.

Dans notre exemple fictif, la gestionnaire approuve une remise sur une commande de vingt unités. Avant l’exécution, le représentant passe la quantité à deux cents. Le montant et l’exposition commerciale ont changé. Le scénario attendu consiste à interrompre l’application de la remise et à demander une nouvelle validation avec les paramètres actualisés.

Le même raisonnement s’applique à un changement de destinataire, de devise, de produit ou de compte client. Identifiez les champs qui rendent l’approbation caduque. D’autres changements, comme une note interne sans effet commercial, peuvent suivre une règle différente. Ces distinctions doivent être explicites et couvertes par la recette.

La concurrence mérite un scénario distinct. Deux exécutions peuvent présenter la même approbation presque simultanément. Une lecture suivie d’une écriture séparée laisse une fenêtre de réutilisation. Demandez comment le serveur vérifie et consomme l’autorisation dans une opération indivisible, et comment il reconnaît une reprise après une réponse incertaine.

La recette doit inclure un compte sans droit de remise, une approbation expirée et un dossier modifié. Ajoutez un refus humain, un outil inconnu et une panne du service d’autorisation. Écrivez le résultat attendu pour chaque situation avant les essais. Une indisponibilité ne devrait pas ouvrir temporairement tous les droits.

Testez aussi un courriel fictif qui demande à l’agent d’ignorer la politique ou d’envoyer le dossier à une autre adresse. Le résultat attendu porte sur les actions effectivement bloquées et sur les données non divulguées. Un message rassurant de l’agent ne démontre rien si l’appel d’outil a déjà transmis l’information.

Intégrez ces scénarios à la recette de votre application web sur mesure. Notez la version de l’agent, la configuration des outils, les droits des comptes et les preuves observées. Les cas proposés ici constituent un protocole à exécuter; aucun résultat de test n’est revendiqué.

Un journal utile permet de relier la demande initiale à l’effet final. Dans un exemple expurgé, un identifiant de corrélation associerait le représentant, le compte client fictif, l’action proposée, les paramètres autorisés, l’approbatrice et le résultat retourné par le CRM. Conservez les heures et les versions nécessaires à la reconstitution.

Évitez de verser automatiquement chaque conversation et document dans les journaux. Ils peuvent contenir des renseignements personnels ou des secrets. Définissez les champs retenus, les personnes autorisées à les lire et leur durée de conservation. Une référence protégée vers une pièce justificative peut suffire lorsqu’une copie complète augmenterait inutilement l’exposition.

Préparez enfin l’arrêt opérationnel : qui suspend l’outil d’envoi, comment traiter les actions en attente et comment confirmer les modifications déjà appliquées. Une correction dans le CRM ne rappelle pas un courriel reçu. Le plan de reprise doit distinguer les opérations annulables et celles qui exigent une communication humaine.