--- title: Laisser l’IA agir en sécurité : un seul journal d’audit, pas cinq canonical: https://getcyril.com/fr/blog/les-agents-ont-besoin-d-un-seul-journal-d-audit/ published: 2026-06-02 updated: 2026-08-28 author: Sam Akbari language: fr --- # Laisser l’IA agir en sécurité : un seul journal d’audit, pas cinq Mal répondre à une question coûte une minute. Mal exécuter une action envoie le courriel, déplace l'affaire, crédite la facture. Entre l'IA générative et l'IA agentique, l'écart est celui qui sépare l'inutile du dangereux — et l'essentiel du travail qui permet de le combler sans danger se joue en dessous du modèle. Cyril est conçu pour que des agents agissent en votre nom. Cela ne tient que si chaque action passe par les trois mêmes points qu'une action humaine : un contrôle de permissions, un enregistrement d'audit, et un moyen de revenir en arrière. ## Le problème des actions réparties sur cinq outils Dans une pile assemblée à la main, un agent qui agit doit agir *à travers des intégrations*. Il crée le projet dans un outil, envoie le courriel par un deuxième, met à jour l'affaire dans un troisième. Chacun a son propre modèle de permissions, sa propre piste d'audit — ou aucune — et aucune notion partagée d'« annulation ». Alors le jour où quelque chose tourne mal — et avec des agents, quelque chose tournera mal — il vous reste à reconstituer les faits à partir de cinq journaux partiels qui ne partagent ni identifiant, ni horloge, ni vocabulaire. Impossible de répondre à la seule question qui compte : *qu'a fait l'agent, sous quelle autorité, et comment revenir en arrière ?* Ce n'est pas un problème de sûreté du modèle. C'est un problème d'architecture, et aucune invite de garde-fou ne le corrige. ## Un seul modèle de permissions Chez Cyril, un agent est un appelant, pas un mode dieu. Il agit à l'intérieur du même RBAC que celui qui gouverne les personnes : cantonné à un `org_id`, borné par un rôle, autorisé exactement aux permissions de son habilitation — pas une de plus. Un agent à qui l'on demande quelque chose qui sort de ses permissions se voit opposer le même refus qu'un utilisateur, par le même chemin de code. C'est important, parce que cela rend l'autorité d'un agent *lisible*. « Que peut faire cet agent ? » appelle une réponse de même forme que « que peut faire cette personne ? » — et cela se règle au même endroit. ## Un seul journal d'audit Chaque action — humaine ou agentique — écrit dans une piste d'audit unique : l'acteur, l'autorité sous laquelle il a agi, l'avant et l'après, et un horodatage issu d'une seule horloge. Une action d'agent est marquée comme telle, si bien que « montre-moi tout ce que l'assistant a fait sur le compte Phoenix la semaine dernière » tient en une requête, et non en une reconstitution judiciaire à travers plusieurs systèmes. Quand les actions et leurs traces vivent sur un même graphe, le journal d'audit n'est pas une pièce rapportée. C'est une lecture naturelle des mêmes données. ## Une seule voie de retour arrière Parce que les mutations sont transactionnelles et que les données des clients font l'objet d'une suppression logique plutôt que d'une destruction, l'action d'un agent a un inverse défini. Un mauvais geste est un geste rattrapable. La propriété qui vous protège d'un mauvais clic humain vous protège d'un mauvais pas d'agent — il n'existe pas de voie d'écriture « IA » distincte, plus risquée, qui contournerait les protections. ## La validation humaine est un réglage, pas une refonte Certaines actions doivent simplement se faire ; d'autres doivent attendre une personne. Comme toutes passent par un pipeline unique, « exiger une approbation » est une règle que l'on applique à une classe d'actions — pas une fonction à re-développer pour chaque intégration. Vous décidez de la latitude laissée à l'agent, action par action, et vous changez d'avis sans toucher à l'agent. ## Ce que cela change pour vous - Laissez un agent dérouler un flux en plusieurs étapes à travers les modules, et voyez exactement ce qu'il a fait, dans un seul journal, sous une seule identité. - Donnez-lui une autorité réelle sans lui donner une autorité illimitée — mêmes rôles, même cloisonnement que pour votre équipe. - Annulez une étape erronée comme vous annuleriez n'importe quelle étape, parce qu'il n'y a jamais eu de seconde voie d'écriture, plus faible. La fiabilité d'une IA qui agit ne tient pas d'abord à l'invite. Elle tient à la capacité de la plateforme en dessous à répondre de ce que l'agent a fait. Cyril est bâti pour pouvoir le faire, toujours. ## Questions fréquentes ### Une invite de garde-fou ne suffit-elle pas ? Une invite oriente ce que le modèle cherche à faire. Elle ne change rien à ce que la plateforme l'autorise à faire, et c'est la seconde qui tient quand la première se trompe. Traitez l'invite comme du confort d'usage et le modèle de permissions comme le mécanisme de contrôle. ### Un agent doit-il avoir son propre compte de service ? Pas un compte largement ouvert. Un compte de service doté d'un vaste accès en lecture déplace la question de l'autorité hors de votre modèle de rôles, vers un endroit que personne ne relit. Un agent qui agit en tant qu'utilisateur, dans les permissions de celui-ci, laisse « que peut faire cet agent » se répondre au même endroit que « que peut faire cette personne ». ### Que veut dire concrètement une seule voie de retour arrière ? Que l'écriture d'un agent emprunte le même chemin de code, transactionnel et à suppression logique, que celle d'un humain — l'inverse existe donc déjà. Il n'y a pas de seconde voie d'écriture, plus faible, réservée à l'IA et contournant les protections : c'est justement celle que l'on ajoute d'ordinaire sous la pression du lancement. ### L'approbation peut-elle n'être exigée que pour certaines actions ? Oui, et c'est tout l'intérêt de faire passer l'ensemble par un pipeline unique : l'approbation est une règle appliquée à une classe d'actions, pas une fonction reconstruite pour chaque intégration. Vous modifiez la latitude laissée à l'agent sans toucher à l'agent. --- Si vous voulez être parmi les premiers à utiliser Cyril, [inscrivez-vous sur la liste d'attente](/waitlist/).