Téléverser des documents dans un chatbot IA : vérification des fichiers, protection des données et handoff

Un symbole de téléversement dans la fenêtre de chat semble simple : sélectionner un fichier, poser une question, recevoir une réponse. D'un point de vue technique et éditorial, un processus distinct commence toutefois à cet endroit. Un document peut contenir des données à caractère personnel, du contenu actif, des structures de fichiers manipulées, des numérisations illisibles ou des instructions qu'un modèle linguistique ne doit pas traiter comme des faits dignes de confiance. C'est pourquoi le téléversement de documents dans un chatbot IA nécessite des limites claires avant le transfert, plusieurs étapes de contrôle après celui-ci et une solution de secours compréhensible en cas de problème.

Le guide suivant s'adresse aux équipes chargées du site web, du support et des produits. Il ne décrit pas une fonctionnalité fournisseur isolée, mais une cible éprouvée : les utilisateurs savent avant le téléversement ce qui est autorisé ; le système sépare la réception, le contrôle de sécurité et l'évaluation du contenu ; les erreurs restent compréhensibles ; les cas sensibles passent sous le contrôle d'un être humain de manière maîtrisée.

Le téléversement a besoin d'un objectif clair

Ne commencez pas par une liste de formats pris en charge la plus longue possible, mais par quelques tâches ciblées. Le chatbot doit-il expliquer des informations figurant sur une facture, résumer de la documentation technique ou compléter une demande de support avec une capture d'écran ? Pour chaque tâche, il convient de déterminer quels contenus sont nécessaires, quelle décision le système est autorisé à prendre et quand un contrôle humain est obligatoire.

Cette limitation de la finalité évite que le téléversement ne devienne un stockage général de documents. Elle aide également à la conception : un justificatif pour une réclamation nécessite des instructions et des règles de conservation différentes de celles d'une description de produit publique destinée à une base de connaissances. Le guide existant sur l'entraînement avec des FAQ, des documents et le contenu d'un site web traite de la base de connaissances organisée ; il s'agit ici en revanche de fichiers que les visiteurs soumettent au cours d'une conversation en cours.

Rendre visibles les types de fichiers, tailles et quantités autorisés

Les utilisateurs doivent voir les règles avant que la boîte de dialogue de sélection des fichiers ne s'ouvre : formats autorisés, taille maximale, nombre maximal et si les fichiers protégés par mot de passe ou compressés sont acceptés. Utilisez une liste d'autorisation (allowlist) qui ne permet que les formats professionnellement nécessaires. « Tous les documents » n'est pas une exigence utile.

L'attribut HTML accept améliore la sélection dans le navigateur, mais ne constitue pas un contrôle de sécurité. MDN souligne expressément que les utilisateurs peuvent souvent contourner les restrictions de sélection et que la vérification doit donc s'effectuer côté serveur. L'interface utilisateur peut donc proposer les extensions de fichiers appropriées, tandis que le serveur évalue indépendamment l'extension, le type MIME déclaré, la signature réelle et la structure.

Ne pas reprendre les noms de fichiers et métadonnées sans vérification

Un nom d'origine peut contenir des caractères spéciaux, des éléments de chemin d'accès, des chaînes de caractères très longues ou des informations sensibles. Pour le stockage interne, le système doit attribuer son propre identifiant aléatoire et traiter le nom visible uniquement comme une information d'affichage nettoyée. De même, les métadonnées intégrées peuvent contenir des noms, des informations sur les appareils ou des données de géolocalisation. Le besoin d'utiliser ces données doit découler directement de la finalité du traitement.

Le Cheat Sheet de téléversement de fichiers de l'OWASP recommande notamment une liste d'autorisation pour les extensions, une vérification indépendante du type, des noms de fichiers sécurisés, des limites de taille, le stockage en dehors de la racine web (webroot) et une protection contre les téléversements non autorisés. Aucun contrôle isolé ne suffit à lui seul ; il est judicieux de mettre en place une chaîne de contrôles simples et traçables.

Séparer la réception, la vérification de sécurité et l'évaluation

Un fichier accepté ne doit pas être immédiatement disponible dans le chat. Un processus solide comporte au moins trois états : reçu, en cours de vérification et validé pour l'évaluation. Pendant la vérification, le fichier se trouve dans une zone isolée. L'extraction n'a accès au fichier qu'une fois le contrôle réussi. Les URL publiques directes ou les chemins de stockage prévisibles doivent être évités.

Examen des malwares et de la structure

