Pièces jointes d’un formulaire web : contrôler les fichiers avant de les ouvrir

Un formulaire de contact accepte un plan, une photo ou un cahier des charges. Le fichier arrive ensuite dans la messagerie, le CRM ou un outil d’analyse. Cette circulation mérite une règle claire : à quel moment la pièce jointe devient-elle disponible pour votre équipe ?

Pour une PME, le sujet concerne autant la continuité du traitement commercial que la sécurité. Un fichier bloqué doit rester visible comme problème à résoudre, tandis qu’un fichier reçu ne doit pas être considéré automatiquement comme vérifié. Voici les décisions à prendre avec votre prestataire avant d’ajouter un bouton « Joindre un document ».

1. Définir les documents réellement utiles

Partez des demandes que l’équipe sait traiter. Avez-vous besoin d’un PDF décrivant le projet, de photographies ou d’un fichier métier particulier ? Chaque format accepté doit correspondre à un usage identifié. Si une description suffit au premier contact, le document peut être demandé plus tard, par un canal adapté.

Rédigez une courte règle de dépôt comprenant :

• les formats acceptés ;
• la taille maximale par fichier et par envoi ;
• le nombre de pièces jointes autorisées ;
• la solution proposée lorsqu’un document ne peut pas être transmis.

Choisissez ces limites à partir de vos documents habituels et des capacités de votre hébergement. Évitez de reprendre une valeur par défaut sans vérifier ce qu’elle permet. Faites aussi préciser le traitement des documents protégés par mot de passe : peuvent-ils être analysés, et que voit le prospect lorsqu’ils sont refusés ?

2. Distinguer l’aide à la sélection et le contrôle du serveur

Le sélecteur de fichiers peut proposer uniquement certains formats. C’est une aide utile, mais le navigateur ne constitue pas le dernier point de contrôle. MDN précise que l’attribut HTML « accept » guide la sélection sans valider les fichiers ; la vérification doit également avoir lieu côté serveur. Documentation MDN sur l’attribut accept.

Demandez donc ce qui est vérifié après réception. L’OWASP recommande de combiner une liste de formats autorisés, des limites de taille et des contrôles du type réel. Le type annoncé lors de l’envoi peut être falsifié, et la signature d’un fichier ne suffit pas, seule, à établir sa sécurité. Recommandations OWASP pour les fichiers déposés.

Dans votre cahier des charges, formulez un résultat observable : un fichier incompatible doit être refusé même si son nom se termine par une extension autorisée. Faites réaliser cette vérification dans un environnement de test, avec des fichiers inoffensifs préparés par le prestataire.

3. Prévoir une zone de réception isolée

Le fichier doit suivre un parcours maîtrisé avant d’apparaître dans les outils de l’équipe. Microsoft recommande notamment une zone de dépôt dédiée, sans permission d’exécution, distincte de l’arborescence de l’application. Sa documentation préconise aussi de générer le nom utilisé pour le stockage plutôt que de faire confiance au nom fourni. Guide Microsoft sur le dépôt de fichiers.

Demandez à votre prestataire de vous montrer ce parcours : réception, contrôles, analyse, puis mise à disposition. La personne qui répond aux demandes doit retrouver la référence du dossier et le nom compréhensible du document, sans avoir à manipuler son adresse de stockage.

Prévoyez également le cas où plusieurs prospects envoient un fichier portant le même nom. Chaque dépôt doit rester associé à sa propre demande. Un remplacement de pièce jointe doit laisser un état clair : quelle version est en attente, et laquelle peut être consultée ?

4. Traiter explicitement les analyses incomplètes

Un service d’analyse peut retourner plusieurs états. Microsoft Defender for Storage distingue notamment l’absence de menace détectée, la détection d’un fichier malveillant, une erreur et l’absence d’analyse. Ces résultats nécessitent des traitements différents. Documentation Microsoft sur les résultats d’analyse.

Pour votre formulaire, définissez une règle de fonctionnement : la pièce jointe reste indisponible pour le traitement ordinaire tant que tous les contrôles requis n’ont pas donné un résultat permettant sa mise à disposition. Un fichier détecté comme malveillant reste bloqué et déclenche une alerte au responsable. Une erreur ou une absence d’analyse doit créer une attente ou un refus explicite, avec un responsable et une procédure de reprise.

Conservez le résultat technique associé à la version exacte du fichier. Un document remplacé doit repasser par les contrôles prévus. Demandez aussi comment l’application obtient un résultat fiable : Microsoft avertit que les étiquettes de résultat modifiables sur ses fichiers stockés ne doivent pas servir seules de contrôle de sécurité.

L’absence de menace détectée reste un résultat d’analyse, sans garantie absolue. Les autres protections du parcours demeurent nécessaires.

5. Éviter que les notifications contournent les contrôles

Reconstituez tout ce qui se déclenche après l’envoi du formulaire. Une copie est-elle immédiatement jointe à un email ? Une automatisation transmet-elle le document au CRM ? Un aperçu est-il généré avant l’analyse ? Ces étapes doivent respecter le même état de validation.

Nous recommandons une notification qui signale la nouvelle demande et indique si sa pièce jointe est disponible, en attente ou refusée. L’équipe peut ainsi prendre connaissance du besoin sans ouvrir un fichier encore non vérifié.

Si un prestataire externe analyse les documents, vérifiez quelles données lui sont envoyées et selon quelles conditions. L’OWASP souligne le risque de fuite lié à certains services publics d’analyse. Évitez donc d’y déposer spontanément les fichiers confidentiels reçus par votre entreprise.

Les droits de consultation restent à définir séparément, comme expliqué dans notre guide sur les accès aux documents d’un espace client.

6. Faire une recette avec l’équipe qui reçoit les demandes

Avant la mise en ligne, demandez une démonstration des cas suivants :

• un document autorisé termine le parcours et rejoint le bon dossier ;
• un format refusé produit un message compréhensible ;
• un envoi trop volumineux indique comment poursuivre ;
• une interruption de l’analyse laisse le fichier bloqué et avertit le responsable ;
• une détection simulée laisse le fichier bloqué et déclenche l’alerte prévue ;
• le remplacement d’un document relance les vérifications ;
• les emails et automatisations respectent l’état du fichier.

Pour chaque essai, notez le résultat attendu, le résultat observé et la personne chargée de corriger l’écart. Utilisez des documents de test dépourvus de données clients. Toute simulation de détection doit être organisée par le prestataire dans un périmètre convenu, sans collecter de logiciel malveillant.

À la fin, l’équipe doit savoir retrouver une demande bloquée et expliquer au prospect comment la compléter. Cette procédure, les règles de dépôt et les résultats des essais constituent une base concrète pour accepter la fonctionnalité. Ils ne remplacent pas un audit de sécurité.

Vous préparez un formulaire ou une automatisation documentaire ? Décrivez votre parcours à KADRI AI, depuis le dépôt jusqu’à l’outil utilisé par votre équipe, pour préciser les contrôles attendus.

Sources officielles consultées le 15 octobre 2026. Les fonctions disponibles dépendent des services et de leur configuration.