Comprendre FTP, FTPS et SFTP pour choisir le bon protocole

FTP, FTPS et SFTP servent tous à transférer des fichiers, mais ils ne reposent pas sur la même logique. Les confondre peut créer des problèmes de sécurité, de pare-feu ou de compatibilité, surtout lorsqu’un accès serveur est ouvert à un prestataire, à un site web ou à une automatisation.

Pour approfondir ce point, consultez KeePass ou KeePassXC, choisir le bon coffre, qui traite plus précisément de keepass ou keepassxc, choisir le bon coffre pour vos mots de passe.

La règle simple est la suivante : FTP est le protocole historique, FTPS ajoute une couche TLS à FTP, et SFTP transfère les fichiers à travers SSH. Pour un usage moderne sur Internet, FTP seul n’est généralement plus un bon choix. La bonne question n’est donc pas “quel client graphique installer”, mais quel protocole correspond au niveau de risque, au serveur et au pare-feu que vous administrez.

Quelle différence entre FTP, FTPS et SFTP ?

FTP est un ancien protocole de transfert de fichiers. Il sépare les commandes et les données, ce qui explique certaines complications avec les pare-feu et les modes actif/passif. Surtout, FTP ne chiffre pas nativement les identifiants ni les fichiers : sur un réseau exposé, c’est une faiblesse majeure. Même si le fichier transféré semble banal, le mot de passe utilisé pour se connecter peut donner accès à un espace web, à des sauvegardes ou à des données plus sensibles.

FTPS conserve la base FTP, mais ajoute TLS pour protéger la connexion. Il peut être explicite, quand le client demande le chiffrement après connexion, ou implicite, quand le chiffrement est attendu dès le départ. Cette protection améliore la sécurité, mais ajoute une couche de gestion : certificats, ports, compatibilité client et configuration du mode passif.

SFTP fonctionne autrement. Malgré son nom, ce n’est pas “FTP sécurisé”. C’est un protocole de transfert de fichiers au-dessus de SSH. Dans la pratique, il utilise souvent le même accès que l’administration SSH du serveur, avec une authentification par mot de passe ou par clé. Cette architecture le rend souvent plus lisible côté réseau, car le flux passe dans un canal unique et déjà connu des administrateurs. Elle oblige en revanche à réfléchir aux droits accordés au compte SSH associé.

Pourquoi FTP seul pose problème aujourd’hui

Le problème principal de FTP est la transmission en clair. Les identifiants, les commandes et les fichiers peuvent être observés si le trafic traverse un réseau non fiable. Dans un contexte professionnel, ce risque est rarement acceptable, même pour des fichiers qui semblent peu sensibles.

Il existe aussi un problème d’exploitation. FTP utilise un canal de commande et un ou plusieurs canaux de données. Selon le mode actif ou passif, le serveur ou le client doit ouvrir des ports supplémentaires. Ce comportement peut compliquer la configuration des pare-feu, des NAT et des hébergements mutualisés. Lorsqu’un transfert échoue “au moment de lister le dossier”, la cause vient souvent de cette séparation entre connexion de contrôle et connexion de données.

FTP peut encore exister dans des environnements anciens, des automates, des scripts historiques ou des réseaux isolés. Dans ce cas, il faut le traiter comme une dette technique : documenter l’usage, restreindre l’accès et prévoir une alternative chiffrée.

FTPS : utile, mais plus exigeant à configurer

FTPS répond à une limite évidente de FTP : il chiffre la connexion avec TLS. C’est utile lorsqu’un partenaire impose un environnement FTP sécurisé ou lorsqu’une application métier ne sait pas parler SFTP. Dans ce cas, FTPS peut rester une solution sérieuse, à condition d’être configuré proprement. Il faut notamment savoir si l’organisation attend du FTPS explicite ou implicite, car le port et le comportement initial de la connexion ne seront pas les mêmes.

La difficulté vient de l’empilement. Vous gardez les mécanismes FTP, puis vous ajoutez TLS. Le serveur doit présenter un certificat valide, le client doit l’accepter, et le pare-feu doit laisser passer les ports nécessaires. Un FTPS mal réglé peut devenir pénible à diagnostiquer, notamment lorsque les transferts échouent seulement en mode passif.

