Journaliser les usages IA : obligation ou précaution ?
En bref. Tenir un journal des usages d’IA consiste à enregistrer, de façon structurée, qui a sollicité quel modèle, avec quelle donnée d’entrée et à quel moment. Cette trace permet de vérifier la conformité, de retrouver l’origine d’une décision automatisée et d’ajuster les paramètres sans repartir de zéro. Selon la sensibilité des données, il convient de conserver les journaux entre trois mois et deux ans, en les chiffrant et en limitant l’accès aux personnes habilitées.
Une situation concrète qui montre l’intérêt du journal
Lors de la revue mensuelle du pôle marketing, la responsable a constaté que l’assistant IA intégré au CRM avait proposé une segmentation de clientèle basée sur des données datant de six mois, alors que les dernières interactions n’étaient pas prises en compte. En consultant le journal des requêtes, elle a découvert que le flux d’alimentation du modèle avait été interrompu suite à une mise à jour du connecteur n8n qui n’avait pas été re‑validé. Cette visibilité a permis de rétablir le pipeline en moins de deux heures, évitant une campagne basée sur des informations obsolètes.
Ce qu’il faut enregistrer
- Identifiant de l’utilisateur ou du service qui a lancé la requête (ex. : compte Salesforce, adresse e‑mail interne).
- Horodatage UTC de la demande.
- Nom et version du modèle utilisé (ex. : GPT‑4o‑2024‑08, Mistral‑7b‑instruct).
- Jeu de données d’entrée fourni (référence au fichier, extrait anonymé ou hash du prompt).
- Paramètres de génération (temperature, top‑p, nombre de tokens max).
- Sortie brute renvoyée par le modèle (texte, JSON, score).
- Éventuelle note ou correction apportée par un opérateur humain.
Ces éléments tiennent généralement dans quelques centaines de caractères par ligne ; ils peuvent être stockés dans un fichier CSV, une table SQL ou un indice Elasticsearch selon le volume.
Combien de temps conserver les journaux
La durée de conservation dépend du niveau de sensibilité des données traitées et des obligations sectorielles. À titre d’ordre de grandeur :
| Type de donnée | Durée de conservation recommandée |
|---|---|
| Logs d’usage sur des données publiques ou déjà anonymisées | 3 à 6 mois |
| Logs portant sur des données personnelles (RGPD) ou des informations commerciales sensibles | 12 à 24 mois |
| Logs liés à des décisions pouvant faire l’objet d’un contrôle réglementaire (finance, santé) | 24 à 36 mois |
Au-delà de ces périodes, il est recommandé d’archiver les journaux sous forme compressée et chiffrée, puis de les détruire de façon sécurisée.
Comment mettre en place un journal simple avec des outils courants
Pour une PME qui utilise déjà un CRM (ex. : HubSpot) et un outil d’automatisation (Make ou n8n), il suffit d’ajouter un webhook qui, à chaque appel au modèle, écrit une ligne dans une base SQLite hébergée sur un serveur interne. Le scénario suivant illustre le flux :
- L’utilisateur lance une demande via le chatbot du CRM.
- Make reçoit le webhook, enrichit la requête avec l’identifiant de l’utilisateur et l’horodatage, puis appelle l’API du modèle (Claude ou GPT‑4o).
- Avant de retourner la réponse, Make insère un enregistrement dans la table
ia_logs(colonnes : user_id, timestamp, model, prompt_hash, response, params). - Le chatbot affiche la réponse à l’utilisateur.
Ce dispositif ne nécessite pas de licence supplémentaire ; il repose sur les fonctions natives de Make (HTTP request → DB insert). Pour les volumes supérieurs à quelques milliers de lignes par jour, basculer vers une base PostgreSQL ou un service managé comme Amazon RDS reste une évolution raisonnable.
Quand ne pas journaliser – un cas à éviter
Journaliser chaque prompt contenant des données de santé non pseudonymisées vers un service de logging externalisé (ex. : un compte Google Sheets partagé) crée un risque de fuite qui dépasse largement le bénéfice de traçabilité. Dans ce contexte, la réponse est « ne le faites pas » : mieux vaut renoncer à la journalisation externe et privilégier un stockage local chiffré, voire limiter l’usage du modèle à des tâches qui ne manipulent pas d’informations sensibles. Le surcoût en conformité et la perte de confiance des parties prenantes justifient cette précaution.
Prochaine action concrète
Planifiez une réunion de 30 minutes avec le responsable IT et le pilote du projet IA afin de cartographier les flux actuels d’appels aux modèles, d’identifier les points où un webhook peut être ajouté sans perturber l’expérience utilisateur, et de définir un premier scénario de journalisation à tester sur un environnement de pré‑production pendant deux semaines.
Questions fréquentes
Dois-je journaliser les appels à un modèle utilisé uniquement pour du brainstorming interne ?
Si les entrées ne contiennent aucune donnée personnelle ou confidentielle, un journal léger conservé trente jours suffit pour retrouver une idée ou ajuster le paramétrage. Au-delà, la valeur ajoutée diminue tandis que la charge de stockage augmente.
Quel format de fichier est le plus adapté pour un archivage à long terme ?
Un fichier CSV compressé (gzip) accompagné d’un fichier de métadonnées JSON décrivant les colonnes et le schéma assure une lisibilité future indépendamment de l’outil utilisé. Évitez les formats propriétaires qui peuvent devenir obsolètes.
Puis-je utiliser le même journal pour plusieurs modèles différents ?
Oui, à condition d’inclure le champ « model » permettant de distinguer les entrées. Un schéma commun simplifie les requêtes d’audit et les tableaux de bord de suivi.
Est‑ce que le journaling ralentit significativement le temps de réponse ?
L’insertion d’une ligne dans une base locale ajoute généralement moins de cinquante millisecondes, négligeable devant le temps d’inférence du modèle. Seul un volume extrêmement élevé ou une base distante mal configurée pourrait impacter la latence.