Pourquoi le PPAP est mauvais pour la sécurité des e-mails, et que faire à la place

· Mis à jour le: · · Sécurité des e-mails, PPAP, Prévention des fuites d'informations, B2B, Réutilisation des ressources existantes

« Est-il vraiment sûr d’envoyer un ZIP protégé par mot de passe, puis d’envoyer le mot de passe dans un e-mail séparé ? » Cette question revient encore régulièrement aujourd’hui. En apparence, cela semble sûr puisque quelque chose est chiffré, mais c’est précisément là que se cache le piège en pratique.

Le PPAP, comme on l’appelle, est une protection faible contre l'interception, insuffisant comme protection contre les erreurs d'envoi, et de surcroît il a tendance à gêner l'inspection sur le trajet du courrier — ce qui en fait une méthode difficile à recommander dans la sécurité des e-mails actuelle.1234

Dans cet article, en nous appuyant sur des documents publics et des sources primaires vérifiables au mois d’avril 2026, nous examinons les problèmes du PPAP et la façon dont il est naturel de le remplacer dans la pratique.12536748910

1. La conclusion d’abord

Abandonner le PPAP ne signifie pas abandonner le chiffrement. Ce qu’il faut abandonner, c’est la conception consistant à « chiffrer la pièce jointe en ZIP, puis envoyer le mot de passe plus tard par le même canal d’e-mail ».

Ce qu’il faut envisager à la place, ce sont les trois points suivants.

  1. Pour les e-mails professionnels ordinaires, partir du principe d’une protection du canal de communication comme TLS / STARTTLS.710
  2. Si l’authenticité ou le chiffrement de l’e-mail lui-même sont nécessaires, utiliser un mécanisme comme S/MIME.536
  3. Pour la remise de fichiers confidentiels, privilégier le téléchargement authentifié ou le partage à accès contrôlé plutôt que la pièce jointe.489

En résumé, l’important est de ne pas chercher à résoudre tous les problèmes liés à l’e-mail avec un simple mot de passe de ZIP.

2. Qu’est-ce que le PPAP, au fond ?

Le PPAP, tel qu’on l’entend ici, désigne généralement le déroulé suivant.

  1. Placer le fichier dans un ZIP protégé par mot de passe
  2. Envoyer le ZIP dans un premier e-mail
  3. Envoyer le mot de passe dans un second e-mail

Cette pratique a tendance à être perçue comme « sûre parce qu’on n’envoie pas en clair ». Dans les faits, cependant, ce qu’elle protège réellement reste assez limité.

Aspect Le PPAP est-il suffisant ? Évaluation réelle
Confidentialité sur le trajet de communication Faible L’envoi séparé par le même canal d’e-mail a peu d’effet
Protection contre les erreurs d’envoi Insuffisante L’incident est pratiquement consommé dès que le destinataire est erroné
Protection contre les logiciels malveillants Plutôt défavorable Tend à gêner l’inspection sur le trajet
Authenticité de l’expéditeur Non protégée Ce n’est pas une mesure anti-usurpation
Contrôle d’accès Non protégé Contrôle faible de qui peut consulter le fichier

Le PPAP est loin d’être aussi universel qu’il en a l’air : il paraît « vaguement sûr » tout en échouant à protéger ce qui compte réellement, et c’est bien là le problème.

3. Pourquoi le PPAP est mauvais

3.1 Une protection faible contre l’interception

Le Cabinet Office (Japon) a conclu que la méthode consistant à envoyer automatiquement le mot de passe par le même canal que l’envoi du fichier ZIP n’est pas appropriée.1 Le point important est que chiffrer le fichier a peu de sens si la conception ne prend pas aussi en compte la manière de transmettre la clé.

En effet, si l’on se contente d’envoyer un e-mail de suivi dans le même environnement de messagerie, vers la même boîte de réception, au même destinataire, l’ensemble des personnes pouvant voir le ZIP et l’ensemble de celles pouvant voir le mot de passe finissent par être presque identiques. Il ne reste alors que le simple fait d’« avoir chiffré », avec une confidentialité réelle qui n’est pas si forte que cela.

