Journal d'audit

Le journal d'audit d'i1n enregistre chaque modification au sein d'une organisation — pas comme une ligne générale « fichier de traduction mis à jour », mais comme un événement structuré, par clé et par langue. Lorsqu'un utilisateur du tableau de bord modifie la traduction en espagnol (es_mx) de errors.insufficient_funds à 14:32 UTC, le journal capture la valeur exacte avant la modification, la valeur exacte après la modification, l'identité de l'acteur, l'horodatage, l'adresse IP et l'agent utilisateur de la requête qui a produit le changement.

La couverture s'étend à toute la surface de la plateforme : création, modification et suppression de traductions ; création, renommage et suppression d'espaces de noms ; modifications des paramètres du projet et de la voix de la marque ; invitations d'équipe, modifications et suppressions de rôles ; création, rotation, modification de portée et suppression de clés API ; modifications du plan de facturation, événements d'abonnement et activation BYOK.

Les opérations en masse telles que la poussée i1n produisent un événement par paire clé-langue modifiée plutôt qu'un résumé global unique, avec un identifiant de lot partagé dans les métadonnées. Une poussée qui met à jour 200 clés dans quatre langues produit 800 entrées d'audit adressables individuellement, chacune avec sa propre différence. Les auditeurs peuvent donc répondre à la question « qu'est-ce qui a changé le 17 avril à 14h32 » jusqu'à la chaîne exacte.

Les événements sont émis par des déclencheurs PostgreSQL attachés à chaque table auditée. Il n'existe aucun chemin d'écriture au niveau de l'application qui contourne le journal — every successful mutation generates its audit row inside the same database transaction. A change that is committed without a corresponding audit row is not possible by construction.

Chaque entrée d'audit est associée à l'un des cinq types d'acteurs : user pour les mutations du tableau de bord, cli pour les opérations directes en ligne de commande, mcp pour les modifications effectuées par un agent IA via le serveur i1n MCP, webhook pour les événements provenant de systèmes externes tels que le fournisseur de facturation, et system pour les tâches internes à la plateforme telles que l'élagage de rétention.

L'attribution des utilisateurs du tableau de bord est cryptographique. L'identifiant de l'acteur est l'ID de compte de l'utilisateur authentifié, associé à son e-mail vérifié et à son nom de la liste des membres de l'organisation. Les administrateurs qui examinent le journal voient des identités humaines réelles, pas des UUID opaques.

L'attribution CLI et MCP est cryptographiquement liée à la clé d'API utilisée, le préfixe de la clé étant enregistré pour la corrélation forensique. Les indices dérivés de la configuration git du développeur — e-mail et nom complet — sont également capturés mais sont explicitement marqués comme non vérifiés dans le tableau de bord. Cette séparation honnête entre l'identité cryptographique et les métadonnées auto-déclarées est ce que les examinateurs de conformité attendent d'un système d'audit mature.

L'observabilité des agents IA est, à notre connaissance, unique à i1n. Chaque modification de traduction effectuée par Claude Code, Cursor ou tout autre client connecté au serveur i1n MCP est taguée avec actor_type = 'mcp'. Les organisations peuvent filtrer le journal d'audit pour répondre à la question « quelles traductions ont été modifiées pour la dernière fois par un agent IA par rapport à un réviseur humain » — une question qui n'a pas de réponse claire sur aucune autre plateforme de localisation.

Alors que les agents d'IA assument une plus grande partie du flux de travail de localisation, la capacité de les auditer en tant qu'acteurs de premier plan devient une exigence d'approvisionnement. Le filtre de type d'acteur est à un clic dans le tableau de bord et à un paramètre de requête dans l'exportation CSV.

Le journal d'audit est en mode ajout uniquement au niveau de la base de données. Les déclencheurs émettent des lignes ; aucun chemin d'INSERT n'est exposé aux clients, et il n'y a pas de politiques UPDATE ou DELETE sur la table. Les membres d'une organisation ne peuvent pas modifier leur propre historique. Le personnel des opérations i1n ne peut pas non plus modifier ou supprimer des entrées — la table est protégée au niveau du schéma, pas au niveau de l'application.