Selon le niveau de risque, l'analyse antivirus ou l'environnement de bac à sable (sandbox), le contrôle des signatures et, pour les fichiers Office ou PDF appropriés, le Content Disarm and Reconstruction (CDR) doivent faire partie du processus. Les archives, les fichiers imbriqués et les contenus particulièrement compressés nécessitent leurs propres limites, car ils peuvent accaparer des ressources ou attaquer les analyseurs synthaxiques (parsers). Les scanners et bibliothèques doivent être à jour et configurés de manière à ce qu'un dépassement de délai (timeout) ou une erreur d'analyse ne soit pas considéré comme une validation.

L'extraction de texte est un état de qualité à part entière

Un fichier sécurisé peut néanmoins s'avérer inutilisable : un document numérisé de travers, une photo avec des reflets, une note manuscrite ou un PDF sans couche de texte extractible. Le système doit donc indiquer séparément si le fichier a été accepté en toute sécurité et si le contenu a pu être lu correctement. Une faible qualité d'extraction ne doit pas être masquée par des ajouts inventés.

Formuler des erreurs précises et orientées vers l'action

« Échec du téléversement » ne précise pas ce qu'il faut faire ensuite. Des messages distincts sont préférables : format non pris en charge, fichier trop volumineux, protection par mot de passe détectée, contrôle de sécurité échoué, texte illisible ou traitement temporairement indisponible. Le message ne doit pas révéler de détails internes sur le scanner ou l'infrastructure, mais doit proposer une solution de correction sécurisée.

Les WCAG 2.2 exigent une identification et une description textuelles des erreurs de saisie détectées automatiquement. Les explications relatives au Critère de succès 3.3.1 Identification des erreurs soulignent que le simple fait d'afficher à nouveau un formulaire ne suffit pas. Pour le chat, cela signifie : nommer le nom du fichier ou la position du téléversement, expliquer l'erreur sous forme de texte et proposer une option concrète pour remplacer, supprimer ou transférer le fichier.

Communiquer la progression de manière accessible

Pour les fichiers volumineux, des temps d'attente surviennent. Une barre visuelle seule n'aide pas tout le monde. Les changements d'état tels que « Téléversement en cours », « Contrôle de sécurité », « Lecture du contenu » et « Prêt » doivent être identifiables par les technologies d'assistance, sans déplacer le focus du clavier de manière intempestive. L'explication du W3C sur les WCAG 4.1.3 Messages d'état mentionne explicitement la progression, le succès et les erreurs comme des informations d'état pertinentes.

L'action d'annulation doit rester accessible. Après une annulation, il doit être visible si le transfert a effectivement été arrêté et si une copie déjà reçue a été supprimée. Sur les appareils mobiles, le nom du fichier, la progression et le bouton de suppression doivent être disposés de manière à ne pas masquer la zone de saisie ni la navigation importante.

Expliquer la protection des données avant le téléversement

L'information doit répondre aux questions suivantes avant le transfert de données : À quoi sert le fichier ? Qui peut le voir ? Combien de temps reste-t-il conservé ? Son contenu est-il utilisé pour améliorer un modèle ? Comment le fichier peut-il être supprimé ? Les politiques de confidentialité générales restent importantes, mais elles ne remplacent pas l'information contextuelle fournie directement lors du téléversement.

L'article 5 du Règlement général sur la protection des données prévoit notamment la limitation des finalités, la minimisation des données et la limitation de la conservation. En pratique, cela signifie : ne demander que les documents nécessaires, éviter les pages ou métadonnées inutiles, définir un délai de suppression justifié et vérifier techniquement la suppression effective. Il ne s'agit pas d'un conseil juridique individuel ; les obligations concrètes doivent être évaluées pour chaque cas d'utilisation.

Séparer les chats publics des démarches sécurisées

Un chat public sur un site web n'est pas automatiquement l'endroit approprié pour des contrats, des pièces d'identité, des données de santé ou des documents bancaires. Pour les opérations sensibles, la conversation doit basculer vers une zone authentifiée ou un canal sécurisé établi. L'article chatbot IA public vs. espace client montre comment séparer l'identité et l'accès aux données.

Même dans une zone connectée, le principe du moindre privilège s'applique. Un agent de support peut avoir besoin de consulter un justificatif, mais n'a pas automatiquement besoin d'un accès permanent à tous les documents téléversés d'un compte. Les accès, téléchargements et suppressions doivent être journalisés de manière traçable, sans copier inutilement le contenu du document dans les événements d'analyse.

Le contenu du document ne doit pas être considéré comme fiable