3.2 Une protection insuffisante contre les erreurs d’envoi

Certaines pratiques considèrent le PPAP comme une protection contre les erreurs d’envoi, mais il est faible sur ce point également.

Les réponses types de l’IPA pour l’examen d’ingénieur en technologies de l’information appliquées relèvent, parmi les problèmes du PPAP, le fait que si l’e-mail principal est envoyé au mauvais destinataire, le mot de passe de déchiffrement parvient lui aussi à ce destinataire erroné.3 Un document de l’Agence numérique (Japon) présente également une conclusion allant dans le même sens : « l’envoyer dans un e-mail séparé revient à l’envoyer au même destinataire, ce qui ne fonctionne donc pas comme un contrôle ».4

Autrement dit, une fois le ZIP envoyé au mauvais destinataire, si l’on envoie ensuite le mot de passe par habitude, l’incident se consomme purement et simplement. Ce qui est réellement nécessaire, c’est une méthode de remise permettant la vérification du destinataire, l’approbation, une relecture avant envoi, et la révocation ou le rappel après envoi.

3.3 Il gêne l’inspection contre les logiciels malveillants

C’est un point du PPAP qu’on ne peut pas se permettre de négliger.

L’IPA met en garde, à propos des e-mails d’attaque Emotet comportant une pièce jointe ZIP protégée par mot de passe, que, la pièce jointe étant chiffrée, il existe une forte probabilité qu’elle échappe à la détection et à la mise en quarantaine des produits de sécurité présents sur le trajet d’acheminement du courrier, et qu’elle parvienne jusqu’au destinataire.2

Du côté de l’expéditeur, on peut croire avoir « sécurisé les choses en chiffrant », mais du point de vue du destinataire ou du relais, cela devient une pièce jointe dont le contenu est difficile à inspecter. Sur ce point également, on ne peut pas dire que le PPAP soit une méthode qui s’accorde bien avec les défenses actuelles de la messagerie.

3.4 Il ne garantit ni l’authenticité ni le contrôle d’accès

Le PPAP ne prouve pas que l’expéditeur est authentique. Il ne dispose pas non plus, ou presque, de contrôle d’accès portant sur qui a téléchargé quoi et quand, sur la possibilité de révoquer l’accès ultérieurement, ou sur la répartition des droits selon le destinataire.

L’IPA, de son côté, traite des e-mails à signature électronique tels que S/MIME, ce qui les relie contextuellement en tant qu’alternative au PPAP.56 Par ailleurs, les documents de l’IPA sur la sécurité web concluent que les sites web traitant des informations non publiques ont besoin d’une fonction d’authentification et d’un contrôle d’accès.8

En combinant ces deux éléments, la réponse devient assez claire.

  • Pour l’authenticité de l’e-mail et la détection de falsification : S/MIME
  • Pour les droits de consultation des fichiers et la gestion de la révocation : le téléchargement authentifié

L’envoi séparé du mot de passe du ZIP ne répond proprement à aucun des deux.

4. La bonne approche consiste à « séparer selon la finalité »

L’exigence « vouloir envoyer en sécurité » n’est, en réalité, pas une exigence unique. Sans cette séparation, on cherche à tout couvrir avec le PPAP et la conception s’effondre.

4.1 Les e-mails professionnels ordinaires

Pour les e-mails professionnels ordinaires, une protection du canal de communication comme TLS / STARTTLS constitue d’abord la base.710 Au-delà, si l’authenticité de l’expéditeur, la détection de falsification ou le chiffrement du corps de l’e-mail lui-même sont nécessaires, il est logique d’envisager S/MIME.536

4.2 La remise de fichiers confidentiels

Vouloir remettre le fichier uniquement à la personne concernée, contrôler les droits de consultation, pouvoir révoquer l’accès ultérieurement. Pour ces besoins, le téléchargement authentifié ou le partage à accès contrôlé sont plus naturels que la pièce jointe.489

