Inférence ML chiffrée de bout en bout avec Amazon SageMaker AI et le chiffrement homomorphe

Traçabilité de bout en bout avec DVC et Amazon SageMaker AI MLflow

Les équipes de machine learning en production font face à un problème récurrent : retracer précisément l'origine d'un modèle déployé. Quelle version du jeu de données l'a entraîné ? Peut-on reproduire à l'identique un modèle mis en production il y a six mois ? Amazon Web Services propose une réponse concrète en combinant trois outils : DVC (Data Version Control), Amazon SageMaker AI et SageMaker AI MLflow Apps. L'architecture s'articule en quatre étapes : un job SageMaker Processing prétraite les données brutes et les versionne via DVC en les poussant vers Amazon S3 ; un job SageMaker Training clone le dépôt DVC à un tag Git précis, récupère le dataset exact via dvc pull, entraîne le modèle et enregistre tout dans MLflow. Chaque run MLflow stocke un identifiant datagitcommit_id, soit le hash DVC pointant vers le dataset exact dans S3. Le modèle entraîné est ensuite enregistré dans le MLflow Model Registry et peut être déployé sur un endpoint SageMaker. La chaîne de traçabilité complète devient alors : modèle en production → run MLflow → commit DVC → dataset dans Amazon S3. Cet enchaînement répond à un besoin critique dans les secteurs régulés : santé, services financiers, véhicules autonomes. Dans ces domaines, les exigences d'audit imposent de relier chaque modèle déployé à ses données d'entraînement précises, et de pouvoir exclure à la demande des enregistrements individuels des futurs cycles d'entraînement. Sans ce niveau de traçabilité, une question apparemment simple, "quelles données ont servi à entraîner le modèle actuellement en production ?", peut mobiliser plusieurs jours d'enquête dans des logs dispersés, des notebooks et des buckets S3. La solution proposée réduit ce risque opérationnel en rendant la traçabilité structurelle plutôt qu'optionnelle. DVC est un outil open source gratuit qui étend Git pour gérer des datasets volumineux et des artefacts ML que Git seul ne peut pas versionner. MLflow, de son côté, assure le suivi des expériences, le registre des modèles et la lignée. Les deux outils couvrent chacun la moitié du problème de traçabilité, et leur combinaison ferme la boucle. L'implémentation requiert un compte AWS avec des permissions sur SageMaker, S3, CodeCommit et IAM, Python 3.11 ou 3.12, et le SDK SageMaker v3.4.0 minimum. Les notebooks utilisent AWS CodeCommit comme backend Git pour les métadonnées DVC, mais l'architecture est compatible avec GitHub, GitLab ou Bitbucket moyennant un simple remplacement de l'URL remote. AWS publie des notebooks d'accompagnement permettant de déployer les deux patterns décrits, traçabilité au niveau du dataset et traçabilité au niveau de l'enregistrement individuel, directement dans un compte AWS existant.

Enseigner aux modèles à oublier : le désapprentissage sélectif avec Amazon Nova

