3 Les grands modèles de langage s’entraînent sur des jeux de données massifs : des milliards, voire des milliers de milliards de tokens issus de textes du web, de collections propriétaires et de corpus spécialisés. Les données d’entraînement déterminent la qualité et le comportement du modèle. Pourtant, leurs enjeux de sécurité et de résilience sont rarement abordés. Une violation peut exposer les méthodologies, permettre le vol ou révéler des informations sensibles. L’indisponibilité des données peut interrompre des projets qui valent des millions. Cet article traite de la sécurité des données d’entraînement des LLM (protection contre l’exfiltration, la corruption et les pannes) pour des infrastructures massives et distribuées. L’échelle et la sensibilité des corpus d’entraînement des LLM Comprendre les données d’entraînement des LLM, c’est d’abord comprendre leur échelle. Les modèles de pointe s’entraînent sur des centaines de gigaoctets à des pétaoctets de texte issus de jeux de données publics, d’explorations du web, de livres, d’articles et de contenus propriétaires. Contrairement aux jeux de données traditionnels composés de quelques gros fichiers, les corpus LLM contiennent des milliards de petits documents ou fragments : pages web, paragraphes, extraits. Le stockage doit gérer un nombre de fichiers colossal, des accès aléatoires pendant l’entraînement et une ingestion continue de données. Leur sensibilité est sous-estimée. Les corpus contiennent des informations publiques, mais aussi des données propriétaires, des identifiants publiés par erreur, des adresses e-mail et des informations que leurs auteurs n’imaginaient pas voir servir à l’entraînement de modèles de ML. Une violation a plusieurs conséquences. Les concurrents obtiennent des indices sur l’architecture et la méthodologie du modèle. Des informations sensibles sont exposées aux régulateurs ou au public. Des adversaires découvrent les données sur lesquelles le modèle a été entraîné, ce qui leur permet de mener des attaques exploitant leurs propriétés spécifiques. Prévenir l’exfiltration et cloisonner les données La première préoccupation de sécurité est d’empêcher l’exfiltration, c’est-à-dire la copie ou la transmission non autorisée des données hors de votre contrôle. Le problème a plusieurs dimensions. Le filtrage des flux sortants empêche les fuites vers internet, mais pas l’exfiltration par une personne interne ni les attaques sophistiquées (exfiltration DNS, stéganographie). Les contrôles applicatifs (journalisation des transferts, restriction des accès) sont nécessaires, mais insuffisants face aux menaces internes. De nombreuses organisations recourent à l’isolation réseau. L’infrastructure d’entraînement est déployée dans des segments restreints, où les connexions sortantes vers internet sont bloquées, sauf vers des sources approuvées. L’accès aux données d’entraînement est réservé à l’infrastructure d’entraînement, à l’exclusion des postes de travail. Une solution de stockage évolutif pour les pipelines d’IA (en anglais) applique ces frontières de manière systématique. Le cloisonnement est toutefois complexe. L’infrastructure d’entraînement s’étend sur plusieurs data centers ou régions cloud, et les données doivent rester isolées malgré cette répartition. Utilisez des réseaux overlay distincts, des clés de chiffrement différentes et des contrôles explicites sur les ressources de calcul autorisées à accéder à chaque jeu de données. Pour les données les plus sensibles, utilisez une infrastructure isolée (air gap) : des réseaux physiquement séparés, avec des procédures formelles d’entrée et des sorties contrôlées. Vous obtenez une très forte garantie contre l’exfiltration, au prix d’une complexité opérationnelle accrue. Intégrité et détection de la corruption L’entraînement des LLM est sensible à la qualité des données. Une corruption ou un empoisonnement dégrade la qualité, introduit des biais ou provoque des comportements inattendus. Des adversaires peuvent corrompre les données au repos. Des inversions de bits dans quelques documents peuvent passer inaperçues pendant l’entraînement (qui tolère bien les exemples isolés), mais une corruption systématique a un impact significatif sur la qualité. Votre stockage doit garantir l’intégrité au moyen de sommes de contrôle. Calculez une somme de contrôle pour chaque fragment à l’écriture et validez-la à la lecture pour l’entraînement. En cas de corruption, alertez les opérateurs et empêchez l’utilisation des données. Point important : la protection de l’intégrité doit être indépendante de la validation applicative. Si une application d’entraînement compromise compromet aussi la validation, la défense tombe. Une protection au niveau du stockage (sommes de contrôle calculées par le stockage, et non par l’application) assure une défense en profondeur. Au-delà de la corruption accidentelle, envisagez les attaques par empoisonnement délibéré, où des adversaires insèrent des données malveillantes via des sources compromises ou des pipelines exploités. L’empoisonnement est plus difficile à détecter que la corruption, mais cloisonner les jeux de données par source et surveiller le comportement du modèle limite les dégâts. Un stockage IA haute capacité doté d’un versionnage intégré permet un retour arrière rapide en cas d’empoisonnement. Stockage distribué et haute disponibilité L’entraînement de LLM sur une infrastructure distribuée exige une disponibilité continue des données. Une panne de stockage en plein entraînement interrompt des expériences qui consomment beaucoup de temps GPU et de budget de calcul. Il faut donc répliquer les données d’entraînement sur plusieurs systèmes ou régions : si l’un tombe, l’entraînement se poursuit avec les répliques. Mais la réplication ajoute de la complexité : synchronisation, gestion des divergences, tolérance au surcoût. La plupart des organisations utilisent une réplication asynchrone, avec un décalage (toutes les heures ou toutes les quatre heures). Le surcoût est moindre, mais les ajouts récents au corpus peuvent être perdus si le stockage principal tombe. Pour des jeux de données stables, c’est acceptable ; pour des corpus qui évoluent rapidement, une réplication plus fréquente, voire synchrone, est nécessaire. La réplication favorise aussi la disponibilité géographique. Les tâches d’entraînement sont réparties entre data centers, et les données sont répliquées dans toutes les régions pour un accès local sans latence. Sauvegarde et restauration de l’infrastructure d’entraînement Intégrez les données d’entraînement à votre stratégie de sauvegarde et de reprise après sinistre, mais à l’échelle du pétaoctet, les approches traditionnelles sont impraticables : des sauvegardes quotidiennes de plusieurs pétaoctets sont irréalisables. Organisez plutôt la sauvegarde autour d’objectifs de restauration : Archive immuable : des snapshots complets peu fréquents (hebdomadaires ou mensuels), conservés sur un stockage immuable et distribué, pour se protéger d’une perte catastrophique. Sauvegarde incrémentielle : des sauvegardes incrémentielles des données modifiées depuis le dernier snapshot permettent de restaurer entre deux snapshots sans tout retraiter. Restauration à un instant donné : documentez quelles données ont été utilisées pour quels entraînements et quels points de contrôle. Vous pourrez ainsi restaurer les données exactes correspondant à une version précise du modèle. Les tests de restauration sont indispensables. Restaurez régulièrement des jeux de données complets pour vérifier que les procédures fonctionnent et que les données correspondent. Découvrir une corruption pendant une restauration réelle est bien pire que de la découvrir lors d’un test. Contrôles d’accès et moindre privilège L’accès aux données d’entraînement doit suivre le principe du moindre privilège. Tous les data scientists n’ont pas besoin d’accéder à toutes les données, et les accès doivent être auditables. Mettez en place un contrôle d’accès basé sur les rôles, avec des permissions différentes : les data engineers ingèrent et maintiennent les données les data scientists mènent les expériences les ingénieurs d’infrastructure gèrent le stockage les équipes sécurité et conformité auditent les accès Chaque rôle dispose exactement des accès nécessaires. Les data scientists ont un accès en lecture seule à des jeux de données précis, et non aux sources brutes. Les ingénieurs ont un accès en écriture aux zones de préparation, et non aux données de production. Ce cloisonnement limite les dégâts en cas d’identifiants compromis : si le compte d’un data scientist est compromis, les attaquants n’accèdent qu’à ses jeux de données, et non à toutes les données d’entraînement. Supervision et détection des anomalies Même avec des contrôles d’accès solides, la surveillance des activités suspectes est indispensable. Votre stockage doit journaliser : tous les accès (qui, quoi, quand, combien de temps) les suppressions et modifications (pistes d’audit) les transferts volumineux ou tentatives d’exfiltration les schémas inhabituels (heures atypiques, jeux de données inhabituels) Intégrez ces journaux à votre supervision de sécurité. Des alertes automatiques sur les anomalies (volume de transfert inhabituel, emplacements inattendus, suppressions en masse) permettent de repérer une violation avant qu’elle ne cause des dommages importants. Bâtir une infrastructure sécurisée pour les données d’entraînement des LLM Sécuriser le stockage des données d’entraînement des LLM impose de dépasser les approches traditionnelles. Ces données sont précieuses et sensibles à une échelle sans précédent. Leur protection exige le cloisonnement (isolation des réseaux), la surveillance de l’intégrité (détection de la corruption ou de l’empoisonnement), une sauvegarde fiable (pour survivre aux pannes) et une supervision complète (alertes sur les accès suspects). Les organisations qui abordent la sécurité de manière réfléchie, en traitant les données comme une infrastructure critique et en investissant dans l’isolation, la supervision et la résilience, peuvent investir dans le développement de LLM sans risque de perte. Une sauvegarde résistante aux ransomwares (en anglais) garantit la restauration dans les pires scénarios. La sécurité et la résilience doivent être fondamentales dès le départ, et non ajoutées plus tard lorsque des incidents l’imposent. Pour aller plus loin Stratégie de données en cloud hybride pour les charges de travail d’IA Pipelines de données d’IA : architecture, étapes et bonnes pratiques L’intégrité des données dans les systèmes de stockage haute densité (en anglais) Le stockage de sauvegarde isolé (air gap) Durabilité ou disponibilité des données (en anglais) Le stockage multicloud : architecture, avantages et stratégie (en anglais)
