Erreurs courantes de journalisation et de conservation dans les équipes SaaS

Les erreurs les plus fréquentes ne viennent pas d'un manque de données. Elles apparaissent lorsque l'équipe ne peut expliquer ce qu'elle enregistre, pourquoi, qui le contrôle, combien de temps elle le conserve ou quelle question précise ces traces permettent de résoudre. On obtient alors une télémétrie coûteuse qui accroît les risques de confidentialité et de sécurité sans constituer une piste d'audit IA défendable.

Pour les systèmes d'IA à haut risque, l'article 12 du règlement européen sur l'IA impose des capacités techniques d'enregistrement automatique des événements pendant le cycle de vie. Les articles 19 et 26 demandent aux fournisseurs et déployeurs de conserver les journaux automatiques sous leur contrôle pendant une durée adaptée et, en principe, au moins six mois, sauf disposition contraire d'un autre droit applicable. Toute fonctionnalité SaaS n'est donc pas à haut risque et chaque prompt ou réponse ne doit pas être conservé.

Erreur 1 : commencer par la plateforme plutôt que le périmètre

Activer tous les événements ne délimite pas un système. Un flux SaaS assisté par IA peut inclure interface, récupération, règles métier, modèle tiers, validation humaine et automatisation aval. Ne journaliser que l'appel au modèle laisse souvent de côté les faits qui expliquent le résultat.

Documentez finalité, utilisateurs, personnes concernées, entrées, sorties, intégrations, versions, environnements et décisions influencées. Déterminez ensuite le rôle de l'entreprise, sa classification, les hypothèses et les déclencheurs de réexamen. Le guide de l'AI Act pour les fournisseurs SaaS donne le contexte général.

Erreur 2 : tout enregistrer par défaut

Prompts, documents, résultats et identifiants complets peuvent contenir données personnelles, secrets clients ou identifiants d'accès. Une collecte indifférenciée augmente les risques d'accès, d'incident, de contentieux et de suppression, tout en noyant les événements utiles.

Reliez chaque champ à une question. Pour identifier la version ayant produit un résultat, utilisez des identifiants stables du système et de la version. Pour démontrer la supervision humaine, enregistrez l'exigence, l'action, le rôle, l'heure et le résultat. Une référence, un hash, une catégorie ou un résumé protégé suffit souvent à la place du contenu complet.

Erreur 3 : prendre la télémétrie pour une piste d'audit

Les journaux applicatifs indiquent disponibilité, latence et erreurs, mais ils ne relient pas nécessairement un résultat important au modèle, à la configuration, à la source récupérée, au contrôle, à l'action humaine ou à la version déployée.

Une piste utile corrèle l'ensemble du flux : versions, horodatage, identifiant de transaction, contexte, références d'entrée et de sortie, contrôles, alertes, revue humaine, action aval et statut d'incident. Il faut aussi des schémas documentés, des horloges cohérentes et des identifiants non ambigus. Une personne indépendante doit pouvoir reconstituer un événement choisi.

Erreur 4 : appliquer six mois à tous les enregistrements

Le minimum de six mois concerne les journaux automatiques des systèmes à haut risque sous le contrôle de l'opérateur concerné. Ce n'est ni une durée universelle ni une autorisation de conserver indéfiniment toutes les données personnelles journalisées.

Le calendrier doit préciser la classe de données, le début du délai, la date d'effacement, la finalité, les exceptions, les approbations, les répliques, exports et sauvegardes. Conciliez traçabilité, minimisation, limitation de conservation, sécurité, règles sectorielles ou sociales et contrats. Testez l'effacement au-delà du tableau de bord principal.

Erreur 5 : ignorer les frontières de contrôle

Fournisseur, déployeur, client et prestataire amont peuvent contrôler des parties différentes. Associez chaque événement nécessaire à la partie et au système qui le contrôlent. Contrats et documentation doivent préciser création, accès, demande de preuve, conservation et fin de service. Vérifiez la configuration déployée, pas seulement le questionnaire fournisseur.

Avant une adoption, utilisez les questions de revue des outils IA internes et alignez les réponses clients sur les contrôles IA attendus par les acheteurs.

Erreur 6 : laisser la responsabilité implicite

Produit maîtrise finalité et parcours ; l'ingénierie, l'instrumentation et les schémas ; la sécurité, accès et intégrité ; la protection des données, la minimisation ; la conformité, le référentiel d'exigences et la norme de preuve. Désignez un responsable du dispositif et précisez qui traite les exceptions, autorise l'accès, répond aux demandes, prolonge une durée, impose un gel et corrige les lacunes.

Erreur 7 : mal protéger la piste

Les journaux peuvent révéler activité utilisateur, décisions internes, contenu client et faiblesses du système. Appliquez moindre privilège, authentification forte, chiffrement, journalisation des accès, séparation des environnements et contrôle des exports. Protégez l'intégrité par des schémas maîtrisés, des horodatages fiables, des transformations traçables et des procédures de préservation. Séparez accès opérationnel et accès d'enquête privilégié.

Erreur 8 : ne jamais tester la reconstitution

Choisissez un événement important et demandez à une personne indépendante d'identifier version, contexte, contrôles, action humaine, résultat aval et suivi. Consignez les lacunes et attribuez les corrections. Recommencez après toute modification du modèle, du prompt, de la source, du seuil, de l'intégration, de la supervision ou de la finalité, ainsi qu'après un incident ou une plainte.

Cette discipline correspond aux nouvelles attentes de gouvernance IA : les contrôleurs veulent la preuve du fonctionnement des contrôles, pas seulement une politique.

Processus pratique de correction

Commencez par un flux important. Documentez périmètre, finalité, rôle, classification, sources, fournisseurs et responsables. Listez les questions probables et reliez-les aux événements minimaux. Évaluez chaque champ sous l'angle nécessité, sensibilité, accès, intégrité, conservation et suppression. Réalisez ensuite un test de reconstitution et un test d'effacement, puis conservez ensemble résultats, lacunes, responsables et échéances.

Selon le calendrier actuel de la Commission, les règles à haut risque s'appliquent aux systèmes de l'annexe III le 2 décembre 2027 et à l'IA intégrée aux produits réglementés de l'annexe I le 2 août 2028.

FAQ

Quelle est l'erreur principale ?

Collecter des événements sans définir le système et les questions de contrôle. Cela crée du volume sans traçabilité fiable.

Toute fonctionnalité IA SaaS doit-elle disposer de ces journaux ?

Non. Les articles 12, 19 et 26 visés ici concernent les systèmes à haut risque et dépendent du rôle et du contrôle. D'autres lois, contrats ou contrôles peuvent néanmoins justifier des traces.

Faut-il conserver chaque prompt ?

Non. Choisissez des champs proportionnés. Références, hashes, catégories, métriques ou échantillons protégés peuvent suffire.

Que faut-il documenter d'abord ?

Périmètre, finalité, rôle, classification, sources contrôlées, questions, schéma minimal, responsable, accès et conservation.

Comment vérifier l'utilité des traces ?

Faites reconstituer un événement par un tiers et testez l'effacement des données expirées dans chaque copie.

Sources

• Règlement (UE) 2024/1689, notamment ses articles 6, 12, 19 et 26.
• Règlement (UE) 2026/1744 concernant les dates d'application modifiées.
• Commission européenne, « AI Act », calendrier actuel de mise en œuvre.