La scène est composite et les détails sont illustratifs. Un agent sortant est mis en ligne un lundi avec accès au CRM, à l'outil de séquençage et à une API d'enrichissement. Mercredi, il avait enregistré 2 400 contacts. Jeudi, quelqu'un remarque que 300 d'entre eux appartiennent à des comptes avec des opportunités ouvertes, détenus par des AE qui n'ont jamais demandé d'aide. Une quarantaine sont chez un client en plein renouvellement. Personne ne peut dire quel signal a motivé chaque inscription, car l'agent a enregistré un résumé plutôt que ses entrées. Annuler ces actions occupe deux administrateurs pendant presque toute la journée du vendredi, et le CRO place ensuite chaque action de l'agent derrière une file d'attente de révision manuelle. Un mois plus tard, la file d'attente compte 900 éléments, les commerciaux l'ignorent et l’agent est de fait désactivé.
Les deux sont des échecs de gouvernance. Le premier n’avait aucun contrôle ; le second en avait un, et c'était un humain.
Les données d'incident ne sont pas rassurantes. L'étude de SailPoint sur les agents IA, menée par Dimensional Research auprès de 353 professionnels de l'informatique qui assument des responsabilités en matière de sécurité d'entreprise et publiée en mai 2025, a révélé que 82 % des organisations utilisent déjà des agents IA, mais que seulement 44 % ont des politiques les sécurisant. Quatre-vingt pour cent ont déclaré que leurs agents IA avaient pris des mesures involontaires, notamment en accédant à des systèmes ou à des ressources non autorisés (39 %). L'état de l'IA dans l'entreprise en 2026 de Deloitte (3 235 responsables informatiques et commerciaux dans 24 pays) a révélé que seulement 21 % des organisations disposent d'un modèle de gouvernance mature pour l'IA agentique, ce qui signifie des limites de décision claires, une surveillance en temps réel et des pistes d'audit.
L’activité commerciale évolue plus rapidement que ses contrôles. Le rapport Salesforce sur l'état des ventes (4 050 professionnels de la vente, publié en février 2026) révèle que 54 % des vendeurs ont déjà utilisé des agents d'IA et que près de neuf sur dix prévoient de le faire d'ici 2027. La prédiction de Gartner de juin 2025 selon laquelle plus de 40 % des projets d'IA agentique seront annulés d'ici la fin de 2027 cite l’insuffisance des contrôles de risque parmi trois causes, avec les coûts et l’absence de valeur clairement démontrée. Gartner prédit également que les « agents gardiens », des systèmes qui supervisent d'autres agents, représenteront au moins 10 à 15 % du marché de l'IA agentique d'ici 2030 (juin 2025).
Il s'agit d'un problème de système, pas d'un problème de document politique ni d'un problème de personnes. Une stratégie dans une diapositive ne peut pas arrêter un appel d'API, et un réviseur qui voit chaque action devient le plafond de débit du système. La seule gouvernance qui évolue avec le volume de l'agent est celle que la pile applique elle-même : au niveau de la couche d'autorisation, au niveau du chemin d'écriture et dans le journal. Le Top 10 2025 des applications LLM de OWASP qualifie directement le modèle d'échec d'« agence excessive » et le relie à trois causes profondes : fonctionnalité excessive, autorisations excessives et autonomie excessive.
Où ça se brise
Quatre anti-modèles sont récurrents dans les piles qui exécutent des agents sans couche de gouvernance.
Utilisateur d'intégration disposant de droits d'administrateur
L'agent s'authentifie en tant qu'utilisateur d'intégration partagé, généralement celui créé il y a des années pour la synchronisation de l'automatisation du marketing, avec un profil qui peut modifier chaque objet et champ. L'agent n'a besoin que de lire Account, Contact et Intent_Signal__c et de créer des enregistrements Task, mais il peut également mettre à jour Opportunity.Amount, réaffecter OwnerId et supprimer des enregistrements. Le périmètre d’impact correspond à l'ensemble du CRM, et chaque changement apparaît dans l'historique du champ en tant qu'utilisateur de l'intégration, impossible à distinguer de la synchronisation. Le même problème de propriété, avec des personnes plutôt que des agents, est la raison pour laquelle l'attribution de territoire nécessite sa propre piste d'audit.
Journaux qui enregistrent les résultats, pas les décisions
La plupart des journaux d'agent capturent ce qui s'est passé : "contact inscrit dans une séquence". Rares sont ceux qui saisissent pourquoi : quel déclencheur s'est déclenché, quels champs et signaux ont été lus, quelle version de politique a été appliquée, ce que le modèle a renvoyé et avec quelle confiance. Sans les entrées, une mauvaise action ne peut pas être rejouée ou reliée aux données, à l'invite ou à la règle. Une entrée de journal sans run_id la joignant aux entrées est un journal intime, pas une piste d’audit. La fiabilité des agents et le journal de décision expliquent ce qu'il faut instrumenter.
Points de validation sur tout ou sur rien
Les équipes choisissent l'un des deux paramètres suivants. Soit chaque action attend un humain, ce qui recrée le goulot d'étranglement et entraîne les évaluateurs à cliquer sur approuver sans lire, soit aucune ne le fait, ce qui fonctionne jusqu'à ce que le premier e-mail soit envoyé à un compte stratégique en cours de négociation. Aucun de ces paramètres ne distingue une création de tâche d’une modification de remise. Les barrières doivent être déclenchées par le risque de l’action, et non appliquées à l’agent dans son ensemble. La matrice de réversibilité des risques pour la conception human-in-the-loop montre comment les trier.
Pas de plafond et pas d'annulation
Un agent dans une boucle de nouvelle tentative ou dans une modification d'invite qui desserre un filtre peut exécuter des milliers d'actions avant que quiconque ne les regarde. Sans plafonds par exécution et par jour sur les actions et les dépenses, la seule limite est le quota de l'API, et le coût de la supervision et de la correction des erreurs atterrit de toute façon dans le modèle de coût par réunion qualifiée. Et sans enregistrement de la valeur antérieure de chaque champ, la restauration signifie la restauration à partir d'une sauvegarde et la perte de toutes les modifications légitimes effectuées depuis.
Architecture de référence
L'architecture comporte quatre contrôles : permissions limitées, plafonds d'action et de dépenses, journalisation des actions et capacité de restauration. Les points de validation s’ajoutent à eux sous forme de règles, et non comme cinquième file d’attente. Les contrôles sont déclarés une fois par agent, dans un fichier de stratégie dont les changements sont visibles dans le contrôle de version, et appliqués par les couches ci-dessous. Un exemple minimal pour un agent sortant :
agent: signal_outbound_v3
identity: svc_agent_outbound # its own user, never shared
read: [Account, Contact, Intent_Signal__c, Opportunity.StageName]
write: [Task.*, Sequence_Enrollment__c.*, Contact.Agent_Last_Touch__c]
deny_if: Account.Open_Opportunity__c = true OR Account.Renewal_Window__c = true
caps: {enrollments_per_run: 50, enrollments_per_day: 300, llm_spend_per_day_usd: 40}
gates:
- action: send_first_email
when: Account.Tier__c = "Strategic" OR model.confidence < 0.80
route: account_owner, expires_after: 24h, on_expiry: drop
log: {fields: [run_id, trigger, inputs_hash, policy_version, output, confidence, prior_values]}
rollback: by run_id
Chaque valeur est illustrative ; l’essentiel est la structure. Chaque couche de la pile en applique une partie.
Composants : événements des enregistrements CRM, les flux d'intention et d'enrichissement, les événements d'utilisation du produit, les remplissages de formulaires.
Contrat sur l'identité et la qualité des données : chaque déclencheur comporte un type d'événement, un horodatage, un système source et un ID d'enregistrement, afin que le journal puisse ultérieurement indiquer exactement ce qui a déclenché une exécution.
Composants : une identité de service par agent (un utilisateur d'intégration dédié ou une application connectée avec son propre ensemble d'autorisations), des identifiants de compte et de contact résolus et des indicateurs de suppression tels que Open_Opportunity__c, Renewal_Window__c et Do_Not_Contact__c calculés avant l'exécution de l'agent. Ces indicateurs sont aussi fiables que la couche de résolution d'identité située en dessous.
Contrat à l'orchestration : l'agent reçoit uniquement les champs de sa liste de lecture, déjà résolus en enregistrements canoniques. La suppression est un champ que lit l'agent, et non un jugement qu'il porte.
Composants : une vérification de politique qui s'exécute avant chaque écriture, évaluant les règles de refus, les plafonds et les conditions de validation ; compteurs d'actions et de dépenses de modèle par exécution et par jour ; un disjoncteur qui met l'agent en pause lorsqu'un plafond est atteint ou que le taux d'erreur augmente.
Contrat avec le système de référence : aucune écriture ne quitte cette couche sans qu'une décision politique y soit attachée : autoriser, bloquer ou refuser, avec le policy_version qui l'a créé.
Composants : sécurité au niveau du champ sur l'ensemble d'autorisations de l'agent, de sorte que même un moteur de stratégie bogué ne peut pas écrire Amount ou Discount__c ; un objet d'approbation pour les actions soumises à validation ; suivi de l'historique des champs, ainsi qu'un objet Agent_Action_Log__c ou une table d'entrepôt qui stocke les valeurs précédentes et nouvelles par run_id.
Contrat d'activation : chaque modification apportée par un agent peut être trouvée par run_id et rétablie à sa valeur antérieure sans toucher aux modifications apportées par les utilisateurs.
Composants : l'agent lui-même ; infrastructure d'envoi et de séquençage ; actions soumises à validation fournies au propriétaire du compte dans Slack ou CRM avec une approbation ou un rejet en un clic, une expiration et une valeur par défaut sûre à l'expiration.
Contrat de direction : une vue hebdomadaire par agent des actions, des validations, du délai d'approbation, des remplacements, des atteintes de plafond et des annulations.
Voici comment les quatre contrôles correspondent aux cas d'utilisation courants de l'agent GTM, à titre d’exemple illustratif plutôt que de prescription :
| Cas d'utilisation de l'agent | Permissions limitées | Plafonds | Point de validation | Annulation |
|---|---|---|---|---|
| Sortant basé sur les signaux | Lire les comptes et les signaux ; créer des tâches et des inscriptions uniquement | Inscriptions par exécution et par jour ; dépenses du modèle par jour | Premier e-mail adressé à des comptes stratégiques ou inférieur à un seuil de confiance | Annuler les inscriptions par run_id |
| Hygiène des pipelines | Écrire les champs de l'étape suivante et des indicateurs ; jamais l’étape ni le montant | Enregistrements touchés par exécution | Toute modification proposée à CloseDate est transmise au représentant en tant que suggestion | Restaurer les valeurs antérieures par run_id |
| Note de transfert | Lire l’affaire gagnée ; créer un enregistrement de synthèse | Une synthèse par opportunité | Aucun ; le CSM édite le brief | Supprimer le brief |
| Recommandation de tarification de renouvellement | Lecture seule ; écrire dans un objet de recommandation | Recommandations par jour | Toujours ; un humain fixe n'importe quel prix | Rien à annuler |
| Questions sur les revenus et commentaires sur les prévisions | Lecture seule, avec un accès au niveau des lignes correspondant aux droits du demandeur | Requêtes par utilisateur et par jour | Aucune pour les réponses ; toute écriture est hors de portée | Non applicable |
Séquence de construction
Six étapes, chacune avec un test.
Inventairez chaque agent et l'identité sous laquelle il s'exécute
Répertoriez chaque agent, action de copilote et automatisation assistée par l'IA qui écrit dans un système de revenus, avec l'utilisateur ou le jeton sous lequel il s'authentifie et les objets que l'identité peut modifier. Le playbook de diagnostic avant de créer s'applique. Test : aucun agent, ni un agent et une synchronisation, ne partagent une identité.
Classez chaque action par réversibilité et périmètre d’impact
Pour chaque action qu'un agent peut entreprendre, posez deux questions : peut-elle être annulée sans que le client ne s'en aperçoive, et combien d'enregistrements ou de personnes une mauvaise exécution peut-elle affecter ? Les tâches et les indicateurs sont faibles ; les e-mails, les changements de responsable et les prix sont élevés. Test : chaque action de la liste possède une classe, acceptée par la personne à qui appartient le résultat.
Définissez l'identité et appliquez-la dans le CRM
Donnez à chaque agent son propre ensemble d'autorisations avec uniquement les objets et les champs dont sa liste d'actions a besoin, et refusez le reste avec une sécurité au niveau du champ, et non avec des instructions dans une invite. Test : une tentative d'écriture dans un champ en dehors de la liste échoue au niveau du CRM, pas dans le code de l'agent.
Ajoutez des plafonds, un disjoncteur et un journal de décision
Placez la vérification des règles devant chaque écriture : règles de refus, compteurs d'actions et de dépenses, ainsi qu'une pause lorsqu'un plafond est atteint. Enregistrez chaque décision avec son run_id, son déclencheur, ses entrées, sa version de politique, sa sortie, sa confiance et la valeur antérieure de chaque champ modifié. Test : une exécution délibérément bouclée s'arrête au plafond et ses entrées de journal peuvent reconstruire chaque action.
Validez selon la politique, avec expiration et valeur par défaut sécurisée
Acheminez uniquement les actions à haut risque vers un humain, livrez-les là où le propriétaire travaille et attribuez à chaque point de validation une expiration et une valeur par défaut : supprimez l'e-mail, conservez l'ancienne valeur, créez une tâche à la place. Test : une action bloquée à laquelle personne ne répond se résout d'elle-même en toute sécurité, et la part des actions bloquées reste suffisamment petite pour que les évaluateurs les lisent quand même.
Prouvez la restauration et le backtest avant d'élargir la portée
Annulez un test complet exécuté par run_id et confirmez que les modifications humaines survivent. Ensuite, testez l'agent sur une vingtaine de vos propres cas passés, étiquetés par votre équipe. Nous exigeons le même seuil pour chaque système : au moins 85 % d'accord avec ces étiquettes et aucune action dangereuse non détectée, sinon il n’est pas mis en production. Test : les résultats du rollback et du backtest sont enregistrés avant qu'un plafond ne soit relevé ou qu'un point de validation soit supprimé.
Construire ou acheter : compromis
Il existe trois emplacements courants pour placer la couche de gouvernance. Les outils sont des exemples et non des recommandations.
| Approche | Adéquation | Coût de possession | Risque de défaillance |
|---|---|---|---|
| Contrôles natifs CRM (ensembles d'autorisations, sécurité au niveau du champ, processus d'approbation et historique des champs dans Salesforce ou HubSpot, ainsi que tous les garde-fous dans une plate-forme d'agent native) | Agents qui n'agissent qu'à l'intérieur d'un seul CRM ; l'endroit le plus puissant pour appliquer les autorisations limitées | Faible. Maintenu par l'administrateur et déjà audité par la plateforme ; les limites de conservation de l'historique des champs peuvent nécessiter l'exportation des journaux | Faible niveau de plafonds et de limites de dépenses entre systèmes ; les journaux de décision incluent rarement les entrées du modèle et la confiance |
| Outil de workflow en tant que couche de stratégie (par exemple n8n, Make ou Workato placé entre l'agent et les systèmes) | Agents qui agissent sur CRM, outils de séquençage et de messagerie ; plafonds et validations en un seul endroit | Modéré. Quelqu'un doit posséder des politiques, des compteurs et des tables de journaux | Risque de contournement si l'agent détient également des informations d'identification directes pour l'API ; le CRM doit toujours appliquer les autorisations en dessous |
| Service de stratégie personnalisé avec un cadre d'agent (par exemple un petit service devant des agents construits sur LangGraph ou similaire) | Plusieurs agents, volume élevé ou besoin de stratégie en tant que code versionnée et de relecture | Le plus élevé. Temps d'ingénierie nécessaire pour construire, tester et maintenir | Devient son propre système critique ; un bug dans le moteur de règles peut tout autoriser ou tout bloquer en même temps |
L'exécuter en production
Observez cinq chiffres par agent : actions, part des actions soumises à validation, latence d'approbation, taux de dérogation et plafond atteint. Une part croissante d’actions soumises à validation signifie que la politique est trop large ; un taux de dérogation croissant signifie que l'agent se trompe plus souvent ; une longue latence d'approbation signifie que la demande est acheminée vers la mauvaise personne.
Chaque point de validation expire en appliquant sa valeur par défaut sûre, chaque plafond déclenche le disjoncteur et chaque agent peut être mis en lecture seule avec un seul paramètre, sans redéploiement. Si le moteur de stratégie est en panne, les écritures sont refusées et la restauration par run_id est répétée tous les trimestres.
Trois phrases résument le fonctionnement : chaque agent ne peut toucher que les enregistrements et les champs dont son travail a besoin, et le CRM l'applique ; chaque agent a des limites strictes quant à ce qu'il peut faire en une journée, et chaque action peut être retracée et annulée ; les humains approuvent uniquement les actions qui seraient coûteuses et difficiles à annuler, et nous suivons la rapidité avec laquelle ils les accomplissent.
Où cela se situe-t-il dans le système
La gouvernance permet à chaque système VANDFORT de fonctionner sans qu'une personne ne surveille chaque étape. Le Signal-Based Outbound Engine comporte les contrôles les plus stricts : droits d'inscription limités, plafonds quotidiens, suppression des opportunités ouvertes et des renouvellements, limite stricte sur les segments que vous avez nommés et aucun envoi sans l'approbation d'une personne. Le Pipeline Hygiene Sentinel signale et escalade mais ne modifie jamais une transaction, ne modifie pas une étape ou ne déplace une date de clôture. Renewal Radar escalade et planifie mais n'engage jamais votre équipe à une remise ou à une concession. Revenue Answers et Forecast Assistant répondent et indiquent plutôt que d'écrire, ce qui supprime la majeure partie du problème de gouvernance avant qu’il n’apparaisse. Chacun d'entre eux commence par un accès en lecture seule à vos systèmes d'enregistrement jusqu'à ce que vous l'élargissiez. La carte complète se trouve sur la page systèmes.
La couche de gouvernance dépend également des couches qui l'entourent. Les indicateurs de suppression sont aussi efficaces que la résolution d'identité, et les plafonds ne vous protègent que si chaque agent effectue la même vérification de stratégie. C'est pourquoi une mission d’ingénierie intégrée aux équipes du client commence avec les propres données du client et livre un système à la fois, chacun avec ses contrôles testés avant la mise en service. L'arbre de décision GTM entre ingénieur RevOps et ingénieur de croissance aide à décider à qui appartiennent les politiques d'agent.
Sources : SailPoint, AI Agents : The New Attack Surface, recherche menée par Dimensional Research (353 professionnels de l'informatique ; mai 2025). Deloitte, State of AI in the Enterprise (3 235 dirigeants informatiques et commerciaux ; 2026). Salesforce, rapport sur l'état des ventes (4 050 professionnels de la vente ; février 2026). Gartner, Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027 (juin 2025). Gartner, Gartner Predicts that Guardian Agents will Capture 10-15% of the Agentic AI Market by 2030 (juin 2025). OWASP GenAI Security Project, LLM06:2025 Excessive Agency (2025).