Par exemple, des besoins comme les suivants sont plus faciles à gérer côté web que via une pièce jointe.

  • Le téléchargement n’est possible qu’après connexion
  • Le lien peut être limité dans le temps
  • Les droits peuvent être répartis selon le destinataire
  • Un historique peut être conservé si nécessaire

4.3 Quand la pièce jointe est vraiment inévitable

Il existe des situations où, en raison des contraintes du destinataire, seule la pièce jointe est réellement utilisable. Dans ce cas, comme l’indique également l’analyse du Cabinet Office, le minimum consiste à transmettre le fichier et le mot de passe par des canaux entièrement séparés.1

Cependant, il ne s’agit pas d’une solution définitive, mais d’une mesure provisoire. Plutôt que de la figer comme pratique standard à chaque fois, mieux vaut l’envisager avec, en perspective, un passage futur vers le partage authentifié.

5. Une procédure de remplacement pour les petites et moyennes entreprises

Lorsqu’une petite ou moyenne entreprise abandonne le PPAP, il est plus efficace de commencer par clarifier la classification que d’introduire d’emblée un système de grande ampleur.

5.1 Ce qu’il faut arrêter en premier

  • Le chiffrement ZIP automatique
  • L’envoi séparé automatique du mot de passe par le même canal d’e-mail
  • La règle uniforme « tous les fichiers importants passent par le PPAP »

5.2 Ce qu’il faut décider ensuite

  • Ce qui peut être envoyé par e-mail ordinaire
  • Ce qui doit être interdit en pièce jointe
  • Ce qui doit être orienté vers le téléchargement authentifié
  • Quelle procédure d’approbation appliquer en cas de pièce jointe exceptionnelle

5.3 La logique d’une configuration minimale

Au départ, il suffit de séparer les choses en deux filières comme suit.

  1. E-mail ordinaire
    • Communication professionnelle
    • S/MIME selon les besoins
  2. Fichiers confidentiels
    • Téléchargement authentifié
    • Paramétrage des droits
    • Partage à durée limitée

Si ce point reste flou, le terrain a tendance à finalement revenir au « PPAP par défaut ».

6. Un logigramme de décision

NonOuiOuiNonOuiNonCe que vous voulez remettreS'agit-il d'un fichier hautement confidentielE-mail professionnel ordinaireEnvoyer en s'appuyant sur TLS / STARTTLSSi l'authenticité ou le chiffrement importent, S/MIMELe destinataire peut-il se connecter pour le recevoirTéléchargement authentifié / partage à accès contrôléDéfinir droits, expiration et révocation selon les besoinsUne pièce jointe est-elle vraiment inévitableFichier chiffré + mot de passe manuel via un canal séparé

Ce qui importe dans ce schéma, c’est de ne pas positionner le PPAP comme une solution intermédiaire universelle. L’e-mail et la remise de fichiers sont plus faciles à concevoir lorsqu’on les pense séparément.

7. Idées reçues fréquentes

7.1 « Le ZIP est chiffré, donc c’est sûr »

Même chiffré, cela ne suffit pas si la manière de transmettre la clé est faible. Pire encore, un ZIP protégé par mot de passe peut gêner l’inspection sur le trajet.12

7.2 « Il suffit de l’envoyer dans un autre e-mail »

Un envoi de suivi vers le même destinataire, par le même canal d’e-mail, ne constitue pas un contrôle fort.14

7.3 « Abandonner le PPAP empêche d’envoyer des pièces jointes »

Ce n’est pas le cas. Il suffit d’utiliser l’outil adapté à chaque situation : e-mail ordinaire, S/MIME, téléchargement authentifié, ou mot de passe par canal séparé pour les exceptions.

7.4 « S/MIME est réservé aux grandes entreprises et n’est pas réaliste »