Le bon réflexe est donc de documenter le mode FTPS utilisé, la plage de ports passifs, le certificat, le nom DNS attendu et les clients compatibles. Sans cette documentation, le protocole fonctionne parfois “sur le poste de quelqu’un” mais casse dès qu’un prestataire ou un serveur change.

SFTP : le choix le plus simple dans beaucoup de cas

SFTP est souvent préféré pour les accès serveur modernes, car il repose sur SSH. Cela permet de centraliser l’authentification, les droits, les journaux et les règles réseau autour d’un service déjà présent sur de nombreux serveurs Linux. Le transfert de fichiers passe dans une connexion chiffrée, sans multiplier les ports de données. Pour un petit site, un serveur de déploiement ou un NAS d’entreprise, cette simplicité réduit le nombre de réglages à maintenir dans la durée.

Cette simplicité ne dispense pas de sécuriser l’accès. Un compte SFTP doit avoir des droits limités, un répertoire de travail clair et, si possible, une authentification par clé. Pour un prestataire qui dépose des fichiers, évitez de lui donner un compte système trop large ou un accès SSH interactif inutile.

SFTP convient très bien aux déploiements web simples, aux échanges réguliers entre serveurs, aux sauvegardes contrôlées et aux scripts d’automatisation. Il devient moins adapté si votre partenaire impose explicitement FTPS ou si un équipement ancien ne sait gérer que FTP. Dans ce cas, la bonne approche consiste à isoler le cas legacy plutôt qu’à abaisser le niveau de sécurité de toute l’infrastructure.

Pour approfondir ce point, consultez protocole SMB, qui traite plus précisément de partager des fichiers avec smb sans fragiliser son réseau.

Ports, pare-feu et modes de connexion

Fixez les ports avant les tests, sinon chaque échec pousse à ouvrir trop largement le pare-feu.

Les ports sont souvent la source des confusions. FTP utilise traditionnellement le port 21 pour les commandes, puis des ports supplémentaires pour les données. FTPS peut utiliser le port 21 en mode explicite ou 990 en mode implicite, avec également une plage de ports passifs à prévoir. SFTP utilise généralement le port SSH, souvent le port 22.

Dans une entreprise, ce tableau doit être traduit en règle d’exploitation. Qui ouvre les ports ? Qui renouvelle le certificat ? Qui supprime l’accès d’un ancien prestataire ? Un protocole sécurisé peut rester risqué si la gestion des comptes est négligée. Le meilleur protocole sur le papier ne compense pas un compte partagé entre cinq personnes, un mot de passe jamais changé ou un répertoire accessible trop largement.

Quel protocole choisir en pratique ?

Pour un serveur web, un VPS, un NAS moderne ou un échange régulier avec une équipe technique, choisissez SFTP par défaut. Il est généralement plus simple à sécuriser, plus lisible pour les pare-feu et mieux intégré aux pratiques d’administration serveur. C’est aussi le choix le plus facile à expliquer à un prestataire : un hôte, un port SSH, un compte limité, une clé ou un mot de passe, puis un dossier de dépôt clairement défini.

Choisissez FTPS lorsqu’il existe une contrainte claire : partenaire qui l’exige, logiciel déjà validé, workflow historique ou conformité interne documentée. Dans ce cas, prenez le temps de tester le client, le certificat, le mode passif et les règles réseau avant de le considérer comme prêt pour la production. Ajoutez aussi un test depuis l’extérieur du réseau interne, car beaucoup de configurations FTPS fonctionnent localement puis échouent dès qu’un NAT, un proxy ou un pare-feu applicatif entre en jeu.

Gardez FTP uniquement pour des cas strictement encadrés. Si un outil ancien l’impose, limitez l’accès à un réseau privé ou à une adresse IP précise, créez un compte dédié et supprimez les droits inutiles. Le pire choix consiste à laisser un FTP ancien ouvert “parce qu’il a toujours fonctionné”.

Pour approfondir ce point, consultez Configurer FileZilla Server sans ouvrir une brèche, qui traite plus précisément de configurer filezilla server sans ouvrir une brèche dans le réseau.

