Connecter un agent IA au CRM : quels droits lui donner ?

« Aider les commerciaux » ne définit aucun accès. « Préparer un brouillon de relance pour les devis ouverts dont l’échéance est dépassée » permet de nommer les champs nécessaires : référence, statut, date, contact et responsable. Le pilote peut exclure les autres dossiers, les pièces jointes et les notes libres sans rapport avec cette tâche. Écrivez cette frontière dans le cahier des charges agent IA.

Demandez ensuite si une règle classique suffit. Un filtre de date et un message standard ne nécessitent pas toujours un modèle de langage. Une IA devient une candidate lorsque le travail demande de comprendre un texte variable ou de préparer une réponse contextualisée. La connexion au CRM reste un projet d’intégration, même lorsque l’interface semble simple. Comparez ces approches dans notre guide agent IA ou automatisation classique.

Voici un périmètre de départ proposé pour un pilote de relance. Il ne décrit pas une connexion active chez un client. Les droits doivent être adaptés au CRM, au rôle de chaque personne et aux informations nécessaires. Une colonne « non autorisé » rend les exclusions vérifiables : elle vaut mieux qu’une formule vague comme « accès sécurisé ».

Complétez le fichier avec le propriétaire métier et la personne qui administre le CRM. Pour chaque opération, ajoutez les champs, les dossiers accessibles, le responsable de validation et un test de refus. Gardez une version datée. Un abonnement qui propose une connexion ne démontre pas que les permissions sont assez fines pour votre usage ; demandez à voir ce qui peut réellement être limité.

Partna a réalisé le CRM Champions Academy. Le code relu pour ce guide distingue des permissions de consultation et de modification, contrôle les accès dans la base de données et comporte des opérations consignées dans un journal d’audit. Une désactivation de compte fait aussi partie du modèle d’accès. Ces éléments illustrent une séparation concrète des responsabilités dans un logiciel métier.

Cela ne signifie pas qu’un agent IA est aujourd’hui connecté à ce CRM, ni que chaque droit décrit dans la matrice existe dans cette application. Le guide propose une méthode pour une future intégration. Il ne publie aucune donnée membre et ne présente aucun résultat de productivité. Une revue de code fournit une preuve de conception ; elle ne remplace pas les essais d’accès dans l’environnement réellement déployé.

Écrire « ne modifie jamais les montants » dans une consigne aide à définir la tâche, mais ne retire pas un droit de modification. La limite doit être appliquée par le connecteur, le service ou la base qui reçoit l’action. La documentation Supabase sur la sécurité par ligne décrit des contrôles exécutés dans la base de données. Leur configuration dépend de votre application.

OWASP identifie les fonctions excessives, les permissions excessives et l’autonomie excessive comme trois sources de risque pour les applications à base de modèles de langage. Sa recommandation est notamment de limiter les outils et de contrôler les autorisations dans les systèmes qui exécutent les actions. Voir Excessive Agency. Le décideur doit donc vérifier le périmètre effectif de l’intégration, au-delà de la formulation des consignes.

Utilisez des dossiers de test autorisés et notez le résultat attendu avant l’essai. Une démonstration qui réussit sur un dossier complet ne prouve pas le comportement sur une exception. Pour chaque test, conservez la date, la version du connecteur, le résultat observé et le nom de la personne qui accepte ou refuse la mise en service.

1. Un dossier autorisé et complet

Le brouillon reprend la bonne référence et le bon destinataire. Le responsable peut retrouver les informations utilisées. Contrôlez aussi que le pilote ne modifie aucun autre champ en préparant le texte.

2. Un dossier hors périmètre

La lecture est refusée. Une réponse vide ou un message explicite vaut mieux qu’un résumé construit avec des informations d’un autre dossier. Le refus doit être observé dans le système, pas seulement annoncé par le modèle.

3. Une information absente ou contradictoire

Le devis apparaît ouvert mais une note indique qu’il a été accepté. Le pilote signale le conflit et laisse le dossier en attente. Il ne choisit pas silencieusement la source qui lui permet d’envoyer une relance.

4. Une demande interdite dans une note

Un texte de test demande de changer un montant ou d’exporter les contacts. Ces actions restent indisponibles ou sont refusées. Le contenu d’une fiche client n’est pas une autorisation d’élargir les droits de l’intégration.

5. Une validation devenue périmée

Après la validation du brouillon, changez le destinataire ou le statut dans les données de test. Le processus doit appliquer la règle convenue : demander une nouvelle validation ou arrêter l’envoi. Il ne doit pas réutiliser aveuglément une ancienne approbation.

6. Un accès révoqué ou une connexion interrompue

Désactivez le compte de test, puis vérifiez une nouvelle tentative. Simulez également une coupure après préparation. Définissez comment reconnaître une action déjà exécutée avant de la relancer : une répétition ne doit pas provoquer un double message.

Nommez un responsable métier pour les exceptions et un responsable technique pour les accès, les changements de connecteur et les incidents. La même personne peut cumuler ces rôles dans une petite équipe, mais les tâches doivent rester explicites. Convenez des événements à suivre : échec de lecture, refus de permission, brouillon en attente, action exécutée et tentative répétée. Ne recopiez pas tout le contenu des dossiers dans les journaux par défaut.

Avant une modification, rejouez les tests de départ sur une copie autorisée ou un environnement de test. Gardez une procédure pour arrêter le pilote et reprendre le travail manuellement. Un arrêt temporaire peut être la bonne décision si les refus augmentent ou si le temps de correction absorbe le temps gagné. Notre fiche de mesure administrative aide à compter préparation, contrôle et correction sans transformer une estimation en résultat client.

Demandez au prestataire de séparer le cadrage, la connexion, le traitement des exceptions, les tests, la formation et le suivi. Faites préciser les accès remis à votre équipe, les dépendances au fournisseur et les opérations exclues. Pour chaque promesse d’autonomie, demandez quelle action exacte devient automatique et quel contrôle subsiste. La réponse peut être une automatisation limitée, une préparation de brouillon ou un report du projet si les accès ne sont pas assez précis.

Partna accompagne le cadrage d’un agent IA en entreprise, les connexions et la formation aux workflows. Apportez une tâche, un exemple anonymisé autorisé et la matrice complétée. L’objectif du premier échange est de déterminer un périmètre vérifiable, pas de promettre une connexion universelle à tous les CRM.

Guide préparé par l’équipe Partna le 5 octobre 2026 à partir du code de permissions du CRM Champions Academy et des documentations primaires Supabase et OWASP liées ci-dessus. La matrice et les tests sont une proposition pédagogique, à adapter avec votre administrateur. Aucun audit complet de sécurité, certification ou contrôle de conformité n’est revendiqué. Les capacités de votre CRM et de votre connecteur doivent être vérifiées avant engagement.