Il faut certes vérifier la compatibilité du destinataire, mais au minimum, c’est plus cohérent que le PPAP par rapport à ce que l’on cherche à protéger. Par ailleurs, pour les destinataires avec lesquels S/MIME ne convient pas, le téléchargement authentifié reste une autre option.

8. Résumé

Ce qui rend le PPAP mauvais, c’est qu’il chiffre tout en donnant facilement l’impression d’être devenu sûr. Dans les faits, les problèmes suivants subsistent :

  • L’envoi séparé par le même canal d’e-mail offre une confidentialité faible
  • Il est insuffisant comme protection contre les erreurs d’envoi
  • Le ZIP protégé par mot de passe gêne l’inspection sur le trajet
  • Il ne garantit ni l’authenticité de l’expéditeur ni le contrôle d’accès

1234

Ainsi, ce qu’il faut faire n’est pas de légèrement modifier les pratiques de type PPAP pour les maintenir artificiellement en vie. Il s’agit de protéger l’e-mail en tant qu’e-mail, et de concevoir la remise de fichiers en tant que remise de fichiers.

En une phrase, cela donne :

Abandonner le PPAP ne signifie pas abandonner le chiffrement : cela signifie abandonner le mauvais contrôle pour le remplacer par des contrôles adaptés à la finalité.

Articles connexes

Références

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Qu'est-ce que le PPAP ?
C'est une pratique qui consiste à placer un fichier dans un ZIP protégé par mot de passe, à envoyer ce ZIP dans un premier e-mail, puis à envoyer le mot de passe dans un second e-mail. Comme rien n'est envoyé en clair, cela peut sembler sûr, mais dans les faits, ce que cette pratique protège réellement reste assez limité. La confidentialité sur le trajet de communication est faible, elle est insuffisante comme protection contre les erreurs de destinataire, et elle ne garantit ni l'authenticité de l'expéditeur ni le contrôle d'accès.
Pourquoi le PPAP est-il dangereux ?
Il y a quatre problèmes principaux. Même en envoyant le mot de passe séparément par le même canal d'e-mail, l'ensemble des personnes pouvant voir le ZIP et l'ensemble de celles pouvant voir le mot de passe finissent par être presque identiques, ce qui en fait une protection faible contre l'interception. Si le destinataire est erroné, le mot de passe de déchiffrement parvient lui aussi à ce même destinataire, ce qui en fait une protection insuffisante contre les erreurs d'envoi. Comme le ZIP protégé par mot de passe est chiffré, il a tendance à échapper à la détection et à la mise en quarantaine des produits de sécurité présents sur le trajet d'acheminement du courrier, et il a été effectivement exploité par des e-mails d'attaque comme ceux d'Emotet. Enfin, il ne garantit ni l'authenticité de l'expéditeur ni le contrôle d'accès.
Si l'on abandonne le PPAP, que faut-il utiliser à la place ?
La base consiste à séparer les besoins en trois catégories selon leur finalité. Pour les e-mails professionnels ordinaires, on part du principe d'une protection du canal de communication comme TLS / STARTTLS, et on utilise S/MIME si l'authenticité ou le chiffrement de l'e-mail lui-même sont nécessaires. Pour la remise de fichiers confidentiels, en privilégiant le téléchargement authentifié ou le partage à accès contrôlé plutôt que la pièce jointe, on peut gérer jusqu'aux paramètres de droits, aux liens à durée limitée et à la gestion de la révocation. L'important est de ne pas chercher à résoudre tous les problèmes liés à l'e-mail avec un simple mot de passe de ZIP.
S'il faut absolument envoyer en pièce jointe, que faire ?
Si, en raison des contraintes du destinataire, seule la pièce jointe est utilisable, le minimum consiste à transmettre le fichier chiffré et le mot de passe par des canaux entièrement séparés. Cependant, ce n'est pas une solution définitive, mais une mesure provisoire. Plutôt que de la figer comme pratique standard permanente, il est plus sûr de l'envisager avec, en perspective, un passage futur vers le partage authentifié.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.

Retour au blog