FTP fait partie de ces technologies si anciennes qu’elles semblent aller de soi. Pourtant, derrière sa simplicité apparente se cache une réalité souvent oubliée : FTP n’est pas chiffré par défaut. Cette caractéristique n’est pas un oubli accidentel, mais le résultat d’un contexte historique, technique et économique très précis.
FTP, pour File Transfer Protocol, apparaît dans les premières décennies des réseaux informatiques. Sa version de référence la plus connue est décrite dans la RFC 959, publiée en 1985, mais ses origines remontent encore plus loin, au début des années 1970. À cette période, Internet n’est pas encore le réseau mondial ouvert que nous connaissons. Il s’agit surtout d’un environnement universitaire, militaire et scientifique, utilisé par un nombre limité d’acteurs identifiés.
Dans ce contexte, la priorité n’est pas la confidentialité des échanges, mais l’interopérabilité. Il faut permettre à des systèmes très différents de transférer des fichiers de manière fiable. Les standards Internet sont alors documentés dans des textes techniques appelés RFC, dont le rôle est expliqué dans cet article consacré à la façon dont les protocoles deviennent des références communes. FTP s’inscrit pleinement dans cette logique : fonctionner partout, avec peu de ressources, et sans dépendre de mécanismes cryptographiques encore peu répandus.
Le FTP original repose sur une hypothèse devenue dangereuse aujourd’hui : le réseau est considéré comme relativement fiable et les utilisateurs comme légitimes. Lorsqu’un client se connecte à un serveur FTP, il transmet généralement son nom d’utilisateur et son mot de passe en clair. Les commandes envoyées au serveur, tout comme les fichiers transférés, peuvent également être observés si quelqu’un intercepte le trafic.
À l’époque de sa conception, cette exposition n’était pas perçue comme un risque majeur. Les communications circulaient sur des réseaux fermés ou semi-fermés, loin des points d’accès Wi-Fi publics, des opérateurs multiples et des infrastructures cloud modernes. Aujourd’hui, la situation est radicalement différente. Un mot de passe FTP envoyé sans chiffrement peut être capturé sur un réseau local compromis, dans un environnement d’hébergement mal segmenté ou lors d’une mauvaise configuration d’entreprise.
FTP n’utilise pas une seule connexion, mais deux canaux distincts. Le canal de contrôle sert à envoyer les commandes, souvent via le port 21. Le canal de données, lui, est ouvert séparément pour transférer les fichiers ou lister les répertoires. Selon le mode actif ou passif, c’est le client ou le serveur qui initie cette connexion secondaire.
Cette architecture était pratique dans les premiers réseaux, mais elle complique l’ajout tardif du chiffrement. Les pare-feu, les routeurs NAT et les équipements de filtrage doivent comprendre les commandes FTP pour ouvrir dynamiquement les bons ports. Lorsque le trafic est chiffré, ces équipements ne voient plus les instructions internes. Le protocole devient alors plus difficile à faire passer correctement, surtout dans les infrastructures anciennes ou fortement filtrées.
On pourrait se demander pourquoi les éditeurs de serveurs FTP n’ont pas activé automatiquement le chiffrement dès qu’il est devenu disponible. La réponse tient en grande partie à la compatibilité. Des millions de clients, scripts, automates industriels, sauvegardes et applications métier ont longtemps dépendu de comportements FTP très précis. Changer le mode de connexion par défaut aurait cassé de nombreux usages.
Le chiffrement impose aussi une négociation cryptographique entre client et serveur. Dans le web moderne, cette étape est devenue habituelle, notamment avec TLS et des mécanismes comme la négociation ALPN utilisée par HTTP/2. FTP, lui, n’a pas été conçu autour de cette idée. Ajouter une couche de sécurité sans perturber les anciens clients a donc nécessité des variantes, mais pas une transformation automatique du protocole historique.
Pour sécuriser les transferts, deux solutions sont souvent citées : FTPS et SFTP. FTPS correspond à FTP avec TLS. Il conserve une logique proche du FTP traditionnel, mais ajoute le chiffrement pour protéger l’authentification et les données. Il existe notamment en mode explicite, où le client demande l’activation de TLS, et en mode implicite, historiquement associé au port 990.
SFTP, malgré son nom, est un protocole différent. Il fonctionne au-dessus de SSH, généralement sur le port 22, et ne reprend pas l’architecture à deux canaux de FTP. C’est pourquoi il traverse souvent plus facilement les pare-feu et les environnements modernes. Dans de nombreuses entreprises, SFTP est aujourd’hui préféré à FTP pour les échanges automatisés, car il combine authentification robuste, chiffrement et simplicité opérationnelle.
FTP reste présent parce que l’informatique ne se remplace pas toujours d’un bloc. Des logiciels de gestion, des imprimantes multifonctions, des serveurs de vidéosurveillance, des solutions de paie ou des chaînes de production utilisent encore des transferts FTP. Certains systèmes n’acceptent pas facilement SFTP ou FTPS, soit par limitation technique, soit parce qu’ils n’ont pas été mis à jour depuis longtemps.
Ce phénomène explique pourquoi des protocoles plus récents peuvent cohabiter avec des technologies anciennes pendant des années. Le web a, lui aussi, évolué par couches successives, avec de nouveaux mécanismes destinés à améliorer la performance ou la sécurité. Le fonctionnement de QUIC, utilisé par HTTP/3, illustre bien cette volonté moderne de repenser les échanges réseau dès la conception, plutôt que d’ajouter des correctifs après coup.
Le cas de FTP rappelle une réalité importante : beaucoup de protocoles historiques ont été créés sans chiffrement systématique. DNS, HTTP, POP3 ou IMAP ont longtemps transmis des informations sensibles sans protection par défaut. La généralisation de TLS, du HTTPS et de solutions comme DNS over HTTPS répond à une prise de conscience progressive des risques liés à l’observation du trafic.
La protection des échanges ne concerne pas seulement les mots de passe. Les métadonnées, les noms de fichiers, les adresses IP ou la fréquence des connexions peuvent révéler des informations sensibles. Les débats autour de la confidentialité apportée par DNS over HTTPS montrent que le chiffrement est désormais envisagé comme une composante normale de l’architecture Internet, même lorsqu’il soulève aussi des questions de supervision et de gouvernance.
La première recommandation est simple : éviter FTP lorsque des identifiants ou des données sensibles sont en jeu. Pour un nouvel usage, mieux vaut choisir SFTP, FTPS ou une solution de stockage avec HTTPS. Si FTP reste indispensable pour des raisons de compatibilité, il devrait être limité à un réseau privé, protégé par un VPN, avec des comptes restreints et une surveillance régulière des accès.
Il faut aussi distinguer les risques selon les contextes. Un FTP anonyme servant à publier des fichiers publics n’a pas le même niveau de criticité qu’un transfert de données clients ou de sauvegardes. Dans les applications web, d’autres mécanismes encadrent les échanges entre origines, comme les règles CORS appliquées par les navigateurs, mais ils ne remplacent jamais le chiffrement du transport.
FTP n’est donc pas chiffré par défaut parce qu’il vient d’un Internet où la confiance précédait la menace. Son histoire montre combien les choix techniques initiaux pèsent longtemps. Aujourd’hui, la bonne pratique est claire : ne plus considérer FTP comme adapté aux échanges sensibles, sauf à l’encadrer strictement ou à le remplacer par une alternative sécurisée.
