Sécurité et IA responsable pour le développement Windows

Les outils d’IA peuvent considérablement accélérer le développement d’applications Windows, mais ce gain de vitesse n’exonère pas de toute responsabilité. Le code généré par votre agent IA est le code que vous envoyez, et vous êtes responsable de tout ce qui se trouve dans votre application, quelle que soit la façon dont elle a été écrite.

Cette page aborde deux sujets connexes : les pratiques responsables pour l’utilisation d’outils IA pour créer des applications et des problèmes de sécurité spécifiques au code généré par l’IA.

Vous êtes propriétaire du code

Lorsqu’un agent IA génère une fonction, une disposition ou un appel d’API, il devient votre code le moment où vous le validez. Les mêmes normes s’appliquent si le code a été écrit manuellement ou généré :

  • Lire et comprendre chaque modification avant de l’accepter
  • Testez le code généré par l’IA au moins aussi minutieusement que le code écrit manuellement : les modèles peuvent générer du code qui semble plausible mais qui est subtilement erroné
  • N’utilisez pas « l’IA l’a écrit » comme explication d’un bogue ou d’un problème de sécurité en production

Les outils IA ne suppriment pas la nécessité d’une révision du code. Ils changent ce que vous évaluez, pas le fait que vous l’évaluiez.

Qu’est-ce qu’il ne faut pas envoyer aux outils IA

Soyez délibéré sur ce que vous incluez dans les invites et les fenêtres contextuelles :

  • Secrets et informations d’identification : ne collez jamais les clés API, les mots de passe ou les chaînes de connexion dans une invite. Même dans une session de conversation privée, des identifiants saisis dans les prompts constituent un risque de sécurité et peuvent apparaître dans les logs. Consultez la gestion des informations d’identification et des secrets ci-dessous.
  • Données client et informations d’identification personnelles : n’utilisez pas de noms de clients réels, d’e-mails ou de données d’utilisation comme exemples d’entrées, même pour expliquer un bogue. Utilisez des données synthétiques.
  • Logique métier propriétaire : comprendre la stratégie de votre organisation sur le code source qui peut être envoyé aux services IA externes avant de partager le code des systèmes internes.

Validation d’entrée

L’IA a tendance à générer un traitement des entrées trop permissif. Validez toujours les longueurs, les types et les plages avant d’agir sur l’entrée utilisateur.

  • Ne transmettez jamais de valeurs brutes TextBox.Text aux commandes shell, aux chemins de fichier ou aux requêtes de base de données.
  • Validez les longueurs de chaîne avant d’écrire dans le stockage ou d’envoyer sur le réseau.
  • Utilisez une approche de liste d’autorisations pour les chemins de fichiers — vérifiez que les chemins résolus restent dans les répertoires attendus.

Ajoutez ceci à votre invite : « Ajouter des limites de validation et de longueur d’entrée à tous les champs accessibles par l’utilisateur ».

Gestion des informations d’identification et des secrets

Ne codez jamais en dur les clés d’API, les mots de passe ou les chaînes de connexion. L’IA génère souvent des chaînes d’espace réservé comme "your-api-key-here" : traitez-les comme des bogues.

  • Stockez les informations d’identification dans Windows.Security.Credentials.PasswordVault :

    var vault = new PasswordVault();
vault.Add(new PasswordCredential("MyApp", username, password));

  • Récupérez-les au moment de l’exécution :

    var credential = vault.Retrieve("MyApp", username);
credential.RetrievePassword();

  • Utilisez des variables d’environnement ou des Azure Key Vault pour les informations d’identification de service dans les scénarios CI ou côté serveur.

Intégrité des paquets et des dépendances

Passez en revue chaque package NuGet qu’un agent IA suggère avant de l’ajouter à votre projet.

  • Vérifiez l’éditeur sur nuget.org : recherchez le bouclier bleu (Microsoft) ou un éditeur connu.
  • Recherchez les vulnérabilités connues : 
    dotnet list package --vulnerable
  • Préférez les packages avec des mises à jour récentes et une maintenance active.

Fonctionnalités et autorisations d’application

Les fichiers générés par l’IA incluent souvent des fonctionnalités étendues Package.appxmanifest . Passez en revue la <Capabilities> section et supprimez tout ce dont votre application n’a pas besoin.

Fonctionnalités courantes sur-étendues à surveiller :

  • broadFileSystemAccess — nécessaire uniquement si votre application lit réellement des chemins de système de fichiers arbitraires
  • documentsLibrary — nécessite l’approbation spéciale du Store ; éviter, sauf si nécessaire
  • userAccountInformation — uniquement si vous avez besoin du nom ou de la photo de l’utilisateur