Les équipes de développement Amazon Nova viennent de détailler une nouvelle méthode baptisée rDPO (Reverse Direct Preference Optimization), conçue pour résoudre un problème récurrent chez les entreprises qui déploient des modèles de fondation : les garde-fous de modération de contenu bloquent souvent des usages professionnels légitimes. Une société de médias qui résume des scénarios contenant un langage cru, une entreprise de cybersécurité qui simule des attaques réelles, ou un cabinet juridique qui traite des preuves sensibles se heurtent régulièrement à des refus du modèle, même lorsque leur intention est parfaitement défensive. L'exemple typique cité par Amazon est celui d'une équipe de sécurité demandant à un modèle de générer un email de phishing factice pour former ses employés, et se voyant opposer un refus malgré le caractère pédagogique de la demande. Amazon a donc lancé les Customizable Content Moderation Settings (CCMS) pour Nova, un système permettant à des clients approuvés d'ajuster sélectivement les réglages de sécurité sur quatre piliers : la sécurité physique (armes, activités dangereuses, substances contrôlées), le contenu sensible (grossièretés, nudité, harcèlement), l'équité (biais et considérations culturelles) et la sécurité informatique (malwares et contenus malveillants). Certains contrôles fondamentaux, comme la protection des enfants et de la vie privée, restent quant à eux non configurables. Cette avancée compte parce qu'elle change la donne pour les entreprises qui utilisent des modèles d'IA générative dans des contextes professionnels spécialisés où le blocage systématique de certains contenus devient un obstacle plutôt qu'une protection. Jusqu'ici, ces refus intégrés au niveau des paramètres du modèle pendant l'alignement post-entraînement ne pouvaient pas être contournés par du simple prompt engineering, obligeant les entreprises à composer avec des limitations rigides ou à entraîner leurs propres modèles depuis zéro, une option coûteuse et complexe. Avec rDPO, Amazon propose une alternative plus fine : plutôt que de désactiver un garde-fou dans son ensemble, la technique permet de retirer chirurgicalement un comportement d'évitement appris sur une politique précise, tout en conservant l'alignement du modèle sur toutes les autres politiques et en préservant ses capacités générales comme le raisonnement, le code ou les mathématiques. Sur le plan technique, la solution s'appuie sur des adaptateurs LoRA (Low-Rank Adaptation) entraînés spécifiquement pour désapprendre certaines politiques de responsabilité (RAI) du modèle central, chaque client recevant un adaptateur identifié par un ARN (Amazon Resource Name) unique. Le défi scientifique consistait à désapprendre efficacement un comportement de refus sans dégrader la qualité générale du modèle, un piège classique du fine-tuning direct. Une approche existante, la Negative Preference Optimization (NPO), dérivée de la Direct Preference Optimization (DPO), permettait déjà de faire oublier un comportement en retirant les échantillons positifs de l'objectif d'optimisation, mais sans guider le modèle vers une réponse alternative de bonne qualité, ce qui pouvait dégrader les résultats. rDPO résout ce manque en inversant la paire de préférences dans l'objectif DPO, poussant le modèle non seulement à cesser de refuser, mais aussi à produire une réponse de substitution pertinente. Cette approche s'inscrit dans un mouvement plus large de recherche sur le désapprentissage sélectif des modèles de langage, un domaine appelé à prendre de l'importance à mesure que les entreprises réclament un contrôle plus granulaire sur l'alignement de leurs IA en production.

💬 Enfin quelqu'un qui traite le sujet correctement au lieu de mettre tout le monde dans le même panier. Le vrai problème depuis toujours c'est que les garde-fous sont binaires alors que les usages pros ne le sont pas, et une boîte de cybersécurité qui veut simuler un phishing n'a rien à voir avec un usage malveillant. rDPO ne supprime pas la sécurité, il la rend sélective par client via des adaptateurs LoRA identifiés, ce qui revient à dire que la modération devient un paramètre de contrat plutôt qu'une propriété figée du modèle. Reste à voir combien de temps avant qu'un adaptateur mal configuré fasse sauter la mauvaise politique chez le mauvais client.

Le silence comportemental dans la négociation à base d'agents : formaliser et limiter les attaques par inférence via des politiques aléatoires

Les chercheurs à l'origine de cet article, accepté au workshop AI4TCI (AI for Secure and Trustworthy Critical Infrastructure Systems) organisé dans le cadre de la conférence internationale ARES 2026 (Availability, Reliability and Security), s'attaquent à un problème émergent dans le déploiement d'agents de négociation autonomes. Ces agents, de plus en plus utilisés dans des secteurs sensibles comme l'assurance et les achats professionnels (procurement), sont censés protéger la confidentialité des données grâce à des techniques cryptographiques qui chiffrent les valeurs explicitement communiquées, comme les prix ou les seuils de tolérance. Mais l'étude met en lumière une faille bien plus subtile: la fuite de confidentialité comportementale. Un adversaire peut, sans jamais accéder aux données chiffrées, déduire les contraintes privées d'un agent simplement en observant la dynamique de la négociation, notamment les trajectoires de concessions et le timing des réponses. Cette découverte a des implications concrètes pour toute organisation déployant des agents de négociation automatisés. Même sans violer directement le chiffrement, un concurrent ou un adversaire pourrait reconstituer les marges de manœuvre réelles d'une entreprise, sa stratégie de prix minimum ou ses priorités cachées, simplement en analysant le comportement observable de l'agent au fil des échanges. Cela fragilise la confiance placée dans ces systèmes pour des transactions à enjeux élevés. Ce travail s'inscrit dans une tendance plus large d'adoption de l'IA agentique pour automatiser des processus commerciaux complexes, où la sécurité cryptographique classique montre ses limites face à des attaques par inférence comportementale. Les auteurs proposent de formaliser cette menace et d'y répondre via des politiques randomisées, une piste de mitigation qui introduit de l'aléatoire dans le comportement de négociation pour brouiller les signaux exploitables par un observateur malveillant.