Ne pas oublier la gestion des accès

Le protocole n’est qu’une partie de la sécurité. Un accès SFTP parfaitement chiffré reste problématique si le compte est partagé, si le mot de passe circule par e-mail ou si personne ne sait quand le supprimer. La vraie sécurité vient aussi de la durée de vie de l’accès, des permissions et de la traçabilité.

Pour un prestataire, créez un compte nominatif ou dédié à la mission, limitez-le au dossier utile et notez une date de fin. Pour un script, utilisez un compte technique séparé, avec une clé spécifique et des droits minimaux. Cette discipline évite de transformer un simple dépôt de fichiers en porte d’entrée durable sur le serveur.

Les erreurs fréquentes lors d’une migration

La première erreur consiste à remplacer FTP par SFTP sans revoir les droits. Si le compte SFTP peut lire tout le serveur, le chiffrement ne suffit pas. Le bon objectif est un accès limité au dossier nécessaire, avec des permissions cohérentes et une procédure de retrait des accès. Sur un site web, un compte destiné à déposer des images ne devrait pas pouvoir parcourir les fichiers de configuration ou les sauvegardes de base de données.

La deuxième erreur est de confondre FTPS et SFTP dans les paramètres d’un client. Un client configuré en SFTP ne parlera pas à un serveur FTPS, même si l’écran affiche “sécurisé”. Vérifiez le protocole exact, le port, le type d’authentification et le message d’erreur avant de modifier le pare-feu. Cette vérification simple évite de masquer une erreur de protocole derrière une fausse panne réseau.

La troisième erreur est d’oublier les scripts. Une migration réussie ne concerne pas seulement FileZilla ou un client graphique. Elle doit aussi couvrir les tâches cron, sauvegardes, exports métiers, dépôts automatiques et clés stockées dans des outils CI/CD.

Checklist avant de donner un accès fichier

• Créer un compte dédié pour chaque prestataire ou automatisation.
• Limiter le répertoire accessible au strict nécessaire.
• Choisir SFTP ou FTPS selon les contraintes réelles, pas selon une habitude.
• Tester l’envoi et la récupération depuis un réseau externe.
• Prévoir une date de fin pour les accès temporaires.
• Journaliser les transferts quand les fichiers ont une valeur métier ou de sécurité.
• Documenter les ports, la méthode d’authentification et le responsable de l’accès.

Un accès fichier engage toujours la sécurité du serveur, même lorsqu’il sert seulement à déposer quelques images.

Cette checklist paraît simple, mais elle évite la plupart des incidents courants : accès oublié, compte partagé, dépôt dans le mauvais dossier, script cassé après changement de protocole ou certificat expiré sans propriétaire identifié. Elle doit être relue à chaque nouveau prestataire, pas seulement lors de la première mise en place du serveur.

La bonne décision pour un débutant

Pour un débutant, le bon protocole est celui qui reste compréhensible six mois plus tard.

Si vous débutez et que vous administrez un site ou un serveur récent, partez sur SFTP. Vous aurez moins de ports à expliquer, une connexion chiffrée, une gestion cohérente avec SSH et une configuration plus facile à auditer. C’est le choix le plus lisible pour la majorité des usages modernes. Commencez avec un compte dédié, testez un dépôt et une suppression de fichier, puis verrouillez les droits avant de transmettre l’accès.

Si votre hébergeur ou votre partenaire parle uniquement FTPS, ce n’est pas forcément mauvais. Vérifiez simplement que le certificat est valide, que le mode passif est documenté et que le client utilisé est compatible. FTPS reste solide quand il est bien exploité, notamment dans les échanges interentreprises où les procédures, journaux et certificats sont déjà cadrés.

FTP, lui, doit devenir l’exception. Le conserver sans restriction revient à accepter un transfert non chiffré dans un monde où les accès serveur, les sauvegardes et les fichiers métier ont rarement vocation à circuler en clair.

Pour approfondir ce point, consultez digital workplace, qui traite plus précisément de digital workplace : choisir une stratégie utile avant les outils.