Liste de contrôle de révision du code

Avant d’envoyer du code généré par l’IA, vérifiez :

  • Aucun secret ou informations d’identification codés en dur
  • Entrée utilisateur validée avant l’utilisation
  • Chemins d’accès aux fichiers comparés aux répertoires autorisés
  • Fonctionnalités minimales nécessaires déclarées dans le manifeste
  • Packages NuGet analysés pour les vulnérabilités (dotnet list package --vulnerable)
  • Données sensibles stockées dans PasswordVault, et non ApplicationData.LocalSettings
  • Tous les appels réseau utilisent HTTPS
  • Les messages d’exception n’exposent pas de chemins d’accès internes ni de traces de pile aux utilisateurs

Les modèles IA ont des connaissances obsolètes

Les outils IA que vous utilisez aujourd’hui ont été formés sur les données avec une date de coupure. Pour Windows développement, cela signifie que les modèles ont vu beaucoup plus d’exemples UWP que les exemples WinUI 3, ce qui est exactement la raison pour laquelle cette section de documentation existe.

Ne considérez pas les résultats de l’IA comme une source fiable pour :

  • Noms d’API et espaces de noms actuels (à vérifier dans la référence de l’API WinUI 3)
  • Versions actuelles du Kit de développement logiciel (SDK) et noms de package
  • Règles de la boutique et exigences de soumission (celles-ci changent fréquemment)
  • Conseils de sécurité (les modèles peuvent reproduire des modèles de chiffrement ou d’authentification obsolètes)

Le serveur Microsoft Learn MCP et le plugin d’agent WinUI atténuent le problème des connaissances obsolètes en ancrant votre agent dans une documentation à jour — mais vérifiez toujours tout ce qui est critique pour la sécurité auprès des sources primaires.

Accessibilité

L’interface utilisateur générée par l’IA omet fréquemment la prise en charge de l’accessibilité. Un modèle entraîné sur des millions d’échantillons XAML reproduira la qualité moyenne de ces échantillons — une qualité moyenne qui a historiquement fait l’impasse sur AutomationProperties, la navigation au clavier et un contraste suffisant.

Lors de l’acceptation du code XAML ou des contrôles générés par l’IA :

  • Vérifier que les éléments interactifs ont AutomationProperties.AutomationId et AutomationProperties.Name défini
  • Vérifier que l’ordre de navigation au clavier est logique — les points d’arrêt de tabulation doivent suivre l’ordre de lecture
  • Tester avec le Narrateur ou un autre lecteur d’écran avant l’expédition
  • Utilisez l’outil Accessibility Insights pour Windows pour détecter automatiquement les lacunes

Demandez explicitement à votre agent : « Ajouter des propriétés d’accessibilité à tous les éléments interactifs de ce code XAML ». Ne supposez pas qu’elle a été faite.

Si votre application utilise des fonctionnalités IA

Si vous créez des fonctionnalités d’IA dans votre application , pas seulement en utilisant l’IA pour écrire l’application, des responsabilités supplémentaires s’appliquent.

Soyez transparent avec les utilisateurs. Indiquer aux utilisateurs :

  • Quelles données votre application envoie aux services IA
  • Si l’IA prend des décisions qui les affectent
  • Comment désactiver le cas échéant

Faire intervenir une personne pour les actions à fort enjeu. Ne laissez pas l’IA supprimer de manière autonome les données, effectuer des achats, envoyer des messages pour le compte de l’utilisateur ou effectuer d’autres actions irréversibles sans confirmation explicite.

Testez les biais et les sorties inattendues. Les modèles IA peuvent produire des sorties qui sont biaisées, offensives ou factuelment incorrectes. Testez les fonctionnalités d’INTELLIGENCE artificielle de votre application avec diverses entrées et cas de périphérie avant l’expédition.

Utilisez des outils de sécurité du contenu. Si votre application génère ou traite du texte, des images ou d’autres contenus à l’aide de l’IA, utilisez Azure AI Sécurité du Contenu ou un filtrage équivalent pour intercepter les sorties dangereuses avant d’atteindre les utilisateurs.

Licences et attributions

Les outils IA peuvent générer du code semblable au code open source existant. Avant d’utiliser du code généré par l’IA dans une application commerciale :

Principes de l’IA responsable de Microsoft

Microsoft conçoit des produits et fonctionnalités IA guidés par six principes : équité, fiabilité et sécurité, confidentialité et sécurité, inclusion, transparence et responsabilité.

En savoir plus sur microsoft.com/ai/responsible-ai.

Contenu connexe

  • Last updated on