Confidentialité et sécurité des données dans un projet d’IA : guide pratique

Recherche documentaire, automatisation de tâches, création de produits numériques : les usages de l’IA se multiplient. Pour les organisations, le choix d’un modèle n’est pourtant qu’une partie du projet. Il faut aussi savoir quelles données circulent, à quelles ressources l’application accède et où ses réponses sont envoyées.

Voici une méthode de départ pour les décideurs et les équipes de réalisation. Elle vise surtout l’IA générative, même si plusieurs questions de gouvernance concernent aussi d’autres systèmes d’IA.

Cartographier les données avant de choisir une solution

Définissez d’abord une tâche métier précise, puis les seules données nécessaires à son exécution. Un assistant de support peut par exemple avoir besoin d’une documentation produit validée, sans accès à toute la base clients. Suivez le parcours des informations : systèmes sources, requêtes, fichiers transmis, index de recherche, prestataires de modèles, réponses, journaux et sauvegardes.

À chaque étape, identifiez le responsable des données, leur sensibilité, les droits d’accès, le lieu de traitement, la durée de conservation et la finalité. Distinguez l’utilisation des données pour répondre à une demande de leur utilisation pour entraîner ou améliorer un modèle. L’autorité britannique de protection des données, l’ICO, explique dans sa réponse sur la limitation des finalités dans le cycle de vie de l’IA générative pourquoi entraînement et déploiement doivent être examinés séparément.

Supprimez les champs superflus et privilégiez, lorsque c’est possible, des données de test représentatives. Masquer des identifiants réduit l’exposition sans rendre automatiquement les données anonymes. Faites examiner les exigences applicables par des spécialistes qualifiés : elles varient selon les territoires, les données et l’usage.

Comparer les modes de déploiement

Une API de modèle hébergée peut alléger la gestion de l’infrastructure, mais les informations transmises franchissent la frontière d’un prestataire. Un modèle auto-hébergé ou installé dans un environnement privé peut offrir davantage de contrôle direct, tout en confiant davantage de responsabilités à l’organisation pour l’infrastructure, les mises à jour, la surveillance et les accès. Aucun de ces choix n’est sûr par nature.

Évaluez les solutions selon le processus métier, le budget, les performances, la sensibilité des données et les moyens d’exploitation disponibles. Demandez aux fournisseurs et aux partenaires de réalisation :

• Les requêtes, fichiers, réponses ou journaux sont-ils conservés ? Pendant combien de temps et avec quels réglages possibles ?
• Les données clients servent-elles à entraîner les modèles ou à améliorer le service ? Quelles conditions et quels paramètres s’appliquent au produit choisi ?
• Où les données sont-elles traitées et stockées, y compris par les sous-traitants ? Quels dispositifs de transfert sont pertinents ?
• Quelles garanties ou preuves sont disponibles concernant les accès, le chiffrement, les incidents, la suppression et les audits ?
• Que deviennent les index, sauvegardes et autres copies à la fin du service ou lorsqu’une suppression est nécessaire ?

Demandez des réponses écrites et vérifiez la configuration effective. Supprimer une donnée à la source ne l’efface pas nécessairement de toutes les copies en aval : leur traitement doit être convenu à l’avance.

Protéger toute l’application, pas seulement le modèle

L’IA générative ajoute des risques aux enjeux habituels de sécurité applicative. L’OWASP décrit l’injection de prompt : une instruction présente dans une entrée utilisateur ou un contenu externe peut détourner le comportement du modèle. Un document ou un courriel consulté peut donc être utile tout en restant une entrée non fiable.

Imposez les autorisations en dehors du modèle : limitez les données consultables et les actions possibles pour chaque utilisateur et service, vérifiez les sorties avant leur transmission à d’autres systèmes et prévoyez une validation humaine pour les actions sensibles. Une consigne dans un prompt ne remplace pas un contrôle d’accès. Si l’application interroge des documents internes par génération augmentée par récupération, préservez les droits des sources dans la couche de recherche et testez l’accès entre utilisateurs. L’OWASP présente également les risques des systèmes vectoriels et des embeddings, notamment la récupération non autorisée.

Protégez les identifiants techniques, chiffrez les données en transit et au repos lorsque cela convient, et limitez l’accès aux journaux : ils peuvent contenir des requêtes ou des réponses sensibles. Le risque de divulgation d’informations sensibles justifie aussi de tester le filtrage des sorties et les contrôles d’accès, sans les considérer comme infaillibles.

Prévoir des critères de lancement et un suivi

Avant la mise en production, désignez un responsable métier et définissez les risques qui doivent bloquer le lancement. Testez des scénarios concrets : demande d’un document appartenant à une autre équipe, instruction malveillante dans un fichier récupéré, donnée sensible dans une réponse ou tentative d’action au-delà des droits accordés. Consignez les résultats, corrigez les échecs et recommencez les tests.

Après le lancement, surveillez les accès et les activités inhabituelles sans collecter plus de données personnelles que nécessaire. Planifiez la révision des permissions, des durées de conservation, du comportement du modèle, des changements du fournisseur et de la réponse aux incidents. Précisez qui peut désactiver l’intégration, enquêter sur une exposition et prévenir les parties concernées lorsque cela est requis. Le profil du NIST pour l’IA générative fournit un cadre volontaire de gestion des risques sur l’ensemble du cycle de vie.

Clarifier les responsabilités avec les partenaires

Un acheteur peut demander au partenaire de réalisation une architecture documentée, une cartographie des flux, un plan de contrôle et de test, ainsi qu’une documentation de transfert précisant les responsabilités après lancement. Convenez de qui valide les sources, configure le fournisseur, maintient les intégrations, traite les incidents et finance l’exploitation. Pour des partenaires stratégiques ou des investisseurs, ces éléments permettent aussi d’évaluer la solidité opérationnelle d’un projet au-delà de sa démonstration.

Les activités d’Altweeb en développement logiciel, conseil technologique et automatisation par l’IA s’inscrivent dans ces choix de réalisation. Le périmètre et les contrôles appropriés restent à définir pour chaque projet.

Conclusion

Un projet d’IA mieux sécurisé repose sur une finalité claire, des accès limités et des responsabilités explicites. Ces choix doivent être testés avant la mise en production, puis réexaminés lorsque le système ou son environnement évolue.

Pour approfondir ce sujet, découvrez aussi Faites de votre prochain projet numérique un vrai levier..