Pendant un an, trois agents IA ont fait tourner le back-office de ma propre activité, et aucun n’a jamais rien fait de dangereux. Ils se sont tus. L’agent d’audit est resté aveugle dix jours d’affilée avant que je m’en aperçoive, et le démon qui rédigeait les spécifications était arrêté depuis 47 jours sans qu’aucune alarme ne le signale. Les règles qui ont tenu portaient sur ce que chaque agent pouvait toucher, sur la façon dont il demandait une approbation, et sur la manière dont je verrais qu’il s’était arrêté.
Le dispositif, et ses limites
Il s’agissait de l’intendance d’une activité en solo : recherche, suivi du pipeline, rédaction, outillage interne. Les trois agents avaient des privilèges volontairement inégaux, et je restais le seul point de décision. Un orchestrateur détenait le contexte métier et rédigeait tout ce qu’une personne allait lire ; sa production s’arrêtait toujours au brouillon. Un agent de code travaillait à partir de spécifications écrites, dans une branche isolée, sans données métier, et ne commitait jamais sur la branche principale. Un auditeur planifié comparait le tableau de suivi aux dépôts sans rien pouvoir modifier ; sa seule sortie était une pull request. Le travail circulait par des fichiers, des branches et des cartes, si bien que chaque étape laissait une trace lisible des semaines plus tard.
Mon métier, c’est la conduite de programmes et l’enseignement de Salesforce. C’était mon propre back-office, pas un livrable client, à l’échelle d’une personne et d’un tableau de suivi. Ces leçons sont celles que j’apporte aujourd’hui aux administrateurs que je forme à l’IA dans Salesforce : qui détient quels droits, à quelles données un agent accède, et comment les équipes adoptent un outil qui agit sans elles. Les mêmes questions, appliquées à Agentforce, sont dans la note Modèle opérationnel Agentforce.
En septembre 2026, j’ai retiré ce dispositif à trois agents et je l’ai regroupé en un seul assistant, avec moins de pièces mobiles. Les règles sont passées intactes, parce qu’aucune ne dépendait du nombre d’agents. Elles s’appliquent à tout composant qui agit quand personne ne regarde.
L’autonomie tombe en panne en silence
La tâche de l’agent d’audit tournait chaque matin et ouvrait une pull request avec ses constats. Les pull requests continuaient d’arriver, donc le système semblait vivant. Chacune était vide : l’agent ne pouvait plus atteindre les données qu’il devait auditer. La même revue a trouvé le démon de rédaction des spécifications, coupé 47 jours plus tôt par un lot de configuration. Les deux fois, la mécanique fonctionnait. C’est l’alimentation et la surveillance qui ont failli.
On écrit surtout sur les actions nuisibles des agents. Ce que j’ai rencontré, c’est l’absence, et aucun modèle ne signale sa propre absence. Chaque composant planifié a besoin d’un battement de cœur et d’une alarme quand ce battement s’arrête. Un rapport qui arrive vide n’est pas un battement de cœur : le contrôle doit lire le contenu. Cela se met en place dès la première version.
Moins de privilèges à mesure que l’autonomie grandit
La règle de fond : plus un agent agit librement, moins il peut toucher. Sa forme la plus nette est le triangle d’exfiltration. Un agent qui combine une entrée contrôlable par un attaquant, une sortie autonome vers l’extérieur et l’accès à des données sensibles est à une injection de prompt d’une fuite, quel que soit le modèle. Deux côtés sur trois sont acceptables ; les trois, non. Chaque agent avait donc un côté retiré structurellement, par un identifiant absent ou un chemin réseau bloqué, jamais par une ligne de prompt priant le modèle de bien se tenir. L’agent de code lisait du contenu de dépôt non fiable et pouvait pousser des branches : il ne détenait aucune donnée sensible.
Deux incidents ont affûté la règle. Un prototype de tri de boîte mail retirait d’abord les données personnelles des messages, pour ne laisser à l’agent que des catégories et des indicateurs. Un test réel a montré qu’on ne rédige pas une réponse utile à partir d’indicateurs. La correction a inversé l’arbitrage : l’agent lisait les messages complets, et c’est la sortie qui a été coupée (proxy à liste blanche, pas d’identifiant d’envoi, pas d’outil de requête web). Plus tard, une revue de sécurité a trouvé des outils shell sur un rédacteur sans interface qui résumait des messages entrants non fiables : un chemin plausible entre un message malveillant et du code exécuté sur la machine. Il a été reconstruit en simple rédacteur de texte, un script d’enveloppe gérant toutes les entrées et sorties. Un agent sans interface qui traite des entrées non fiables n’a ni shell ni dérogation de permissions.
L’approbation, un contrat mécanique
Aucun modèle n’a jamais envoyé de message sortant. Tout ce qui visait un client finissait dans une file, et un script sans modèle ne l’envoyait qu’une fois qu’une personne avait posé un indicateur d’approbation. L’étape d’envoi était volontairement trop simple pour se laisser convaincre de quoi que ce soit.
Chaque proposition, changement de code ou correction du tableau, arrivait sous forme de pull request. Fusionner valait approbation ; fermer avec un commentaire valait refus. Cette seule convention donnait la piste d’audit, la revue du diff et la possibilité de bloquer un changement en approuvant le reste, grâce à des outils éprouvés.
Le contrat ne marche que si une tâche se vérifie mécaniquement. Une règle d’aiguillage décidait de ce que l’agent de code pouvait recevoir : si l’acceptation ne pouvait pas s’écrire en tests qui passent, build vert et recherche qui renvoie le nombre attendu, la tâche restait chez un agent supervisé. Quand les premières tâches sont revenues refusées, corriger les spécifications a corrigé les refus. Le modèle, lui, n’avait pas changé.
Armer selon le rayon d’impact
Chaque automatisme était classé en lecture (il lit seulement), brouillon (il produit ce qu’une personne approuve) ou exécution (il agit sans personne dans la boucle). Lecture et brouillon tournaient toute la journée sans pouvoir toucher l’extérieur. L’exécution dépendait d’un seul fichier d’armement dans le dépôt : présent, l’automatisme était armé ; le supprimer arrêtait tout, et son état se lisait dans l’historique de version. Les coupe-circuits étaient des fichiers plutôt que des entrées de configuration, parce qu’un fichier se compare, se recherche et se lit sans ambiguïté en plein incident.
La barrière a servi une fois : l’auditeur a proposé de passer une tâche en « prêt à livrer » sur un dépôt qui déployait à la fusion. Ces dépôts figuraient sur la liste des actions interdites, et la proposition est remontée jusqu’à moi. La carte était légitime ; un autre jour, le même geste est un déploiement en production que personne n’a relu.
L’automatisme le plus large, des actions sur toutes les tâches du tableau, a été livré derrière son propre coupe-circuit, a tourné en simulation et est resté éteint. Les incidents sont venus des composants armés. C’est le rayon d’impact qui fixait l’ordre d’armement, et certains interrupteurs méritaient de rester éteints plus longtemps que l’enthousiasme ne le voulait.
À vérifier
- Un seul fichier de présence arme tout ce qui agit sans personne, avec un coupe-circuit par composant à côté.
- Aucun modèle ne détient d’identifiant d’envoi. Une étape sans modèle envoie sur un indicateur posé par une personne.
- Les propositions arrivent en pull request : la fusion approuve, la fermeture refuse, rien ne s’approuve à l’oral.
- Chaque composant planifié a un battement de cœur et une alarme sur le silence, et l’alarme lit le contenu en plus de l’arrivée.
- Chaque agent a un côté du triangle d’exfiltration retiré structurellement.
- Les fichiers d’instructions, d’identité et de voix, ainsi que la mémoire des agents, ne sont modifiables par aucun agent.