Vos développeurs font déjà tourner l'IA en local : pourquoi l'inférence sur appareil est l'angle mort du RSSI

Depuis dix-huit mois, les responsables de la sécurité informatique (CISO) géraient l'essor de l'IA générative avec une stratégie claire : surveiller le réseau. Bloquer les accès aux API d'OpenAI, Anthropic ou Google, router les requêtes via des passerelles contrôlées, logger chaque appel sortant. Ce modèle supposait que l'IA vivait dans le cloud et que toute interaction avec des données sensibles générait forcément du trafic réseau observable. Ce postulat est désormais obsolète. Une nouvelle génération de matériel grand public a rendu l'inférence locale non seulement possible, mais banale : un MacBook Pro équipé de 64 Go de mémoire unifiée peut faire tourner des modèles quantifiés de 70 milliards de paramètres à des vitesses utilisables. Les outils de distribution open-source permettent en une seule commande de télécharger un modèle de plusieurs gigaoctets, de couper le Wi-Fi, et de traiter des données sensibles sans qu'un seul paquet ne quitte l'appareil. Aucun log proxy, aucune trace cloud, aucune alerte DLP. Le danger ne réside plus uniquement dans la fuite de données vers l'extérieur, mais dans trois angles morts que la plupart des entreprises n'ont pas encore opérationnalisés. Premier risque : l'intégrité du code. Un développeur senior peut coller du code d'authentification ou des scripts d'infrastructure dans un modèle local non validé pour le "nettoyer", obtenir une sortie qui compile et passe les tests unitaires, puis committer le résultat sans que personne ne sache qu'une IA a influencé ce chemin de code. Les vulnérabilités introduites (validation d'entrées défaillante, paramètres par défaut dangereux) seront investigées sans que l'on remonte jamais à leur vraie cause. Deuxième risque : la conformité des licences. De nombreux modèles performants interdisent l'usage commercial, exigent des attributions, ou imposent des restrictions incompatibles avec le développement de produits propriétaires. Quand les équipes les font tourner localement, ces modèles contournent entièrement le processus habituel d'achat et de validation juridique, exposant potentiellement l'entreprise à des litiges. Ce phénomène, que certains appellent déjà le "Shadow AI 2.0" ou l'ère du BYOM (Bring Your Own Model), s'est imposé grâce à la convergence de trois facteurs techniques : la montée en puissance des accélérateurs grand public, la démocratisation de la quantification qui réduit drastiquement la taille des modèles, et la simplicité extrême des outils de distribution comme Ollama ou LM Studio. Le débat en entreprise reste encore cadré autour de l'exfiltration vers le cloud, alors que le risque le plus immédiat se joue désormais à l'intérieur même de l'appareil. Pour les CISO, l'enjeu n'est plus seulement de contrôler ce qui sort du réseau, mais de repenser entièrement leur modèle de gouvernance de l'IA, en intégrant l'inventaire des modèles locaux, l'audit des usages endpoint, et des politiques claires sur les modèles autorisés avant que ces pratiques ne se normalisent sans cadre.

💬 Les RSSI ont passé dix-huit mois à construire des digues autour du cloud, pendant que leurs devs téléchargeaient des 70B quantifiés en une commande sur leur MacBook. La stratégie réseau tenait la route tant que l'IA vivait chez OpenAI, mais Ollama a mis fin à ça sans que personne lève la main. Aucune boîte n'a d'inventaire de ses modèles internes, et c'est là que le feu va prendre.