Un fichier validé a été traité techniquement, mais son contenu ne constitue pas encore une source faisant autorité. Les documents peuvent être obsolètes, contradictoires ou délibérément manipulés. Ils peuvent également contenir des instructions visant à inciter le modèle à divulguer des données ou à contourner des règles. Traitez donc le texte extrait comme du contenu non fiable (untrusted content), séparez-le des règles du système et limitez les outils ainsi que les accès aux données.

Le guide sur l'injection de prompts dans les chatbots de site web explique cette limite pour le RAG et les outils. Pour les téléversements, un élément s'ajoute : les réponses doivent se référer à des passages identifiables du document, indiquer les incertitudes et ne pas compléter les informations manquantes lors de décisions critiques.

Human handoff avec un paquet de contexte restreint

Un transfert humain est nécessaire si la vérification de sécurité échoue de manière répétée, si l'extraction reste peu fiable, si l'identité ou les autorisations ne sont pas claires, ou si une décision métier dépasse les capacités du chatbot. Seules les informations dont l'agent humain a besoin pour poursuivre la demande sont transmises : le sujet, le statut du téléversement, la référence sécurisée du document, le message d'erreur concret, les informations déjà confirmées et la prochaine étape souhaitée.

Le fichier ne doit pas être envoyé en plus par courrier électronique non sécurisé sous prétexte que le chatbot n'a pas pu le lire. Un processus de human handoff structuré préserve le contexte, la responsabilité et les attentes, sans dupliquer inutilement des contenus sensibles.

Mesurer avec des événements, pas avec le contenu des documents

Pour l'amélioration du produit, des événements structurés suffisent souvent : sélection démarrée, téléversement annulé, type refusé, limite de taille atteinte, contrôle de sécurité réussi, extraction insuffisante, transfert choisi et suppression confirmée. Les noms de fichiers, le texte extrait et les contenus à caractère personnel ne doivent pas figurer automatiquement dans les outils d'analyse ou les journaux d'erreurs.

Évaluez conjointement les indicateurs de succès et de protection. Un taux de téléversement élevé n'a aucune valeur si de nombreuses personnes ne comprennent pas quel fichier est attendu, ou si des documents sensibles se retrouvent dans le chat public. Il convient donc de suivre également le taux de correction, l'abandon après l'information sur la protection des données, la proportion de fichiers illisibles, le temps écoulé jusqu'à l'affichage d'un message d'erreur compréhensible et la poursuite réussie de l'échange après le transfert humain.

Liste de contrôle avant la mise en service

• Un objectif clair et un type de document autorisé sont-ils définis pour chaque cas de téléversement ?
• Le format, la taille, le nombre, la protection par mot de passe et la durée de conservation sont-ils visibles avant la sélection ?
• Le serveur vérifie-t-il l'extension, le type MIME, la signature, la structure et les limites de taille indépendamment du navigateur ?
• La mise en quarantaine, le contrôle anti-malware, l'extraction et la validation sont-ils mis en œuvre sous forme d'états distincts ?
• Les utilisateurs reçoivent-ils des messages de progression et d'erreur précis et accessibles ?
• Les démarches sensibles sont-elles transférées vers un canal authentifié ou pris en charge par un humain ?
• La durée de conservation, l'accès, la journalisation et la suppression confirmée sont-ils testés dans la pratique ?
• Le chatbot traite-t-il le texte extrait comme non fiable et cite-t-il des passages vérifiables ?
• Les outils d'analyse contiennent-ils uniquement les événements nécessaires plutôt que des noms de fichiers ou le contenu de documents ?
• Le transfert humain est-il testé avec des cas d'erreur réels sur ordinateur et mobile ?

Conclusion : Le téléversement sécurisé commence avant le fichier

Un bon téléversement de documents rend les limites visibles avant que les données ne circulent. Ensuite, il sépare la réception technique, la vérification de sécurité, la qualité du contenu et la décision métier. De cette façon, un chatbot IA peut utiliser les documents comme un contexte de conversation utile, sans accorder une confiance aveugle à chaque octet reçu ou à chaque instruction extraite.

Si vous souhaitez mettre en place un chatbot de site web et intégrer ces processus dans une architecture globale fiable, vous pouvez consulter les fonctionnalités de ChatReact. Planifiez le téléversement comme un service contrôlé – avec un consentement clair, un statut compréhensible et un parcours sécurisé vers un conseiller humain.

Sources

• OWASP Cheat Sheet Series: File Upload
• MDN : Attribut HTML accept
• W3C WAI : Comprendre les messages d'état
• W3C WAI : Comprendre l'identification des erreurs
• EUR-Lex : Règlement (UE) 2016/679