Votre client demande si ses données sont cloisonnées, si l’IA conserve ses documents et qui a exporté un fichier. Vous avez les schémas, la documentation fournisseur et les anciennes réponses. Lesquelles décrivent le produit exploité aujourd’hui ?
Le directeur technique qui examine un produit B2B doté d’une fonctionnalité d’IA doit préparer des engagements étayés. Certaines questions appellent de meilleures preuves ; d’autres révèlent un contrôle absent à corriger. Une réponse bien rédigée ne le met pas en place.
Lors d’un appel avec un directeur technique, nous l’avons formulé ainsi : « Un questionnaire convaincant décrit le produit que vous comptez avoir. Un contrôle qui fonctionne est un contrôle que vous pouvez montrer sur le produit exploité aujourd’hui. »
La réponse courte : reliez chaque affirmation importante au code, à la configuration déployée et à une vérification ciblée à l’exécution. Précisez le produit, les chemins et les conditions que ces vérifications couvrent. S’il manque des éléments, limitez la réponse ou signalez l’écart. L’assurance indépendante et l’acceptation par le client restent distinctes.
1. Définir le périmètre du produit avant de répondre
Prenons un portail documentaire fictif : chaque client possède un espace où déposer des fichiers, demander des résumés par IA et télécharger des exports. Supabase gère la base, l’authentification et les fichiers ; le serveur appelle le modèle. Aucun test réalisé ni cas client d’IZZY n’est rapporté.
La CCM et le CAIQ de la Cloud Security Alliance structurent les contrôles cloud et leur évaluation. La demande du client exige une réponse sur votre mise en œuvre.
Distinguez navigateur, API, traitement d’export, support, fournisseur d’IA et copies conservées. Identifiez version, déploiement, date des réglages, rôles et éléments communicables. Une capture de préproduction n’établit pas l’état de la production.
Trois niveaux se complètent :
- Le code montre où le contrôle doit s’appliquer, y compris sur les chemins particuliers.
- La configuration déployée montre les règles, réglages et identités effectivement en place.
- La vérification à l’exécution montre ce qui s’est produit pour des actions et des conditions précises.
Aucun niveau ne remplace automatiquement les deux autres. Un test réussi sur un chemin ne couvre pas les autres. La CNIL recommande des tests et des protections côté serveur : masquer un bouton ne règle pas la question des droits d’accès.
2. « Un client ne peut pas télécharger les fichiers d’un autre »
Le dossier contient des règles de sécurité au niveau des lignes de la base, ou RLS, et un test : l’utilisateur de l’espace A ne peut pas lire la ligne documentaire de B. C’est un élément utile. Le traitement d’export reste à examiner.
Dans notre scénario, ce traitement reçoit un identifiant de document et utilise un accès privilégié pour récupérer le fichier. S’il accepte cet identifiant sans vérifier l’appartenance à l’espace concerné, le test sur la base ne démontre pas le cloisonnement du téléchargement.
Cette distinction découle des contrôles documentés de la plateforme. La documentation RLS de Supabase décrit des accès privilégiés qui peuvent contourner ces règles ; l’identité effective de la requête compte. Le stockage des fichiers a ses propres règles d’accès, définies sur sa table d’objets, qu’une clé de service contourne entièrement. Une preuve portant sur la base ne suffit donc pas pour le fichier servi par votre serveur.
Suivez l’affirmation à travers :
- Le code : comment le traitement relie l’utilisateur, son espace et le document, puis autorise l’export avant de lire le fichier.
- La configuration : l’identité du traitement déployé, les règles de la base et des fichiers, l’usage permis des identifiants techniques.
- L’exécution : un téléchargement autorisé, une demande visant un autre espace et une demande après retrait des droits, avec comptes et données de test maîtrisés.
Si l’autorisation manque dans le traitement, l’écart concerne le contrôle lui-même. Il faut le mettre en place au point où l’accès est décidé, puis vérifier les chemins concernés. Joindre une capture supplémentaire laisserait le défaut intact.
Avec ces seuls éléments fictifs, la réponse serait : « Le cloisonnement en base est étayé sur le chemin examiné. L’autorisation d’export reste à vérifier ; le cloisonnement de toute l’application n’est pas établi. » Après correction, actualisez la réponse selon le périmètre retesté, en distinguant le support.
La vérification complète du cloisonnement entre clients, sur les requêtes, les exports et la diffusion en temps réel, se trouve dans Un client peut-il accéder aux données d’un autre ?.
3. « Les documents clients ne servent pas à entraîner des modèles »
Cette phrase demande une vérification des flux en plus de la documentation fournisseur. Identifiez l’organisation de production, le projet, l’API, les fonctions utilisées et les réglages applicables. Examinez ce que le serveur envoie et les intermédiaires qui le reçoivent.
Par exemple, la documentation de l’API OpenAI indique que les données de l’API ne servent pas à entraîner ses modèles, sauf choix explicite de partage. Elle décrit séparément les journaux de surveillance des abus et les données conservées pour certaines fonctions. L’absence d’entraînement ne démontre pas l’absence de conservation.
Le portail peut, lui aussi, stocker les résumés ou transmettre une requête en échec à un outil de suivi d’erreurs. Le réglage du fournisseur de modèles ne décrit pas ces copies.
Examinez l’intégration dans le code, les réglages du compte utilisé et la trace expurgée d’une requête de test. Évitez de copier un document confidentiel pour démontrer le flux. Comparez les destinataires constatés à la liste déclarée des prestataires ; la fiche CNIL sur la sous-traitance aide à examiner les mesures de sécurité et les responsabilités.
La correction peut retirer un partage involontaire, exclure le contenu inutile du suivi d’erreurs ou modifier l’intégration. Sans preuve sur le compte : « La documentation décrit l’absence d’entraînement par défaut. Nos réglages et les conservations restent à confirmer. » La documentation du fournisseur ne démontre ni vos réglages ni votre situation contractuelle.
4. « Nous pouvons identifier la personne qui a exporté un document »
Une trace HTTP avec une heure, une réponse positive et l’identité du traitement peut montrer que le point d’entrée a répondu. Elle peut laisser inconnu l’utilisateur à l’origine de la demande.
Examinez le code qui produit l’évènement, sa destination déployée, les droits sur les journaux et un évènement expurgé issu d’un export de test. Peut-on relier l’utilisateur, son espace, la référence du document et le résultat ? Pour un traitement asynchrone, peut-on suivre la demande jusqu’à son résultat, au-delà de son entrée dans une file d’attente ?
La CNIL distingue les traces applicatives, liées à l’activité des utilisateurs, des traces techniques, qui couvrent aussi les interventions des administrateurs, et déconseille la duplication excessive de données personnelles dans les journaux. Enregistrer le document ou le prompt complet pour combler ce manque peut créer un autre problème.
Si la trace identifie seulement le traitement technique, il faut préserver l’attribution appropriée lors du passage de relais. Vérifiez ensuite que l’évènement est produit, retrouvable et protégé comme prévu. La durée de conservation et la responsabilité d’examen des anomalies demandent aussi des éléments : la présence d’un outil de logs ne les établit pas.
Pour la trace limitée au traitement : « Les journaux identifient le traitement technique ; l’attribution à l’utilisateur n’est pas démontrée. » Après correction, nommez les évènements et la période couverts, sans généraliser à toutes les actions.
5. « Supprimer un compte retire ses données et ses accès »
Cette phrase regroupe plusieurs engagements. L’opération supprime-t-elle l’identité de connexion, les lignes applicatives, les fichiers, les résumés et les entrées de recherche ? Que deviennent les tâches en attente, les jetons déjà émis et les copies conservées ?
La documentation de gestion des utilisateurs Supabase montre pourquoi la séquence compte : un jeton JWT déjà émis peut rester valide jusqu’à son expiration après suppression, et la propriété de fichiers Storage peut empêcher la suppression d’un utilisateur. Cela ne décrit pas l’ensemble de votre processus.
Dans le portail fictif, examinez le traitement de suppression et ses tâches différées, puis les réglages de stockage et de conservation. Utilisez un compte de test contenant un fichier et un résumé. Contrôlez les emplacements concernés et tentez les actions précédemment autorisées. Distinguez le retrait immédiat de l’accès de l’effacement prévu ultérieurement.
Supposons que le traitement supprime une ligne en base sans déclencher le nettoyage des fichiers. Il faut corriger le processus et sa gestion des échecs et des reprises : une description plus convaincante ne suffit pas. Testez aussi un nettoyage interrompu : une suppression partielle ne doit pas être annoncée comme terminée.
Pour ce traitement incomplet : « La suppression en base existe ; l’effacement complet des fichiers n’est pas établi. » La réponse corrigée précisera quoi, quand et selon quelles exceptions. Les responsables habilités confirment ces engagements ; les éléments techniques ne valent pas conclusion générale de conformité.
6. Valider la réponse étayée ou engager le travail manquant
Revenez aux quatre affirmations. L’examen doit déboucher sur une action :
| Constat | Suite utile |
|---|---|
| Le contrôle existe, mais les éléments actuels manquent | Recueillir et faire valider les éléments avant d’affirmer le contrôle. |
| Le contrôle couvre moins de chemins que la question | Préciser la limite et examiner les chemins restants. |
| Un contrôle demandé manque | Attribuer la correction et sa contre-vérification ; prévoir une restriction provisoire si nécessaire. |
| Le client exige une assurance indépendante | Définir avec lui et le spécialiste compétent le périmètre attendu. |
Un conseil que nous contestons : « répondez oui maintenant, corrigez avant l’audit ». Si le contrôle n’existe pas aujourd’hui, nous indiquons sa limite actuelle et proposons la correction ou un engagement plus restreint. Nous n’écrivons pas un oui que le produit exploité ne peut pas démontrer.
Le directeur technique répond de la description technique ; les personnes habilitées valident les autres engagements. Le responsable de la revue côté client décide si les éléments répondent à son exigence. Une réponse exacte peut rester insuffisante pour l’assurance demandée.
Partagez des éléments expurgés par le canal convenu, sans diffusion incontrôlée des secrets, contenus clients ou détails exploitables. Conservez la réponse et réexaminez-la lorsque l’implémentation change.
Pour les contrôles du code produit par l’IA, consultez les preuves de validation du code généré. Pour le questionnaire en cours, commencez par l’affirmation non étayée qui engage le plus votre produit, et suivez-la jusqu’au produit en service.
Vérifions l’affirmation ensemble
Pour un regard extérieur, apportez fonctionnalité, question client et limite à éclaircir au service Sécurité IA & durcissement du code d’IZZY. La revue peut porter sur la fonctionnalité telle qu’elle est mise en œuvre et sur les éléments de réponse au client. Corrections et contre-vérification ne sont incluses que si le devis convenu les mentionne.
Sources et limites
Sources consultées le 10 novembre 2026. Le portail, les écarts, les vérifications et les réponses possibles sont fictifs ; aucun test à l’exécution ni revue client n’a été mené pour cet article. Les sources citées étayent les distinctions précises présentées. La configuration réelle, les autorisations de partage et l’assurance indépendante requise restent à examiner pour le produit concerné.