La rétention est de 365 jours, conformément à la base de référence du contrôle SOC 2 pour les journaux d'activité. Les enregistrements de plus de 365 jours sont supprimés par une tâche planifiée qui émet elle-même une entrée d'audit — chaque suppression est traçable. Les organisations qui nécessitent des périodes plus longues pour un examen réglementaire spécifique peuvent demander une extension au niveau du contrat.

Le journal affiche les points de données que les réviseurs de conformité demandent généralement : qui, quoi, quand, où (adresse IP), comment (agent utilisateur) et ce qui a changé (valeurs avant et après, en totalité). Pour les organisations soumises à l'article 30 du RGPD sur la tenue de registres ou aux régulateurs de la fintech qui exigent la traçabilité du contenu destiné aux utilisateurs, l'exportation est suffisante comme preuve principale.

i1n ne publie pas actuellement de rapport SOC 2 Type II au niveau de la plateforme. Le journal d'audit est le contrôle sous-jacent qui soutient le propre programme de conformité SOC 2, GDPR ou fintech d'un client — il ne remplace pas les contrôles organisationnels, mais il élimine le blocage le plus courant dans les revues de conformité, qui est l'absence d'une piste vérifiable sur les modifications de contenu.

L'accès en lecture au journal d'audit est réservé aux propriétaires et administrateurs de l'organisation. Les éditeurs et les lecteurs ne voient pas l'onglet du journal d'audit dans le tableau de bord et ne peuvent pas l'interroger via l'API. Cette séparation est appliquée par la sécurité au niveau des lignes de PostgreSQL, et non par une dissimulation côté client — il n'existe aucun moyen de lire le journal à partir d'un rôle non privilégié.

Les éditeurs et les spectateurs restent entièrement soumis au journal d'audit. Chaque action qu'ils effectuent sur la plateforme — modifications de traduction, demandes de traduction par IA, opérations au niveau des membres — est enregistrée avec leur identité et visible par l'équipe d'administration. Les personnes auditées ne peuvent pas se retirer de l'audit.

Les propriétaires et les administrateurs ne peuvent pas modifier les entrées historiques. La question « qui peut lire » et la question « qui peut modifier » ont délibérément des réponses différentes — la lecture est au niveau de l'administrateur, la modification est impossible pour quiconque. Cela satisfait les attentes de séparation des tâches que les auditeurs appliquent lors de l'examen des contrôles d'accès internes.

L'accès à l'API reflète le modèle du tableau de bord. Le journal d'audit est exposé via les mêmes politiques de sécurité au niveau des lignes qui régissent le tableau de bord, de sorte que tout compte de service ou jeton d'intégration utilisé pour interroger le journal hérite automatiquement des mêmes restrictions.

Les données du journal d'audit peuvent être exportées au format CSV depuis le tableau de bord en une seule action. L'exportation couvre toute plage horaire sélectionnée et respecte les filtres actifs — type d'acteur, type d'événement, projet et terme de recherche — afin que les réviseurs puissent recevoir une tranche ciblée plutôt que l'historique complet. Le CSV conserve une fidélité complète : horodatage, organisation, projet, identité de l'acteur, type d'acteur, préfixe de clé API, type d'événement, entité, valeur précédente, valeur suivante, adresse IP, agent utilisateur et métadonnées.

Chaque exportation CSV génère elle-même une entrée d'audit de type audit_log.exported, enregistrant qui a effectué l'exportation et quels filtres ont été appliqués. Cela clôture la boucle de chaîne de traçabilité que les examinateurs de conformité demandent — l'acte de récupérer des preuves fait partie intégrante des preuves.

Le journal d'audit est automatiquement actif sur toutes les organisations Enterprise. Aucune étape de configuration, aucun commutateur d'activation et aucune configuration n'est requise. Les clients Enterprise existants, y compris belo, le partenaire de lancement, disposent d'un journal rempli dès l'expédition de la fonctionnalité, capturant l'activité de chaque tableau de bord, CLI et client MCP connecté à l'organisation.

Les organisations utilisant les offres Pro ou Business n'ont pas accès au journal d'audit. La mise à niveau vers Enterprise active le journal immédiatement et commence à capturer les événements à partir de l'horodatage de la mise à niveau ; la conservation historique antérieure à la mise à niveau n'est pas fournie. Contactez l'équipe i1n pour discuter des tarifs Enterprise pour votre organisation.